[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.

Wed May 11 14:52:42 CDT 2011

> On 2011-05-11 14:42:52, Jared Smith wrote:
> > I've admittedly been away from the Asterisk development community for a while, but I have to admit that I'm confused by the need for this particular patch.
> > 
> > The dialplan already has several capable tools for dealing with this sort of situation (using pattern matches, regular expression operators, CUT(), FIELDQTY(), and/or FILTER() just to name a few).  Is there really a need to have this sort of thing done automagically by the extension matching code in Asterisk?
> > 
> > Yes, I can see how the pattern matching algorithm changed between 1.4 and later versions -- this was done very deliberately, and I personally think we're much better off because of it.  (I could spend half a day talking about the intricacies of the pattern matching and how it's *so* much better now.)  At the very least, I'd argue that if you're serious about adding this patch, that the principle of least surprise says you also add a flag (to either the [general] section of extensions.conf or to the [options] section of asterisk.conf) to enable the patch -- otherwise, you're going to catch creative folks like me off guard.  
> > 
> > Besides -- I'm not sure the group of us can really enumerate all the different ways we might want to strip off part of the extension, or what characters we might want to split it on, or whether we want to somehow capture the pieces that have been split off.  Today it's a semicolon, but tomorrow -- who knows?  Instead of trying to hard-code one particular case, I'd feel much more comfortable making sure that the end users have the tools they need to do exactly what they want, and the knowledge on how to use said tools.

I've talked to both Jonathan and Jared about this, and I think we're pretty much on the same page here. The main reason I'm not in favor of this change (and I wish I had realized what Jonathan was working on prior to today so I could have saved him the time) is that, as Jared alludes to, we have all the tools to deal with this change already. I would hate to over-engineer something that can be dealt with fairly trivially in the dialplan.

Lets say the example is we're getting something like 1234;phonecontext=incoming as the extension, and we only care about the 1234 part. Well we can simply use the CUT() function to get everything to the left of the semicolon. I believe this would work:

[incoming]
exten => _XXXX.,1,NoOp()
same => n,Set(RequestedExten=${CUT(EXTEN,\;,1)})
same => n,Goto(CallMangler,${RequestedExten},1)

[CallMangler]
exten => _XXXX,1,NoOp()
same => n,NoOp(Continue to be awesome)

Of course the dialplan could be made more elaborate to make sure we have a value to go to, that the extension exists, that the value is a number, and all sorts of things. All of this can already be done in the dialplan, and can be controlled by the administrator based on what they expect (and don't expect) their end points to send.

- Leif

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/1214/#review3528
-----------------------------------------------------------

On 2011-05-11 09:46:56, jrose wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/1214/
> -----------------------------------------------------------
> 
> (Updated 2011-05-11 09:46:56)
> 
> 
> Review request for Asterisk Developers, Russell Bryant, Mark Michelson, and David Vossel.
> 
> 
> Summary
> -------
> 
> This is sort of a natural follow-up to https://reviewboard.asterisk.org/r/1188/
> 
> Reading over RFC3261 and talking to mmichelson made the following things clear to me:
> 
> 1.  semi-colons are allowed in the user field of the uri.  In fact, the very data I was trying to parse out is described as belonging in the user field by pages 156-158.
> 2.  Theoretically, a user could make an extension something like 2005;bunch-of-uri-user-parameters
> 3.  Since that's the case, simply parsing out this data before it ever gets used by anything based on semicolons could interfere with current behavior.
> 
> What I did to address it:
> 
> 1.  In the case of the user field in the uri from the bug...
> "4254883646;phone-context=+1;npdi=yes" -- Asterisk needs to match 4254883646.  Since this can't be safely removed in parsing, there is now a fail-triggered semi-colon delimited removal
> performed in chan_sip's get_destination.  If no extensions are made before it reaches the end, we check to see if there was a semicolon in the uri/decoded uri and if there was, we start the searches
> over again with the uri terminated at the first semicolon.
> 
> 2.  If one of those uri semicolons is found, we preserve that data within a string field which can be accessed from the channel function.
> 
> 3.  A test was added to check that teluris that are converted into sip uris are read like it appears they should according to RFC3261.
> 
> 
> This addresses bug 18344.
>     https://issues.asterisk.org/view.php?id=18344
> 
> 
> Diffs
> -----
> 
>   /branches/1.8/channels/chan_sip.c 318337 
>   /branches/1.8/channels/sip/dialplan_functions.c 318337 
>   /branches/1.8/channels/sip/include/sip.h 318337 
>   /branches/1.8/channels/sip/reqresp_parser.c 318337 
>   /branches/1.8/funcs/func_channel.c 318337 
> 
> Diff: https://reviewboard.asterisk.org/r/1214/diff
> 
> 
> Testing
> -------
> 
> I tested to make sure it didn't interfere with regular dialing behavior of sip phones by using one of my own sip phones.
> 
> I tested the basic behavior by forcing the following sip message using sipp:
> 
> INVITE sip:2005;phone-context=+1;npdi=yes at 127.0.0.1:5060 SIP/2.0
> Via: SIP/2.0/UDP 127.0.1.1:5062;branch=z9hG4bK-23024-1-0
> From: "Lrrrr Schmrrr" <sip:sipp at 127.0.1.1:5062>;tag=1
> To: Asterisk <sip:2005:whoop;phone-context=+1;npdi=yes at 127.0.0.1:5060>
> Call-ID: 1-23024 at 127.0.1.1
> CSeq: 1 OPTIONS
> Contact: sip:sipp at 127.0.1.1:5062
> Max-Forwards: 70
> Subject: Asterisk Testsuite
> Content-Length: 0
> 
> And using this dialplan setup I'd check to make sure values were what I expected:
> [sipp]
> exten => 2005,1,Answer()
> exten => 2005,n,Background(tt-weasels)
> exten => 2005,n,NoOp(callerid => ${CALLERID(all)})
> exten => 2005,n,NoOp(exten => ${EXTEN})
> exten => 2005,n,NoOp(uri => ${CHANNEL(uri)})
> exten => 2005,n,NoOp(user_options => ${CHANNEL(uri_user_parameters)})
> exten => 2005,n,Wait(1)
> exten => 2005,n,HangUp()
> 
> yielding these results:
>    -- Executing [2005 at sipp:1] Answer("SIP/sipp-00000000", "") in new stack
>     -- Executing [2005 at sipp:2] BackGround("SIP/sipp-00000000", "tt-weasels") in new stack
>     -- <SIP/sipp-00000000> Playing 'tt-weasels.gsm' (language 'en')
>     -- Executing [2005 at sipp:3] NoOp("SIP/sipp-00000000", "callerid => "Lrrrr Schmrrr" <sipp>") in new stack
>     -- Executing [2005 at sipp:4] NoOp("SIP/sipp-00000000", "exten => 2005") in new stack
>     -- Executing [2005 at sipp:5] NoOp("SIP/sipp-00000000", "uri => sip:sipp at 127.0.1.1:5062") in new stack
>     -- Executing [2005 at sipp:6] NoOp("SIP/sipp-00000000", "user_options => phone-context=+1;npdi=yes") in new stack
>     -- Executing [2005 at sipp:7] Wait("SIP/sipp-00000000", "1") in new stack
>     -- Executing [2005 at sipp:8] Hangup("SIP/sipp-00000000", "") in new stack
> 
> I was paranoid that my goto statement would potentially cause a memory leak, so I also compared "memory show summary chan_sip.c" before and after the channel lived for both the case of the normal call and the case where it has to do the repetition with goto.  I repeated the process with pbx.c and likewise saw no memory leak (though I thought I did at first when 4 allocations were made to pbx.c, but it turned out to be unrelated since I performed the test while creating hundreds of similar sip channels and saw no additional increases)  Still, it's something worth looking at since I'm still rather likely to miss that sort of thing.
> 
> 
> Thanks,
> 
> jrose
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20110511/eb35f37a/attachment-0001.htm>