Those are not valid names for G729. Your device is broken in sending them in that manner, but FS is able to recognise it and work around it it seems.<div><br></div><div>Annex A is an alternative encoding method. Lower CPU usage. The other side does not need to know because the output is compatible with the standard G729 decoder.</div>
<div><br></div><div>Annex B (silence compression) is indicated by a annexb=yes flag. Not through the codec name. Again the output can be decoded by a client not supporting annexb so the same name is used and you only send the flag to request the other side does or does not do silence compression.<span></span></div>
<div><br></div><div>-Steve<br><div><br></div><div><br></div><div><br><br>On Thursday, June 6, 2013, Ashwin Rath  wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div><div><div>Hello all<br><br></div>Here is our ingress SDP to freeSWITCH (partial text only)<br><br><p><span lang="EN-US">m=audio
40000 RTP/AVP 97 96 98</span></p>

<p><span lang="EN-US">a=rtpmap:97
G.729b/8000</span></p>

<p><span lang="EN-US">a=rtpmap:96
G.729ab/8000</span></p>

<p><span lang="EN-US">a=rtpmap:98
G.729a/8000</span></p><br>and this is the egress from FS<br><br>

<p><span lang="EN-US">m=audio
20788 RTP/AVP 18 101 13</span></p>

<p><span lang="EN-US">a=rtpmap:101
telephone-event/8000</span></p>

<p><span lang="EN-US">a=fmtp:101
0-16</span></p><br><br></div>Notice that FS is substituting the G729 flavors with just 18 in the outgoing SDP.<br><br></div>Can we have the same codecs offered in the outgoing SDP as well ?<br><br> <br><div><div><div><p>

<span lang="EN-US"></span></p><br></div><div>--Ashwin<br></div></div></div></div>
</blockquote></div></div>