On 06/18/2011 06:17 PM, Daniel-Constantin Mierla wrote:
indeed, if 183 does not copy record-route headers is not much to do in A side -- I expected that any 1xx reply apart of 100, and especially 183 to mirror record-route headers. I searched a bit and in several cases I could spot, the 183 had the R-R headers.
So the fault would be now in B, but if there is no _MUST_ for 183 to mirror R-R, then it is in IETF WG :-) ...
Well, here's what 3261 12.1.1 ("UAS Behavior") says on the subject:
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.
Since a 183 does not establish a dialog, I suppose that means there's no need for the UAS to copy the RR headers.
On the other hand, take a look at page 7 of RFC 3262:
http://www.ietf.org/rfc/rfc3262.txt
It seems to say that Record-Route goes into "2xx,18x", although offers no elaboration on this point. Whether this constitutes an amendment to the 3261 view I do not know.
- if there is no R-R header in 183 and you know it is going to be a
bridged call (via some flag set or a special onreply route), then insert the headers manually with append_hf(R-R: sip:ip1;lr\r\nR-R: sip:ip2;lr\r\n");
Yeah, that was going to be my next step, I just figured I'd try to avoid something so ugly. :-)
Thanks for your help!