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

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 7 Sep 2001 16:18:15 -0400

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
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

> -----Original Message-----
> From: Jonathan Rosenberg 
> Sent: Wednesday, August 22, 2001 5:57 PM
> To: [email-masked]'
> 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
> [email-masked]                     FAX:   (973) 952-5050
> http://www.jdrosen.net                      PHONE: (973) 952-5000
> 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 [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 10 Sep 2001 08:15:13 +0300

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