Subject: Re: [Sip] The Future of SIP Call Control

From: William Marshall <[email-masked]>
Date: Wed, 28 Nov 2001 16:45:07 -0500 (EST)

Many of the services are definitely "one-sided", where the other just
does as it is told.

But, the discussion on REFER is leaving the "policy decision" to the
subscriber/vendor/user as to whether they actually do as they are
told or ignore it.

This is the combination that will NOT produce interoperable services.

So, in addition to the definition of primitives like REFER, it is
absolutely necessary to provide guidance to the policy decisions
that are needed to implement services.  This part is missing --
MUST-strength requirements (testable) defining how a UA responds 
to the commands (e.g. REFER).  

I think the only real issue is whether this belongs in the sip draft
that defines the primitive, or in the sipping draft that defines
the use of the primitive.

Bill Marshall
[email-masked]

-----original message-----
From: [email-masked]
Date: Wed, 28 Nov 2001 15:53:56 EST
Subject: Re: [Sip] The Future of SIP Call Control
To: [email-masked]

In a message dated 11/28/01 12:45:57 AM Eastern Standard Time, 
[email-masked] writes:

> > -----Original Message-----
>  > From: [email-masked] [mailto:[email-masked]]
>  > Sent: Tuesday, November 27, 2001 5:19 PM
>  > To: [email-masked]
>  > Subject: Re: [Sip] The Future of SIP Call Control
>  > 
>  > 
>  > I'm not sure what the distinction is between "standardizing those services" 
>  > and the alternative. Either you do or you don't. If you don't standardize 
>  > each service, that is, the complete protocol needed to allow it to be 
>  > implemented on multiple devices built by multiple vendors, and to interwork 
>  > with other services, then you can never prove  interoperability and you can 
>  > never use that service in a real network. I believe strongly  that we can't 
>  > just standardize "protocol primitives". It is first necessary  to agree on the 
>  > set of services to be supported  and to have a concept of  what "protocol 
>  > primitives" could be, and then to determine the general way  in which these 
>  > services are to be supported in SIP. Then a set of "protocol  primitives" can 
>  > be developed which provide the necessary functions, while individual 
>  > standards are being written for each service using those "primitives".
>  
>  I don't think the latter is needed in many cases. 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.
>  
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), 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?

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

_______________________________________________
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: Dean Willis <[email-masked]>
Date: Thu, 29 Nov 2001 13:25:35 -0600

>to the commands (e.g. REFER).  
Remember, we specify protocols -- not services. We can give examples of 
services that one might build. We can describe the requirements that 
implementation of a service place on a protocol. We can work with 
implementors like 3GPP who are defining services. But we don't 
standardize services, as I think we're using the term here, in the IETF.

>the use of the primitive.
Implentation guidance on "how to use" something is within the scope of 
SIPPING.

--
Dean