Re: [splices] SIP INVOKE method

Paul Kyzivat <pkyzivat@cisco.com> Tue, 17 May 2011 13:51 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 E350DE067B for <splices@ietfa.amsl.com>; Tue, 17 May 2011 06:51:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Level:
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[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 ESiVJ+v9IXJd for <splices@ietfa.amsl.com>; Tue, 17 May 2011 06:51:15 -0700 (PDT)
Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfa.amsl.com (Postfix) with ESMTP id 7EC0DE0769 for <splices@ietf.org>; Tue, 17 May 2011 06:51:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=2062; q=dns/txt; s=iport; t=1305640275; x=1306849875; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=wrYGb4Q74JRhQ47zkzGVbdxCiimJrS+W0hsUcifYj2o=; b=SK9J6yK7asjUIhS6c/vfKogIShfBSXgnLpTFanaylqLmR6HzkcGWudyJ Oh2lVjrP8lahtyp6B/s5+SvGUTLLaa/U3FQVADmEIicU1MoPlb2UW8xY2 wjxfhBcJzsgBNcsuBkWMSepnIVgj08zmYxOinCtCGk5g/hdTRw+4BALEa Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AjEIAOJ80k2rRDoJ/2dsb2JhbACYDY4Md6oJniGGGQSQEYQvimI
X-IronPort-AV: E=Sophos;i="4.65,225,1304294400"; d="scan'208";a="698741291"
Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-6.cisco.com with ESMTP; 17 May 2011 13:51:15 +0000
Received: from [161.44.174.124] (dhcp-161-44-174-124.cisco.com [161.44.174.124]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p4HDpEoD029827 for <splices@ietf.org>; Tue, 17 May 2011 13:51:14 GMT
Message-ID: <4DD27D52.9030509@cisco.com>
Date: Tue, 17 May 2011 09:51:14 -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: splices@ietf.org
References: <6369CB70BFD88942B9705AC1E639A33822CBDA8EBF@DC-US1MBEX4.global.avaya.com>
In-Reply-To: <6369CB70BFD88942B9705AC1E639A33822CBDA8EBF@DC-US1MBEX4.global.avaya.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: Re: [splices] SIP INVOKE method
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, 17 May 2011 13:51:19 -0000

Rifaat,

I just did a quick read of this.
Some things I like, others not so much.

I like using something other than REFER.

I don't like defining something new that creates an implicit 
subscription. In retrospect the implicit subscription of REFER is widely 
thought to have been a mistake - one we won't do again. As co-chair of 
sipcore I can safely promise that it won't be approved in that form.

Some off-the-cuff thoughts about how to change this to address the concern:

Define an event package. (You already have that.) But require a 
subscription to that package to be overtly established (with subscribe).

Then do one of the following to deliver the action:
- make the action a header in the subscribe request
- encode the action in the body of the subscribe request
- define an in-dialog method to deliver the action within
   the subscribe request.

Of those, I'm tending to the method approach. It would allow use of the 
body to convey extra information about the action.

Perhaps there are cases where the method could be sent without a 
subscription when there is no need to learn the outcome.

In cases where you want to have an ongoing control relationship with 
another device you could just establish the subscription once, and then 
send a series of action requests to it.

	Thanks,
	Paul

On 5/17/2011 9:15 AM, Shekh-Yusef, Rifaat (Rifaat) wrote:
> Hi,
>
> As discussed in the last SPLICES WG meeting in Prague, the REFER method
> is overloaded and has limitations that prevents it from being the ideal
> method for action invocation.
>
> We have worked on the following new draft that defines a new SIP method
> to be used for invoking actions:
>
> https://datatracker.ietf.org/doc/draft-yusef-splices-invoke/
>
> We would appreciate it if people review the document and provide us with
> their feedback.
>
> Regards,
>
> Rifaat
>
>
>
> _______________________________________________
> splices mailing list
> splices@ietf.org
> https://www.ietf.org/mailman/listinfo/splices