15 May
2014
15 May
'14
5 p.m.
Hello,
hopefully someone here with the RFC fresh in mind and its grammar for
sip uri parameter can jump on to clarify if the value of the parameter
can be changed to lower/upper case.
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...
Cheers,
Daniel
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
16 May
16 May
8:56 p.m.
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
9:15 p.m.
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:
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
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
9:26 p.m.
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".
-- juha
9:35 p.m.
On 16/05/14 20:26, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
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
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
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".
17 May
17 May
7:50 a.m.
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.
-- juha
21 May
21 May
1:44 p.m.
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
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
19 May
19 May
11:01 a.m.
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.
--
Alex Hermann
21 May
21 May
1:47 p.m.
On 19/05/14 10:01, Alex Hermann wrote:
On Friday 16 May 2014 20:15:11 Daniel-Constantin
Mierla wrote:
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
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
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.
3841
days inactive
3847
days old
8 comments
3 participants
participants (3)
-
Alex Hermann -
Daniel-Constantin Mierla -
Juha Heinanen