Subject: Re: [Sip] Major Open Issue #113: Overlapping Transactions

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 18 Dec 2001 15:02:33 -0500

There was consensus at IETF 52 that overlapping non-INVITE should be 
allowed, and that does not seem to have been controversial in this thread.

The main issue remains overlapping INVITE. This is tightly coupled to 
whether or not a new INVITE Is used for the solution for both (1) early 
media and (2) the heterogeneous error response forking problem. In both 
cases, the UA needs to pass additional information to a specific UAS in 
order for call processing to continue, in order to generate a final 
response to INVITE.

So, the big question is: do we use INVITE for this, or something else? 
Some of the issues to tackle when using INVITE are:

1. what happens to the first transaction when the second INVITE arrives? 
Does the uas reject it (this may impact services)? Does it continue to 
use it, but accept the second one? If so, what is the implication on 
status of the dialog? What if the first INVITE is later rejected - is 
the dialog up or down? Race conditions may make it hard to say.

2. what is the impact on intermediate proxy and other elements (like 
firewall controllers)?

I am beginning to come around to liking the idea of using an UPDATE 
request in the forward direction, to provide some kind of additional 
information, which would be answered immediately. Need to think about it 
more though...

-Jonathan R.

Anders Kristensen wrote:

> 
> Jonathan Rosenberg wrote:
> 
>>Issue:
>>
>>This is a major issue. One of the more major ones remaining.
>>
>>Currently, the spec forbids more than one INVITE at a time, and more than
>>one non-INVITE at a time. This is simple, but there are valid concerns that
>>it will bite us down the road when uses require faster operation. Thus, the
>>issue is whether to relax this two constraints.
>>
>>Discussion points:
>>
>>The reason we forbid it with INVITE was that you couldn't easily figure out
>>the most recent session description. There was no way to tell whether the
>>response to the first INV was sent before or after the response to the
>>second INVITE. Without a consistent view of which was the most recent SDP,
>>the session parameters would be wrong.
>>
> 
> I agree that it would be desirable to allow overlapping transactions,
> including INVITEs. What's the problem with saying that the CSeq (and
> subordinately RSeq) defines which is the most recent SDP?
> 
> Anders
> 

-- 
Jonathan Rosenberg, PhD                 72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
[email-masked]                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH: (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: Wed, 19 Dec 2001 13:49:05 +0200

Hi,

>information, which would be answered immediately. Need to think about it

I think the UPDATE proposal is interesting. However, instead of defining
a method which we would use for specific early media cases I think we
should look at it from a generic perspective, and define exactly what
the method can, and can not, be used for.

A few issues/questions I think we should ask ourselves are:

Q1. Can we use it to update the Request-URI? 

IF, I guess the overlap dialing discussion will once again come up; do
we use INVITE + UPDATE(s), or do we use re-INVITEs (for separate legs)?

Q2. Can we use it to update the SDP? 

In a basic SIP situation the answer is probably no, since SIP uses the
INVITE/200 (or 200/ACK) mechanism. However, extension mechanisms
(similar to the manyfolks resource reservation) could use it - instead
of PRACK.

Q3. Can we use it in mid-session, ie "outside" an ongoing INVITE
transaction?

Can the method be used, instead of re-INVITE (and in some cases maybe
also instead of INFO) to update some parameters. A current example is
the Allow header; would we really need a re-INVITE to update that, if we
can use the UPDATE method?

Q4. Proxy support?

Depending on the method would be used for, there are cases where proxy
support for the method would be needed (in another mail Jonathan gave
midcom as an example). Would we define an option-tag, or would it be a
MUST for proxies to support the method?

I am sure there are many more similar questions, and I think we should
try to answer all of them before we define a new method/extension.
Otherwise they will come up sooner or later anyway, and the discussion
will go on forever... 

Please also note that the text above are NOT proposals - simply
QUESTIONS that would come up if an UPDATE method proposal was to be
given.

Regards,

Christer Holmberg
Ericsson Finland