Freeswitch SDP manipulation with dynamic payload types
Hello all Here is our ingress SDP to freeSWITCH (partial text only) m=audio 40000 RTP/AVP 97 96 98 a=rtpmap:97 G.729b/8000 a=rtpmap:96 G.729ab/8000 a=rtpmap:98 G.729a/8000 and this is the egress from FS m=audio 20788 RTP/AVP 18 101 13 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 Notice that FS is substituting the G729 flavors with just 18 in the outgoing SDP. Can we have the same codecs offered in the outgoing SDP as well ? --Ashwin
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. 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. 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. -Steve On Thursday, June 6, 2013, Ashwin Rath wrote:
Hello all
Here is our ingress SDP to freeSWITCH (partial text only)
m=audio 40000 RTP/AVP 97 96 98
a=rtpmap:97 G.729b/8000
a=rtpmap:96 G.729ab/8000
a=rtpmap:98 G.729a/8000
and this is the egress from FS
m=audio 20788 RTP/AVP 18 101 13
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
Notice that FS is substituting the G729 flavors with just 18 in the outgoing SDP.
Can we have the same codecs offered in the outgoing SDP as well ?
--Ashwin
participants (2)
-
Ashwin Rath
-
Steven Ayre