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

[Michael Manousos]

Kevin Walsh wrote:
> 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.

Well, no matter what kind of concealment algorithm is used, just the
first one or two packets will be concealed. The rest losses will result
in no-playback. No CN interpretation, just absolute silence.

> 
> 
>>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.

Exactly. So the receiver, in case of no-receiption, should go back and
see what was the last packet correctly received and act as I described
above.

> 
> The difficult part to handle would be late or out-of-sequence RTP

Actually this is not so difficult, if there is a jitter buffer.

> 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.
> 


Michael.