[kamailio] Unquoted IPv6 Contact header alias parameter causes issues with Asterisk (PJSIP) & TOPOH module (#120)
When using Kamailio from the master branch, I'm encountering an issue where IPv6 contact address aliases that are added via ```set_contact_alias()``` for WebSocket connections (for example) are unquoted and create problems for Asterisk: ``` pjsip:0 <?>: sip_transport. Error processing 3633 bytes packet from UDP 10.0.0.1:5060 : PJSIP syntax error exception when parsing 'Request Line' header on line 11 col 129: ``` and TOPOH garbles the Request-URI when processing the ACK: ``` WARNING: sanity [sanity.c:236]: check_ruri_scheme(): failed to parse request uri [�a�{1me▒s�na@50�9���1.�8:�2v0;i��a��=11>7�n7x>10O�2v0~1] ```
I have tested this with CSipSimple nightly branch (PJSIP) Asterisk 13.2.0 (PJSIP), Google Chrome 41.0.2272.118, and Firefox 37 and all fail to handle the Contact alias parameter properly.
An example of an invite that shows this issue follows (this INVITE is without TOPOH on). ``` INVITE sip:testuser@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@example.com From: "WS Test User 1" sip:wstest1@example.com;tag=t5r2736hf9 Call-ID: uugmpjgjpoklrnf0um56 CSeq: 7244 INVITE Contact: sip:wstest1@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 ```
I believe that the Contact header alias parameter might need quotes in order to properly handle the bracketed IPv6 alias address, something like the following, but unfortunately I haven't been able to find evidence to be certain that this is the fix, though I do notice that parameters in headers with special characters like brackets are often quoted. ``` Contact: sip:wstest1@example.com;gr=urn:uuid:2e54e8a2-66e4-433a-a024-b57f3665a44b;alias="[2001:db8::99]~43691~6" ```
--- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/120
Parameter values for SIP URI must not be enclosed in quotes (as per sip rfc).
However, given that the IP open appear as value of a uri parameter, I would expect '[' and ']' to allowed as chars in uri parameters. The SIP grammar has to be checked.
--- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/120#issuecomment-90427590
Ok @miconda. Thanks. I'll check in with the Asterisk/PJSIP folks. There still is something strange about the TOPOH processing, however. I'll need to look more into that.
--- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/120#issuecomment-90516151
Check also/first the grammar for uri parameters in rfc3261.
--- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/120#issuecomment-90630600
Thank you for the advice, @miconda. I believe this may be a bug in PJSIP's header parsing (https://trac.pjsip.org/repos/browser/pjproject/trunk/pjsip/src/pjsip/sip_par...). I'm not a C coder, but I've learned to troll through the code until I find something reasonable. Perhaps you can spot something in there. I have requested to join the PJSIP mailing list to ask about this issue.
I asked originally about the quoting because I noticed Kamailio does quote the "received" parameter in the Contact header when it's sent back to a UAC: ``` SIP/2.0 200 OK. v: SIP/2.0/UDP 10.1.1.1:5060;rport=5060;branch=z9hG4bKPjCF9fXKT.TUYCvcI8L4gj70nJMeMYZwXR;received=10.1.1.2. f: "Test" sip:test@example.com;tag=fFfFWPFbM71fqOQLp9biV6jtcZy-M3Ja. t: "Test" sip:test@example.com;tag=ac90c8713242940d16090974f12e49d3.d0ca. i: ZU0l8HgtMQ80aFG.P6LdNwCTtFiAlTBr. CSeq: 895 REGISTER. Contact: sip:test@10.1.1.1:5060;ob;expires=900;received="sip:10.1.1.2:5060". Supported: outbound. Content-Length: 0. ```
--- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/120#issuecomment-90752535
I have asked for assistance on the PJSIP mailing list to see if any further information can be provided there: http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/2015-April/018313.htm...
Thanks for pointing me in the right direction, @miconda.
--- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/120#issuecomment-90767986
For reference, from sip grammar (rfc3261, section25):
``` uri-parameters = *( ";" uri-parameter) uri-parameter = transport-param / user-param / method-param / ttl-param / maddr-param / lr-param / other-param
other-param = pname [ "=" pvalue ] pname = 1*paramchar pvalue = 1*paramchar paramchar = param-unreserved / unreserved / escaped param-unreserved = "[" / "]" / "/" / ":" / "&" / "+" / "$" ```
Therefore '[' and ']' are allowed in uri parameter, being part of 'param-unreserved' group of chars.
--- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/120#issuecomment-90902611
Closed #120.
--- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/120#event-356167429
-
Anthony Messina -
Daniel-Constantin Mierla