linphone-developers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Linphone-developers] escaped characters in Record-Route header


From: Simon MORLAT
Subject: Re: [Linphone-developers] escaped characters in Record-Route header
Date: Tue, 25 May 2021 18:10:24 +0200

Hi,

Thank you for submitting this case.
To my understanding it is not correct to say that these characters must be escaped.
According to ABNF, uri parameters are defined as follows:

uri-parameters    =  *( ";" uri-parameter)
uri-parameter     =  transport-param / user-param / method-param
                     / ttl-param / maddr-param / lr-param / other-param

# We need to go through the definition of other-param, since sipXecs-rs is an "other-param".
other-param       =  pname [ "=" pvalue ]

pvalue is defined as:

pvalue            =  1*paramchar
paramchar         =  param-unreserved / unreserved / escaped
param-unreserved  =  "[" / "]" / "/" / ":" / "&" / "+" / "$"
unreserved  =  alphanum / mark
mark        =  "-" / "_" / "." / "!" / "~" / "*" / "'"
/ "(" / ")"

As you can see the * and ~ both appear in "mark" definition, so they are allowed in URI parameters.

It might be questionable why Linphone is unescaping them. The reason is mainly because the parser API returns strings under their unescaped form (for usernames, hostnames and parameters). They are internally stored unescaped too.
While constructing the Record-route when making the response, a re-escaping is done according to the rules, which might then render a different aspect if the original string had unnecessarily escaped characters.

RFC3261 stipulates rules for URI comparisons in https://datatracker.ietf.org/doc/html/rfc3261#section-19.1.4 .
One of them is:

 Characters other than those in the "reserved" set (see RFC 2396
         [5]) are equivalent to their ""%" HEX HEX" encoding.

I would then conclude that the SIP proxy that added this Record-Route should be able to successfully match the URI it used with the URI it receives from Linphone.
Unless I missed something in my understanding of the RFC, my recommendation would be to notify the issue to the developers of the proxy server that inserts this kind of Record-route.
Feel free to comment.

Best regards,

Simon




Le ven. 23 avr. 2021 à 13:16, Gisel, Max <max.gisel@helmholtz-berlin.de> a écrit :

Dear Linphone Developers,

 

We’ve noticed that Linphone clients are removing escaped characters from header fields. Linphone removes the escaped characters present (from our example in the Record-Route header i. e. %2A or %60) by translating them to their respective symbols (* or `). This leads to problems with other components handling the call. In the end the needed ACK can not be handled by the other components due to the manipulated Record Route Header and Linphone cancels the call after about 30 seconds because it doesn’t receive an ACK. According to the SIP standard, this modification should not take place, as these characters must be escaped. Is it possible to request a fix for this, so that Linphone would no longer modify SIP headers by translating escaped characters?

 

INVITE sent to Linphone:

Record-Route: <sip:X.X.X.X:5060;lr;sipXecs-CallDest=INT;sipXecs-rs=%2Aauth%7E.%2Afrom%7EMTEwOTFjYWQ3Ng%60%60%21700858ce08920bc97e992777a785159a>

 

200 OK received from Linphone in response to the INVITE above:

Record-route: <sip:X.X.X.X:5060;lr;sipXecs-CallDest=INT;sipXecs-rs=*auth~.*from~MTEwOTFjYWQ3Ng``!700858ce08920bc97e992777a785159a>

 

Best Regards

Max Gisel

 

_______________________________________________
Linphone-developers mailing list
Linphone-developers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/linphone-developers

reply via email to

[Prev in Thread] Current Thread [Next in Thread]