FreeSWITCH

Problem with codec negotiation

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Minor Minor
  • Resolution: Not A Bug
  • Affects Version/s: None
  • Fix Version/s: 1.0.7
  • Component/s: freeswitch-core
  • Labels:
    None
  • Platform:
    Win32/VS
  • CPU Info:
    Mobile Pentium II, 300Mhz
  • FreeSWITCH GIT Revision:
    Past week GIT head
  • Reproduced with GIT HEAD?:
    yes

Description

I can't make call from device A to B. But I can make call from B to A. The reason seems to be FS, that creates the problem with codec negotiation in the middle.

Let's take a look at two scenarios.

Making call from A to B (failure):
-------------------------------------------------
A sends fo FS:
   INVITE XXX SIP/2.0
   m=audio 4002 RTP/AVP 102 0 8 9 107 106 105 101
   a=rtpmap:102 iLBC/8000
   a=rtpmap:0 PCMU/8000
   a=rtpmap:8 PCMA/8000
   a=rtpmap:9 G722/8000
   a=rtpmap:107 speex/32000
   a=rtpmap:106 speex/16000
   a=rtpmap:105 speex/8000
   a=rtpmap:101 telephone-event/8000
-------------------------------------------------
FS sends to B:
   INVITE XXX SIP/2.0
   m=audio 27962 RTP/AVP 98 99 101 13
   a=rtpmap:98 iLBC/8000
   a=rtpmap:99 iLBC/8000
   a=rtpmap:101 telephone-event/8000
   m=audio 27962 RTP/AVP 18 100 102 9 0 8 3 101 13
   a=rtpmap:100 G7221/32000
   a=rtpmap:102 G7221/16000
   a=rtpmap:101 telephone-event/8000
-------------------------------------------------
FS to A:
   SIP/2.0 183 Session Progress
   m=audio 23712 RTP/AVP 102 101
   a=rtpmap:102 iLBC/8000
   a=rtpmap:101 telephone-event/8000
-------------------------------------------------
B to FS:
   SIP/2.0 488 Not Acceptable Here
-------------------------------------------------
FS to B:
   ACK sip:205@XX.YY.220.149:11508 SIP/2.0
-------------------------------------------------
[INFO] mod_dptools.c:2690 Originate Failed. Cause: INCOMPATIBLE_DESTINATION
-------------------------------------------------
Call goes to VM.
-------------------------------------------------

Making call from B to A (success):
-------------------------------------------------
B makes new call:
   INVITE XXX SIP/2.0
   m=audio 16636 RTP/AVP 0 8 18 104 102 103 105 101
   a=rtpmap:0 PCMU/8000
   a=rtpmap:8 PCMA/8000
   a=rtpmap:18 G729/8000
   a=rtpmap:104 G726-32/8000
   a=rtpmap:102 G726-16/8000
   a=rtpmap:103 G726-24/8000
   a=rtpmap:105 G726-40/8000
   a=rtpmap:101 telephone-event/8000
-------------------------------------------------
FS sends to A:
   INVITE XXX SIP/2.0
   m=audio 24338 RTP/AVP 0 18 98 99 9 8 3 101 13
   a=rtpmap:98 G7221/32000
   a=fmtp:98 bitrate=48000
   a=rtpmap:99 G7221/16000
   a=fmtp:99 bitrate=32000
   a=rtpmap:101 telephone-event/8000
   a=fmtp:101 0-16
   a=rtpmap:100 iLBC/8000
   a=fmtp:100 mode=30
   a=rtpmap:101 telephone-event/8000
   a=fmtp:101 0-16
-------------------------------------------------
FS sends to B:
   SIP/2.0 183 Session Progress
   m=audio 21532 RTP/AVP 0 101
   a=rtpmap:0 PCMU/8000
   a=rtpmap:101 telephone-event/8000
-------------------------------------------------
A to FS:
   SIP/2.0 200 OK
   m=audio 4000 RTP/AVP 0 101
   a=rtpmap:0 PCMU/8000
   a=rtpmap:101 telephone-event/8000
-------------------------------------------------
FS to A:
   ACK XXX SIP/2.0
-------------------------------------------------
FS to B:
   SIP/2.0 200 OK
   m=audio 28976 RTP/AVP 0 101
   a=rtpmap:0 PCMU/8000
   a=rtpmap:101 telephone-event/8000
-------------------------------------------------
B to FS:
   ACK XXX SIP/2.0
-------------------------------------------------
Successful conversation...

As you can see the problem is created by FS, that insists on using iLIB or G722 codecs, which are not supported by device B. It clearly indicates its list of supported codecs: PCMU, PCMA, G729, etc., some of which are in the list of offered by device A.

Related questions:
1. In the first scenario why FS offers iLBC/8000 twice (98 and 99)?
2. What is the codec G7221/32000, that FS sends to A in the second scenario? I guess it's a typo in the log (and it's actually G722/32000), but it should be checked...
3. How in the second scenario A gets codec PCMU/8000, if it's not even listed in the INVITE request sent from FS to A?

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Yuri Ost added a comment -
@Anthony,
I need your help. Could you please remove IP address of the host mentioned in the issue above.
Thanks!
Show
Yuri Ost added a comment - @Anthony, I need your help. Could you please remove IP address of the host mentioned in the issue above. Thanks!
Hide
Permalink
Anthony Minessale II added a comment -
your far end does not properly support multiple m= lines in sdp and you are trying to use codecs with multiple ptimes in the same session description.

set this globally in your vars.xml

sdp_m_per_ptime=false
Show
Anthony Minessale II added a comment - your far end does not properly support multiple m= lines in sdp and you are trying to use codecs with multiple ptimes in the same session description. set this globally in your vars.xml sdp_m_per_ptime=false
Hide
Permalink
Yuri Ost added a comment -
@Anthony,
Thank you for the suggestion. I've added the new line to vars.xml. Now it looks like:
-------------------------------------------------
  <X-PRE-PROCESS cmd="set" data="global_codec_prefs=iLBC,G7221@32000h,G7221@16000h,G722,PCMU,PCMA,GSM"/>
  <X-PRE-PROCESS cmd="set" data="outbound_codec_prefs=iLBC,PCMU,PCMA,GSM"/>
  <X-PRE-PROCESS cmd="set" data="sdp_m_per_ptime=false"/>
-------------------------------------------------
It removed second m= line from the INVITE request, sent to B. But the problem with device B still persist. It may reply on INVITE requests or it may not (looks like randomly). Reason is unknown so far and I've opened an issue with manufacturer of device B, asking for help.

Meantime, here is a simple question and I'm sure you may have an answer here. Why FS converts set of supported codecs from offered by device A, when it sends INVITE request to device B?

It looks like FS tries to force device B with its own set of codecs (BTW, in this case, non of them is supported by device B). I guess it takes them from "global_codec_prefs" variable, but then, why I see iLBC twice in INVITE request? See example below:
-------------------------------------------------
A to FS:
   m=audio 4006 RTP/AVP 102 0 8 9 107 106 105 101
   a=rtcp:4007 IN IP4 XX.XX.XX.XX
   a=rtpmap:102 iLBC/8000
   a=rtpmap:0 PCMU/8000
   a=rtpmap:8 PCMA/8000
   a=rtpmap:9 G722/8000
   a=rtpmap:107 speex/32000
   a=rtpmap:106 speex/16000
   a=rtpmap:105 speex/8000
   a=sendrecv
   a=rtpmap:101 telephone-event/8000
   a=fmtp:101 0-15
-------------------------------------------------
FS to B:
   v=0
   o=FreeSWITCH 1314041379 1314041380 IN IP4 XX.XX.XX.XX
   s=FreeSWITCH
   c=IN IP4 XX.XX.XX.XX
   t=0 0
   m=audio 27026 RTP/AVP 98 99 100 102 9 0 8 3 101 13
   a=rtpmap:98 iLBC/8000
   a=fmtp:98 mode=30
   a=rtpmap:99 iLBC/8000
   a=fmtp:99 mode=30
   a=rtpmap:100 G7221/32000
   a=fmtp:100 bitrate=48000
   a=rtpmap:102 G7221/16000
   a=fmtp:102 bitrate=32000
   a=rtpmap:101 telephone-event/8000
   a=fmtp:101 0-16
   a=ptime:30
-------------------------------------------------

Is it necessary to force device B with a different set of codecs, than the device A sent to FS? Should it be a bit more flexible (keep what was offered by A and add to B its own FS's supported set of codecs?

If it's not possible - how to make FS just to transfer set of codecs offered by A to device B without any change?
Show
Yuri Ost added a comment - @Anthony, Thank you for the suggestion. I've added the new line to vars.xml. Now it looks like: -------------------------------------------------   <X-PRE-PROCESS cmd="set" data="global_codec_prefs=iLBC, G7221@32000h , G7221@16000h ,G722,PCMU,PCMA,GSM"/>   <X-PRE-PROCESS cmd="set" data="outbound_codec_prefs=iLBC,PCMU,PCMA,GSM"/>   <X-PRE-PROCESS cmd="set" data="sdp_m_per_ptime=false"/> ------------------------------------------------- It removed second m= line from the INVITE request, sent to B. But the problem with device B still persist. It may reply on INVITE requests or it may not (looks like randomly). Reason is unknown so far and I've opened an issue with manufacturer of device B, asking for help. Meantime, here is a simple question and I'm sure you may have an answer here. Why FS converts set of supported codecs from offered by device A, when it sends INVITE request to device B? It looks like FS tries to force device B with its own set of codecs (BTW, in this case, non of them is supported by device B). I guess it takes them from "global_codec_prefs" variable, but then, why I see iLBC twice in INVITE request? See example below: ------------------------------------------------- A to FS:    m=audio 4006 RTP/AVP 102 0 8 9 107 106 105 101    a=rtcp:4007 IN IP4 XX.XX.XX.XX    a=rtpmap:102 iLBC/8000    a=rtpmap:0 PCMU/8000    a=rtpmap:8 PCMA/8000    a=rtpmap:9 G722/8000    a=rtpmap:107 speex/32000    a=rtpmap:106 speex/16000    a=rtpmap:105 speex/8000    a=sendrecv    a=rtpmap:101 telephone-event/8000    a=fmtp:101 0-15 ------------------------------------------------- FS to B:    v=0    o=FreeSWITCH 1314041379 1314041380 IN IP4 XX.XX.XX.XX    s=FreeSWITCH    c=IN IP4 XX.XX.XX.XX    t=0 0    m=audio 27026 RTP/AVP 98 99 100 102 9 0 8 3 101 13    a=rtpmap:98 iLBC/8000    a=fmtp:98 mode=30    a=rtpmap:99 iLBC/8000    a=fmtp:99 mode=30    a=rtpmap:100 G7221/32000    a=fmtp:100 bitrate=48000    a=rtpmap:102 G7221/16000    a=fmtp:102 bitrate=32000    a=rtpmap:101 telephone-event/8000    a=fmtp:101 0-16    a=ptime:30 ------------------------------------------------- Is it necessary to force device B with a different set of codecs, than the device A sent to FS? Should it be a bit more flexible (keep what was offered by A and add to B its own FS's supported set of codecs? If it's not possible - how to make FS just to transfer set of codecs offered by A to device B without any change?
Hide
Permalink
Anthony Minessale II added a comment -
1) enable late negotiation on your sofia profile.
   <param name="inbound-late-negotiation" value="true"/>
   then you need to set absolute_codec_string to ep_codec_string in your dial string
   {absolute_codec_string=${ep_codec_string}}sofia/foo/foo@bar.com

2) just manually set absolute_codec_string to the codecs you want.

3) use proxy media, you will not be able to process the media at all in this mode, eg play files, record audio.
    <param name="inbound-proxy-media" value="true"/>



BTW, your guesses of what the pertinent info from the logs is never a good plan. Just attach raw traces so we have all the data.

I also suggest you read the many details on codec negotiation in the WIKI since this is a bug tracker not an educational tool.

Show
Anthony Minessale II added a comment - 1) enable late negotiation on your sofia profile.    <param name="inbound-late-negotiation" value="true"/>    then you need to set absolute_codec_string to ep_codec_string in your dial string    {absolute_codec_string=${ep_codec_string}}sofia/foo/foo@bar.com 2) just manually set absolute_codec_string to the codecs you want. 3) use proxy media, you will not be able to process the media at all in this mode, eg play files, record audio.     <param name="inbound-proxy-media" value="true"/> BTW, your guesses of what the pertinent info from the logs is never a good plan. Just attach raw traces so we have all the data. I also suggest you read the many details on codec negotiation in the WIKI since this is a bug tracker not an educational tool.
Hide
Permalink
Yuri Ost added a comment -
1. Tried to use "Late Negotiation" and it looks like it doesn't work.
There is no any difference with or without these settings:
-------------------------------------------------
internal.xml:
<param name="inbound-late-negotiation" value="true"/>
dialplan:
<action application="set" data="inherit_codec=true"/>
<action application="export" data="codec_string=${ep_codec_string}"/>
-------------------------------------------------
I see in log though:
EXPORT (export_vars)[codec_string]=[PCMU@8000h@20i@64000b,PCMA@8000h@20i@64000b]
but it makes no any difference on choosing codecs. I expect, if both nodes support the same codec, it should be used. What I see is - FS makes transcoding instead of offering PCMU to both ends. Both ends support PCMU, BTW.

2. Tried to set a particular codec set:
-------------------------------------------------
internal.xml:
<param name="inbound-late-negotiation" value="true"/>
dialplan:
<action application="bridge" data="{absolute_codec_string=PCMU\,PCMA}user/${dialed_extension}@${domain_name}"/>
-------------------------------------------------
I see in log:
EXECUTE sofia/internal/101@domain.tld bridge({absolute_codec_string=PCMU\,PCMA}user/105@domain.tld)
but codecs, that eventually used by both ends are different. Both ends support PCMU. But as a result, one uses iLBC and another one PCMU...

3. Tried to set proxy media mode and it works!
-------------------------------------------------
dialplan:
<action application="set" data="proxy_media=true"/>
-------------------------------------------------
Both devices start using G729 codec and sound quality was the best... No transcoding, no cracking sound, etc.

I'll try to use bypass media mode too and report, if I see problems there.
Show
Yuri Ost added a comment - 1. Tried to use "Late Negotiation" and it looks like it doesn't work. There is no any difference with or without these settings: ------------------------------------------------- internal.xml: <param name="inbound-late-negotiation" value="true"/> dialplan: <action application="set" data="inherit_codec=true"/> <action application="export" data="codec_string=${ep_codec_string}"/> ------------------------------------------------- I see in log though: EXPORT (export_vars)[codec_string]=[ PCMU@8000h @ 20i@64000b , PCMA@8000h @ 20i@64000b ] but it makes no any difference on choosing codecs. I expect, if both nodes support the same codec, it should be used. What I see is - FS makes transcoding instead of offering PCMU to both ends. Both ends support PCMU, BTW. 2. Tried to set a particular codec set: ------------------------------------------------- internal.xml: <param name="inbound-late-negotiation" value="true"/> dialplan: <action application="bridge" data="{absolute_codec_string=PCMU\,PCMA}user/${dialed_extension}@${domain_name}"/> ------------------------------------------------- I see in log: EXECUTE sofia/internal/101@domain.tld bridge({absolute_codec_string=PCMU\,PCMA}user/105@domain.tld) but codecs, that eventually used by both ends are different. Both ends support PCMU. But as a result, one uses iLBC and another one PCMU... 3. Tried to set proxy media mode and it works! ------------------------------------------------- dialplan: <action application="set" data="proxy_media=true"/> ------------------------------------------------- Both devices start using G729 codec and sound quality was the best... No transcoding, no cracking sound, etc. I'll try to use bypass media mode too and report, if I see problems there.
Hide
Permalink
Auto Admin added a comment -
Due to a long period of inactivity (13 or more days), this issue is due to be automatically close within 24 hours.
If this issue is not actually resolved, please reopen it and add appropriate comments to help developers fix the issue.

Thanks,
  Jira Admin
Show
Auto Admin added a comment - Due to a long period of inactivity (13 or more days), this issue is due to be automatically close within 24 hours. If this issue is not actually resolved, please reopen it and add appropriate comments to help developers fix the issue. Thanks,   Jira Admin
Hide
Permalink
Auto Admin added a comment -
Since there has been no change to the status of this issue, it is being closed for inactivity

Thanks,
  Jira Admin
Show
Auto Admin added a comment - Since there has been no change to the status of this issue, it is being closed for inactivity Thanks,   Jira Admin

People

  • Assignee:
    Anthony Minessale II
    Reporter:
    Yuri Ost
Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved: