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!
--
Alex Balashov - Principal
Evariste Systems LLC
260 Peachtree Street NW
Suite 2200
Atlanta, GA 30303
Tel: +1-678-954-0670
Fax: +1-404-961-1892
Web: http://www.evaristesys.com/
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
