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

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 8 Dec 2001 00:03:42 -0500

Whooaaaa, hang on their folks.

We are NOT talking about overlap dialing, as Gonzalo said. We are talking
about overlapping INVITEs, which could be used for any number of things. As
has been pointed out, one potential application is early media (although I
am now unsure that overlapping INVITE solves that). Since sending this email
even, I have come up with another potential application to solve the
Heterogeneous Error Response Forking Problem (HERFP). As currently specified
in the overlap signaling specification, each updated SIP INVITE is a
different dialog, since it has an updated To header (this is my
interpretation, at least).

So, please, no more comments on overlap dialing.

-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: [email-masked] [mailto:[email-masked]]
> Sent: Friday, December 07, 2001 2:23 PM
> To: [email-masked]; [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: RE: [Sip] Major Open Issue #113: Overlapping Transactions
> 
> 
> I'm in favor of avoiding overlap dialing.  However, before it 
> is ruled out
> completely, bear in mind it may still be used in Europe.  
> They support SAM
> messages in ETSI ISUP.  I'm not familiar with how prevalent its use is
> though.  We don't want to decide something that may cause 
> problems with ETSI
> ISUP gateway interop.
> 
> John Hearty
> Level3
> 
> -----Original Message-----
> From: Mart Nurmet [mailto:[email-masked]]
> Sent: Friday, December 07, 2001 10:47 AM
> To: [email-masked]; [email-masked]
> Cc: Chiou, Mark
> Subject: Re: [Sip] Major Open Issue #113: Overlapping Transactions
> 
> 
> Mike:
> 
> Overlap dialing was appropriate for dial pulse signaling to 
> hold the trunk.
> This was done away with once MF (Multi Frequency) signaling 
> to be used [it
> was not allowed then].  Then the end office collected all the 
> digits and
> determined the end of signaling by timing the digit reception 
> or receipt of
> the # sign.  Then the end office, forwarded the full string.  Overlap
> dialing could possibly be still found on dial pulse trunks 
> but it would hard
> to find that anywhere else. In the SIP world that is a 
> fuction that should
> not be needed.
> 
> - Mart
> 
> ----- Original Message -----
> From: <[email-masked]>
> To: <[email-masked]>
> Sent: Friday, December 07, 2001 10:28 AM
> Subject: Re: [Sip] Major Open Issue #113: Overlapping Transactions
> 
> 
> > In a message dated 12/6/01 4:18:52 PM Eastern Standard Time,
> > [email-masked] writes:
> >
> > > 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.
> > >
> > 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
> >
> > _______________________________________________
> > 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
> >
> 
> 
> _______________________________________________
> 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
> 
> _______________________________________________
> 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
> 

_______________________________________________
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: Sun, 09 Dec 2001 17:56:44 +0200

Hello,

It has been said at least 3 times but folks seems to ignore it.

If you want to discuss about something that is NOT Bug#113 (like overlap
dialing), PLEASE CHANGE THE SUBJECT OF THE MAIL!!

Otherwise it is very difficult (and time consuming) to check if there is
consensus of a particular open issue in bis in order to close it.

As an example, this thread has 19 messages and only 6 of them deal with
bug#113. When only 30% of the messages of a thread deal with the actual
problem being discussed the overhead delays the standardization process
a lot.

Thanks,

Gonzalo