Re: [Sip] RE: Open Issue #11: Record-routing non-INVITE mid-call

[Christer Holmberg <[e-mail]>]

Hi,

Should we put some lines in the bis about the issue of a proxy CHANGING
an established route, Is a ie by REMOVING its own, or someone elses,
R-R/R headers?

Regards,

Christer Holmberg
Ericsson Finland



Jonathan Rosenberg wrote:
> 
> Its been two weeks since I posted this. There was consensus on this at IETF,
> and I now interpret the lack of responses to this to imply broader list
> consensus. The proposed text will be incorporated into bis-05.
> 
> Thanks,
> Jonathan R.
> 
> ---
> Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
> Chief Scientist                             First Floor
> dynamicsoft                                 East Hanover, NJ 07936
> [e-mail]                     FAX:   [phone]
> http://www.jdrosen.net                      PHONE: [phone]
> http://www.dynamicsoft.com
> 
> 
> > -----Original Message-----
> > From: Jonathan Rosenberg
> > Sent: Wednesday, August 22, 2001 5:57 PM
> > To: '[e-mail]'
> > Subject: Open Issue #11: Record-routing non-INVITE mid-call
> >
> >
> > Issue:
> >
> > Can a proxy record-route non-INVITE, mid-call requests, such
> > as INFO? NOTIFY?
> >
> > Points to consider:
> >
> > Generally, its hard to argue that proxies should be
> > disallowed to record-route. We want them to be able to
> > record-route anything so that their operation can be
> > method-independent. The issue is, what does the UA do with
> > that information? For things in the middle of an INVITEd
> > session, the UA does nothing. I think bis is clear on that.
> > If one side has lost the state of the session, a re-INVITE is
> > the only thing that can replace the lost route set.
> >
> > The complex issue comes up with "session things" that are not
> > created by INVITE. The one and only example to date is
> > SUBSCRIBE. Adam has proposed that a SUBSCRIBE can usefully
> > fork, resulting in the creation of multiple subscriptions.
> > However, because of non-INVITE response merging rules, the
> > UAC will learn of only one of these. It learns of the others
> > through NOTIFY. Proxies can record-route those NOTIFY's, and
> > the result is that the subscriber will get NOTIFY requests
> > with new call legs (but the same Call-ID). It can therefore
> > recognize these as creating multiple "subscription-legs",
> > much like multiple 200 OK create multiple call legs for
> > INVITE. Now, like any other "leg", we need to establish a
> > route set for it. The proposal is that for NOTIFY, the UA be
> > allowed to construct a route set for that subscription-leg,
> > using the Record-Route/Contact in the NOTIFY.
> >
> > The issue is therefore tightly coupled with forking of
> > non-INVITE. There was consensus to allow forking of
> > non-invite (message on this is pending), so the need for this
> > is clear.
> >
> > In general, new methods which can usefully fork and construct
> > state at multiple recipients will need a similar 4-way
> > handshake used by SUBSCRIBE. The four-way handshake is a
> > request-response in the forward direction, followed by a
> > different request in the reverse direction, one for each
> > entity that state was created on. For all such requests,
> > construction of route sets for each "leg" makes sense, so
> > there is definitely a general need here.
> >
> > Proposal:
> >
> > The proposal is that proxies MAY record-route any method.
> > Whether the UA uses this to build a route set is method
> > dependent. For bis, the only method where route sets are
> > built from record-routes is INVITE. Other extensions which
> > build upon a four-way handshake for some kind of
> > session-establishment will likely need this, and can specify
> > it on a method-by-method basis. Bis will discuss the issue in
> > general, and explain why this is so.
> >
> > There was consensus for this proposal at the meeting. So,
> > speak up now and object, or forever hold your peace.
> >
> > -Jonathan R.
> >
> >
> > ---
> > Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
> > Chief Scientist                             First Floor
> > dynamicsoft                                 East Hanover, NJ 07936
> > [e-mail]                     FAX:   [phone]
> > http://www.jdrosen.net                      PHONE: [phone]
> > http://www.dynamicsoft.com
> >
> >
> 
> _______________________________________________
> Sip mailing list  http://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use [e-mail] for questions on current sip
> Use [e-mail] for new developments on the application of sip