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

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 22 Aug 2001 17:57:20 -0400

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