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

[Kevin Walsh]

Michael Manousos [manousos at inaccessnetworks.com] wrote:
> 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).
>
Agreed.

> 
> 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).
>
Both of the above cases are identifiable using a line state flag.
Asterisk can (a) continue to generate CN or (b) generate a new frame
type to get the codec to handle the concealment - where possible.

> 
> 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.
>
I would propose that after x lost packets, Asterisk should treat
all further lost packets as CN.  The proceeding x packets should be
interpreted as RTP packet loss and run through the concealment routine.

>
> 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. 
>
In this case, there is nothing to conceal anyway, as the last received
data was a CN packet.  In this case, the CN state should be continued
until an RTP packet is received and the line state can be changed.

The difficult part to handle would be late or out-of-sequence RTP
packets.  These should be ironed out by the jitter buffer.  Late,
lost and juggled packets are to be expected when dealing with UDP.

> > 
> > 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.
> 
I hope so too.  Asterisk would benefit greatly from these improvements.

-- 
   _/   _/  _/_/_/_/  _/    _/  _/_/_/  _/    _/
  _/_/_/   _/_/      _/    _/    _/    _/_/  _/   K e v i n   W a l s h
 _/ _/    _/          _/ _/     _/    _/  _/_/    kevin at cursor.biz
_/   _/  _/_/_/_/      _/    _/_/_/  _/    _/