static rtpmap entries are not shown in outbound invites
Hi, When I'm using late negotiation and in my dialplan do the following: <action application="export" data="codec_string=${ep_codec_string}"/> <action application="set" data="inherit_codec=true"/> (I also tried with absolute_codec_string instead of codec_string) Then the codecs (or more precisely said, the rtpmap lines) that are offered in the SDP of the A leg are not offered to the b-leg. Only the RTP payload numbers as defined by IANA are there in the media (m) header. For example: a-leg SDP in INVITE: m=audio 16864 RTP/AVP 18 101. a=rtpmap:18 G729/8000. a=rtpmap:101 telephone-event/8000. b-leg SDP in INVITE: m=audio 24148 RTP/AVP 18 101 13. a=rtpmap:101 telephone-event/8000. Is there a reason why FS removes the G729 rtpmap, even though I exported all into the codec_string chan var ? Now, this would normally be fine because G729 being 18 is a static rtpmap, but I have one endpoint that has the behavior that if I send an invite with RTP payload 18 and omit the rtpmap being G729, then it responds with a 183 session progress containing rtpmap G.729 (notice the dot) - this is wrong as far as I can tell. Apparently they respond with the correct G729 (without the dot) in their 183 sess progress if I include the rtpmap in my invite. I believe I read somewhere there was an option settable (on a sip profile?) that enables to always send all payloads as defined in the media (m) sdp header as a=rtpmap lines, but I cannot find the option anymore (or perhaps I'm mistaken and saw it somewhere else ?) Can someone help me with this ? Thanks & kind regards, Leon
verbose_sdp=true docs/ChangeLog: mod_sofia: apparently some sip device vendors did not read the RFC (who knew?) adding verbose_sdp=true var to add needless a= lines for standard iana codecs that explicitly do not require them (r:6c4f49a8) /b On Mar 4, 2011, at 12:06 PM, Leon de Rooij wrote:
Can someone help me with this ?
Hi Brian, Thanks, that works :-) I got one last question about sdp, would you know why chan var ep_codec_string isn't set after an incoming invite with the following sdp: v=0. o=FOOBAR 123456 654321 IN IP4 1.2.3.4. s=-. c=IN IP4 1.2.3.4. t=0 0. m=audio 22262 RTP/AVP 18 101. a=rtpmap:18 G729/8000/1. a=rtpmap:101 telephone-event/8000/1. a=fmtp:101 0-15. Can it be the trailing /1 (encoding parameters) on both rtpmaps ? - According to parse_rtpmap() in libsofia it should be parsed alright, but still, ep_codec_string gets filled when I receive an SDP like this (from another endpoint): v=0. o=BARFOO 20494030 20494030 IN IP4 4.3.2.1. s=-. c=IN IP4 4.3.2.1. t=0 0. m=audio 50000 RTP/AVP 18 100. a=rtpmap:18 G729/8000. a=sendrecv. a=ptime:20. a=rtpmap:100 telephone-event/8000. a=fmtp:100 0-15. (btw, I'm having inbound- and outbound-codec-prefs on the incoming profile set as: "G7221@32000h,G7221@16000h,G722,PCMA,PCMU,G729,GSM" and am doing inbound-late-negotiation="true") Thanks, Leon On Mar 4, 2011, at 7:09 PM, Brian West wrote:
verbose_sdp=true
docs/ChangeLog: mod_sofia: apparently some sip device vendors did not read the RFC (who knew?) adding verbose_sdp=true var to add needless a= lines for standard iana codecs that explicitly do not require them (r:6c4f49a8)
/b
On Mar 4, 2011, at 12:06 PM, Leon de Rooij wrote:
Can someone help me with this ?
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Can it be the trailing /1 (encoding parameters) on both rtpmaps ? - According to parse_rtpmap() in libsofia it should be parsed alright, but still, ep_codec_string gets filled when I receive an SDP like this (from another endpoint):
That means 1 channel (mono), which is the default. Although optional it is correct and *should* be handled fine... -Steve On 7 March 2011 13:59, Leon de Rooij <leon@scarlet-internet.nl> wrote:
Hi Brian,
Thanks, that works :-)
I got one last question about sdp, would you know why chan var ep_codec_string isn't set after an incoming invite with the following sdp:
v=0. o=FOOBAR 123456 654321 IN IP4 1.2.3.4. s=-. c=IN IP4 1.2.3.4. t=0 0. m=audio 22262 RTP/AVP 18 101. a=rtpmap:18 G729/8000/1. a=rtpmap:101 telephone-event/8000/1. a=fmtp:101 0-15.
Can it be the trailing /1 (encoding parameters) on both rtpmaps ? - According to parse_rtpmap() in libsofia it should be parsed alright, but still, ep_codec_string gets filled when I receive an SDP like this (from another endpoint):
v=0. o=BARFOO 20494030 20494030 IN IP4 4.3.2.1. s=-. c=IN IP4 4.3.2.1. t=0 0. m=audio 50000 RTP/AVP 18 100. a=rtpmap:18 G729/8000. a=sendrecv. a=ptime:20. a=rtpmap:100 telephone-event/8000. a=fmtp:100 0-15.
(btw, I'm having inbound- and outbound-codec-prefs on the incoming profile set as: "G7221@32000h,G7221@16000h,G722,PCMA,PCMU,G729,GSM" and am doing inbound-late-negotiation="true")
Thanks,
Leon
On Mar 4, 2011, at 7:09 PM, Brian West wrote:
verbose_sdp=true
docs/ChangeLog: mod_sofia: apparently some sip device vendors did not read the RFC (who knew?) adding verbose_sdp=true var to add needless a= lines for standard iana codecs that explicitly do not require them (r:6c4f49a8)
/b
On Mar 4, 2011, at 12:06 PM, Leon de Rooij wrote:
Can someone help me with this ?
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Hi Steven, Ah yes, I knew it meant mono. But I found the problem.. * The call that worked properly with G729/8000 was on a sip profile that had G729 allowed in inbound-codec-prefs * The call that didn't work was on a second profile that apparently didn't have G729 set for inbound-codec-prefs (I did specify it in the xml, but only did a reload on the profile which isn't sufficient - I should've restarted it -- doh) Thanks all & kind regards, Leon On Mar 7, 2011, at 6:57 PM, Steven Ayre wrote:
Can it be the trailing /1 (encoding parameters) on both rtpmaps ? - According to parse_rtpmap() in libsofia it should be parsed alright, but still, ep_codec_string gets filled when I receive an SDP like this (from another endpoint):
That means 1 channel (mono), which is the default. Although optional it is correct and *should* be handled fine...
-Steve
On 7 March 2011 13:59, Leon de Rooij <leon@scarlet-internet.nl> wrote:
Hi Brian,
Thanks, that works :-)
I got one last question about sdp, would you know why chan var ep_codec_string isn't set after an incoming invite with the following sdp:
v=0. o=FOOBAR 123456 654321 IN IP4 1.2.3.4. s=-. c=IN IP4 1.2.3.4. t=0 0. m=audio 22262 RTP/AVP 18 101. a=rtpmap:18 G729/8000/1. a=rtpmap:101 telephone-event/8000/1. a=fmtp:101 0-15.
Can it be the trailing /1 (encoding parameters) on both rtpmaps ? - According to parse_rtpmap() in libsofia it should be parsed alright, but still, ep_codec_string gets filled when I receive an SDP like this (from another endpoint):
v=0. o=BARFOO 20494030 20494030 IN IP4 4.3.2.1. s=-. c=IN IP4 4.3.2.1. t=0 0. m=audio 50000 RTP/AVP 18 100. a=rtpmap:18 G729/8000. a=sendrecv. a=ptime:20. a=rtpmap:100 telephone-event/8000. a=fmtp:100 0-15.
(btw, I'm having inbound- and outbound-codec-prefs on the incoming profile set as: "G7221@32000h,G7221@16000h,G722,PCMA,PCMU,G729,GSM" and am doing inbound-late-negotiation="true")
Thanks,
Leon
On Mar 4, 2011, at 7:09 PM, Brian West wrote:
verbose_sdp=true
docs/ChangeLog: mod_sofia: apparently some sip device vendors did not read the RFC (who knew?) adding verbose_sdp=true var to add needless a= lines for standard iana codecs that explicitly do not require them (r:6c4f49a8)
/b
On Mar 4, 2011, at 12:06 PM, Leon de Rooij wrote:
Can someone help me with this ?
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
participants (3)
-
Brian West
-
Leon de Rooij
-
Steven Ayre