Re: [splices] SIP INVOKE method v1

"Worley, Dale R (Dale)" <dworley@avaya.com> Tue, 14 June 2011 18:39 UTC

Return-Path: <dworley@avaya.com>
X-Original-To: splices@ietfa.amsl.com
Delivered-To: splices@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DCC511E812E for <splices@ietfa.amsl.com>; Tue, 14 Jun 2011 11:39:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.931
X-Spam-Level:
X-Spam-Status: No, score=-102.931 tagged_above=-999 required=5 tests=[AWL=-0.332, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BwsjmRaGxxov for <splices@ietfa.amsl.com>; Tue, 14 Jun 2011 11:39:14 -0700 (PDT)
Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id 0BD4211E8072 for <splices@ietf.org>; Tue, 14 Jun 2011 11:39:07 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EAOqp902HCzI1/2dsb2JhbABSplN3rVwCm32GJASWPIsP
X-IronPort-AV: E=Sophos;i="4.65,366,1304308800"; d="scan'208";a="193426600"
Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 14 Jun 2011 14:39:05 -0400
X-IronPort-AV: E=Sophos;i="4.65,366,1304308800"; d="scan'208";a="666095061"
Received: from unknown (HELO DC-US1HCEX3.global.avaya.com) ([135.11.52.22]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 14 Jun 2011 14:38:45 -0400
Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.192]) by DC-US1HCEX3.global.avaya.com ([135.11.52.22]) with mapi; Tue, 14 Jun 2011 14:38:44 -0400
From: "Worley, Dale R (Dale)" <dworley@avaya.com>
To: "Hutton, Andrew" <andrew.hutton@siemens-enterprise.com>, "Shekh-Yusef, Rifaat (Rifaat)" <rifatyu@avaya.com>, Paul Kyzivat <pkyzivat@cisco.com>, "splices@ietf.org" <splices@ietf.org>
Date: Tue, 14 Jun 2011 14:35:48 -0400
Thread-Topic: [splices] SIP INVOKE method v1
Thread-Index: AcwnpwHyWdPZ0GtcQdet0Lc+UVQPIgCJvnyQADiYGNAAANdDQAABWEfrAAFc1lAAANTSAw==
Message-ID: <CD5674C3CD99574EBA7432465FC13C1B222907E9D7@DC-US1MBEX4.global.avaya.com>
References: <6369CB70BFD88942B9705AC1E639A33822CD81384C@DC-US1MBEX4.global.avaya.com> <4DF27461.8060204@cisco.com> <101C6067BEC68246B0C3F6843BCCC1E30C22977E6A@MCHP058A.global-ad.net> <6369CB70BFD88942B9705AC1E639A33822CDA812C4@DC-US1MBEX4.global.avaya.com>, <101C6067BEC68246B0C3F6843BCCC1E30C229785C2@MCHP058A.global-ad.net> <CD5674C3CD99574EBA7432465FC13C1B222907E9D3@DC-US1MBEX4.global.avaya.com>, <101C6067BEC68246B0C3F6843BCCC1E30C229785F5@MCHP058A.global-ad.net>
In-Reply-To: <101C6067BEC68246B0C3F6843BCCC1E30C229785F5@MCHP058A.global-ad.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [splices] SIP INVOKE method v1
X-BeenThere: splices@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Loosely-coupled SIP Devices \(splices\) working group discussion list" <splices.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/splices>, <mailto:splices-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/splices>
List-Post: <mailto:splices@ietf.org>
List-Help: <mailto:splices-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/splices>, <mailto:splices-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 14 Jun 2011 18:39:15 -0000

________________________________________
From: Hutton, Andrew [andrew.hutton@siemens-enterprise.com]

I think the problem is that we don't have any specified requirements so we don't know what the boundaries are.

What has been specified so far already looks like it is trying to do CTI type things and for that we know the list of possible services is endless. The most relevant standards would probably be ECMA-269 and ECMA-323 (http://www.ecma-international.org/publications/standards/Ecma-323.htm) if you want to see the XML for this.

I don't see how it is really possibly to limit this to a small set of actions as once the mechanism is implemented there will always be requirements to add more actions.
________________________________________

Thanks for those references!

Yes, there is a real scope-creep problem.  Looking at ECMA-323, I see 45 "Call control services and events", and that is not the majority of the defined operations.

One possibility would be to define INVOKE as a carrier for ECMA-323 operations.  But even then, a lot of care needs to be taken to see how to embed the dataflow model of ECMA-323 into the SIP request/response structure.  If we define our own CTI set, we have to create our own dataflow model.

Dale