Michail Pappas
2006-Jul-19 01:14 UTC
[asterisk-users] Alternative (?) ways to handle G.729 and annexb
Hello everybody, naive Asterisk user here, so please excuse my vast ignorance on the subject that follows. I would be more than happy to be corrected here, so implicitly an "AFAIK" is present in all of my sentences. :) As you (may already) know and AFAIK, G.729-enabled Asterisk responds to G.729 offers as follows: m=audio XXXX RTP/AVP X Y 18 Z ... a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no ... Notice that the response specifies essentially two things: 1) We concur to using codec 18 (G.729) and 2) We state we will not send and we are not willing to receive SID frames In a RFC context, the SDP answer above is correct, if the offer was something like this: m=audio YYYY RTP/AVP 18 K L Z ... a=rtpmap:18 G729/8000 a=mtp:18 annexb=no ... The problem here is that the other side might have sent an offer that implicitly (no reference to annexb=no) or explicitly (direct reference to annexb=yes) indicated Annex B behaviour. All the following are semantically equivalent according to Table 1 and Section 4.5.6 of STD0065 (RFC3551) and Section 4.1.9 of RFC3555: m=audio XXXX RTP/AVP X Y 18 Z ... <no reference to payload 18> ... -OR- m=audio XXXX RTP/AVP X Y 18 Z ... a=rtpmap:18 G729/8000 <No reference to fmtp:18 annexb=yes> ... -OR- m=audio XXXX RTP/AVP X Y 18 Z ... a=rtpmap:18 G729/8000 a=fmtp:18 annexb=yes ... In all the examples above, sender requests Annex B behaviour and will most likely send SID frames. Asterisk accepts the comms, but will drop (perhaps) SID frames. End result: worse voice quality. Thoughts so far: 1) Perhaps I'm totally wrong here, but shouldn't "18" in these last cases be dropped, since annexb behaviour is not supported by us -> an important characteristic of the codec offered is not supported by us, hence this is not an attribute that could be changed in asterisk's answer -> "18" should be dropped altogether in our response? 2) Quite a few clients out there do not send a=fmtp:18 annexb=no (a=fmtp:XX annexb=no), meaning they are Annex B capable, whereas they are not... This must be taken into account (current Asterisk implementation does not present any problems here, non-Annex-B comms will be established both ways) since in the future Asterisk might support Annex B as well... With these in mind, some criteria for a "robust" (it's a joke actually, since my knowledge is veeeery limited, so like I said please spare me :) ) G.729 implementation would be: 1) Best sound quality possible 2) Recognition of UAs at fault which are not sending annexb info Possible pcode for an Asterisk implementation with no Asterisk AnnexB functionality: for <all codetypes offered by UA in initial INVITE> if <codetype is "G729"> then if <exists(annexb) and annexb=no> then proceed with normal SDP parsing else drop codenumber which correspond to offered G729 if <this is the only codenumber offered> then respond with error code and terminate call exit endif // Note that AFAIK the UA can specify multiple codetypes for G729 // one for Annex B with annexb=yes, another for non-Annex-B, // with annexb=no select an unused (from both the offer and the answer) codenumber above 96 say ZZ // to isolate the case where the UA does not send annexb, even though // it is not annexb compliant, we are offering a new codepoint which in // in the answer's m SDP line would have the same priority as if // we accepted G.729 in the first place include in the response: a=rtpmap:ZZ G729/8000 a=fmtp:ZZ annexb=no endif endif endif end for <rest of code> send RE-invite to UA, specifying only: a=rtpmap:ZZ G729/8000 a=fmtp:ZZ annexb=no Sorry for not making sense, my English could be better. Any opinions, especially from developers would be kindly appreciated. Regards, M.-
Kevin P. Fleming
2006-Jul-31 12:48 UTC
[asterisk-users] Alternative (?) ways to handle G.729 and annexb
----- Michail Pappas <michail.pappas@gmail.com> wrote:> In all the examples above, sender requests Annex B behaviour and will > most likely send SID frames.And that would be incorrect behavior. What is listed in the SDP is what you want to _receive_; it has nothing (directly) to do with what you will send, that is dictated by the SDP provided by the other party.> 1) Perhaps I'm totally wrong here, but shouldn't "18" in these last > cases be dropped, since annexb behaviour is not supported by us -> an > important characteristic of the codec offered is not supported by us, > hence this is not an attribute that could be changed in asterisk's > answer -> "18" should be dropped altogether in our response?Uhh... no. The 'fmtp:18' is what ties that annexb=no line to the payload type '18' in the offer, rather than being associated with another payload type in the offer. -- Kevin P. Fleming Senior Software Engineer Digium, Inc.