[SR-Users] 100rel without direct reachability

Alex Balashov abalashov at evaristesys.com
Sun Jun 19 00:34:13 CEST 2011


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/



More information about the sr-users mailing list