[sr-dev] [SR-Users] topoh, angle brackets and Contact URI params interpretation

Libor Chocholaty libor_ml1 at mts.cz
Thu Feb 3 20:18:36 CET 2011


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




More information about the sr-dev mailing list