Is it acceptable for a UA to merely use the presence of a branch parameter
in the VIA to distinguish a request as having been received from a proxy
instead of from another UA.
I am also interested in determining whether all parameters in a VIA need to
be used or just the branch alone will do to distinguish one proxy from
another, in the case of a merged request at the UA.
Finally, is the branch a mandatory parameter when a proxy adds a VIA to the
request? Neither the rfc nor the bis-04 specify this explicitly. But they
seem to strongly imply this. For example, bis04 states in 10.46.6 Syntax
[The "branch" parameter is included by every proxy.]
----- Original Message -----
From: "Jonathan Rosenberg" <[EMAIL PROTECTED]>
To: "'Jo Hornsby'" <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>
Cc: "McMurry, Kathleen" <[EMAIL PROTECTED]>
Sent: Thursday, October 25, 2001 9:41 PM
Subject: RE: [Sip-implementors] RE: [Sip] Isomorphic Request Definition
> Jo is right on target.
>
> Merged and looped requests are the only reason for the inclusion of Via in
> isomorphic requests. Each non-isomorphic request received at a proxy is a
> separate transaction that is processed indepdnetly of any other. That is
the
> resoluton of the open issue Jo mentions and is the assumption in bis-05.
> Indeed, bis-05 never even mentions request mergign because it doesn't have
> to... the proposed resolution is the defacto behavior that results from
> ignoring the scenario entirely.
>
> -Jonathan R.
>
> ---
> Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave.
> Chief Scientist First Floor
> dynamicsoft East Hanover, NJ 07936
> [EMAIL PROTECTED] FAX: (973) 952-5050
> http://www.jdrosen.net PHONE: (973) 952-5000
> http://www.dynamicsoft.com
>
>
> > -----Original Message-----
> > From: Jo Hornsby [mailto:[EMAIL PROTECTED]]
> > Sent: Tuesday, October 23, 2001 6:42 AM
> > To: [EMAIL PROTECTED]
> > Cc: McMurry, Kathleen
> > Subject: [Sip-implementors] RE: [Sip] Isomorphic Request Definition
> >
> >
> > [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/ms
> g00950.html
> - is the proposed resolution.
>
>
> - Jo.
>
> _______________________________________________
> Sip-implementors mailing list
> [EMAIL PROTECTED]
> http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
> _______________________________________________
> Sip-implementors mailing list
> [EMAIL PROTECTED]
> http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
>
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
