[asterisk-dev] [Code Review] Yet Another Whack at the SIP user options issue.

[David Vossel]

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

Ship it!


Great work! I don't like that this involves another wrapper around the sip_parsing function, but with that said I can't even convince myself that this belongs in the parse_uri either.  What you have here works. If it needs to do something different in the future we'll do it then.  No sense and making this any more complicated.


/branches/1.8/configs/sip.conf.sample
<https://reviewboard.asterisk.org/r/1223/#comment7251>

    Use spaces on these lines instead of tabs.


- David


On 2011-05-19 14:02:21, jrose wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/1223/
> -----------------------------------------------------------
> 
> (Updated 2011-05-19 14:02:21)
> 
> 
> Review request for Asterisk Developers, Russell Bryant, David Vossel, and Leif Madsen.
> 
> 
> Summary
> -------
> 
> A quick recap:
> As of Asterisk 1.8, semicolons in user fields are accepted as just part of the user field in compliance with RFC 3261.  This makes devices that employ those options unable to register and also unable to match intended extensions without dialplan workarounds.
> 
> This approach involves a global sip option (if it were done per channel, we couldn't match on registers unfortunately) to strip the semicolons in the same general way as it was done in 1.6.2.  For that reason I chose to call it legacyuseroptionparsing
> 
> 
> This addresses bug 18344.
>     https://issues.asterisk.org/view.php?id=18344
> 
> 
> Diffs
> -----
> 
>   /branches/1.8/channels/chan_sip.c 319526 
>   /branches/1.8/channels/sip/include/sip.h 319526 
>   /branches/1.8/configs/sip.conf.sample 319526 
> 
> Diff: https://reviewboard.asterisk.org/r/1223/diff
> 
> 
> Testing
> -------
> 
> Made sure matches while the option were on would happen with the following using sipp:
> 
> 
>         REGISTER sip:localhost SIP/2.0
>         Via: SIP/2.0/[transport] [local_ip]:[local_port];branch=[branch]
> 		To: "Jonathan" <sip:evilhost;garbage@[local_ip]:[local_port]>
>         From: "Jonathan" <sip:evilhost;garbage@[local_ip]:[local_port]>;tag=[call_number]
> 
>         Call-ID: [call_id]
>         CSeq: 1 REGISTER
>         Contact: sip:evilhost@[local_ip]:[local_port];expires=3600
>         ALLOW: INVITE,ACK,BYE,CANCEL,OPTIONS,PRACK,REFER,NOTIFY,SUBSCRIBE,INFO,MESSAGE
> 		User-Agent: Sipp
>         Content-Length: [len]
> 
> And
> 
> 
>         INVITE sip:2005;5002;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;5002;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]
> 
> 
> Also that they also acted the same as the way they acted before with the option off.
> 
> 
> Thanks,
> 
> jrose
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20110519/2c5f5016/attachment.htm>