Re: [splices] SIP INVOKE method v1

Paul Kyzivat <pkyzivat@cisco.com> Tue, 14 June 2011 19:56 UTC

Return-Path: <pkyzivat@cisco.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 152BE1F0C56 for <splices@ietfa.amsl.com>; Tue, 14 Jun 2011 12:56:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.404
X-Spam-Level:
X-Spam-Status: No, score=-110.404 tagged_above=-999 required=5 tests=[AWL=0.195, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 l8nUo18VlyLj for <splices@ietfa.amsl.com>; Tue, 14 Jun 2011 12:56:06 -0700 (PDT)
Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by ietfa.amsl.com (Postfix) with ESMTP id DB0281F0C55 for <splices@ietf.org>; Tue, 14 Jun 2011 12:56:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=4071; q=dns/txt; s=iport; t=1308081365; x=1309290965; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=JQ1naa317M/+TBoM1NmvOR2v8Xg2wMjB6LkoQmvI/UA=; b=KKbJSUVDA2Ixl6X4jAwlyWeMxFRKHvd9OX9GZgMTbqH4VAMgWvtVHZG9 H9k0YAA9xgNQUcJZCdhqoiPcO6eEVHO/+GBevsy6RGESS9XPiTtbeWq3U 2jezidZASgKwrgcSg12SDXc+rhqYP0H1bz7ydfTl5pnkfCU2opEzyt0/n k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EADW8902tJV2c/2dsb2JhbABSplR3qmyeQ4YkBJFIhFeEQYZr
X-IronPort-AV: E=Sophos;i="4.65,366,1304294400"; d="scan'208";a="236355709"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rtp-iport-1.cisco.com with ESMTP; 14 Jun 2011 19:56:04 +0000
Received: from [161.44.174.125] (dhcp-161-44-174-125.cisco.com [161.44.174.125]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id p5EJu3Kx023338; Tue, 14 Jun 2011 19:56:04 GMT
Message-ID: <4DF7BCD3.7050804@cisco.com>
Date: Tue, 14 Jun 2011 15:56:03 -0400
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
To: "Hutton, Andrew" <andrew.hutton@siemens-enterprise.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> <BANLkTimdTmoZ7fDz7wOVBPCPS0WxrRfJoQ@mail.gmail.com> <101C6067BEC68246B0C3F6843BCCC1E30C229785FF@MCHP058A.global-ad.net>
In-Reply-To: <101C6067BEC68246B0C3F6843BCCC1E30C229785FF@MCHP058A.global-ad.net>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: "splices@ietf.org" <splices@ietf.org>
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 19:56:07 -0000

I'm with Dale that we need to scope the command set,
or equivalently, scope the environment that is being manipulated and the 
degrees of freedom that it has.

If it isn't "small" then it at least needs to be characterized. And the 
larger it is the bigger a deal the work is. So its important to figure 
it out. The mechanism to convey the commands is secondary to that.

For instance (as I have mentioned before in passing), if the scope 
includes "call control" in the sip sense, including o/a, then it becomes 
a very big deal unless we can reuse sip for it. We really don't want to 
define something new and different from sip that is functionally 
equivalent to sip.

My expectation is that we are talking about something at a higher level 
of abstraction than SIP. But being at a higher level doesn't mean 
"vague". And while it almost certainly needs to be extensible for things 
we don't consider at first, IMO that doesn't mean we should define a 
mechanism with no intrinsic functionality, just an extension mechanism. 
That is a guarantee we will get it wrong.

We can look to CSTA or one or more definitions of CTI. I did investigate 
CSTA once, and didn't love it. But if it comes close to the needs here 
we might consider adopting it. I don't know much about CTI, but my 
impression is that it is a buzz word with many only loosely related 
instantiations, and is predicated on different architectural models than 
will work for us. (But I'll be pleased to be educated by somebody who 
really knows.)

	Thanks,
	Paul

On 6/14/2011 2:25 PM, Hutton, Andrew wrote:
> Hi Alan,
>
> Might be nice to keep it to a small set but I an not convinced it is possible and most actions will need parameters when you consider different media types, audio devices etc. and even simple actions like call terminate will almost certainly need a reason code.
>
> Regards
> Andy
>
>
>> -----Original Message-----
>> From: Alan Johnston [mailto:alan.b.johnston@gmail.com]
>> Sent: 14 June 2011 18:46
>> To: Worley, Dale R (Dale)
>> Cc: Hutton, Andrew; Shekh-Yusef, Rifaat (Rifaat); Paul Kyzivat;
>> splices@ietf.org
>> Subject: Re: [splices] SIP INVOKE method v1
>>
>> Andy,
>>
>> I agree with Dale that the set of actions should be small, otherwise,
>> we are doing something else.  Also, the set of parameters needs to be
>> small.  In fact, I think most actions won't have any parameters at
>> all.  This is why we are using URNs, just names, for the actions.
>>
>> To do otherwise is to introduce complex actions or scripts, and I
>> don't want this mechanism to be used for that.  There are other
>> mechanisms (e.g. CPL) that allows a script to be uploaded or
>> downloaded to control a UA or proxy operation, but that is very
>> different from what we are talking about here.
>>
>> I agree that we could discuss BNF vs XML, but if we agree that we
>> really are dealing with URNs, then a header makes more sense than a
>> body.
>>
>> - Alan -
>>
>> On Tue, Jun 14, 2011 at 12:32 PM, Worley, Dale R (Dale)
>> <dworley@avaya.com>  wrote:
>>>> From: Hutton, Andrew [andrew.hutton@siemens-enterprise.com]
>>>>
>>>> The list of potential actions and associated parameters is huge and
>>>> for this kind of problem I believe that an XML body would be a much
>>>> better solution. I guess I much prefer XML to BNF.
>>>
>>> I'd feel much more comfortable if we settled on either:
>>>
>>> 1) a small number of actions
>>>
>>> 2) to use an appropriate subset of an existing CTI standard
>>>
>>> In the latter case, could someone provide a pointer to the standard?
>>>
>>> Essentially, INVOKE is to provide an interface to a command set, and
>>> we need to have some idea what the outer limits of the command set
>>> will be.  Only then can we choose a good way to represent the
>> commands
>>> within a SIP request.
>>>
>>> Dale
>>> _______________________________________________
>>> splices mailing list
>>> splices@ietf.org
>>> https://www.ietf.org/mailman/listinfo/splices
>>>
>