Subject: [Sip] The Future of SIP Call Control

From: Rohan Mahy <[email-masked]>
Date: Mon, 26 Nov 2001 11:40:27 -0800

Hi Everyone,

Currently SIP Call Control is an item on the SIP Charter:

 >The specific deliverables of the group are:
...
 >2. callcontrol: Completion of the SIP call control specifications, which
 >enables multiparty services, such as transfer and bridged sessions.
...

Obviously this charter item is not as important as bis, but we should 
either make progress on it or drop it.

Aside from work on REFER and transfer, there has been very little activity 
on call control.  I believe call control needs a holistic apporach.  I 
don't think we can add transfer here, conference there, park here, 
etc.  Therefore I propose that we take one of the following actions:

1)  Write a Call Control requirements document in SIP.  Quickly identify 
missing peices and evaluate proposals for adding the required 
functionality.  A subteam can do a lot of this work and post the issues 
back to the list.  This would only require a Milestone recharter in SIP.

2)  Do Call Control framework and requirements documents in SIPPING.  Pass 
the requirements to SIP.  Quickly identify missing peices/evaluate 
proposals, etc.   (This is similar to the proposal for *new* work items in 
SIP).  This would require a recharter in both SIPPING and SIP (to move 
cc-framework to SIPPING).

3)  Abandon call control altogether.  I would be very disappointed if we 
let this happen.

thanks,
-rohan (as an individual)

_______________________________________________
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: Robert Sparks <[email-masked]>
Date: Mon, 26 Nov 2001 14:53:49 -0500

I will be suprised if anyone steps up to support 3, but
I understand the frustration with having a goal and 
insufficient cycles applied to reaching it.

I think this falls clearly into SIPPING (and I hope most
of the realization of the goals can stay there - agreeing
on the use of existing tools, returning to SIP only when
we discover new tools are needed).
 
But aside from the process pain you alude to, is there a
significant difference between your first 2 options? In either
case, the subteam approach is going to be needed to make
progress.

RjS

> -----Original Message-----
> From: Rohan Mahy [mailto:[email-masked]]
> Sent: Monday, November 26, 2001 1:40 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [Sip] The Future of SIP Call Control
> 
> 
> Hi Everyone,
>

---

From: "Roy, Radhika R, ALCTA" <[email-masked]>
Date: Tue, 27 Nov 2001 13:07:45 -0500

...

Yes, it is critically important that each service (call transfer,
conference, 
park) not be dealt with separately. 

...

Where is the statement of the 
functional requirements for a Call Transfer service to be supported by SIP? 
...

[RRR] Both Rohan and Mike have raised good questions. 

[RRR] I believe that "SIP Call Control" will include the items like call
transfer (consultation transfer, out-of-consultation transfer), conference
(out-of consultation), call park, call diversion, call hold
(near-end/remote-end hold, near-end/remote-end hold/retrieve), call
diversion, call/message waiting, message waiting callback, call intrusion
and others.

[RRR] The next thing, as Mike pointed out, let us define the functional
requirements for each call service (although standard works for some
services are going on). It will provide the big picture how all those
services will be glued together when we develop standards.

[RRR] Any comments?

Mike Pierce

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 27 Nov 2001 13:19:36 -0500

I think (2) is the right approach.

We already know about a few call control primitives that we need to
standardize in SIP; namely, REFER and 3pcc. That work is already underway.
What missing is whether that is sufficient for all call control services.
I'm sure its not, and I'm sure we'll also need things like the call and
conference state subscription work. To fully determine whats needed, I would
support a sipping item to work through some scenarios and distill out a set
of required protocol primitives for supporting a range of services.

This is not the same as standardizing those services, which I do not
support. 

-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

> Sent: Monday, November 26, 2001 2:40 PM
> To: [email-masked]
> Cc: [email-masked]

---

From: "Roy, Radhika R, ALCTA" <[email-masked]>
Date: Tue, 27 Nov 2001 15:18:10 -0500

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]]
Sent: Tuesday, November 27, 2001 1:20 PM
To: 'Rohan Mahy'; [email-masked]
Subject: RE: [Sip] The Future of SIP Call Control

[RRR] I think that it will provide a good example. 3pcc is a call control
service. When this service was analyzed, it turns out that there needs to be
an extension in SIP and REFER was proposed. What has been missing though, I
guess, is the functional requirements for the 3pcc service.

I'm sure its not, and I'm sure we'll also need things like the call and
conference state subscription work. 

[RRR] We can take into account other services as well. For example,
conference (out-of consultation), call park, call diversion, call hold
(near-end/remote-end hold, near-end/remote-end hold/retrieve), call
diversion, call/message waiting, message waiting callback, call intrusion
and others.

To fully determine whats needed, I would
support a sipping item to work through some scenarios and distill out a set
of required protocol primitives for supporting a range of services.

[RRR] I fully agree with this proposal.

[RRR] Right. All we need to find out, like REFER in 3pcc, whether any
extensions are needed in SIP.

-Jonathan R.

---

---

From: [email-masked]
Date: Tue, 27 Nov 2001 17:19:07 EST

>  This is not the same as standardizing those services, which I do not

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 understand that REFER was invented as the "protocol primitive" to support 
Call Transfer, but I think I've seen it suggested for use in other places.

I see draft-ietf-sip-cc-transfer-05 is an attempt to "standardize this 
service".

Mike Pierce

---

From: "Roy, Radhika R, ALCTA" <[email-masked]>
Date: Tue, 27 Nov 2001 17:33:41 -0500

Hi, Mike:

Yes, I agree with you.

Let me explain.

There needs to be a two-step process: 1. Define the SIP protocol primitives
and 2. Use of SIP protocol primitives to offer services (e.g., cc-transfer
draft).

I believe that above two-step process will ensure interoperability.

Best regards,

Radhika R. Roy
[email-masked]

-----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

just standardize "protocol primitives". It is first necessary to agree on
the 

Mike Pierce

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 28 Nov 2001 00:29:59 -0500

> 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.

---

---

From: [email-masked]
Date: Wed, 28 Nov 2001 15:53:56 EST

>  draft is becoming timely...
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

---

From: "Roy, Radhika R, ALCTA" <[email-masked]>
Date: Wed, 28 Nov 2001 16:28:15 -0500

My comments are inline [RRR].

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, November 28, 2001 3:54 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Sip] The Future of SIP Call Control

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

>  > with other services, then you can never prove  interoperability and you

can 
>  > just standardize "protocol primitives". It is first necessary  to agree

on the 
>  "one-sided", in that they require the invoker to understand the semantics

of
>  need to write a separate draft for each of these variants, and the result

of

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?

[RRR] I do not know whether I can answer your questions directly. Let me try
to answer indirectly. We are working for SIP-H.323 interworking in the
SIP-H323-eGroup (IETF). At some point of time, we will address interworking
between SIP and H.323 supplementary services. We may find some ways for
interworking (e.g.,
http://www.cs.columbia.edu/~hgs/sip/drafts/SIP-H.323_Call_Examples.txt), not
necessarily the same experiences/functionalities in both sides.

[RRR] I would NOT say "Does your product comply with H.323, H.225, H.425,
and H450.2 for Call Transfer?" What I would like to see happen is that SIP
call control services will have the equivalent capabilities/functionalities
what H.323 supplementary services provide. The way I prefer that we should
proceed has been explained in earlier emails: 1. Functional requirements, 2.
Standardize SIP primitives, and 3. RFCs for SIP call control (or
conferencing) services.

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.

[RRR] From service provider point of view, it is the most important point as
Mike has pointed out.

[RRR] As mentioned before, the two step-process may be the right way to
address the concerns that Mike has mentioned: 1. Standardize all primitives
in SIP that are needed to provide services and 2. Publish the RFCs that show
how SIP call control (or conferencing) services are offered. These RFCs will
foster the global interoperability for SIP call control (or conferencing)
services.

Mike Pierce