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.