Hello Rhys , Here are my two bits . 1> Your Container/Proxy must not recurse through the the contact header(s) in the 3xx response unless it is responsible for the original Request URI(R1 in your diagram) (see section 16.5 and 16.6 in 3261 for more on this)
2>Construction and sending of the ACK request should not be a an issue at the UAC in your diagram because the from tag , to tag and the callid will be used to identify the dialog. The rules for sending the ACK request for the 2xx to an INVITE are outlined in sections 13.2.2.4 and section 12 (and not 17.1.1.3).As such , these guidelines are to be followed for sending the ACK by the UAC. Regards , Sayan -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rhys D Ulerich Sent: Tuesday, September 21, 2004 10:54 AM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: [Sip-implementors] INVITE, 3xx, and ACK via proxy question. My apology for the cross-posting; this is both a SIP protocol-level and a SIP Container question. Say I've got an outbound proxy which automagically handles 3xx responses for me (e.g. a SIP Container defined in JSR 116 when Proxy.setRecurse(true) is in effect), and I've got an INVITE scenario that looks as follows: UAC Container Redirect1 UAS --- INVITE R1-> <--------100------ ---INVITE-------> <---3xx, UAS------ ---ACK----------> ---------------------INVITE UAS----> <-----------------180------------------- <----------180--- <-----------------200------------------- <----------200--- -------------------------ACK------------------------------> ***alternative 1*** versus -----ACK--------> ----------------------ACK---------------> ***alternative 2*** The basic idea is that UAC sends an INVITE with a RequestURI directed to Redirect1. Redirect1 responds with a 3xx with a Contact header containing the address for UAS. The Container/3xx handling proxy sends an INVITE to UAS, and then passes the 180/200 responses to UAC. The problem I have is at the ACK: Alternative 1: Because the request URI of the INVITE sent to UAS was rewritten without the UAC knowing it, the UAC cannot correct send an ACK directly to UAS because there's no way (I see no way) of informing UAC of the request URI rewrite. Without that information, no end-to-end ACK can be constructed because it'll be malformed according to RFC 3261 section 17.1.1.3. Alternative 2: The UAC may send an ACK to the Container/3xx Proxy, and then the Proxy may send the corresponding ACK to the UAS. The problem I see here is that this requires additional logic in the Proxy, and then the ACK isn't really end-to-end like it was intended. In the context of a SIP Container, this requires automagic manipulation of a subsequent request in a dialog. Am I missing something? Which alternative is correct on a SIP protocol level? What does the correct alternative require from a SIP Container implementation under this circumstance? Thanks, Rhys __________________________________ Rhys Ulerich Telecommunications Solutions Software Development Email: [EMAIL PROTECTED] Office: 512-838-1428 IBM Software Group - Austin, TX _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors Confidentiality Notice The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain confidential or privileged information. If you are not the intended recipient, please notify the sender at Wipro or [EMAIL PROTECTED] immediately and destroy all copies of this message and any attachments. _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
