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

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 5 Dec 2001 21:31:26 -0500

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.

The reason we forbid it with non-INVITE was that we had no easy way to do
end-to-end sequenced delivery (there could be gaps in CSeq due to proxy
challenges).

Its not clear if there is a pressing need at this time for overlapping
INVITE. Early media may require it; draft-rosenberg-sip-early-media used it,
but its not clear that this was the easiest or best way to do this.
Overlapping non-INVITE has already come up, in the context of MESSAGE
(although it looks like it won't be needed there), but it is likely to be an
issue with NOTIFY as well.

I've been on the fence, but now believe its important to allow overlapping
non-INVITE, since we will probably really need it down the road, and
eliminating the possibility for any future method seems dangerous. THus, I
propose that we allow overlapping invite transactions. Ordering may or may
not be important depending on the method; the content or some other headers
may determine ordering as needed. As an example, PRACK can be overlapped and
there is not even a need for ordering. 

I am more on the fence with INVITE, and here too fear we may find we need
it. To allow it, we would need to require that all INVITEs are full state,
and that the INVITE with the highest CSeq, and the response to the INVITE
with the highest CSeq, always take precedence. 

So, here is an example. A sends INVITE, CSeq 1, to B. It then sends INVITE,
CSeq 2, to B. B receives sequence 2 first. It generates a 200 OK with SDP.
It then gets the first INVITE. This invite is really irrelevant; CSeq 2
carried all information that is needed, so this one is out of date. B
responds with 200 OK with some SDP. The 200 OK to CSeq 2 arrives at A, which
uses that. The 200 OK for CSeq 1 arrives, and is ignored. All of this works
because we can enforce that INVITE and the response have full state.

Things would get a little tricky with non-2xx responses. Consider the same
case, but now B responds to the INVITE with CSeq 2 with 400, but the INVITE
with CSeq 1 with 200. Is the call still up? I would say yes; A would get the
400 first, and then would need to know to wait for the first response to
determine the state of the call. Thats a bit complex.

So, in the interests of making a decision:

Proposal:

Disallow overlapping INVITE (because it could get ugly)
Allow overlapping non-INVITE (because we will restrict ourselves too much
without it)
  
-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: Gonzalo Camarillo <[email-masked]>
Date: Fri, 07 Dec 2001 01:08:47 +0200

Hi,

> Disallow overlapping INVITE (because it could get ugly)

INVITEs are essential for early media as it is specified so far (we all
agree early media is both ugly and needed).

Early media only happens within a dialog (in the "early" state). What
about allowing to have exactly one pending INVITE within an early
dialog?

That is, I send my INVITE and I receive a 1xx response with a To tag.
Now I have my early dialog. I can send another INVITE now to change
early media stuff (or for whatever), but I cannot overlap a 3rd INVITE
at the same time. If I want to send a 3rd INVITE I have to wait until
the 2nd has completed. And if I want to send a 4th one, I have to wait
until the 3rd has completed.

> Allow overlapping non-INVITE (because we will restrict ourselves too much

Agreed.

Regards,

Gonzalo

---

From: "Brett Tate" <[email-masked]>
Date: Thu, 6 Dec 2001 20:04:19 -0500

> Disallow overlapping INVITE (because it could get ugly)

I agree that it might be too ugly/late/uncommon 
to resolve within the bis.  However the 
functionality of updating SDP prior to answer 
should not be forbidden by the bis.  A solution 
such as described in draft-rosenberg-sip-early-media
works without too much complexity and with
minimal race condition side-effects.  Thus
the bis could reflect that it doesn't address 
such activity, and it could be resolved through 
an extension to the standard.

> Allow overlapping non-INVITE (because we will 
> restrict ourselves too much without it)

I agree.

---

From: "Bob Penfield" <[email-masked]>
Date: Fri, 7 Dec 2001 19:50:31 -0500

----- Original Message -----
From: "Gonzalo Camarillo" <[email-masked]>
> until the 3rd has completed.

When you say "completed", do you mean get a final response? or get a
provisional response (like the initial INVITE)?

---

From: Gonzalo Camarillo <[email-masked]>
Date: Sun, 09 Dec 2001 04:34:13 +0200

Hello,

inline:

> provisional response (like the initial INVITE)?

Sorry. What I meant was that a 490 Request Updated response has been
received for the previous INVITE, so we know for sure that the remote
end is processing only one INVITE at a time.

Regards,

Gonzalo

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 10 Dec 2001 03:22:56 +0200

Hi,

>until the 3rd has completed.

This is not related to any specific early media proposal, but assume
that an "early" re-INVITE is used to "turn on" early media. So, the UAC
receives an early media offer from UAS_A and accepts it using a
re-INVITE. In a forking environement it may then receive other early
media offers. It may decide to accept the new offer from UAS_B, and
"turn off" the previous offer by sending a new re-INVITE to UAS_A. It
now has 3 active INVITE transactions with UAS_A. 

Now, I am NOT saying that it should be handled this way, or that it even
should be allowed (that should be discussed in a separate thread about
early media), but it COULD be a scenario where more than 2 active INVITE
transactions are needed...

So, my question is: IF we allow overlapping INVITE transactions, does it
really matter how many we allow? In most cases there won't be more than
2 anyway, so...

>>Allow overlapping non-INVITE (because we will restrict ourselves too much

I agree on this too.

Regards,

Christer Holmberg
Ericsson Finland

---

From: Anders Kristensen <[email-masked]>
Date: Tue, 11 Dec 2001 17:22:02 -0500

> 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