Subject: [Sip] re: the future of call control

From: Rohan Mahy <[email-masked]>
Date: Sun, 02 Dec 2001 09:42:18 -0800

>To: [email-masked]
 >Subject: Re: [Sip] The Future of SIP Call Control
 >From: [email-masked]
 >Date: Wed, 28 Nov 2001 15:53:56 EST
 >CC: [email-masked]
 >List-Id: Session Initiation Protocol <sip.ietf.org>
 >Sender: [email-masked]
[snip]
 >In a message dated 11/28/01 12:45:57 AM Eastern Standard Time,
 >[email-masked] writes: > > -----Original Message-----
 >> Many services are
 >>  "one-sided", in that they require the invoker to understand the semantics
 >of
 >>  the service, but require the other side to only follow a particular
 >protocol
 >>  primitive. Thus, with a sufficiently generaly set of primitives, you can
 >>  make many more of these services work in this fashion. Certainly that is
 >the
 >>  case, for example, with transfer. There are many variants on it, and the
 >>  exact variant (bridged, blind, consulutation, etc.) need ONLY be known by
 >>  the UA invoking the service. If, however, we did as you propose, we would
 >>  need to write a separate draft for each of these variants, and the result
 >of
 >>  that is painfully slow deployment of services, lack of innnovation in
 >>  services, and limited set of standardized services. I do not believe that
 >>  this is the right route, and it has been fairly fundamental to sip that
 >this
 >>  remain the case.
 >>
 >>  Now, this same one-sidedness, with the proper primitives and general,
 >>  service independent components (like the ones described in
 >>  http://www.jdrosen.net/papers/draft-rosenberg-sip-app-components-01.txt),
 >>  you can pretty much nail everything in this way. Conferencing, hold, mute,
 >>  transfer, and with
 >>  http://www.jdrosen.net/papers/draft-rosenberg-sip-call-package-00.txt, 
park
 >>  and pickup, all as these "one-sided services".
 >>
 >>  I've been meaning to write a draft that discusses this stuff in more
 >detail,
 >>  along with how it relates to the user interface problem. Seems like that
 >>  draft is becoming timely...
 >>
 >>  -Jonathan R.
 >>
Mike Pierce then replied:
 >I agree that many services are "one-sided" in that one of the end points
 >involved just responds to messages that are a part of the simple call setup
 >procedures. But that doesn't obviate the need for a "standard". Taking Call
 >Transfer as an example - yes, there are many variants, which is complicating
 >all the discussion of REFER and other protocol elements. But what it all
 >comes down to in the end is, if you want to sell thousands of
 >IP telephones for use in a real network, they will have to be
 >tested/certified as complying with some standard. Currently, with H.323
 >(which I understand is virtually the only IP phones in real use)

No,  For folks to deploy thousands of IP phones, the services merely need 
to work.  Standardization and certification of "blind transfer" (for 
example) is not necessary to sell phones.  As proof of this I will point 
out that there are many more thousands of proprietary IP phones than there 
are H.323 or SIP phones.  This is a regretable situation, but 
understandable since we have not put sufficient protocol primitives in the 
hands of developers to build some of these "one-sided" services.

 >, the
 >question can be "Does your product comply with H.323, H.225, H.425, and
 >H450.2 for Call Transfer?" If anyone tries to sell SIP phones for use in real
 >networks, what would the equivalent question be for compliance?

What you are talking about standardizing is basically user interface 
dependent.  who gets to define the interface for call park?  This isn't 
consistent on Centrex services with analog phones, and it isn't consistent 
across PBX and key systems.

 >Unfortunately, I was previously involved with several standardization efforts
 >that attempted to do exactly what you said - define a set of protocol
 >primitives which the user could then string together any way they wanted to
 >create services. It didn't work then, and I don't think it will now. Mike
 >Pierce

I'll bet you a Cisco SIP Phone it will work this time.  ;-)

thanks,
-rohan

_______________________________________________
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: [email-masked]
Date: Mon, 3 Dec 2001 09:38:03 EST

In a message dated 12/2/01 12:45:42 PM Eastern Standard Time, [email-masked] 
writes:

>   >>  "one-sided", in that they require the invoker to understand the 
semantics of
protocol
>   >>  make many more of these services work in this fashion. Certainly that 
is the
>   >>  need to write a separate draft for each of these variants, and the 
result of
>   >>  this is the right route, and it has been fairly fundamental to sip 
that this
>   >> <snip>
I understand that there are thousands of proprietary IP phones now. The 
organization I represent may want 10's of thousands of IP phones, but will 
not touch proprietary ones. They must be "standard". The point I made was 
about what was required to use them in real networks, not for thousands of 
home hobbyists whose major concern (to judge by some of the recent e-mails on 
this list) is how to distinguish between voice calls and requests to play 
"Quake". As you said, for "folks" to deploy, they merely need to work. But 
for "organizations" to deploy, they need to be standard. If "proprietary" was 
okay, the SIP WG, and maybe the whole IETF, would not be needed.

>  across PBX and key systems.
I ceratainly agree that we would not be standardizing the user interface. As 
in all other telecommunications standards activities, the "network interface" 
needs to be standardized. Many of the examples drawn have included 
interactions with a Proxy. This interface can not be proprietary. If some 
services work without the intervention of a Proxy (direct user-to-user 
messages), then they should be easy to standardize, but it still must be done 
in order to define the interaction of these simple services with those that 
require the use of a Proxy. Otherwise, we can't be sure that "blind transfer" 
will work correctly with, say, Call Forwarding on No Answer.

>  -rohan
Mike

---

From: Robert Sparks <[email-masked]>
Date: Mon, 3 Dec 2001 20:33:00 -0500

> okay, the SIP WG, and maybe the whole IETF, would not be needed.

You don't seriously believe that thread was all about hobbiests
trying to play Quake?

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 5 Dec 2001 13:04:27 -0500

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Monday, December 03, 2001 9:38 AM
> To: [email-masked]
> Subject: Re: [Sip] re: the future of call control
> 
> "Quake". 

Mike - condescending comments like this do little to further discussion in
this group. If you are looking for a fora to insult participants in SIP and
IETF, please look elsewhere. People on this list take this technology
seriously, but they are interested in services that are broader than just
POTS. If you think network gaming isn't important to communications, you
should talk to the wireless providers who are making big bucks on such
things and tell them that they are really just hobbyists. I'm sure they
would find your perspective amusing.

Mike previously wrote:
>But what it all comes down to in the end is, if you want to sell thousands
of 
>(which I understand is virtually the only IP phones in real use), the 

>create services. It didn't work then, and I don't think it will now.

A single anecdote is hardly enough to prove anything, especially without any
details about why it didn't work there.

And I can point to real examples where the opposite is true. As a somewhat
ironic example, the concept of a mgcp/megaco phone is based ENTIRELY on the
concept that services are not standardized; rather, primitives from the
server to the phone instruct the phone to do things that result in services
being delivered. The web is also built entirely on the same model, where
services are not standardized, only protocol primitives (fetching and
rendering of content). SIP services are meant to work in a similar way, but
with a more distributed model about where the intelligence for the services
resides.

-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

---

From: [email-masked]
Date: Sat, 8 Dec 2001 22:50:53 EST

In a message dated 12/8/01 9:46:05 PM Eastern Standard Time, 
[email-masked] writes:

> I fully *disagree* that these services need to be standardized.  The reason
>  is simple: what we're being asked to do is standardize a "marketing"
>  function.  What do I mean by that?  You want to advertise that you support
>  "blind transfer".  I can think of at least two, orthogonal ways of
>  implementing it.  Standardizing the call flow for blind transfer means that
>  any of the other, legitimate, possibly superior methods can't be "legally"
>  used.
>  
<snip>
  
>  If you do believe you need "standards" for such interoperation, I can think
>  of three organizations you can bring it to: 3GPP for wireless, CableLabs 
for
>  Broadband, and ISC for wireline.  Note that 3GPP and ISC explicitly state
>  they won't add or change SIP as defined by the IETF.  Documenting a call
>  flow doesn't change SIP :-)
>  
Sorry, but none of the 3 roganizations you listed is a "standards 
organization". IETF is.

I can name at least three real standards organizations that have found it 
necessary and important to write such standards for telephony services for 
previous technologies - ISDN, etc. And it wasn't viewed as "marketing". There 
is no reason why SIP should be any different and not need such standards.

Mike