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
- [Sip] The Future of SIP Call Control Rohan Mahy
- RE: [Sip] The Future of SIP Call Control Robert Sparks
- Re: [Sip] The Future of SIP Call Control Mpierce1
- RE: [Sip] The Future of SIP Call Control Roy, Radhika R, ALCTA
- RE: [Sip] The Future of SIP Call Control Jonathan Rosenberg
- RE: [Sip] The Future of SIP Call Control Roy, Radhika R, ALCTA
- Re: [Sip] The Future of SIP Call Control Mpierce1
- RE: [Sip] The Future of SIP Call Control Roy, Radhika R, ALCTA
- RE: [Sip] The Future of SIP Call Control Jonathan Rosenberg
- Re: [Sip] The Future of SIP Call Control Mpierce1
- RE: [Sip] The Future of SIP Call Control Roy, Radhika R, ALCTA
- Re: [Sip] The Future of SIP Call Control William Marshall
- Re: [Sip] The Future of SIP Call Control Dean Willis
- Re: [Sip] The Future of SIP Call Control Dean Willis
- RE: [Sip] The Future of SIP Call Control Jonathan Rosenberg