Re: [dispatch] SIP Action Referral

Paul Kyzivat <pkyzivat@cisco.com> Sun, 16 January 2011 03:56 UTC

Return-Path: <pkyzivat@cisco.com>
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 199403A6DA3 for <dispatch@core3.amsl.com>; Sat, 15 Jan 2011 19:56:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.524
X-Spam-Level:
X-Spam-Status: No, score=-110.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L4kOrV0-3V2g for <dispatch@core3.amsl.com>; Sat, 15 Jan 2011 19:56:44 -0800 (PST)
Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 981333A67E3 for <dispatch@ietf.org>; Sat, 15 Jan 2011 19:56:44 -0800 (PST)
Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAKn7MU1AZnwM/2dsb2JhbACkaXOka5gehVAEhHCGL4Mkgng
Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 16 Jan 2011 03:59:14 +0000
Received: from [10.86.254.195] ([10.86.254.195]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p0G3xEv4023889 for <dispatch@ietf.org>; Sun, 16 Jan 2011 03:59:14 GMT
Message-ID: <4D326D11.1010107@cisco.com>
Date: Sat, 15 Jan 2011 22:59:13 -0500
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7
MIME-Version: 1.0
To: dispatch@ietf.org
References: <6369CB70BFD88942B9705AC1E639A33822082B69C6@DC-US1MBEX4.global.avaya.com>
In-Reply-To: <6369CB70BFD88942B9705AC1E639A33822082B69C6@DC-US1MBEX4.global.avaya.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: Re: [dispatch] SIP Action Referral
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 16 Jan 2011 03:56:46 -0000

On 1/14/2011 1:41 PM, Shekh-Yusef, Rifaat (Rifaat) wrote:
> Hi,
>
> We have submitted the following SIP Action Referral draft to the IETF and we would like to discuss it during the upcoming DISPATCH meeting in IETF80.
> https://datatracker.ietf.org/doc/draft-yusef-dispatch-action-ref/
> A charter proposal will follow by the end of next week.
>
> We would appreciate any comments or feedback on this draft.

This seems pretty interesting.

Some of it seems relatively reasonable and straightforward.

I am a little concerned that the space of actions that might be 
controlled in this way is largely unbounded - the beginning of an 
enumeration of telephony features. But maybe not.

A couple of pieces seem to be addons/afterthoughts that aren't well 
integrated:

3.2.  Loosely Coupled UAs
3.3.2.  Answer an A/V call on two separate devices

I note that the function used in 3.3.2 is not mentioned in the 
enumeration of actions included in section 4.2.

This feature seems to raise more questions than it answers. 
Specifically, a one time delivery of audio answer SDP from the phone to 
the PC hardly seems like enough to make this work. What would happen on 
subsequent reinvite-o/a interactions between bob and alice? How long 
should the phone keep the audio active, in the absence of a real 
signaling session to control it? I suppose that the PC can send 
additional REFERs to the phone, but then there will be no dialog to 
refer to.

Maybe this could be developed, but there is a lot more to say to make 
this work. But ISTM when this is worked out there will have to be a sip 
dialog with the phone, perhaps from the PC.

	Thanks,
	Paul


> Thanks,
>   Rifaat
>
>
> -----Original Message-----
> From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org]
> Sent: Friday, January 14, 2011 8:15 AM
> To: Shekh-Yusef, Rifaat (Rifaat)
> Cc: fluffy@cisco.com; alan.b.johnston@gmail.com; francois.audet@skype.net
> Subject: New Version Notification for draft-yusef-dispatch-action-ref-00
>
>
> A new version of I-D, draft-yusef-dispatch-action-ref-00.txt has been successfully submitted by Rifaat Shekh-Yusef and posted to the IETF repository.
>
> Filename:	 draft-yusef-dispatch-action-ref
> Revision:	 00
> Title:		 Action Referral in the Session Initiation Protocol (SIP)
> Creation_date:	 2011-01-14
> WG ID:		 Independent Submission
> Number_of_pages: 24
>
> Abstract:
> This specification defines action referral that allows an application
> to make a high level request to a User Agent to perform an action,
> and let the the User Agent execute the action as it sees fit. Action
> referral uses the SIP REFER method with a Refer-To header field
> containing a URN, which indicates the requested action.
>
> This specification also defines the option tag 'action-ref' to allow
> the UA to indicate its support for action referral.
>
>
>
> The IETF Secretariat.
>
>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
>