Summary: | ASTERISK-25123: Bracketed IPv6 Contact header parameter unparsable with Asterisk/PJSIP | ||
Reporter: | Anthony Messina (amessina) | Labels: | |
Date Opened: | 2015-05-23 10:25:20 | Date Closed: | 2016-04-20 08:18:57 |
Priority: | Major | Regression? | |
Status: | Closed/Complete | Components: | Resources/res_pjsip |
Versions: | 13.3.2 | Frequency of Occurrence | Constant |
Related Issues: | |||
Environment: | Fedora 21 x86_64 branches/13 @ eaabc4d | Attachments: | |
Description: | In the underlying PJSIP implementation, there is an issue parsing header parameter values if the parameter value contains a bracketed IPv6 address.
I am reporting this issue as it affects Asterisk and I have not had any luck since I originally reported the issue to PJSIP without response here: http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/2015-April/018313.html. I have tracked down what seems to be the offending code block and offered a patch here http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/2015-May/018386.html that "resolves" the issue, but probably isn't the right resolution. I have also reported the issue to Kamailio here https://github.com/kamailio/kamailio/issues/120. This issue also affects other SIP software using the PJSIP stack, such as CSipSimple and came up during my WebRTC Kamailio-Asterisk integration. In many cases WebSocket connections need to be treated as though they are NATed and Kamailio has good support for this in part by adding a Contact header alias parameter which looks something like the following: {code} Contact: <sip:wstest1 at example.com;gr=urn:uuid:2e54e8a2-66e4-433a-a024- b57f3665a44b;alias=[2001:db8::99]~43691~6> {code} Unfortunately, PJSIP (both in Asterisk 13.3.2 and CSipSimple nightly build) chokes when parsing the 'alias' parameter, giving the following error: PJSIP syntax error exception when parsing 'Request Line' header on line 11 col 105: Where line 11 is the Contact header, and column 105 is the '4' immediately after {code}alias=[2001:db8::99]~{code} in the Contact header. As such, the INVITE never receives any response and is re transmitted by the caller over and over. The full example SIP INVITE is as follows: {code} INVITE sip:testuser at example.com SIP/2.0 Record-Route: <sip:10.0.0.1;r2=on;lr=on;ftag=t5r2736hf9;nat=yes> Record-Route: <sip: [2001:db8::98]:5061;transport=ws;r2=on;lr=on;ftag=t5r2736hf9;nat=yes> Via: SIP/2.0/UDP 10.0.0.1;branch=z9hG4bKa3e8.2bb6508fbc0cf8cc55c1eb6c0eca0b38.0 Via: SIP/2.0/WSS 2e6orc23ptjv.invalid;rport=43691;received=2001:db8::99;branch=z9hG4bK450538 Max-Forwards: 69 To: <sip:testuser at example.com> From: "WS Test User 1" <sip:wstest1 at example.com>;tag=t5r2736hf9 Call-ID: uugmpjgjpoklrnf0um56 CSeq: 7244 INVITE Contact: <sip:wstest1 at example.com;gr=urn:uuid:2e54e8a2-66e4-433a-a024- b57f3665a44b;alias=[2001:db8::99]~43691~6> Allow: ACK,CANCEL,BYE,OPTIONS,INFO,NOTIFY,INVITE Content-Type: application/sdp Supported: gruu,outbound User-Agent: SIP.js/0.6.4 Content-Length: 2768 v=0 o=- 867554869709517848 2 IN IP4 10.0.0.1 s=- t=0 0 a=msid-semantic: WMS livWfUwMWQJMemgnFyBQDf1VXUo9Q0AXwHnH m=audio 30158 RTP/SAVP 111 103 104 9 0 8 106 105 13 126 c=IN IP4 10.0.0.1 a=rtpmap:111 opus/48000/2 a=fmtp:111 minptime=10; useinbandfec=1 a=rtpmap:103 ISAC/16000 a=rtpmap:104 ISAC/32000 a=rtpmap:9 G722/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:106 CN/32000 a=rtpmap:105 CN/16000 a=rtpmap:13 CN/8000 a=rtpmap:126 telephone-event/8000 a=maxptime:60 a=ssrc:1444733772 cname:CuBdEZ9bIWQc1sE+ a=ssrc:1444733772 msid:livWfUwMWQJMemgnFyBQDf1VXUo9Q0AXwHnH ebd0066b-73b9-467c-b696-36e0fa7d72b7 a=ssrc:1444733772 mslabel:livWfUwMWQJMemgnFyBQDf1VXUo9Q0AXwHnH a=ssrc:1444733772 label:ebd0066b-73b9-467c-b696-36e0fa7d72b7 a=sendrecv a=rtcp:30159 a=rtcp-mux a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:/fmyETo1BwAlupltb64sy5Za6e37BW0p5jMmvqHU a=setup:actpass a=fingerprint:sha-1 76:27:60:1E:64:94:B4:6E:8A:64:72:2D:41:2C:B8:F3:FF:4C:1D:56 a=ice-ufrag:U4XlaM4U a=ice-pwd:HqnTPTU5DY3j1yB4XVEL9rs1tn a=candidate:vVzo18e51E8EXCNy 1 UDP 2130706431 10.0.0.1 30158 typ host a=candidate:vVzo18e51E8EXCNy 2 UDP 2130706430 10.0.0.1 30159 typ host a=candidate:xCpWH2paVucFSQXn 1 UDP 2130706175 2001:db8::1 30158 typ host a=candidate:xCpWH2paVucFSQXn 2 UDP 2130706174 2001:db8::1 30159 typ host m=video 30196 RTP/SAVP 100 116 117 96 c=IN IP4 10.0.0.1 a=rtpmap:100 VP8/90000 a=rtcp-fb:100 ccm fir a=rtcp-fb:100 nack a=rtcp-fb:100 nack pli a=rtcp-fb:100 goog-remb a=rtpmap:116 red/90000 a=rtpmap:117 ulpfec/90000 a=rtpmap:96 rtx/90000 a=fmtp:96 apt=100 a=ssrc-group:FID 616715905 3177427003 a=ssrc:616715905 cname:CuBdEZ9bIWQc1sE+ a=ssrc:616715905 msid:livWfUwMWQJMemgnFyBQDf1VXUo9Q0AXwHnH bb5df7ec-28a9-4e94-89a3-2ebb45a9f5bb a=ssrc:616715905 mslabel:livWfUwMWQJMemgnFyBQDf1VXUo9Q0AXwHnH a=ssrc:616715905 label:bb5df7ec-28a9-4e94-89a3-2ebb45a9f5bb a=ssrc:3177427003 cname:CuBdEZ9bIWQc1sE+ a=ssrc:3177427003 msid:livWfUwMWQJMemgnFyBQDf1VXUo9Q0AXwHnH bb5df7ec-28a9-4e94-89a3-2ebb45a9f5bb a=ssrc:3177427003 mslabel:livWfUwMWQJMemgnFyBQDf1VXUo9Q0AXwHnH a=ssrc:3177427003 label:bb5df7ec-28a9-4e94-89a3-2ebb45a9f5bb a=sendrecv a=rtcp:30197 a=rtcp-mux a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:qQRmOwum0YFHgKKzt2dRX0uAQhSwlmxscI3P3JUI a=setup:actpass a=fingerprint:sha-1 76:27:60:1E:64:94:B4:6E:8A:64:72:2D:41:2C:B8:F3:FF:4C:1D:56 a=ice-ufrag:ISaptX08 a=ice-pwd:mxP343kHexU8SwtbCeRj4WyMNI a=candidate:vVzo18e51E8EXCNy 1 UDP 2130706431 10.0.0.1 30196 typ host a=candidate:vVzo18e51E8EXCNy 2 UDP 2130706430 10.0.0.1 30197 typ host a=candidate:xCpWH2paVucFSQXn 1 UDP 2130706175 2001:db8::1 30196 typ host a=candidate:xCpWH2paVucFSQXn 2 UDP 2130706174 2001:db8::1 30197 typ host {code} | ||
Comments: | By: George Joseph (gjoseph) 2016-04-12 16:37:42.480-0500 Anthony, Look under "Gerrit Reviews" for a patch to 13 and master. It's basically your original patch. :) Also the issue with Via/received from over the weekend is fixed and already committed. By: Anthony Messina (amessina) 2016-04-15 22:34:54.576-0500 Your bundled pjproject patches seem to have resolved this issue. Thank you. |