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 >>> >
- Re: [splices] SIP INVOKE method v1 Paul Kyzivat
- [splices] SIP INVOKE method v1 Shekh-Yusef, Rifaat (Rifaat)
- Re: [splices] SIP INVOKE method v1 Hutton, Andrew
- Re: [splices] SIP INVOKE method v1 Shekh-Yusef, Rifaat (Rifaat)
- Re: [splices] SIP INVOKE method v1 Shekh-Yusef, Rifaat (Rifaat)
- Re: [splices] SIP INVOKE method v1 Hutton, Andrew
- Re: [splices] SIP INVOKE method v1 Worley, Dale R (Dale)
- Re: [splices] SIP INVOKE method v1 Shekh-Yusef, Rifaat (Rifaat)
- Re: [splices] SIP INVOKE method v1 Alan Johnston
- Re: [splices] SIP INVOKE method v1 Hutton, Andrew
- Re: [splices] SIP INVOKE method v1 Hutton, Andrew
- Re: [splices] SIP INVOKE method v1 Worley, Dale R (Dale)
- Re: [splices] SIP INVOKE method v1 Paul Kyzivat
- Re: [splices] SIP INVOKE method v1 Peter Musgrave
- Re: [splices] SIP INVOKE method v1 Hutton, Andrew
- Re: [splices] SIP INVOKE method v1 R.Jesske
- Re: [splices] SIP INVOKE method v1 Shekh-Yusef, Rifaat (Rifaat)