On Aug 31, 2004, at 8:42 AM, Steve Underwood wrote:
Chris Shaw wrote:
This is nothing to do with SIP. It is an RTP issue, common to everything which uses RTP - SIP and H.323 included. Sending no packets is perfectly valid, and normal, in RTP. If the receiving end takes no packets (other than, perhaps, an extremely long silence) as a disconnect it does not comply with the RTP spec. DTX is much despised, and CNG only slightly better. They just sound good (pun intende) on paper.- Channel Support:
IAX2 in asterisk
IAX2 in libiax2
Other IP channels in asterisk (RTP-based ones, I guess are all that is
left).
CNG/VAD and DTX in SIP is a must if * is to be taken seriously as a complete
solution... As much as we all hate it's complexity and wish that everything
would speak IAX (I know I do) a large number of devices support (and will be
supporting) SIP, making it equally as important as IAX2 in using * as a
complete telephony solution...
They make a big difference in conferences, actually; In a big conference, you generally have just zero to 2 speakers at any time, and many many calls that are not transmitting. In this case, it is wasteful of all kinds of resources for these clients to transmit anything. Not just bandwidth, but also processing in your mixer.
We currently have deployed app_conference (sources with iaxclient), which depends on iaxclient's ability to do DTX transmission in order to be scalable.
A lot of CNG spec. call for only one transmission, and then silence. Continued CNG has real benefits, but it certainly not the norm.DTX Support: Sending a single CN packet (in IAX2, this should probably
sent reliably) would probably be good.
I second, third and fourth this one as does anyone who's tried to use
BroadVoice with Voicemail... Currently when * is not making any noise (e.g.
recording) absolutely NO packets are sent back to the proxy... A lot of
proxies take this as a sign that the far end has disconnected... Including
BroadWorks! But they do recognize small CN packets as a sign that the SIP
device (Asterisk) is still there...
PLC I think is somewhat implemented already in codecs that support it, but IPLC is seldom included in the codecs. If you read the specs they often mention PLC, but only in terms of how the codec mitigates the awfulness of a lost packet. Few codecs actually include it.
could be wrong, I remember seeing mention of it in the code...
iLBC and speex both include it. Speex' PLC is triggered by simply passing in NULL instead of a pointer to compressed audio. It will then generate a predicted frame without any information: I imagine it basically continues the energy transmission of previous packets.
app_conference currently emulates PLC for GSM or by sending the GSM decoder the previous packet (it only does this if it's sucessfully gotten a few packets in a row). This isn't just something that looks good on paper, but something that significantly improves the quality of conversations in practice. (although, in this practice, the lost packets are just as often artifacts of scheduling issues and the present jitter buffer as they are from actual network loss).
PLC is also really important when using a dynamic jitter buffer, because whenever the jitter buffer wants to grow, PLC can hide the sparse frames. While the current jitter buffer will just give you a big gap, ideally, if you're growing, you'd be able to spread the gaps a bit, and use PLC to hide them. For example, if you have 100ms worth of frames already queued, and you need to grow the jitterbuffer to 180ms, you'd intersperse the 80ms gaps into 20ms (or whatever) size gaps, and use PLC to interpolate them. This would be much less noticable than an 80ms dropout in audio.
-SteveK
_______________________________________________ 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
