Re: [Sip] The Future of SIP Call Control

Mpierce1@aol.com Tue, 27 November 2001 23:03 UTC

Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28747 for <sip-archive@odin.ietf.org>; Tue, 27 Nov 2001 18:03:10 -0500 (EST)
Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id SAA20342 for sip-archive@odin.ietf.org; Tue, 27 Nov 2001 18:03:12 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA19230; Tue, 27 Nov 2001 17:19:43 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA19202 for <sip@optimus.ietf.org>; Tue, 27 Nov 2001 17:19:41 -0500 (EST)
Received: from imo-m03.mx.aol.com (imo-m03.mx.aol.com [64.12.136.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27557 for <sip@ietf.org>; Tue, 27 Nov 2001 17:19:39 -0500 (EST)
From: Mpierce1@aol.com
Received: from Mpierce1@aol.com by imo-m03.mx.aol.com (mail_out_v31_r1.9.) id l.46.1e6b9585 (4421) for <sip@ietf.org>; Tue, 27 Nov 2001 17:19:07 -0500 (EST)
Message-ID: <46.1e6b9585.29356b5b@aol.com>
Date: Tue, 27 Nov 2001 17:19:07 -0500
Subject: Re: [Sip] The Future of SIP Call Control
To: sip@ietf.org
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: AOL 4.0 for Windows 95 sub 112
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

In a message dated 11/27/01 1:48:03 PM Eastern Standard Time, 
jdrosen@dynamicsoft.com writes:

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

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

_______________________________________________
Sip mailing list  http://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip