[asterisk-dev] [Code Review] 3349: Implement RFC-3966 TEL URI incoming INVITE

[Corey Farrell]

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



/trunk/channels/sip/reqresp_parser.c
<https://reviewboard.asterisk.org/r/3349/#comment20956>

    I'm getting a segfault with the test "tel:911".  userinfo == NULL causes strchr to segfault on Ubuntu x86_64 (eglibc 2.17).  I believe we need to add:
    userinfo = uri = "";
    
    blank userinfo to prevent the segfault, blank uri to prevent "911" from being returned in residue.
    
    
    Program received signal SIGSEGV, Segmentation fault.
    __strchr_sse2 () at ../sysdeps/x86_64/multiarch/../strchr.S:32
    32	../sysdeps/x86_64/multiarch/../strchr.S: No such file or directory.
    (gdb) bt full
    #0  __strchr_sse2 () at ../sysdeps/x86_64/multiarch/../strchr.S:32
    No locals.
    #1  0x00007fff88f2e52a in parse_uri_full (uri=0x7fffffffb7d4 "911", scheme=0x7fff88f5661e "sip:,sips:,tel:", user=0x7fffffffb7a0, pass=0x7fffffffb7a8, hostport=0x7fffffffb7b0, params=0x7fffffffb730, 
        headers=0x7fffffffb728, residue=0x0) at sip/reqresp_parser.c:149
            userinfo = 0x0
            parameters = 0x0
            endparams = 0x0
            c = 0x0
            error = -1
            teluri_scheme = 1
            __PRETTY_FUNCTION__ = "parse_uri_full"
    #2  0x00007fff88f2f90e in parse_uri (uri=0x7fffffffb7d0 "tel:911", scheme=0x7fff88f5661e "sip:,sips:,tel:", user=0x7fffffffb7a0, pass=0x7fffffffb7a8, hostport=0x7fffffffb7b0, transport=0x7fffffffb7b8)
        at sip/reqresp_parser.c:524
            ret = -1
            headers = 0x7fff88f55f57 ""
            params = {transport = 0x7fff88f55f57 "", user = 0x7fff88f55f57 "", method = 0x29e88f55f57 <Address 0x29e88f55f57 out of bounds>, 
              ttl = 0x7fff88f583a0 <__PRETTY_FUNCTION__.27916> "sip_parse_uri_test", maddr = 0x7fff88f55e24 "sip/reqresp_parser.c", lr = -1997185193}
    


- Corey Farrell


On March 20, 2014, 5:59 p.m., Geert Van Pamel wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3349/
> -----------------------------------------------------------
> 
> (Updated March 20, 2014, 5:59 p.m.)
> 
> 
> Review request for Asterisk Developers, Corey Farrell, lmadensen, Matt Jordan, and wdoekes.
> 
> 
> Bugs: ASTERISK-17179
>     https://issues.asterisk.org/jira/browse/ASTERISK-17179
> 
> 
> Repository: Asterisk
> 
> 
> Description
> -------
> 
> Implements RFC-3966 TEL URI incoming INVITE.
> 
> See https://issues.asterisk.org/jira/browse/ASTERISK-17179 for a description of the original isssue.
> 
> I have been patching all versions since Asterisk 1.6. I would like to include the code into the main trunk for version 13.
> 
> Previously Asterisk was failing with error on incoming IMS call:
> 
> Nov 13 17:52:05 NOTICE[27459]: chan_sip.c:6973 check_user_full: From address missing 'sip:', using it anyway
> 
> Nov 13 17:52:05 WARNING[27459]: chan_sip.c:6525 get_destination: Huh? Not a SIP header (tel:0987654321;phone-context=+32987654321)?
> 
> Reason: tel: protocol was not recognized.
> 
> 
> Diffs
> -----
> 
>   /trunk/channels/sip/reqresp_parser.c 410429 
>   /trunk/channels/chan_sip.c 410429 
> 
> Diff: https://reviewboard.asterisk.org/r/3349/diff/
> 
> 
> Testing
> -------
> 
> Executed an incoming TEL URI INVITE connection.
> CLI was present on the display and in the CDR file.
> No errors on SIP debug output.
> 
> 
> File Attachments
> ----------------
> 
> RFC-3966 tel URI patch
>   https://reviewboard.asterisk.org/media/uploaded/files/2014/03/13/cad7a996-88c1-47fe-a2a9-cc6987af3b75__rfc-3966-tel-uri-patch-diff.txt
> 
> 
> Thanks,
> 
> Geert Van Pamel
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20140321/f70e74f7/attachment-0001.html>