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

[Michael Manousos]

Kevin Walsh wrote:
> matt.riddell at sineapps.com wrote:
> 
>>On 27 Aug 2004 at 2:33, Kevin Walsh wrote:
>>
>>>There is no packet loss concealment in Asterisk at this time.
>>>
>>
>>Why doesn't asterisk clock to the 1000 interrupts per second instead
>>of the incoming audio?  Were there no interrupts available when it
>>started?  Even if you had no card you could use the ztdummy module
>>and even though that might be off by a bit, surely it'd sound better
>>than a connection which is experiencing packet loss?
>>
> 
> I'm note sure what you're referring to with the "1000 interrupts per
> second."  Asterisk, as it stands, only reacts to incoming frames.
> If nothing is received then nothing is sent.  The authors obviously
> didn't take packet loss into consideration.
> 
> When a packet is received, the expected time of the next packet is
> calculated.  A while ago, I proposed that some sort of "empty frame"
> frame could be scheduled for "now + next ETA".  The "arrival" of the
> empty frame would wake up the receiver and, with the help of the
> jitter buffer, it could determine whether to pass on that frame to the
> translator, or to drop the packet as a "duplicate".  Some codecs could
> recognise the empty frame as a trigger to run their perform packet loss
> concealment code, whereas others (with no PLC) could simply treat it as
> a silent frame.

This approach also is not fully right. On a system that implements
silence suppression and uses discontinuous transmission (DTX), the
receiver has a very tough job. I know that the current implementation
of Asterisk doesn't work well with silence suppression but this doesn't
mean that the design of a solution shouldn't take into account the full
scenario.

Look at the RTP stack of the receiver. When a packet is received, there
are two cases:

a) An RTP packet carrying voice frames is received. In that case the
decoder will play the voice frames.
b) A CN (Comfort Noise) packet is received. In that case the decoder
will generate background noise (or do nothing).

Now the hard part. Nothing is received (while something was expected).
These are the normal interpretations of this situation:

a) The transmitter detected silence and sent nothing (Silence).
The receiver knows it from the last packet received (a CN packet).
b) The transmitter sent a packet but the packet was lost (Packet loss).
The receiver knows it from the last packet received (an RTP packet).

These conditions can be identified at the RTP stack and signalled to
Asterisk through the use of a new frame type (as you propose above).
But, of course these are not always correct and the following situations
could also happen:

a) The transmitter detected silence and sent nothing but the last CN
packet was lost. According to the above interpretations, the receiver
will try to conseal a packet loss, which is wrong.
b) The transmitter sent an RTP packet, that packet was lost and the last
packet correctly received at the receiver was a CN packet. Again,
following the above interpretation, the receiver will do nothing (or
more accurate, will play some background noise), while it should
conseal the packet loss.

These cases cannot be identified, so the receiver just can only guess
about what really happened and act accordingly.

> 
> This all seems possible to me, but I haven't seen a discussion relating
> to this proposal nor any other alternatives.

I hope that the above issues will start a discussion and result to a
solution, no just for PLC, but also for the DTX operation.

[deleted]


Michael.