Summary:ASTERISK-03580: [PATCH] don't do codec matching until we know who the caller is
Reporter:Kevin P. Fleming (kpfleming)Labels:
Date Opened:2005-02-24 20:01:36.000-0600Date Closed:2008-01-15 15:26:20.000-0600
Versions:Frequency of
Environment:Attachments:( 0) sip_postauth_codec_rev1.diff.txt
Description:In current chan_sip, when an INVITE is received, the SDP portion of the packet is processed prior to making any attempt to determine who the user (or peer) placing the call is.

This causes a problem when the allow/disallow settings in the general section of sip.conf (used for non-identified callers) do not support the codec that the user wants to use, but their type=user entry _does_ support that codec.

For example, using a Cisco 7940 (which does not support iLBC), set up sip.conf like this:



When you try to place a call, you cannot, because the INVITE from the phone does not include iLBC, and that's all Asterisk will accept at that point.

However, once Asterisk has determined who the calling user is (via authentication or otherwise), it would be able to accept the call.

The attached patch moves the processing of the SDP portion of the packet to _after_ we have determined who the calling user is (if we are able to do so).


Disclaimer is on file.
Comments:By: Olle Johansson (oej) 2005-02-25 07:22:52.000-0600

Funny, I looked at that portion of the code earlier this week and thought it was a waste of processing, didn't realize that it's also a problem. Good catch!

By: Brian West (bkw918) 2005-02-25 09:51:08.000-0600

Yep we talked about this on the meeting yesterday.... I think this patch is the proper way to do it.


By: Mark Spencer (markster) 2005-02-25 10:39:34.000-0600

Fixed in CVS head.  Thanks.

By: Russell Bryant (russell) 2005-02-26 20:41:44.000-0600

This has been added to 1.0 as well

By: damin (damin) 2005-04-11 09:11:59

Verified that a portion of this patch breaks inband DTMF behavior on Stable for all chan_sip revisions post 2/25/05. Patch needs to be re-worked to ensure that inband DTMF works properly. See http://bugs.digium.com/bug_view_page.php?bug_id=0003847 for more details.

Please make sure this is updated/corrected/tested before dropping 1.0.8.

By: Terry Wilson (twilson) 2005-04-11 11:09:57

Also, in our situation this patch breaks RFC2833 DTMF.  Before this patch, SDP on a 200 OK would contain the 101 for DTMF on an inbound call from one of our SIP providers (who does not include 101 in their initial INVITE, but accept it if you say you support it--screwed up, but that is what they do).  After the patch (even though the SIP peer for them has dtmfmode=rfc2833) the 200OK does not contain the SDP line saying that it supports 101.

Even though an argument could be made that the providers methods are wrong, WE still have the capability of accepting out of band DTMF so it would be nice if we could add the line to our OK.  I have hacked around and forced it to always add the line (since ALL of our devices/peers use rfc2833) to work around it, but it is ugly and makes me nervous.

By: Kevin P. Fleming (kpfleming) 2005-04-13 00:41:32

Agreed, that is _not_ a change that should go into the tree. If a SIP implementation is sending a media type it did not offer in the INVITE, that is very badly broken.

By: Kevin P. Fleming (kpfleming) 2005-04-13 00:46:29

I'm going to re-close this bug, since any fix needed will come in via bug 3847, not this one.

By: Digium Subversion (svnbot) 2008-01-15 15:26:02.000-0600

Repository: asterisk
Revision: 5075

U   trunk/channels/chan_sip.c

r5075 | markster | 2008-01-15 15:26:02 -0600 (Tue, 15 Jan 2008) | 2 lines

Handle SDP *after* authentication (bug ASTERISK-3580)



By: Digium Subversion (svnbot) 2008-01-15 15:26:20.000-0600

Repository: asterisk
Revision: 5096

U   branches/v1-0/CHANGES
U   branches/v1-0/channels/chan_sip.c

r5096 | russell | 2008-01-15 15:26:20 -0600 (Tue, 15 Jan 2008) | 2 lines

move the processing of SDP data to after determining the user (bug ASTERISK-3580)