[asterisk-dev] Pinefool: Poor man's PLC

[Olle E. Johansson]

Hi!

We see a lot of issues in the RTP streams when bridging two sip calls in Asterisk. If there's packet loss coming in, it's the same going out - but in this case the sequence numbers doesn't indicate packet loss. This causes issues with recordings sounding bad and possibly other issues since we have quite long phone calls.

Investigating the PLC in Asterisk, according to Malcolm's wiki article there has to be a core bridge with transcoding and a jitter buffer. That won't work for us.

Looking into the RTP channel, where I've spent some time recently, I notice that we don't bother checking that packets are sequential, so the RTP channel doesn't bother with packet loss much. That needed to change.

I created a very simple PLC in the RTP channel for the incoming stream, following these principles:

- If there is packet loss, resend the previous packet. We discover this at the next packet, so we introduce two frames at once. In most cases with small packet loss, the receiving end will sort this out in the jitter buffer. 
- If there is packet reordering, a jitter causing a packet to arrive too late, we ignore that packet since we've already replaced it
  with another one.

Normally PLC would work hand-in-hand with a jitter buffer so we first reorder incoming RTP packets, then add the missing ones. In this case, I can't afford introducing extra delay caused by a jitter buffer, so I needed a poor man's implementation. It will add a bit of CPU, copying frames that wasn't done previously, but it is not a massive amount of operations - unless you have a really poor connection. In that case, audio will be lost anyway and there's nothing much we can do to save the situation.

How does it work?
================
- If we receive packets 2,3,5 - we will send 2,3,3,5 into the bridge, making sure that we get no skew.
- If we receive 2,3,5,4 we will send 2,3,3,5 and throw away #4.

In both cases, the extra "3" will be sent at the same time as the "5" into the bridge.

Looking at wireshark on the other side of the call, the outbound stream now looks better. Of course, there's jitter but no packet loss in the stream, we still have all expected frames - for Alaw 50 RTP frames per second. Without this PLC we could get 45 and the playback of a recording would sound "fast" - Donald Duckish... :-)

It is a small hack compared with other RTP hacks I've worked with recently- the DTMF length, Comfort Noise and others. But it does make the audio better in case of bad incoming streams.

Please test!

http://svn.digium.com/svn/asterisk/team/group/pinefool-poor-mans-plc-1.4
http://svn.digium.com/svn/asterisk/team/oej/pinefool-poor-mans-plc-1.8

There's also a soup of the day branch with a larger set of patches combined:
- PLC
- Comfort Noise support
- DTMF
- PRACK
- RTCP improvements 

http://svn.digium.com/svn/asterisk/team/oej/pinetestedition-1.8
Look at the patches and the README files in the /patches directory of that branch for more information.

Thank you for your tests and feedback! 
I could have missed some serious issues or a cool trick we could add while working with this.

/O