> Clearly, the Record-Routes in the 1xx and > the 2xx have to be the same, because they > are derived from the Record-Routes seen in > the INVITE as the UAS received it. Given > that restriction, when RFC 3261 says that > a 2xx "updates the route set", the route > set proper (that is, excluding the remote > target (contact)) specified by the 2xx is > the same as the one specified by the 1xx, and > so the "update" causes no change.
Thanks for your response. The following are paragraphs 2 and 3 of rfc3261 section 13.2.2.4. Paragraph 2: "If the dialog identifier in the 2xx response matches the dialog identifier of an existing dialog, the dialog MUST be transitioned to the "confirmed" state, and the route set for the dialog MUST be recomputed based on the 2xx response using the procedures of Section 12.2.1.2. Otherwise, a new dialog in the "confirmed" state MUST be constructed using the procedures of Section 12.1.2." Paragraph 3 (indented): "Note that the only piece of state that is recomputed is the route set. Other pieces of state such as the highest sequence numbers (remote and local) sent within the dialog are not recomputed. The route set only is recomputed for backwards compatibility. RFC 2543 did not mandate mirroring of the Record-Route header field in a 1xx, only 2xx. However, we cannot update the entire state of the dialog, since mid-dialog requests may have been sent within the early dialog, modifying the sequence numbers, for example." Notice that paragraph 3 indicates why the route set must be recomputed. I agree that the record-route of 1xx is likely the same as 2xx; however for backward compatibility (record-route not in 1xx) and potentially related proxy rewrite issues, it appears to not be required. Assuming your interpretation to perform no-op update to route-set is correct, what is the purpose of paragraph 3 since it conflicts with paragraph 2? What is your interpretation of INVITE 2xx's contact upon the remote target when the dialog is known? Should contact be ignored or INVITE 2xx processed like re-INVITE 2xx and allow remote target to be updated? _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
