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

From: "Mark Watson" <[email-masked]>
Date: Thu, 6 Dec 2001 14:15:29 -0000

Jonathan,

My reading of bis-05, following the clarification of the dialog
establishment ambiguity, was that overlapping INVITES *were* allowed on
*established dialogs* - so we could have overlapping INVITEs once we have a
provisional response containing a To: tag.

Is this understanding wrong ?

I do think that overlapping INVITES in this sense are essential for Early
Media as described in your draft & that proper handling of Early Media is
essential for interworking with the PSTN/ISDN where (IMO) most SIP calls
will originate or terminate (at least in the next 10 years or so :-)

Regards,

Mark

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]]
Sent: 05 December 2001 20:31
To: [email-masked]'
Subject: [Sip] Major Open Issue #113: Overlapping Transactions

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: "Chiou, Mark" <[email-masked]>
Date: Thu, 6 Dec 2001 15:18:04 -0600

I vote for no Overlapping for INVITEs. SIP is an IP protocol. People
usually input digits then hit the send button. If the user hit the send
button too early, it is a incomplete address call. It is the same
approach as the wireless network. For 3G release 5 using SIP, I cannot
image supporting overlapping, which will tie up the air resources during
call setup.
 
For PSTN, the black phone is outpulsing every single digit the user
pushes such that inter-digit timer for collecting digits and overlapping
outpulsing on the trunk side do make sense to have the overlapping
mechanism.

For non-INVITEs overlapping, I do not see the usage at all. The
overlapping introduced for Call Processing is for speeding up the
bottleneck such as collecting and outpulsing. We might introduce
non-INVITEs overlapping when an application needs but forbidding it for
now.

Mark Chiou
Santera  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, December 06, 2001 2:37 PM
To: [email-masked]; [email-masked]
Subject: Re: [Sip] Major Open Issue #113: Overlapping Transactions

>  issue is whether to relax this two constraints.
<snip>
>  Allow overlapping non-INVITE (because we will restrict ourselves too
much
Is "overlapping INVITEs" what is being proposed in
draft-ietf-sip-overlap-01 
as a way to handle overlap signaling? That draft proposes to send
another 
INVITE while still waiting for the response to the first. As noted, this

could lead to problems in correct interpretation of responses received
out of 
order.

It seems to make sense to not allow overlapping INVITEs, but would that
then 
invalidate the proposal in draft-ietf-sip-overlap-01?

Mike Pierce

---

From: Nathan Nelson <[email-masked]>
Date: Sat, 8 Dec 2001 22:34:58 -0500

Paul, you are 100% correct.

It is in carriers best interest to not change the basic behavior of
customers.  Adding a step to complete a call would be aggravating for
customers and present additional challenges for carrier customer care
people.

Thx,
Nate Nelson
Principle Architect
Cbeyond Communications 

-----Original Message-----
From: Paul Long [mailto:[email-masked]]
Sent: Saturday, December 08, 2001 10:15 PM
To: [email-masked]
Subject: RE: [Sip] Major Open Issue #113: Overlapping Transactions

Eric,

I believe that overlapped sending is expected on desktop telephones. Sure,
people can adapt, but why? At the very least, this will be a quality of
implementation issue, and products that support it will be preferred over
products that do not. The end user does not care or most often even know
what technology is being used, e.g., "Oh, this is a VoIP phone, so I better
press Send."

Paul Long
ipDialog, Inc.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Eric
Burger
Sent: Saturday, December 08, 2001 8:46 PM
To: [email-masked]
Cc: [email-masked]
Subject: RE: [Sip] Major Open Issue #113: Overlapping Transactions

But doesn't this argue that we don't need to emulate overlap dialing?  Like
you said, it was a problem in the transition to DTMF (30 years ago) and ISDN
(10 years ago).  Wouldn't it be reasonable to say it's not a problem
anymore?

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
[email-masked]
Sent: Friday, December 07, 2001 11:28 AM
To: [email-masked]
Subject: Re: [Sip] Major Open Issue #113: Overlapping Transactions

>  image supporting overlapping, which will tie up the air resources during
In the cellular world, true, you had to hit the send only after entering the
whole number. In the PSTN, not true, the network got each digit separate.

Some would argue that the next generation of phones (IP) should work just
like the old, "black" rotary dial phones. That argument hampered some of the
ISDN standardization and certainly hampered the transition from rotary dial
to DTMF in the US.

I believe it would be appropriate for the IP environment (SIP devices) to
require that the user enter the whole number and then hit "send". We've all
learned to deal with that dialing procedure for celluler. Certainly, 3G
should not support dialing.

Whether this eliminates the need for overlapping INVITEs - I don't know.
There may be other uses, such as the description in
draft-ietf-sip-overlap-01, which is a different issue.

Mike Pierce