Kevin Walsh wrote:
Michael Manousos [EMAIL PROTECTED] 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.
_______________________________________________
Asterisk-Users mailing list
[EMAIL PROTECTED]
http://lists.digium.com/mailman/listinfo/asterisk-users
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
