[Asterisk-Users] PLC (Packet loss cancel) questions

[Steve Kann]

On Aug 31, 2004, at 8:42 AM, Steve Underwood wrote:

> Chris Shaw wrote:
>
>>> - Channel Support:
>>>   IAX2 in asterisk
>>>   IAX2 in libiax2
>>>  Other IP channels in asterisk (RTP-based ones, I guess are all that 
>>> is
>>>
>> left).
>>
>> CNG/VAD and DTX in SIP is a must if * is to be taken seriously as a 
>> complete
>> solution... As much as we all hate it's complexity and wish that 
>> everything
>> would speak IAX (I know I do) a large number of devices support (and 
>> will be
>> supporting) SIP, making it equally as important as IAX2  in using * 
>> as a
>> complete telephony solution...
>>
> This is nothing to do with SIP. It is an RTP issue, common to 
> everything which uses RTP - SIP and H.323 included. Sending no packets 
> is perfectly valid, and normal, in RTP. If the receiving end takes no 
> packets (other than, perhaps, an extremely long silence) as a 
> disconnect it does not comply with the RTP spec. DTX is much despised, 
> and CNG only slightly better. They just sound good (pun intende) on 
> paper.

They make a big difference in conferences, actually;  In a big 
conference, you generally have just zero to 2 speakers at any time, and 
many many calls that are not transmitting.  In this case, it is 
wasteful of all kinds of resources for these clients to transmit 
anything.   Not just bandwidth, but also processing in your mixer.

We currently have deployed app_conference (sources with iaxclient), 
which depends on iaxclient's ability to do DTX transmission in order to 
be scalable.



>>> DTX Support:  Sending a single CN packet (in IAX2, this should 
>>> probably
>>> sent reliably)  would probably be good.
>>>
>>
>> I second, third and fourth this one as does anyone who's tried to use
>> BroadVoice with Voicemail... Currently when * is not making any noise 
>> (e.g.
>> recording) absolutely NO packets are sent back to the proxy... A lot 
>> of
>> proxies take this as a sign that the far end has disconnected... 
>> Including
>> BroadWorks! But they do recognize small CN packets as a sign that the 
>> SIP
>> device (Asterisk) is still there...
>>
> A lot of CNG spec. call for only one transmission, and then silence. 
> Continued CNG has real benefits, but it certainly not the norm.
>
>> PLC I think is somewhat implemented already in codecs that support 
>> it, but I
>> could be wrong, I remember seeing mention of it in the code...
>>
> PLC is seldom included in the codecs. If you read the specs they often 
> mention PLC, but only in terms of how the codec mitigates the 
> awfulness of a lost packet. Few codecs actually include it.

iLBC and speex both include it.  Speex' PLC is triggered by simply 
passing in NULL instead of a pointer to compressed audio.  It will then 
generate a predicted frame without any information:  I imagine it 
basically continues the energy transmission of previous packets.

app_conference currently emulates PLC for GSM or by sending the GSM 
decoder the previous packet (it only does this if it's sucessfully 
gotten a few packets in a row).  This isn't just something that looks 
good on paper, but something that significantly improves the quality of 
conversations in practice.  (although, in this practice, the lost 
packets are just as often artifacts of scheduling issues and the 
present jitter buffer as they are from actual network loss).

PLC is also really important when using a dynamic jitter buffer, 
because whenever the jitter buffer wants to grow, PLC can hide the 
sparse frames.  While the current jitter buffer will just give you a 
big gap, ideally, if you're growing, you'd be able to spread the gaps a 
bit, and use PLC to hide them.  For example, if you have 100ms worth of 
frames already queued, and you need to grow the jitterbuffer to 180ms, 
you'd intersperse the 80ms gaps into 20ms (or whatever) size gaps, and 
use PLC to interpolate them.  This would be much less noticable than an 
80ms dropout in audio.


-SteveK