Re: [splices] SIP INVOKE method v1

Peter Musgrave <musgravepj@gmail.com> Tue, 14 June 2011 22:31 UTC

Return-Path: <musgravepj@gmail.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 99C661F0C6B for <splices@ietfa.amsl.com>; Tue, 14 Jun 2011 15:31:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.903
X-Spam-Level:
X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1]
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 1nNcohGYSlrD for <splices@ietfa.amsl.com>; Tue, 14 Jun 2011 15:31:22 -0700 (PDT)
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id AA4A21F0C61 for <splices@ietf.org>; Tue, 14 Jun 2011 15:31:21 -0700 (PDT)
Received: by vxg33 with SMTP id 33so6990373vxg.31 for <splices@ietf.org>; Tue, 14 Jun 2011 15:31:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:references:in-reply-to:mime-version :content-transfer-encoding:content-type:message-id:cc:x-mailer:from :subject:date:to; bh=cnGA556OCTATnbusm++P1ovNHkQtcKXWukld1f8cPB4=; b=rRexzhm0+jaTX/DemyhxXXgsANcT/QpDTb9JYx7gu2NTa5YBWNF1AXqHbOlfjt2wLm MheyDkvZGRbCyvYflMf3fqDTb36z6Iyw2L0nSZ/MSLCOayYFfrrVN8pZbY29J8f+0+7z 2slP2TboeF/Un25OGXGMqzPZIxa9vOSlyTR6o=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; b=qlmSXNYR9kbyiL4/E0xIMgafZP+2OpOPQI/BQVTmZyOWEdgOKFd3SDI0ahrfOZFBpI wY31okoaHGXTFG2lv+esJDTa2JNM6ISvWVi8ES4SXn2kPn/7ion2EkSsvILYsOOAfabY TMhGAVaQYwjiAlf0rpcrJQEXbAJGkKNFfu2o8=
Received: by 10.52.73.9 with SMTP id h9mr528950vdv.208.1308090680099; Tue, 14 Jun 2011 15:31:20 -0700 (PDT)
Received: from [192.168.1.101] ([204.237.32.134]) by mx.google.com with ESMTPS id du6sm1109286vdb.21.2011.06.14.15.31.18 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 14 Jun 2011 15:31:19 -0700 (PDT)
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> <4DF7BCD3.7050804@cisco.com>
In-Reply-To: <4DF7BCD3.7050804@cisco.com>
Mime-Version: 1.0 (iPad Mail 8J3)
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=us-ascii
Message-Id: <F0FF78BD-80BE-4B93-85BD-C43792FEB25E@gmail.com>
X-Mailer: iPad Mail (8J3)
From: Peter Musgrave <musgravepj@gmail.com>
Date: Tue, 14 Jun 2011 18:31:07 -0400
To: Paul Kyzivat <pkyzivat@cisco.com>
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 22:31:22 -0000

I agree too.

I also thought CSTA was a bit too "kitchen sink" when I looked at it years ago. But perhaps we can use it to guide a very modest subset? It has at least looked at a very similar problem space so there should be lessens learned there...


Peter

Sent from my iPad

On 2011-06-14, at 3:56 PM, Paul Kyzivat <pkyzivat@cisco.com>; wrote:

> 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
>>>> 
>> 
> _______________________________________________
> splices mailing list
> splices@ietf.org
> https://www.ietf.org/mailman/listinfo/splices