[asterisk-dev] [Code Review] SIP user fields are crazy. Repeat extension searches if they all fail and semicolons are obfuscating the extension in the uri.

[David Vossel]

----- Original Message -----
> From: "Jonathan Rose" <jrose at digium.com>
> To: "Asterisk Developers Mailing List" <asterisk-dev at lists.digium.com>
> Sent: Thursday, May 12, 2011 2:21:39 PM
> Subject: Re: [asterisk-dev] [Code Review] SIP user fields are crazy. Repeat extension searches if they all fail and
> semicolons are obfuscating the extension in the uri.
> Alright, so then we've reached a consensus that we are basically going
> to try and specifically resolve this issue simply by having an option
> to
> split from the semi-colon only on channels specifically defined to be
> handled that way.
> 
> In that case, this is basically the same as
> https://reviewboard.asterisk.org/r/1188
> revision 2.
> 
> That leaves a couple things needing to be addressed:
> 
> The discussion on that particular revision was as follows:
> 
> -----------------------------------------------------------------------------------------
> Posted 3 weeks, 2 days ago (April 18th, 2011, 3:16 p.m.)
> Would it make sense to make this something more configurable? The ABNF
> for a SIP-URI is:
> SIP-URI = "sip:" [ userinfo ] hostport
> uri-parameters [ headers ]
> userinfo = ( user / telephone-subscriber ) [ ":" password ] "@"
> user = 1*( unreserved / escaped / user-unreserved )
> user-unreserved = "&" / "=" / "+" / "$" / "," / ";" / "?" / "/"
> 
> So down the road, it is entirely possible that someone does something
> weird like INVITE sip:user?foo=bar&bar=baz and we would need another
> workaround option.
> We could make the option something like uri_exten_terminator=?;&/ or
> something since you are matching with strpbrk anyway. Of course, then
> someone might say
> that we need to have an option to do regex matches on URIs. Then
> someone else will point out the limitations of regexes. :-p But, it
> seems like a cheap and
> easy change that doesn't make things any more confusing. Others may
> disagree
> 1.
> jrose 3 weeks, 2 days ago (April 18th, 2011, 3:40 p.m.)
> I suppose it wouldn't be hard at all to have an option like...
> 
> uri_break_characters=;:/
> instead. Especially since the method this uses for terminating is
> strpbrk against ";" on the uri string. I wouldn't have to do a whole
> lot to change it.
> 
> I really don't know for certain though what the best option for this
> is. I'm still pretty green when it comes to SIP and the various
> scenarios we might encounter with it.
> 1.
> jrose 3 weeks, 2 days ago (April 18th, 2011, 3:41 p.m.)
> And rereading what you just wrote, that's pretty much exactly what you
> said. Oi, I'm a little tired.
> 1.
> Olle E Johansson 3 weeks, 2 days ago (April 19th, 2011,
> 1:24 a.m.)
> I think this is a bug. The URI username options - which this seems to
> be about - should be removed from the actual extension. Maybe be put
> in a variable for later processing, like SIPFULLUSERNAME (username AND
> options) or SIPUSERNAMEOPTIONS - just the options. That way, I could
> restore them on the outbound call leg if needed.
> 
> Please test with 1.4 to compare behaviours.
> 
> Terry - the Username options is not part of your ABNF because it was
> added in a later RFC.
> 1.
> Terry Wilson 3 weeks, 2 days ago (April 19th, 2011, 8:08
> a.m.)
> Agreed. We never should have been matching these to an extension in
> the first place; it is a bug, so we probably don't even need to make
> this optional. We also shouldn't just completely throw them away,
> either. We have a function in channels/sip/reqresp_parser.c named
> parse_uri_full() that seems to break everything up into its
> constituent parts. I don't think we've ever used it though. If we did
> parse it all out and store it, it would make it easily available for
> getting/setting via dialplan variables, functions, etc. For reference,
> RFC 3261 19.1.1
> 
> -----------------------------------------------------------------------------------------------
> 
> With that in mind, should I still be bothering to preserve these user
> parameters, and should I bother to separate on any additional
> characters? After looking over the RFCs, I was heavily under the
> impression that only a semicolon would be used to distinguish the
> beginning of a user parameter, all of which would be at the end of the
> actual user. This was all in a different section of the RFCs though,
> pertaining to the conversion of TEL URIs to SIP URIs.
> 
> 

Nope, just make the option strip off and discard everything after the ';' in the userfield.  It doesn't need to be any more complicated than that for now.  This is just an interoperability patch that allows people with devices that generate URI's that look like this to use them and pattern match the way they expect them to.  If people don't want to use this option, they don't have to.  If people want it to do more in the future, then we'll tackle that when the actual situation occurs.   This is not a standardized thing, there's no pattern to follow here.  This fix is very much dictated by what gets people's real world devices working with Asterisk, and right now that is a sip.conf option that strips off everything after the ';' of a user field.

-- 
David Vossel
Digium, Inc. | Software Developer, Open Source Software
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: www.digium.com & www.asterisk.org
The_Boy_Wonder in #asterisk-dev