Unquoted IPv6 Contact header alias parameter causes issues with Asterisk (PJSIP) & TOPOH module

[amessina]

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">

[miconda]

Parameter values for SIP URI must not be enclosed in quotes (as per sip rfc).

However, given that the IP ofen appear as value of a uri parameter, I would expect '[' and ']' to be allowed as chars in uri parameters. The SIP grammar has to be checked.

[amessina]

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.

[miconda]

Check also/first the grammar for uri parameters in rfc3261.

[amessina]

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_parser.c#L1128). 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.

[amessina]

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

Thanks for pointing me in the right direction, @miconda.

[miconda]

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.