[Home]

Summary:ASTERISK-03712: [patch] SIP methods MUST be parsed case sensitive
Reporter:khb (khb)Labels:
Date Opened:2005-03-19 14:07:09.000-0600Date Closed:2011-06-07 14:11:53
Priority:TrivialRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/Interoperability
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) patch_method_case_parsing.txt
( 1) patch_method_case_parsing2.txt
Description:SIP methods (INVITE, REGISTER, etc.) are by definition UPPER case always and it should not be allowed any differently.

Disclaimed.
Comments:By: Michael Jerris (mikej) 2005-03-19 14:11:42.000-0600

what are the positive affects of this?  While this is appropriate to RFC, this seems to generally go against being strict in what you send and liberal in what you receive.
By: Kevin P. Fleming (kpfleming) 2005-03-19 14:31:35.000-0600

Yeah, this is one case where accepting non-compliant strings seems the prudent thing to do.
By: khb (khb) 2005-03-19 14:32:12.000-0600

That might be appropriate for situations where interpretations can be different, arguably, but when it comes to protocol specifications, non-compliant behavior should be rejected as early as possible. Later on, non-compliance can be very hard to eradicate and can cause all kinds of obscure interoperability issues, and we see that here only too often.
There are a lot of people out there that don't know any better and copy features and behavior from what they see in other applications apparently without reading the specs.

PS: a few times have I been alerted to protocol non-compliance or simple stupid errors, because another server detected my problem and refused service or whatever.  We just saw one of these today again,  the priority in xpidf documents was wrong. I fixed that on some server a long time ago, because some client software rejected service, I think it was MS Messenger.

edited on: 03-19-05 14:38
By: Kevin P. Fleming (kpfleming) 2005-03-19 14:37:44.000-0600

If we are to apply that logic, then we should _not_ apply your patch to case-insensitively match "tag=", because the RFC explicitly lists it as lowercase in the ABNF syntax.
By: khb (khb) 2005-03-19 14:43:01.000-0600

If that holds true, then you are right.  But I think parameter labels are not to be interpreted to be case sensitive.  Have to check again.
By: Kevin P. Fleming (kpfleming) 2005-03-19 14:53:24.000-0600

I've just re-read the ABNF notes, and you are right... tokens are case-insensitive, unless otherwise specified. For SIP, that means header field names and method names are fixed-case and _must_ match the RFC. Pretty much everything else can be in any case.

edited on: 03-19-05 14:56
By: khb (khb) 2005-03-19 15:01:07.000-0600

Uhm, no.
Header field names (the names of the header lines) still are case insensitive.
By: Kevin P. Fleming (kpfleming) 2005-03-19 15:04:47.000-0600

Yeah, that too... I need a nap :-)
By: Olle Johansson (oej) 2005-03-19 15:28:06.000-0600

I agree with this patch. Recommend it for CVS!
By: Mark Spencer (markster) 2005-03-19 18:00:40.000-0600

Applying this patch cannot improve interoperability, it can only hurt it, so I see no reason to add it.
By: khb (khb) 2005-03-19 18:09:23.000-0600

Upon double checking, I have withdrawn 2 hunks of the patch, since it is specified that the SIP version should be parsed case-insensitively, but MUST be sent uppercase always.
By: khb (khb) 2005-03-19 18:10:36.000-0600

Allowing non-compliant behavior always hurts interoperability.
By: Kevin P. Fleming (kpfleming) 2005-03-19 18:11:57.000-0600

RFC compliance is a nasty game to get into, that's for sure :-)
By: Olle Johansson (oej) 2005-03-19 18:20:34.000-0600

Changing my view: MikeJ quoting Jon Postel seems like a good way of doing it. We can add comments that says someething like "ALWAYS send SIP methods in UPPER CASE" and another saying "Even though we should only receive upper case methods, we're nice and accept any case". So if someone reads our source code for reference, they will still learn the proper behaviour.
By: khb (khb) 2005-03-19 18:40:05.000-0600

The first "word" or the first few bytes of a SIP message are particularly sensitive to parsing issues. They establish a signature of the protocol in use, and are sometimes used to sort traffic in multi-protocol applications.
In SIP this can for instance be the distinquishing mark between a SIP protocol packet and an ICE type packet, since that requires both servers to run on the same port. Of course we don't have that problem yet, here, but accepting non-compliant behavior can make things unnessarily obscure, if one party follows standards strictly and another does not.
By: Mark Spencer (markster) 2005-03-19 18:55:22.000-0600

Outside of the BNF this isn't even mentioned.  I did add a comment to say they are case sensitive, but I will not change things *just* to cause it to fail talking to a broken implementation with no other benefit.
By: Digium Subversion (svnbot) 2008-01-15 15:27:57.000-0600

Repository: asterisk
Revision: 5209

U   trunk/channels/chan_sip.c

------------------------------------------------------------------------
r5209 | markster | 2008-01-15 15:27:57 -0600 (Tue, 15 Jan 2008) | 2 lines

Comment on sensitivity (bug ASTERISK-3712)

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

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