I've been working on Kamailio websocket integration and I believe I'm having issues with the IPv6 address representation in the Contact header's alias parameter. After Googling, it appears after https://github.com/kamailio/kamailio/commit/814c08f3 the IPv6 contact is represented in brackets []. However, it when using websockets, and the alias= parameter uses brackets [] around and IPv6 address, there are message parsing issues.
With a header such as the following Contact: sip:wstest1@example.com;gr=urn:uuid:26140e27-0ab7-4e65-98e3-3d0909b1434e;alias=[2001:db8:0:1]~48768~6
Asterisk 13.2.0 will give the following error: pjsip:0 <?>: sip_transport. Error processing 1855 bytes packet from UDP 10.77.79.3:5060 : PJSIP syntax error exception when parsing 'Request Line' header on line 12 col 129:
And when sipjs, or jssip are used with either Firefox or Chrome, they send garbage in the ACK request URI:
Kamailio logs something like the following and the ACK cannot be processed: 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]
Is it proper to have [] brackets around the IPv6 alias address in the Contact header? Does the value need to be quoted?
If I force the browser to use IPv4, without changing anything else, both jssip and sipjs work perfectly in Firefox and Chrome.
On Sunday, March 29, 2015 05:23:26 PM Anthony Messina wrote:
I've been working on Kamailio websocket integration and I believe I'm having issues with the IPv6 address representation in the Contact header's alias parameter. After Googling, it appears after https://github.com/kamailio/kamailio/commit/814c08f3 the IPv6 contact is represented in brackets []. However, it when using websockets, and the alias= parameter uses brackets [] around and IPv6 address, there are message parsing issues.
With a header such as the following Contact: sip:wstest1@example.com;gr=urn:uuid:26140e27-0ab7-4e65-98e3-3d0909b1434e;al ias=[2001:db8:0:1]~48768~6
Asterisk 13.2.0 will give the following error: pjsip:0 <?>: sip_transport. Error processing 1855 bytes packet from UDP 10.77.79.3:5060 : PJSIP syntax error exception when parsing 'Request Line' header on line 12 col 129:
And when sipjs, or jssip are used with either Firefox or Chrome, they send garbage in the ACK request URI:
Kamailio logs something like the following and the ACK cannot be processed: 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]
Is it proper to have [] brackets around the IPv6 alias address in the Contact header? Does the value need to be quoted?
If I force the browser to use IPv4, without changing anything else, both jssip and sipjs work perfectly in Firefox and Chrome.
It seems that the topoh module doesn't cope with this well. Disabling the topoh module seems to resolve the issue, unfortunately.
On Sunday, March 29, 2015 08:57:44 PM Anthony Messina wrote:
On Sunday, March 29, 2015 05:23:26 PM Anthony Messina wrote:
I've been working on Kamailio websocket integration and I believe I'm having issues with the IPv6 address representation in the Contact header's alias parameter. After Googling, it appears after https://github.com/kamailio/kamailio/commit/814c08f3 the IPv6 contact is represented in brackets []. However, it when using websockets, and the alias= parameter uses brackets [] around and IPv6 address, there are message parsing issues.
With a header such as the following Contact: <sip:wstest1@example.com;gr=urn:uuid:26140e27-0ab7-4e65-98e3-3d0909b1434e; al ias=[2001:db8:0:1]~48768~6>
Asterisk 13.2.0 will give the following error: pjsip:0 <?>: sip_transport. Error processing 1855 bytes packet from UDP 10.77.79.3:5060 : PJSIP syntax error exception when parsing 'Request Line' header on line 12 col 129:
And when sipjs, or jssip are used with either Firefox or Chrome, they send garbage in the ACK request URI:
Kamailio logs something like the following and the ACK cannot be processed: 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]
Is it proper to have [] brackets around the IPv6 alias address in the Contact header? Does the value need to be quoted?
If I force the browser to use IPv4, without changing anything else, both jssip and sipjs work perfectly in Firefox and Chrome.
It seems that the topoh module doesn't cope with this well. Disabling the topoh module seems to resolve the issue, unfortunately.
I've added some additional information and an example INVITE here: https://github.com/kamailio/kamailio/issues/120
On 07/04/15 05:32, Anthony Messina wrote:
On Sunday, March 29, 2015 08:57:44 PM Anthony Messina wrote:
On Sunday, March 29, 2015 05:23:26 PM Anthony Messina wrote:
I've been working on Kamailio websocket integration and I believe I'm having issues with the IPv6 address representation in the Contact header's alias parameter. After Googling, it appears after https://github.com/kamailio/kamailio/commit/814c08f3 the IPv6 contact is represented in brackets []. However, it when using websockets, and the alias= parameter uses brackets [] around and IPv6 address, there are message parsing issues.
With a header such as the following Contact: <sip:wstest1@example.com;gr=urn:uuid:26140e27-0ab7-4e65-98e3-3d0909b1434e; al ias=[2001:db8:0:1]~48768~6>
Asterisk 13.2.0 will give the following error: pjsip:0 <?>: sip_transport. Error processing 1855 bytes packet from UDP 10.77.79.3:5060 : PJSIP syntax error exception when parsing 'Request Line' header on line 12 col 129:
And when sipjs, or jssip are used with either Firefox or Chrome, they send garbage in the ACK request URI:
Kamailio logs something like the following and the ACK cannot be processed: 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]
Is it proper to have [] brackets around the IPv6 alias address in the Contact header? Does the value need to be quoted?
If I force the browser to use IPv4, without changing anything else, both jssip and sipjs work perfectly in Firefox and Chrome.
It seems that the topoh module doesn't cope with this well. Disabling the topoh module seems to resolve the issue, unfortunately.
I've added some additional information and an example INVITE here: https://github.com/kamailio/kamailio/issues/120
Wrote in the issue page as well:
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.
Cheers, Daniel
On Tuesday, April 07, 2015 09:42:00 AM Daniel-Constantin Mierla wrote:
On 07/04/15 05:32, Anthony Messina wrote:
On Sunday, March 29, 2015 08:57:44 PM Anthony Messina wrote:
On Sunday, March 29, 2015 05:23:26 PM Anthony Messina wrote:
I've been working on Kamailio websocket integration and I believe I'm having issues with the IPv6 address representation in the Contact header's alias parameter. After Googling, it appears after https://github.com/kamailio/kamailio/commit/814c08f3 the IPv6 contact is represented in brackets []. However, it when using websockets, and the alias= parameter uses brackets [] around and IPv6 address, there are message parsing issues.
With a header such as the following Contact: <sip:wstest1@example.com;gr=urn:uuid:26140e27-0ab7-4e65-98e3-3d0909b1434 e; al ias=[2001:db8:0:1]~48768~6>
Asterisk 13.2.0 will give the following error: pjsip:0 <?>: sip_transport. Error processing 1855 bytes packet from UDP 10.77.79.3:5060 : PJSIP syntax error exception when parsing 'Request Line' header on line 12 col 129:
And when sipjs, or jssip are used with either Firefox or Chrome, they send garbage in the ACK request URI:
Kamailio logs something like the following and the ACK cannot be processed: 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]
Is it proper to have [] brackets around the IPv6 alias address in the Contact header? Does the value need to be quoted?
If I force the browser to use IPv4, without changing anything else, both jssip and sipjs work perfectly in Firefox and Chrome.
It seems that the topoh module doesn't cope with this well. Disabling the topoh module seems to resolve the issue, unfortunately.
I've added some additional information and an example INVITE here: https://github.com/kamailio/kamailio/issues/120
Wrote in the issue page as well:
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.
Cheers, Daniel
I don't doubt that you're right, Daniel. I have asked for some assistance on the PJSIP mailing list, as I get the same error from both Asterisk 13 and CSipSimple nightly build. Since Asterisk has moved to PJSIP, this could pose a significant interoperability issue.
http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/2015-April/018313.htm...
Thanks again. -A
On 08/04/15 02:32, Anthony Messina wrote:
On Tuesday, April 07, 2015 09:42:00 AM Daniel-Constantin Mierla wrote:
On 07/04/15 05:32, Anthony Messina wrote:
On Sunday, March 29, 2015 08:57:44 PM Anthony Messina wrote:
On Sunday, March 29, 2015 05:23:26 PM Anthony Messina wrote:
I've been working on Kamailio websocket integration and I believe I'm having issues with the IPv6 address representation in the Contact header's alias parameter. After Googling, it appears after https://github.com/kamailio/kamailio/commit/814c08f3 the IPv6 contact is represented in brackets []. However, it when using websockets, and the alias= parameter uses brackets [] around and IPv6 address, there are message parsing issues.
With a header such as the following Contact: <sip:wstest1@example.com;gr=urn:uuid:26140e27-0ab7-4e65-98e3-3d0909b1434 e; al ias=[2001:db8:0:1]~48768~6>
Asterisk 13.2.0 will give the following error: pjsip:0 <?>: sip_transport. Error processing 1855 bytes packet from UDP 10.77.79.3:5060 : PJSIP syntax error exception when parsing 'Request Line' header on line 12 col 129:
And when sipjs, or jssip are used with either Firefox or Chrome, they send garbage in the ACK request URI:
Kamailio logs something like the following and the ACK cannot be processed: 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]
Is it proper to have [] brackets around the IPv6 alias address in the Contact header? Does the value need to be quoted?
If I force the browser to use IPv4, without changing anything else, both jssip and sipjs work perfectly in Firefox and Chrome.
It seems that the topoh module doesn't cope with this well. Disabling the topoh module seems to resolve the issue, unfortunately.
I've added some additional information and an example INVITE here: https://github.com/kamailio/kamailio/issues/120
Wrote in the issue page as well:
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.
Cheers, Daniel
I don't doubt that you're right, Daniel. I have asked for some assistance on the PJSIP mailing list, as I get the same error from both Asterisk 13 and CSipSimple nightly build. Since Asterisk has moved to PJSIP, this could pose a significant interoperability issue.
http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/2015-April/018313.htm...
Looked quickly at 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.
Cheers, Daniel