Hello, I'm working on the following scenarios: scenario 1: A --> FS --> B scenario 2: C --> FS --> A Where A supports CN (a=rtpmap:13 CN/8000) and requires CN negotiation, and B and C do not support and aren't able to negotiate it. I successfully implemented scenario 1, CN is negotiated between A party and FS, and not negotiated between FS and B. But scenario 2 doesn't work for me! When C doesn't offer CN in INVITE towards FS, FS also doesn't offer CN in SDP in INVITE towards A. And nothing helps, tried all the combination of VAD options. Gateway A is in the same internal sip profile in both scenarios. This is the SDP in INVITE from C to FS: Media Description, name and address (m): audio 30224 RTP/AVP 0 8 18 101 Media Attribute (a): rtpmap:0 PCMU/8000 Media Attribute (a): rtpmap:8 PCMA/8000 Media Attribute (a): rtpmap:18 G729/8000 Media Attribute (a): fmtp:18 annexb=no Media Attribute (a): rtpmap:101 telephone-event/8000 Media Attribute (a): fmtp:101 0-16 Media Attribute (a): silenceSupp:off - - - - Media Attribute (a): ptime:20 Media Attribute (a): sendrecv And this is the SDP from FS towards A: Media Description, name and address (m): audio 23564 RTP/AVP 0 8 101 13 Media Attribute (a): rtpmap:101 telephone-event/8000 Media Attribute (a): fmtp:101 0-16 Media Attribute (a): ptime:20 FS even puts 13 in m= attribute, but doesn't add a= attribute for rtpmap:13. Is that a bug? -- Best Regards Alex Massover. This mail was sent via Mail-SeCure System.
if you set the var verbose_sdp=true globally in vars.xml or on a per_leg basis you will get the extra a= that some things mistakenly think are mandatory (like some older polycom firmwares) the goal is to make the sdp as small as possible to prevent going over the MTU On Thu, Aug 25, 2011 at 4:25 AM, Alex Massover <alex@jajah.com> wrote:
Hello,
I’m working on the following scenarios:
scenario 1: A à FS à B
scenario 2: C à FS à A
Where A supports CN (a=rtpmap:13 CN/8000) and requires CN negotiation, and B and C do not support and aren’t able to negotiate it.
I successfully implemented scenario 1, CN is negotiated between A party and FS, and not negotiated between FS and B.
But scenario 2 doesn’t work for me! When C doesn’t offer CN in INVITE towards FS, FS also doesn’t offer CN in SDP in INVITE towards A.
And nothing helps, tried all the combination of VAD options. Gateway A is in the same internal sip profile in both scenarios.
This is the SDP in INVITE from C to FS:
Media Description, name and address (m): audio 30224 RTP/AVP 0 8 18 101
Media Attribute (a): rtpmap:0 PCMU/8000
Media Attribute (a): rtpmap:8 PCMA/8000
Media Attribute (a): rtpmap:18 G729/8000
Media Attribute (a): fmtp:18 annexb=no
Media Attribute (a): rtpmap:101 telephone-event/8000
Media Attribute (a): fmtp:101 0-16
Media Attribute (a): silenceSupp:off - - - -
Media Attribute (a): ptime:20
Media Attribute (a): sendrecv
And this is the SDP from FS towards A:
Media Description, name and address (m): audio 23564 RTP/AVP 0 8 101 13
Media Attribute (a): rtpmap:101 telephone-event/8000
Media Attribute (a): fmtp:101 0-16
Media Attribute (a): ptime:20
FS even puts 13 in m= attribute, but doesn’t add a= attribute for rtpmap:13.
Is that a bug?
--
Best Regards
Alex Massover.
This mail was sent via Mail-SeCure System.
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
-- Anthony Minessale II FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ Twitter: http://twitter.com/FreeSWITCH_wire AIM: anthm MSN:anthony_minessale@hotmail.com GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org googletalk:conf+888@conference.freeswitch.org pstn:+19193869900
Hello, That's great, if the other party's stack is not happy without a=, I'll turn on the variable. Many thanks!
-----Original Message----- From: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch- users-bounces@lists.freeswitch.org] On Behalf Of Anthony Minessale Sent: יום ה 25 אוגוסט 2011 19:31 To: FreeSWITCH Users Help Subject: Re: [Freeswitch-users] Forcing CN offer
if you set the var verbose_sdp=true globally in vars.xml or on a per_leg basis you will get the extra a= that some things mistakenly think are mandatory (like some older polycom firmwares) the goal is to make the sdp as small as possible to prevent going over the MTU
On Thu, Aug 25, 2011 at 4:25 AM, Alex Massover <alex@jajah.com> wrote:
Hello,
I’m working on the following scenarios:
scenario 1: A à FS à B
scenario 2: C à FS à A
Where A supports CN (a=rtpmap:13 CN/8000) and requires CN negotiation, and B and C do not support and aren’t able to negotiate it.
I successfully implemented scenario 1, CN is negotiated between A party and FS, and not negotiated between FS and B.
But scenario 2 doesn’t work for me! When C doesn’t offer CN in INVITE towards FS, FS also doesn’t offer CN in SDP in INVITE towards A.
And nothing helps, tried all the combination of VAD options. Gateway A is in the same internal sip profile in both scenarios.
This is the SDP in INVITE from C to FS:
Media Description, name and address (m): audio 30224 RTP/AVP 0 8 18 101
Media Attribute (a): rtpmap:0 PCMU/8000
Media Attribute (a): rtpmap:8 PCMA/8000
Media Attribute (a): rtpmap:18 G729/8000
Media Attribute (a): fmtp:18 annexb=no
Media Attribute (a): rtpmap:101 telephone-event/8000
Media Attribute (a): fmtp:101 0-16
Media Attribute (a): silenceSupp:off - - - -
Media Attribute (a): ptime:20
Media Attribute (a): sendrecv
And this is the SDP from FS towards A:
Media Description, name and address (m): audio 23564 RTP/AVP 0 8 101 13
Media Attribute (a): rtpmap:101 telephone-event/8000
Media Attribute (a): fmtp:101 0-16
Media Attribute (a): ptime:20
FS even puts 13 in m= attribute, but doesn’t add a= attribute for rtpmap:13.
Is that a bug?
--
Best Regards
Alex Massover.
This mail was sent via Mail-SeCure System.
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
-- Anthony Minessale II
FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ Twitter: http://twitter.com/FreeSWITCH_wire
AIM: anthm MSN:anthony_minessale@hotmail.com GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com IRC: irc.freenode.net #freeswitch
FreeSWITCH Developer Conference sip:888@conference.freeswitch.org googletalk:conf+888@conference.freeswitch.org pstn:+19193869900
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
This mail was received via Mail-SeCure System.
This mail was sent via Mail-SeCure System.
participants (2)
-
Alex Massover
-
Anthony Minessale