Thanks for this information, clear with comparison. However, more specific to what I am looking for:

If I add in INVITE:

Record-Route: sip:1.2.3.4;abc=XYZ

Is allowed to the other party to set next header in BYE?

Route: sip:1.2.3.4;abc=xyz

Cheers, Daniel

On 16/05/14 19:56, Juha Heinanen wrote:

Daniel-Constantin Mierla writes:

...

For a specific example, is it allowed that the value of a parameter in contact header uri is changed to upper/lower case when building the sequential request (so this appears in request uri)? Same would be for Recor-Route uri parameter that would appear later in Route headers...

i found this from rfc3261:

19.1.4 URI Comparison ... • Comparison of the userinfo of SIP and SIPS URIs is case-sensitive. This includes userinfo containing passwords or formatted as telephone-subscribers. Comparison of all other components of the URI is case-insensitive unless explicitly defined otherwise.

and

7.3.1 Header Field Format ... When comparing header fields, field names are always case-insensitive. Unless otherwise stated in the defi- nition of a particular header field, field values, parameter names, and parameter values are case-insensitive. Tokens are always case-insensitive. Unless specified otherwise, values expressed as quoted strings are case- sensitive.

and example:

Content-Disposition: session;handling=optional

is equivalent to

content-disposition: Session;HANDLING=OPTIONAL

-- juha

On 16/05/14 20:26, Juha Heinanen wrote:

Daniel-Constantin Mierla writes:

...

Thanks for this information, clear with comparison. However, more specific to what I am looking for:

If I add in INVITE:

Record-Route: sip:1.2.3.4;abc=XYZ

Is allowed to the other party to set next header in BYE?

Route: sip:1.2.3.4;abc=xyz

my interpretation is that that is allowed, because abc=xyz is uri parameter and "comparison of all other components of the URI is case-insensitive unless explicitly defined otherwise".

As abc is custom parameter, not something standard, I wonder how the UA know if it is a case or not of an "explicitly defined otherwise".

I expected that UA has to take them and copy when they need to preserve a value, such as Record-Route body becomes Route body.

Perhaps it is a case requiring lawyers and a judge for a final, obeying decision -- or better I should ask on sip-implementors, hoping for one of the SIP RFC authors to clarify it. Cheers, Daniel

Hello,

On 17/05/14 06:50, Juha Heinanen wrote:

daniel,

how is kamailio doing regarding param case-insensitivity (uri_param, check_route_param functions, uri param and parameter list transformations, etc)? they should all be case-insensitive.

iirc, we looked at some point over them and they are case insensitive. We added also some config functions for matching properly (perhaps in siputils module, or textopx...).

Cheers, Daniel

On 19/05/14 10:01, Alex Hermann wrote:

On Friday 16 May 2014 20:15:11 Daniel-Constantin Mierla wrote:

...

Thanks for this information, clear with comparison. However, more specific to what I am looking for:

If I add in INVITE:

Record-Route: sip:1.2.3.4;abc=XYZ

Is allowed to the other party to set next header in BYE?

Route: sip:1.2.3.4;abc=xyz

RFC 3261 says the Record-Route must be _copied_ into the response and the route set must be _set_ to the Record-route value. Nowhere it says a UA is to parse or manipulate the uri's beforehand. So, IMHO, an element inserting a Record-Route header must receive the corresponding Route header in the exact same way it was sent.

12.1.1 UAS behavior

When a UAS responds to a request with a response that establishes a
dialog (such as a 2xx to INVITE), the UAS MUST copy all Record-Route
header field values from the request into the response (including the
URIs, URI parameters, and any Record-Route header field parameters,
whether they are known or unknown to the UAS) and MUST maintain the
order of those values.

... The route set MUST be set to the list of URIs in the Record-Route header field from the request, taken in order and preserving all URI parameters.

12.1.2 UAC Behavior

The route set MUST be set to the list of URIs in the Record-Route
header field from the response, taken in reverse order and preserving
all URI parameters.

12.2.1.1 Generating the Request

If the route set is not empty, and the first URI in the route set
contains the lr parameter (see Section 19.1.1), the UAC MUST place
the remote target URI into the Request-URI and MUST include a Route
header field containing the route set values in order, including all
parameters.

Thanks for right pointers, it is a lot better, because many headers can carry base64 values which are messed up if someone changes lower to upper case or the other way.

Besides Route/Record-Route, have you spotted if it is the same for Contact URI (which becomes R-URI for within dialog) and Via header parameters?

Cheers, Daniel