[asterisk-users] Alternative (?) ways to handle G.729 and annexb

[Michail Pappas]

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.-