VoIP Mailing List Archives

[ivdreg at gmail.com]

Hi all,

Can I ask 2 questions about codec negotiation:

1. Is it possible Freeswitch to work negotiate codecs between two phones as it is described below.
INVITE from A with some codecs in SDP ---> Freeswitch rewrites codec preference according absolute_codec_string but exclude all codecs not offered by A ----> INVITE to B with rewrited SDP.

example:
from A SDP:PCMA,PCMU,SPEEX ----> absolute_codec_string=G722,PCMU,PCMA,GSM ----> to B SDP: PCMU,PCMA

2. Can I get codec list in INVITE with mod_perl for example or via xml_curl without processing SDP variable (switch_r_sdp). It will be useful to be in format that absolute_codec_string variable takes.

Thanks

[anthony.minessale at g...]

the entire sdp is available as a variable (route the call to the info app to see the variables)
so if you have inbound-late-negotiation set to true on the sip profile
then you can use a regex or a script to set absolute_codec string before you answer.


On Thu, Feb 12, 2009 at 8:06 AM, ivdreg ivdreg <ivdreg@gmail.com (ivdreg@gmail.com)> wrote:

[ivdreg at gmail.com]

Hi Anthony,

Excuse me if I'm wrong but inbound-late-negotiation must be used proxy_media as I see in documentation. I don't want to proxy media because of some issues with MOH or 3-way conferencing. Also I want to exclude media codecs that are supported only in pass-trough mode. Let mi give you an example:

SDP from caller

v=0
o=- 1 2 IN IP4 192.168.20.193
s=CounterPath eyeBeam 1.5
c=IN IP4 192.168.40.81
t=0 0
m=audio 56888 RTP/AVP 100 106 97 105 98 3 101
a=fmtp:101 0-15
a=rtpmap:100 SPEEX/16000
a=rtpmap:106 SPEEX-FEC/16000
a=rtpmap:97 SPEEX/8000
a=rtpmap:105 SPEEX-FEC/8000
a=rtpmap:98 iLBC/8000
a=rtpmap:101 telephone-event/8000
a=sendrecv
a=x-rtp-session-id:61940567309B49E8909127E1393A966E
m=video 46378 RTP/AVP 125 115 34
a=fmtp:125 profile-level-id=42e015; max-br=4000; max-mbps=19800
a=fmtp:115 QCIF=1 MAXBR=4520
a=fmtp:34 QCIF=1 MAXBR=4520
a=rtpmap:125 H264/90000
a=rtpmap:115 H263-1998/90000
a=rtpmap:34 H263/90000
a=sendrecv
a=x-rtp-session-id:E8244E608F65445BA183BBE641C5DF3C
a=nortpproxy:yes

SDP from Freeswitch to called

v=0
o=FreeSWITCH 6228154995644782318 4633980766357417433 IN IP4 10.10.10.10
s=FreeSWITCH
c=IN IP4 10.10.10.10
t=0 0
m=audio 26920 RTP/AVP 3 101 13
a=rtpmap:3 GSM/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=rtpmap:13 CN/8000
a=ptime:20

So we offer only first in codec preference list

from called wich is normal receives
SIP/2.0 488 Not Acceptable Here
called suports - PCMA,PCMU,iLBC

Codec preference to this vars.xml we have witch is used in provile:
<X-PRE-PROCESS cmd="set" data="all_codec_prefs=GSM,speex@32000h@20i,speex@16000h@20i,speex@8000h@20i,iLBC@30i,PCMA,PCMU,G729"/>
also we have in profile:
<param name="inbound-codec-negotiation" value="greedy"/>
<param name="disable-transcoding" value="true"/>
In dialplan I've set:
<action application="set" data="inbound-late-negotiation"/>
<action application="set" data="inherit_codec=true"/>

About my second question:
Why I should parse variable_switch_r_sdp: [v=0
o=- 6 2 IN IP4 192.168.20.193
s=CounterPath eyeBeam 1.5
c=IN IP4 192.168.40.81
t=0 0
m=audio 60642 RTP/AVP 100 106 97 105 98 3 101
a=rtpmap:100 SPEEX/16000
a=rtpmap:106 SPEEX-FEC/16000
a=rtpmap:97 SPEEX/8000
a=rtpmap:105 SPEEX-FEC/8000
a=rtpmap:98 iLBC/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=x-rtp-session-id:0674790128EB43ACB8C7F55829BCFF14
m=video 44938 RTP/AVP 125 115 34
a=rtpmap:125 H264/90000
a=fmtp:125 profile-level-id=42e015; max-br=4000; max-mbps=19800
a=rtpmap:115 H263-1998/90000
a=fmtp:115 QCIF=1 MAXBR=4520
a=rtpmap:34 H263/90000
a=fmtp:34 QCIF=1 MAXBR=4520
a=x-rtp-session-id:D1EAE543055746AC9C03006B91ADE6DF
a=nortpproxy:yes
]
In FS core this parse is already done I'm sure in much more intelligent way. It can be exported as a variable like a absolute codec string I think.

Thanks again.

2009/2/12 Anthony Minessale <anthony.minessale@gmail.com (anthony.minessale@gmail.com)>

[anthony.minessale at g...]

yes you are wrong.

inbound-late-negotiation setting delays the codec negotiation until the instant audio is needed.
It is not tied to inbound-proxy-media.


This allows the call to come into the dialplan before any codec negotiation is done giving you a chance to look at the SDP before the negotiation takes place and insert an absolute_codec string essentially letting you chose unique codec preferences per inbound call.

[ivdreg at gmail.com]

Hi Anthony,

I'm not sure that you understood the problem. As it shown bellow the offered codec in leg B contains only one codec (first matched in codec preference list for this profile). Is there way to offer in leg B not only first codec but all codecs that exists in INVITE in leg A that matches codec preference list. If not is the only way is to parse SDP and set absolute_codec_string manualy?

Regards

2009/2/13 Anthony Minessale <anthony.minessale@gmail.com (anthony.minessale@gmail.com)>

[anthony.minessale at g...]

As i have already answered, no, it does not do what you want automaticly, the only way to influence codec negotiation is the way i have described.

parsing the sdp string allows you to set absolute_codec_string going both ways.
if you set it before you answer the channel with late negotiation enabled it will influence the codecs accepted on the inbound call.
it you set it on the b leg either by using export instead of set on the a leg or putting it in {} in the dial string it controlls what codecs are offered in the outbound invite.




On Fri, Feb 13, 2009 at 10:50 AM, ivdreg ivdreg <ivdreg@gmail.com (ivdreg@gmail.com)> wrote:

[ivdreg at gmail.com]

Hi Antony,

Can you tell me why you do codec negotiation like that. I'm just curious. If you do not have time do not reply me.

Thanks a lot for your help.

2009/2/13 Anthony Minessale <anthony.minessale@gmail.com (anthony.minessale@gmail.com)>

[anthony.minessale at g...]

Do it like what?

you are using FS as a b2bua, the default behavior is to make a list of codecs that are parsed on every inbound call as soon as the invite is received.
if you bridge that inbound leg to an outbound leg it will again use that same list with the one used by the inbound leg as the first choice (this is a favor we do by passing the chosen codec on the a leg over to the outbound call on the b leg) if this is not satisfactory i have left you with the option to control the behaviour yourself in a script.



On Fri, Feb 13, 2009 at 11:50 AM, ivdreg ivdreg <ivdreg@gmail.com (ivdreg@gmail.com)> wrote: