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:
Is allowed to the other party to set next header in BY
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
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:
>
> Is allowed to the other party to set next header in BYE?
>
> Route:
RFC 3261
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
___
SIP Express Router (SER) and Kamailio (OpenS
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:
Is allowed to the other party to set next header in BYE?
Route:
my interpretati
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:
>
> Is allowed to the other party to set next header in BYE?
>
> Route:
my interpretation is that that is allo
Thanks for this information, clear with comparison. However, more
specific to what I am looking for:
If I add in INVITE:
Record-Route:
Is allowed to the other party to set next header in BYE?
Route:
Cheers,
Daniel
On 16/05/14 19:56, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
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
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 uppe