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