I'm having an issue with topoh module in Kamailio 3.1.0. When Contact header is formed like this: Contact: 0991 sip:192.168.0.107;line=sr-N6IAzBysz.tyz.D4M.VLOBMfOBFuWxvfMxV4 The other party responds properly. But when there is no angle brackets in Contact: Contact: sip:192.168.0.107;line=sr-N6IAzB3AWxyfz.stM.quOBFZMJZfWxj7W.y-MljAWBy*
Really, many parsers implement "prefer shift to reduce" principle, which means if something can be interpreted in more enclosed expression, it will be interpreted this way and no as part of less enclosed expression so ;line is interpreted as header parameter but not URI parameter.
RFC 3261 section 20 suggests that any URI parameters be contained within angle brackets: === The Contact, From, and To header fields contain a URI. If the URI contains a comma, question mark or semicolon, the URI MUST be enclosed in angle brackets (< and >). Any URI parameters are contained within these brackets. If the URI is not enclosed in angle brackets, any semicolon-delimited parameters are header-parameters, not URI parameters. === I think the topoh module should force the angle brackets. BTW it seems that parameter needs to be urlencoded, see rule 'other-param' in RFC 3261 section 25.1:
other-param = pname [ "=" pvalue ] pname = 1*paramchar pvalue = 1*paramchar paramchar = param-unreserved / unreserved / escaped param-unreserved = "[" / "]" / "/" / ":" / "&" / "+" / "$"
No .-* characters are allowed in the paramchar. But at least that's not causing me any problems.
On 03.02.2011 10:26, Andrew Pogrebennyk wrote:
I think the topoh module should force the angle brackets. BTW it seems that parameter needs to be urlencoded, see rule 'other-param' in RFC 3261 section 25.1:
From what I understand the valid form is: Contact: sip:192.168.0.107;line=sr-N6IAzB3AWxyfz.stM.quOBFZMJZfWxj7W.y-MljAWBy* or Contact: sip:192.168.0.107;line="sr-N6IAzB3AWxyfz.stM.quOBFZMJZfWxj7W.y-MljAWBy*"
so it should be enclosed by angle brackets or double quote, otherwise most implementations would treat ;line as header parameter and the parsing would fail since "@" is not allowed as header parameter value if it's not enclosed by double quotes.
Hello,
On 2/3/11 1:36 PM, Andrew Pogrebennyk wrote:
On 03.02.2011 10:26, Andrew Pogrebennyk wrote:
I think the topoh module should force the angle brackets. BTW it seems that parameter needs to be urlencoded, see rule 'other-param' in RFC 3261 section 25.1:
From what I understand the valid form is: Contact: sip:192.168.0.107;line=sr-N6IAzB3AWxyfz.stM.quOBFZMJZfWxj7W.y-MljAWBy* or Contact: sip:192.168.0.107;line="sr-N6IAzB3AWxyfz.stM.quOBFZMJZfWxj7W.y-MljAWBy*"
so it should be enclosed by angle brackets or double quote, otherwise most implementations would treat ;line as header parameter and the parsing would fail since "@" is not allowed as header parameter value if it's not enclosed by double quotes.
I will check the sources and fix if the contact address is not between <>.
However, I do not undeerstand where you got the "@", is none there or am I missing something?
Thanks, Daniel
On 03.02.2011 18:12, Daniel-Constantin Mierla wrote:
I will check the sources and fix if the contact address is not between <>.
However, I do not undeerstand where you got the "@", is none there or am I missing something?
Daniel, Sorry, I meant the "*" sign. Thanks for looking into it.
On 02/03/2011 09:26 AM, Andrew Pogrebennyk wrote:
I'm having an issue with topoh module in Kamailio 3.1.0. When Contact header is formed like this: Contact: 0991 sip:192.168.0.107;line=sr-N6IAzBysz.tyz.D4M.VLOBMfOBFuWxvfMxV4 The other party responds properly. But when there is no angle brackets in Contact: Contact: sip:192.168.0.107;line=sr-N6IAzB3AWxyfz.stM.quOBFZMJZfWxj7W.y-MljAWBy*
Really, many parsers implement "prefer shift to reduce" principle, which means if something can be interpreted in more enclosed expression, it will be interpreted this way and no as part of less enclosed expression so ;line is interpreted as header parameter but not URI parameter.
RFC 3261 section 20 suggests that any URI parameters be contained within angle brackets: === The Contact, From, and To header fields contain a URI. If the URI contains a comma, question mark or semicolon, the URI MUST be enclosed in angle brackets (< and >). Any URI parameters are contained within these brackets. If the URI is not enclosed in angle brackets, any semicolon-delimited parameters are header-parameters, not URI parameters. === I think the topoh module should force the angle brackets.
Why? What about regular Contact params?
RFC3261 section 20.10 Contact:
... ... If no "<" and ">" are present, all parameters after the URI are header parameters, not URI parameters. The display name can be tokens, or a quoted string, if a larger character set is desired.
I think that it is clean enough, you should ask why the proxy sends Contact URI without "<" and ">" when there is an URI param.
Libor
BTW it seems that parameter needs to be urlencoded, see rule 'other-param' in RFC 3261 section 25.1:
other-param = pname [ "=" pvalue ] pname = 1*paramchar pvalue = 1*paramchar paramchar = param-unreserved / unreserved / escaped param-unreserved = "[" / "]" / "/" / ":" / "&" / "+" / "$"
No .-* characters are allowed in the paramchar. But at least that's not causing me any problems.
Hello,
I added the code for enclosing contact uri between angle brackets. I committed on git master branch, but have no way to test it for now due to traveling. If you can test it and report back would be great. When all is working fine, I will backport to 3.x branches.
Thanks, Daniel
On 2/3/11 8:18 PM, Libor Chocholaty wrote:
On 02/03/2011 09:26 AM, Andrew Pogrebennyk wrote:
I'm having an issue with topoh module in Kamailio 3.1.0. When Contact header is formed like this: Contact: 0991 sip:192.168.0.107;line=sr-N6IAzBysz.tyz.D4M.VLOBMfOBFuWxvfMxV4 The other party responds properly. But when there is no angle brackets in Contact: Contact: sip:192.168.0.107;line=sr-N6IAzB3AWxyfz.stM.quOBFZMJZfWxj7W.y-MljAWBy*
Really, many parsers implement "prefer shift to reduce" principle, which means if something can be interpreted in more enclosed expression, it will be interpreted this way and no as part of less enclosed expression so ;line is interpreted as header parameter but not URI parameter.
RFC 3261 section 20 suggests that any URI parameters be contained within angle brackets: === The Contact, From, and To header fields contain a URI. If the URI contains a comma, question mark or semicolon, the URI MUST be enclosed in angle brackets (< and>). Any URI parameters are contained within these brackets. If the URI is not enclosed in angle brackets, any semicolon-delimited parameters are header-parameters, not URI parameters. === I think the topoh module should force the angle brackets.
Why? What about regular Contact params?
RFC3261 section 20.10 Contact:
... ... If no "<" and ">" are present, all parameters after the URI are header parameters, not URI parameters. The display name can be tokens, or a quoted string, if a larger character set is desired.I think that it is clean enough, you should ask why the proxy sends Contact URI without "<" and">" when there is an URI param.
Libor
BTW it seems that parameter needs to be urlencoded, see rule 'other-param' in RFC 3261 section 25.1:
other-param = pname [ "=" pvalue ] pname = 1*paramchar pvalue = 1*paramchar paramchar = param-unreserved / unreserved / escaped param-unreserved = "[" / "]" / "/" / ":" / "&" / "+" / "$"
No .-* characters are allowed in the paramchar. But at least that's not causing me any problems.
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Daniel, The problem is fixed and the topoh module has been running fine for a few hours so far. Thank you.
On 04.02.2011 20:32, Daniel-Constantin Mierla wrote:
Hello,
I added the code for enclosing contact uri between angle brackets. I committed on git master branch, but have no way to test it for now due to traveling. If you can test it and report back would be great. When all is working fine, I will backport to 3.x branches.
Thanks, Daniel
-
Andrew Pogrebennyk -
Daniel-Constantin Mierla -
Libor Chocholaty