Hi, Sorry, the RFC says that a= is not mandatory, m= is enough. I was just confused why FS in some scenario puts it and in other doesn’t, despite using only G711@8000. From: Alex Massover Sent: יום ה 25 אוגוסט 2011 12:26 To: 'freeswitch-users@lists.freeswitch.org' Subject: Forcing CN offer 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.