[Home]

Summary:ASTERISK-02181: [patch] bugfix: asterisk may send SIP UA codec not offered in INVITE
Reporter:ajz (ajz)Labels:
Date Opened:2004-08-03 06:37:10Date Closed:2008-01-15 15:05:19.000-0600
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) asterisk-sends-wrong-codec.libpcap
( 1) patch-2004-08-03-asterisk-chan_sip-fix
Description:If asterisk receives an INVITE and accepts the INVITE, it should only send media formats offered by the INVITEr.  (See RFC3264 pg 9.)  However, if the SIP UA is listed in sip.conf as being able to support other formats, then asterisk offers these in its 200 OK message, and incorrectly attempts to send them.

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

Here is some SIP debug.  As you can see, the SIP UA sends an INVITE to asterisk offering ULAW,ALAW, and GSM.  However, asterisk offers G729,GSM,ULAW, and ALAW in its 200 OK, and then actually sends G729, and GSM before finally switching to ULAW.


Sip read:
INVITE sip:1000@10.0.0.229 SIP/2.0
Via: SIP/2.0/UDP 10.0.0.180:5060;branch=z9hG4bK764823000
From: Left Hand Side <sip:8020@10.0.0.229>;tag=1875051636;tag=421696030
To: <sip:1000@10.0.0.229>
Call-ID: 2841235337@10.0.0.180
CSeq: 20 INVITE
Contact: <sip:8020@10.0.0.180>
max-forwards: 10
user-agent: oSIP/Linphone-0.12.0
Content-Type: application/sdp
Content-Length:   262

v=0
o=8020 123456 654321 IN IP4 10.0.0.180
s=A conversation
c=IN IP4 10.0.0.180
t=0 0
m=audio 17000 RTP/AVP 0 8 3 101
c=IN IP4 10.0.0.180
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:3 GSM/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15

11 headers, 12 lines
Using latest request as basis request
Sending to 10.0.0.180 : 5060 (non-NAT)
Found RTP audio format 0
Found RTP audio format 8
Found RTP audio format 3
Found RTP audio format 101
Peer audio RTP is at port 10.0.0.180:17000
Found description format PCMU
Found description format PCMA
Found description format GSM
Found description format telephone-event
Capabilities: us - 0x8010e(GSM|ULAW|ALAW|G729A|H263), peer - audio=0xe(GSM|ULAW|ALAW)/video=0x0(EMPTY), combined - 0xe(GSM|ULAW|ALAW)
Non-codec capabilities: us - 0x1(G723), peer - 0x1(G723), combined - 0x1(G723)
Found user '8020'
Looking for 1000 in default
list_route: hop: <sip:8020@10.0.0.180>
Transmitting (no NAT):
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 10.0.0.180:5060;branch=z9hG4bK764823000
From: Left Hand Side <sip:8020@10.0.0.229>;tag=1875051636;tag=421696030
To: <sip:1000@10.0.0.229>;tag=as3a1fb689
Call-ID: 2841235337@10.0.0.180
CSeq: 20 INVITE
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER
Contact: <sip:1000@10.0.0.229>
Content-Length: 0

to 10.0.0.180:5060
   -- Executing Goto("SIP/8020-3535", "default|s|1") in new stack
   -- Goto (default,s,1)
   -- Executing Wait("SIP/8020-3535", "1") in new stack
   -- Executing Answer("SIP/8020-3535", "") in new stack
We're at 10.0.0.229 port 16104
Answering with preferred capability 0x100(G729A)
Answering with preferred capability 0x2(GSM)
Answering with preferred capability 0x4(ULAW)
Answering with preferred capability 0x8(ALAW)
Answering with non-codec capability 0x1(G723)
Reliably Transmitting (no NAT):
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.0.0.180:5060;branch=z9hG4bK764823000
From: Left Hand Side <sip:8020@10.0.0.229>;tag=1875051636;tag=421696030
To: <sip:1000@10.0.0.229>;tag=as3a1fb689
Call-ID: 2841235337@10.0.0.180
CSeq: 20 INVITE
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER
Contact: <sip:1000@10.0.0.229>
Content-Type: application/sdp
Content-Length: 285

v=0
o=root 31685 31685 IN IP4 10.0.0.229
s=session
c=IN IP4 10.0.0.229
t=0 0
m=audio 16104 RTP/AVP 18 3 0 8 101
a=rtpmap:18 G729/8000
a=rtpmap:3 GSM/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -

to 10.0.0.180:5060
   -- Executing DigitTimeout("SIP/8020-3535", "5") in new stack
   -- Set Digit Timeout to 5
   -- Executing ResponseTimeout("SIP/8020-3535", "10") in new stack
   -- Set Response Timeout to 10
   -- Executing BackGround("SIP/8020-3535", "demo-congrats") in new stack
   -- Playing 'demo-congrats' (language 'en')
asterisk*CLI>

Sip read:
ACK sip:1000@10.0.0.229 SIP/2.0
Via: SIP/2.0/UDP 10.0.0.180:5060;branch=z9hG4bK1004390971
From: Left Hand Side <sip:8020@10.0.0.229>;tag=1875051636;tag=421696030
To: <sip:1000@10.0.0.229>;tag=as3a1fb689
Call-ID: 2841235337@10.0.0.180
CSeq: 20 ACK
max-forwards: 10
user-agent: oSIP/Linphone-0.12.0
Content-Length: 0

The problem is in check_auth_full() in chan_sip.c.  For some reason this is resetting p->jointcapability.  I don't think it should do this.  See attached patch.

Alex
Comments:By: Mark Spencer (markster) 2004-08-03 09:24:25

Actually the very page of the very document you sent us to clearly says that our negotiation is legal:

"  For streams marked as sendrecv in the answer,
  the "m=" line MUST contain at least one codec the answerer is willing
  to both send and receive, from amongst those listed in the offer.
  The stream MAY indicate additional media formats, not listed in the
  corresponding stream in the offer, that the answerer is willing to
  send or receive (of course, it will not be able to send them at this
  time, since it was not listed in the offer)."

Now, if we're actually *sending audio* with a codec that was not in the invite, that's a whole other story.  Is that what you're saying is happening?
By: ajz (ajz) 2004-08-06 04:17:52

Yes, that is what is happening!  Asterisk is actually *sending audio* with a codec that was not in the invite.  From what you've just said, I assume that this is justification for reopening the bug.


I shall try to attach a libpcap file (which can be opened in ethereal.)

Asterisk (10.0.0.229) receives an INVITE offering ULAW, ALAW, and GSM.
However, it replies with a 200 OK offering these *plus* G729.  Then the
first frame it sends off is actually G729 - despite the fact this wasn't
offered in the INVITE.

The root cause is that p->jointcapability was overwritten in
check_user_full() - and I believe this isn't necessary.
By: Mark Spencer (markster) 2004-08-06 10:22:13

It's fine (and proper) for Asterisk to say that it supports G.729.  It is not appropriate however for Asterisk to actually send via G.729 if that wasn't in the original invite.

Can you find me on IRC so we can try to work through this?
By: Olle Johansson (oej) 2004-08-14 15:38:05

Reminder! Please find Mark on the irc - he's known under the acronym of "kram". If you have any problem, find a bug marshal - we are to be found in #asterisk-bugs and #asterisk-dev

/Olle
By: ajz (ajz) 2004-08-18 04:24:01

Sorry, I've been out of the office for a week.  I tried to get hold of kram yesterday but he's 8 hours behind me (I'm based in Cambridge, UK).

Please let me know if there is any information that you need as I am unlikely to be able to contact you using IRC because of the time difference.  Alternatively, is there anyone this side of the pond I can talk to?
By: Mark Spencer (markster) 2004-08-18 10:09:07

Should be fixed in CVS...  Let me know if this does it.
By: ajz (ajz) 2004-08-18 12:10:08

I think this is fixed now.  Asterisk still offers codecs not present in the INVITE in its 200 OK response.  This is unusual but not against the spec.  The important thing is that Asterisk is no longer actually sending codecs not present in the INVITE.

Thank you.
By: Mark Spencer (markster) 2004-08-18 14:00:49

Fixed in CVS
By: Digium Subversion (svnbot) 2008-01-15 15:05:19.000-0600

Repository: asterisk
Revision: 3622

U   trunk/channels/chan_sip.c

------------------------------------------------------------------------
r3622 | markster | 2008-01-15 15:05:18 -0600 (Tue, 15 Jan 2008) | 2 lines

Make sure jointcapability really indicates joint capability (bug ASTERISK-2181)

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

http://svn.digium.com/view/asterisk?view=rev&revision=3622