[asterisk-dev] [Code Review] Add interoperability friendly option to SIP peers in order to cull semicolon delimited values from the URI

Tue Apr 19 08:08:16 CDT 2011

> On 2011-04-18 15:16:58, Terry Wilson wrote:
> > 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.
> 
> jrose wrote:
>     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.
> 
> jrose wrote:
>     And rereading what you just wrote, that's pretty much exactly what you said.  Oi, I'm a little tired.
> 
> Olle E Johansson wrote:
>     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.
>

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

- Terry

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

On 2011-04-18 14:53:48, jrose wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/1188/
> -----------------------------------------------------------
> 
> (Updated 2011-04-18 14:53:48)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Summary
> -------
> 
> Adds a new option to SIP peers in order to truncate the semicolon delimited values in the URI so that devices which generate semicolon delimited values (like the Sonus mentioned in the bug report) can connect to an extension properly without forcing pattern matching and employing weird workarounds with the extension value every time it is used in the dialplan.
> 
> In order to add it to a peer, place the following in sip.conf:
> ignore_uri_sem=yes
> 
> By default it is off, naturally.
> 
> 
> This addresses bug 18344.
>     https://issues.asterisk.org/view.php?id=18344
> 
> 
> Diffs
> -----
> 
>   /branches/1.8/channels/chan_sip.c 313867 
>   /branches/1.8/channels/sip/include/sip.h 313867 
> 
> Diff: https://reviewboard.asterisk.org/r/1188/diff
> 
> 
> Testing
> -------
> 
> Used sipp to make a phone call using the following xml:
> --------------------------------------
> <?xml version="1.0" encoding="ISO-8859-1" ?>
> <!DOCTYPE scenario SYSTEM "sipp.dtd">
> 
> <scenario name="UAC OPTIONS">
>     <send retrans="500"> <![CDATA[
> 
>         INVITE sip:2005;phone-context=+1;npdi=yes@[remote_ip]:[remote_port] SIP/2.0
>         Via: SIP/2.0/[transport] [local_ip]:[local_port];branch=[branch]
>         From: "Lrrrr Schmrrr" <sip:sipp@[local_ip]:[local_port]>;tag=[call_number]
>         To: Asterisk <sip:2005;phone-context=+1;npdi=yes@[remote_ip]:[remote_port]>
>         Call-ID: [call_id]
>         CSeq: 1 OPTIONS
>         Contact: sip:sipp@[local_ip]:[local_port]
>         Max-Forwards: 70
>         Subject: Asterisk Testsuite
>         Content-Length: [len]
> 
>         ]]>
>     </send>
>     <recv response="200"/>
> </scenario>
> --------------------------------------
> 
> Tested those calls against dialplan as follows:
> --------------------------------------
> [sipp]
> exten => 2005,1,Answer()
> exten => 2005,2,Background(tt-weasels)
> exten => 2005,3,NoOp(callerid => ${CALLERID(all)})
> exten => 2005,n,NoOp(exten => ${EXTEN})
> exten => 2005,n,Wait(5)
> exten => 2005,n,HangUp()
> --------------------------------------
> 
> and used the following definitions of sipp in sip.conf:
> --------------------------------------
> [sipp]
> type=friend
> context=sipp
> host=dynamic
> port=6000
> user=sipp
> canreinvite=no
> diallow=all
> allow=ulaw
> ignore_uri_sem=on
> --------------------------------------
> 
> as well as ignore_uri_sem=off
> and with no ignore_uri_sem statement in the config file.
> 
> 
> Results:
> With the option on, the call gets completed as normal if the extension were just 2005.
> With the option off, the call gets interrupted with the following error message: 
> [Apr 18 14:40:58] NOTICE[16316]: chan_sip.c:21496 handle_request_invite: Call from 'sipp' to extension '2005' rejected because extension not found in context 'sipp'.
> 
> because the extension actually contains the entire URI and can't be matched in spite of it showing just 2005 above.
> 
> 
> Thanks,
> 
> jrose
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20110419/8917304a/attachment.htm>