[Home]

Summary:ASTERISK-11782: Codec negotiation failure
Reporter:George Mass (mascool)Labels:
Date Opened:2008-04-03 21:33:23Date Closed:2008-04-09 12:55:40
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/CodecHandling
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:I have a provider that supports both ulaw and g729. Provider set to allowed ulaw and g729 (in that order). Aastra phone set to use G729 only. Call fails with "No audio format found to offer" even though it should be ok based on this line:

Capabilities: us - 0x104 (ulaw|g729), peer - audio=0x105 (g723|ulaw|g729)/video=0x0 (nothing), combined - 0x104 (ulaw|g729)


****** ADDITIONAL INFORMATION ******

SIP debug:
<--- SIP read from 64.158.177.99:5060 --->
INVITE sip:2482467007@200.xx.36.42 SIP/2.0
Max-Forwards: 69
Session-Expires: 3600;Refresher=uac
Supported: timer
To: <sip:2482467007@200.xx.36.42:5060>
From: <sip:5868735246@64.158.177.99>;tag=3416263034-861359
Remote-Party-Id: <sip:5868735246@64.158.177.99:5060>;privacy=off
Call-ID: 1747302-3416263034-861223@is02.broadvox.net
CSeq: 1 INVITE
Via: SIP/2.0/UDP 64.158.177.99:5060;branch=e9f4d0bea6c5385e4e4d8a41c3f5b20a
Contact: sip:5868735246@64.158.177.99:5060
Content-Type: application/sdp
Content-Length: 324

v=0
o=Version 1234 17934 IN IP4 64.158.162.74
s=sip call
c=IN IP4 64.158.162.71
t=0 0
m=audio 26350 RTP/AVP 0 18 4 101
a=rtpmap:0 PCMU/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:4 G723/8000
a=fmtp:4 annexa=no;bitrate=6.3
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv
a=maxptime:30

<------------->
--- (13 headers 15 lines) ---
Sending to 64.158.177.99 : 5060 (no NAT)
Using INVITE request as basis request - 1747302-3416263034-861223@is02.broadvox.net
Found peer 'broadvox'
Found RTP audio format 0
Found RTP audio format 18
Found RTP audio format 4
Found RTP audio format 101
Peer audio RTP is at port 64.158.162.71:26350
Found audio description format PCMU for ID 0
Found audio description format G729 for ID 18
Got unsupported a:fmtp in SDP offer
Found audio description format G723 for ID 4
Got unsupported a:fmtp in SDP offer
Found audio description format telephone-event for ID 101
Got unsupported a:fmtp in SDP offer
Capabilities: us - 0x104 (ulaw|g729), peer - audio=0x105 (g723|ulaw|g729)/video=0x0 (nothing), combined - 0x104 (ulaw|g729)
Non-codec capabilities (dtmf): us - 0x1 (telephone-event), peer - 0x1 (telephone-event), combined - 0x1 (telephone-event)
Peer audio RTP is at port 64.158.162.71:26350
Looking for 2482467007 in hosted_in (domain 200.xx.36.42)
list_route: hop: <sip:5868735246@64.158.177.99:5060>
sip1*CLI>
<--- Transmitting (no NAT) to 64.158.177.99:5060 --->
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 64.158.177.99:5060;branch=e9f4d0bea6c5385e4e4d8a41c3f5b20a;received=64.158.177.99
From: <sip:5868735246@64.158.177.99>;tag=3416263034-861359
To: <sip:2482467007@200.xx.36.42:5060>
Call-ID: 1747302-3416263034-861223@is02.broadvox.net
CSeq: 1 INVITE
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces
Contact: <sip:2482467007@200.xx.36.42>
Content-Length: 0


<------------>
   -- Executing [2482467007@hosted_in:1] Dial("SIP/broadvox-0086ce20", "SIP/02482957753") in new stack
[2008-04-03 22:00:43] WARNING[6472]: chan_sip.c:3008 sip_call: No audio format found to offer. Cancelling call to 02482957753
   -- Couldn't call 02482957753


sip.conf for provider:
[broadvox]
username=broadvox
type=peer
secret=
qualify=120000
nat=no
host=64.158.177.99
dtmfmode=rfc2833
context=hosted_in
canreinvite=yes
insecure=very
disallow=all
allow=ulaw
allow=g729
t38pt_udptl=yes

sip.conf for phone:
[02482957753]
username=02482957753
type=friend
secret=secret
qualify=90000
nat=yes
host=dynamic
dtmfmode=rfc2833
context=2482957753
canreinvite=no
insecure=very
disallow=all
allow=g729
callerid=<2482957753>
mailbox=2482957753@hosted_in

sip.conf general
[general]
limitonpeers=yes
context=default
allowoverlap=no
bindport=5060
bindaddr=0.0.0.0
srvlookup=yes
limitonpeers=yes
rtcachefriends=yes
rtupdate=yes
rtptimeout=300
t38pt_udptl=yes
nat=no
disallow=all
allow=g729,ulaw
Comments:By: Frederic LE FOLL (flefoll) 2008-04-04 03:57:33

Just to be sure : do you have G.729 codec loaded ?
What do "show modules like codec" or "core show translation" say ?
By: George Mass (mascool) 2008-04-04 08:31:15

Why would I need the g729 codec? If both the provider and the second leg support g729, shouldn't asterisk let g729 pass through? If I load the codec then 1st leg is ulaw (from provider) and second is g729 (to the phone)
If I change the order on the provider, put g729 first( allow=g729,ulaw ) then negotiation succeeds


By: Frederic LE FOLL (flefoll) 2008-04-06 16:28:42

>Why would I need the g729 codec? If both the provider and the second leg support
> g729, shouldn't asterisk let g729 pass through?

You are right, depending on your Dial() options, Asterisk may, or may not, need to decode g729, or just let it pass through.
But if you have one leg ulaw and the other g729, then it need to. If you want to use g729 on both legs, in order to avoid codecs translation, it seems better to define g729 as prefered choice for both parts, and then it succeeds as you say in your note.
By: George Mass (mascool) 2008-04-06 17:32:09

Right, however some devices will need to use ulaw. So then ulaw is the second codec in the list for the provider and the first one in the codecs list for the device which takes us back to square one, only it's ulaw and not g729 this time. Also my impression is that if asterisk was able to find common codecs for the 2 legs (in this case: combined - 0x104 (ulaw|g729) ) it shouldn't drop the call because of "no audio format found to offer"
By: Joshua C. Colp (jcolp) 2008-04-07 08:26:36

Codec negotiation (currently) happens independent of the remote side, ie: between the device and Asterisk. So the first leg negotiates at ulaw.
By: les (les) 2008-04-08 18:07:06

I have a similar issue as don't have g729  codec installed.

If I understood correctly when Asterisk checks allowed  codecs on the outgoing leg it has already decided  codec on the incoming leg, therefore even though incoming and outgoing legs do have common  codec Asterisk still tries to get into the audio path.

File, when you say that  codec negotiation algorithm CURRENTLY works this way, do think/know it will be  woking differently later at some point?

It would obviously be a good idea if Asterisk could check both incoming and outgoing legs' allowed  codecs and choose one which both sides support to avoid unnecessary codec_A -> codec_B translation.


By: Joshua C. Colp (jcolp) 2008-04-09 10:53:55

I know of nobody currently actively working to change it, but it is on our minds.
By: Jason Parker (jparker) 2008-04-09 12:55:39

Per the comment from file, I am going to close this.

It's something we've thought about pretty extensively, and it is going to take a great deal of effort to "fix".

For a more in-depth explanation, please see my comment on issue ASTERISK-4703.