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

From: [email-masked]
Date: Tue, 27 Nov 2001 11:19:01 EST

In a message dated 11/26/01 2:47:17 PM Eastern Standard Time, [email-masked] 
writes:

> 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)
>  
>  
Interesting question. I had naively thought that everything being discussed 
beyond baisc "Session Initiation" was really "Call Control".

The seemingly endless discussions on "REFER" and "CANCEL" and forks and 
receiving two requests, etc are all issues that effect the control of 
real-life telephone calls. The real world is a lot more complicated then the 
simple establishment of a one-to-one call/connection ("session") between two 
perfectly cooperating devices.

Yes, it is critically important that each service (call transfer, conference, 
park) not be dealt with separately. I believe a lot of the discussion on 
REFER has been exactly that - discussing the details of a specific protocol 
element and its interaction with other protocol elements, without an 
agreement on the big picture or requirements. Where is the statement of the 
functional requirements for a Call Transfer service to be supported by SIP? I 
would be the first to agree that it doesn't have to be exactly what the 
circuit switched network provides, which is somewhat a matter of evolution 
based on the genes of that network. The IP-based network may have better 
genes (or lack some in some areas) that could result in a slightly different 
service operation for Call Transfer. But it needs to be agreed before the 
detailed protocol work is done.

The development of services for ISDN (and H.323 by extension) was blessed? by 
the previous, well-understood definitions of these services in the existing 
circuit-switched world. While the SIP work was apparently intended to break 
from that background, it does not appear to have created the base on which to 
develop protocols to support Call Control. As other groups have found, that 
step can't be avoided.

I had understood that this function was to be the work of SIPPING. I would 
hope that SIPPING (or whatever WG) is able to write a Service Description 
document that would identify the services and their operation that are 
required to be supported by SIP, and would identify how they interact with 
each other. This document would not mention "REFER" or "INVITE" or any other 
protocol element. (In ITU-T, this is referred to a "Stage 1" of the 
standardization process.) When this is done, SIP WG could develop protocol 
elements for the agreed to services. (This is "Stage 2" and "Stage 3" in the 
ITU-T.) Sometimes, I get the feeling that IETF is good at jumping in at the 
"Stage 3" point in the development, which works fine for well-contained, 
bounded protocol tasks, but fails miserably for things as complex as 
telephony.

My thoughts (also as an individual),
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

---

From: Dean Willis <[email-masked]>
Date: Thu, 29 Nov 2001 11:45:35 -0600

This is clearly a task for SIPPING.

SIPPING has two milestones that I believe relate to this.

Jan 02    Submit Internet-Draft on Call Transfer using REFER to IESG for 
consideration as an Informational RFC

Apr 02    Submit Internet-Draft on Multi-Party/Conferencing Framework to 
IESG for consideration as an Informational RFC

Further discussion of how to interpret and fulfill these milestones 
should be on the SIPPING list. We can, of course, also discuss 
additional milestones. . .

Thanks,

--
Dean