> On March 21, 2014, 6:05 a.m., Corey Farrell wrote: > > /trunk/channels/sip/reqresp_parser.c, line 131 > > <https://reviewboard.asterisk.org/r/3349/diff/7/?file=56285#file56285line131> > > > > 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} > >
Return userinfo when RFC 3966 does not include neither global number, nor context. In this case hostport will not be available. Avoid NULL string reference segmentation fault by adding explicit test && (userinfo != NULL) before strstr test. - Geert ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3349/#review11312 ----------------------------------------------------------- On March 21, 2014, 8:32 a.m., Geert Van Pamel wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviewboard.asterisk.org/r/3349/ > ----------------------------------------------------------- > > (Updated March 21, 2014, 8:32 a.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 > >
-- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
