[Moved to SIP Implementors] > The definition of an Isomorphic Request was changed in one of > the bis drafts to include the top-most Via header. My > question regarding this is two-fold: > > 1) What call flow is it that requires the top-most Via header to > be a part of this definition? The only reference to this I have > seen is in the "Changes made in Version 02" section. That > section indicates that "the Request-URI is the same for all BYE > requests that are record-routed". This doesn't seem to be the > case if the procedures detailed in Section 16.3 are followed.
Hmmm.... This is a good point. I think the reasoning is that the Record-Route magic of Section 16 didn't exist prior to bis-03; we were still in the dark ages of the called party replacing each Record-Route entry with the caller's Contact + whacking in an maddr. In this case, the Request-URI of a BYE from the callee for a call that spiralled through a proxy that Record-Routed in each case would have been the same. > That section indicates that "the URL placed into the Record-Route > header MUST be unique for each unique Request-URI in the request". Indeed. But this wasn't always the case. > 2) If there is a call flow that requires the top-most Via header > to be a part of this definition, what is the appropriate behavior > of a Proxy Server or UAS if the Request-URI, CallID, From, To, > and CSeq are the same in a Request, but the top-most Via header > is different? Some kind of error response? Well, if you get a request that is only different based on the topmost Via, then there are two possible cases: you are acting as the focal point of what is known as a "request merge", or you are looking at a loop (I might note that a loop is a special case of a "request merge"). Very recently, we changed the ideal behaviour of a proxy in a request merging scenario such that it no-longer treats it specially, but just processes the second and subsequent requests as it would if there were no request merge. UA behaviour is slightly different in that it should "prefer" one request over another, and 482 (or similar) the rest. http://www.jdrosen.net/sip/multiple_requests.txt - will explain the history a little better, and http://www.ietf.org/mail-archive/working-groups/sip/current/msg00950.html - is the proposed resolution. - Jo. _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
