|
I'm also interested in this, as the other Steve knows. Anyone in the re-worked jitter-buffer/PLC/DTX crowd besides me going to be at astricon? We can at least start working there on requirements. I think I've wrote this before, but here's what I'd _really_ like to see as requirements for a re-worked jitter-buffer: - Channel Support: IAX2 in asterisk IAX2 in libiax2 Other IP channels in asterisk (RTP-based ones, I guess are all that is left). - DTX Support: Sending a single CN packet (in IAX2, this should probably be sent reliably) would probably be good. - PLC Support: For codecs that support this natively, use that support (iLBC, speex, others). For those that don't, we can add some kind of hack to the codec. For example, in app_conference, I repeat even GSM frames when I detect loss. - Configurability by applications: It seems that some applications (app_fax) might do better without any of this; we should consider what different applications may want to configure in their use of this, and allow them to change settings while the channel is in the application. So, app_fax might want to disable PLC, and also disable any jitter-buffer shrinkage (and dropped frames that it would cause). - For IAX2 (and RTP, I think) Interleaved frame support: For single-channel calls, in IAX2, and a compressed codec, you have about 100% overhead with 20ms frames. Using larger frame sizes of course drops this considerably, but without interleaving, it makes PLC much less effective. Using interleaved frames, where in a single packet you have, for example Packet 1, frame 0,2 Packet 2, frame 1,3 Packet 3, frame 4,6 [...] And PLC, means that if you drop packet 2, you can do a much better job concealing that loss. -SteveK [EMAIL PROTECTED] wrote: On Fri, 27 Aug 2004, Michael Manousos wrote: |
_______________________________________________ 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
