Fix increasing audio delay for WebRTC calls

[hrosa]

The latency level keeps increasing for WebRTC calls.

https://groups.google.com/forum/#!msg/mozilla.dev.media/tkxeLEnBK9M/_4TMgrCShtMJ

[ivelin]

@hrosa Any useful findings from the webrtc diagnostics tools we discussed?

[hrosa]

@ivelin https://github.com/webrtc/testrtc is our best candidate. I opened an issue to wire integrate it in Olympus so we can have a proper tool to measure call quality.

[hrosa]

After disabling RTCP from Mobicents MS I noticed that the RTT kept increasing on Chrome.
This ruled out malformed RTCP from list of possible causes, so I turned my attention to STUN.

Looking at the Wireshark trace, I noticed how Mobicents MS takes increasingly more time to reply to the STUN requests. This matches the information on Chrome's log where the RTT is measured accordingly to the STUN pings.

[hrosa]

I believe I know what is the problem with the audio delay in WebRTC calls.

So, Chrome sends two streams of packets over the same port at different rates: RTP each 20ms and STUN each 400ms.

The Media Server's Scheduler was designed on top of RTP 20ms golden rule, so from the logs I noticed that the UDP Manager invokes the receive() method each 20ms (this means we receive one packet each 20ms, either RTP or STUN).

Now let’s assume this example, representing a sample of the stream coming from chrome:
packet 1 - time=2.310, RTP
packet 2 - time=2.330, RTP
packet 3 - time=2.350, RTP
packet 4 - time=2.370, RTP
packet 5 - time=2.382, STUN
packet 6 - time=2.390, RTP

Notice how the interval between packets 4 and 5 is 12ms, and how interval between packets 5 and 6 is 8ms. This breaks the 20ms rule and that's how the congestion starts pilling up on the MS side.

Based in the last 3 packets we can make the following analysis: "in the interval of 40ms, Chrome sends 3 packets (2 RTP, 1 STUN). In the same interval, Mobicents MS only receives 2 (1 RTP, 1 STUN). So, we add 20ms latency because the 3rd packet will only be received after 20 ms."

...and so on until we end up with latency in the order of n seconds.

[hrosa]

I will have to untie the UdpManager from the Scheduler, so that the UDP manager reads from the sockets continuously and not at a 20ms rate.