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

[jrose]

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

(Updated 2011-05-11 19:13:29.473120)


Review request for Asterisk Developers, Russell Bryant, Mark Michelson, Jared Smith, David Vossel, and leifmadsen.


Changes
-------

Added Leif and Jared


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/20110512/c77d6d8a/attachment-0001.htm>