3 Feb
2011
3 Feb
'11
9:18 p.m.
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.