[Home]

Summary:ASTERISK-10887: [patch] Codec negotiation results in asterisk sending unsupported codec
Reporter:Lars Sundqvist (lasse)Labels:
Date Opened:2007-11-26 07:51:57.000-0600Date Closed:2007-11-27 13:22:03.000-0600
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/CodecHandling
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) bug11376.txt
( 1) debug.log
( 2) debug2.log
( 3) debug3.log
( 4) showchannel1.log
( 5) showchannel2.log
( 6) sip.conf
Description:SIP Phone client that  supports only iLBC
Asterisk configured to support alaw, ilbc in that order (sip.conf).
PSTN provider supports all kinds of codecs

Call from PSTN to sip phone works fine (PSTN -> alaw -> Asterisk -> ilbc -> SIP client)

BUT if the order of the codecs in sip.conf is ilbc, alaw asterisk will send ilbc to PSTN provider and alaw to SIP client (allthough it indicates it only support ilbc in SDP) resulting in a failed call.
Comments:By: Joshua C. Colp (jcolp) 2007-11-26 08:11:09.000-0600

Please provide complete console output with sip debug and sip.conf and a core show channel on each.
By: Lars Sundqvist (lasse) 2007-11-26 08:41:38.000-0600

Attached specified files, show channel output is from a later call (with the same result) but i hope it is sufficient?
By: Olle Johansson (oej) 2007-11-27 01:22:51.000-0600

Well, they do offer ALAW and we answer with ILBC and ALAW, so they can send ALAW to us, but decide not to do it.  This seems to be a bug in both ends.

According to the latest discussions in the SIP standards groups, we should not offer ILBC in the answer. But that's no reason for them cancelling the call when we answer that we would prefer ILBC, but still accept ALAW.
By: Lars Sundqvist (lasse) 2007-11-27 01:34:55.000-0600

I am afraid i was not wording it correctly, the call is not dropped the problem is the SIP client receives ALAW allthough it indicated in its SDP it only supports iLBC (see the 200 OK from 1.2.3.4:5060 that contains the client SDP and the subsequent rtp debug which indicates iLBC (type 97) is being sent to 1.2.3.4:60202). So the problem is the negotiation between the client and asterisk.
By: Olle Johansson (oej) 2007-11-27 01:42:36.000-0600

För tidigt på morgonen... :-)

Yes, in this case the p2p bridge should not kick in. The issue might be that they use payload 97 for something that isn't ilbc and we don't discover that while parsing the SDP, so we end up believing that the PSTN carrier actually supports ILBC.

From the log file you provided:

a=rtpmap:97 G726-16/8000/1

Found RTP audio format 97

Found description format G726-16 for ID 97

Capabilities: us - 0x408 (alaw|ilbc), peer - audio=0x200f1f (g723|gsm|ulaw|alaw|g726|g729|speex|ilbc|g726aal2|h264)/video=0x0 (nothing), combined - 0x408 (alaw|ilbc)
By: Lars Sundqvist (lasse) 2007-11-27 01:50:06.000-0600

Unless i misunderstood something, the sdp from the client is sent in this message:

asl004*CLI>
<--- SIP read from 1.2.3.4:5060 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP 1.2.3.4:5070;branch=z9hG4bK7e06ef7f;rport=5070
From: "Owner of number" <sip:+46987654321@1.2.3.4:5070>;tag=as3300c472
To: "unknown" <sip:46123456789@1.2.3.4>;tag=ae71559a12
Contact: <sip:46123456789@213.50.52.7:63066>
Call-ID: 197def4c6c6d17414029b0ef196ad339@1.2.3.4
CSeq: 102 INVITE
Content-Length: 249
Content-Type: application/sdp
Record-Route: <sip:1.2.3.4;lr;ftag=as3300c472>
Server: SJphone/1.65.377a (SJ Labs)
Supported: replaces,norefersub,timer

v=0
o=- 3405072225 3405072225 IN IP4 10.10.4.18
s=SJphone
c=IN IP4 1.2.3.4
t=0 0
m=audio 60202 RTP/AVP 97 101
c=IN IP4 1.2.3.4
a=rtpmap:97 iLBC/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=setup:active
a=sendrecv

<------------->
--- (12 headers 12 lines) ---
Found RTP audio format 97
Found RTP audio format 101
Peer audio RTP is at port 1.2.3.4:60202
Found description format iLBC for ID 97
Found description format telephone-event for ID 101
Capabilities: us - 0x408 (alaw|ilbc), peer - audio=0x400 (ilbc)/video=0x0 (nothing), combined - 0x400 (ilbc)

And asterisk seems to conclude iLBC is the combined capability but then proceeds to send alaw:
...
Sent RTP P2P packet to 1.2.3.4:60202 (type 08, len 000160)
...
By: Olle Johansson (oej) 2007-11-27 02:02:40.000-0600

I've created an untested patch that actually issues an error if the MIME subtype is unknown and do not add it to the rtpmaps.

If you have the time, please test this on 1.4 code base. Thanks.
By: Olle Johansson (oej) 2007-11-27 02:09:55.000-0600

Well asterisk concludes that we don't need transcoding since everyone accepts ilbc and then sets up an p2p bridge and forwards whatever the pstn side is sending without further consideration.
By: Lars Sundqvist (lasse) 2007-11-27 02:13:43.000-0600

Ahh sorry, you are right. Thanks will test and get back...
I agree...it is way to early in the morning :-)


By: Lars Sundqvist (lasse) 2007-11-27 02:30:32.000-0600

No change with the patch, attached debug2.log
By: Olle Johansson (oej) 2007-11-27 05:45:27.000-0600

Me bad. I'll take another look this afternoon.
By: Olle Johansson (oej) 2007-11-27 06:27:21.000-0600

Ok, try this one instead. Thanks for your patience.
By: Olle Johansson (oej) 2007-11-27 06:50:01.000-0600

What kind of device is the SemSys? I've not seen RED in offers like this. Just curious on the impressive SDP.
By: Lars Sundqvist (lasse) 2007-11-27 06:58:26.000-0600

Worked fine this time, thanks alot for your assistance.

I am afraid i do not know much about the SemSys device as it is our provider machines (http://www.stingnetworks.com/)...however they seem to be happy with them and have been boasting that they are very capable.
By: Olle Johansson (oej) 2007-11-27 07:03:43.000-0600

Interesting. Thanks for the feedback.

I'll have to fix the last issue here and make sure we don't clear a video codec by mistake before I commit this to svn.

Tack för att du rapporterade buggen! /Olle
By: Digium Subversion (svnbot) 2007-11-27 09:20:47.000-0600

Repository: asterisk
Revision: 89630

U   branches/1.4/channels/chan_sip.c
U   branches/1.4/include/asterisk/rtp.h
U   branches/1.4/main/rtp.c

------------------------------------------------------------------------
r89630 | oej | 2007-11-27 09:20:45 -0600 (Tue, 27 Nov 2007) | 12 lines

If we get a codec offer using a well-known payload type, but using it for another
codec that we don't know, Asterisk did not remove that codec from the list.

With this patch, we remove the codec from audio and video rtp objects and
deny it ever existed. Thanks to lasse for testing.

(closes issue ASTERISK-10887)
Reported by: lasse
Patches:
     bug11376.txt uploaded by oej (license 306)
Tested by: lasse

------------------------------------------------------------------------
By: Digium Subversion (svnbot) 2007-11-27 13:22:03.000-0600

Repository: asterisk
Revision: 89698

_U  trunk/
U   trunk/channels/chan_sip.c
U   trunk/include/asterisk/rtp.h
U   trunk/main/rtp.c

------------------------------------------------------------------------
r89698 | oej | 2007-11-27 13:22:02 -0600 (Tue, 27 Nov 2007) | 24 lines

The following patch with updates for trunk. Works much better in trunk.
Also by accident fixed a bad typo by a previous committer, which actually made video calls
not work fully...

Merged revisions 89630 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

........
r89630 | oej | 2007-11-27 16:23:17 +0100 (Tis, 27 Nov 2007) | 12 lines

If we get a codec offer using a well-known payload type, but using it for another
codec that we don't know, Asterisk did not remove that codec from the list.

With this patch, we remove the codec from audio and video rtp objects and
deny it ever existed. Thanks to lasse for testing.

(closes issue ASTERISK-10887)
Reported by: lasse
Patches:
     bug11376.txt uploaded by oej (license 306)
Tested by: lasse

........

------------------------------------------------------------------------