From: "Brett Tate" <[EMAIL PROTECTED]> 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.
I hadn't allowed for the possibility that a 1xx might not carry the Record-Route headers. Of course a 1xx without Record-Route headers leads to trouble, as the UAC will know of a dialog, but it won't have the route-set needed to send requests within the dialog. (E.g., it cannot send an UPDATE successfully.) Within that context, it's clear that when a UAC receives a 2xx, it should process the Record-Route headers to set the route set. If the UAS is well-behaved, that should result in no change to the route set, but if the UAS is not well-behaved, the route set from the 2xx should be kept. 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? Don't focus on the detailed processing specification, focus on what is needed to make the protocol work. You will encounter fewer errors that way. 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? As far as I can tell, all success responses to dialog refresh requests should be used to update the remote target. Dale _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
