Kevin Walsh wrote:
[EMAIL PROTECTED] 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.
_______________________________________________
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
