Re: [dispatch] SIP Action Referral

Christer Holmberg <christer.holmberg@ericsson.com> Mon, 17 January 2011 12:16 UTC

Return-Path: <christer.holmberg@ericsson.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 368493A6F35 for <dispatch@core3.amsl.com>; Mon, 17 Jan 2011 04:16:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.444
X-Spam-Level:
X-Spam-Status: No, score=-6.444 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 bIV-23hXqhWX for <dispatch@core3.amsl.com>; Mon, 17 Jan 2011 04:16:58 -0800 (PST)
Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id D7FCB3A6F31 for <dispatch@ietf.org>; Mon, 17 Jan 2011 04:16:47 -0800 (PST)
X-AuditID: c1b4fb39-b7cfbae000005c8e-09-4d3433c88227
Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id A8.14.23694.8C3343D4; Mon, 17 Jan 2011 13:19:21 +0100 (CET)
Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.2.33]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Mon, 17 Jan 2011 13:19:20 +0100
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: "Shekh-Yusef, Rifaat (Rifaat)" <rifatyu@avaya.com>, "dispatch@ietf.org" <dispatch@ietf.org>
Date: Mon, 17 Jan 2011 13:19:19 +0100
Thread-Topic: [dispatch] SIP Action Referral
Thread-Index: Acuz7WF7P6FR+vtkQAqbY89oD60UaAAHEC9AAIMP9KA=
Message-ID: <7F2072F1E0DE894DA4B517B93C6A05850A22A8BF42@ESESSCMS0356.eemea.ericsson.se>
References: <6369CB70BFD88942B9705AC1E639A33822082B69C6@DC-US1MBEX4.global.avaya.com>
In-Reply-To: <6369CB70BFD88942B9705AC1E639A33822082B69C6@DC-US1MBEX4.global.avaya.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAA==
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: Mon, 17 Jan 2011 12:16:59 -0000

Hi,

A few initial questions/comments on the document.


GENERAL:
========

GQ1: I assume this is a continuation/re-start of draft-audet-sipping-feature-ref, ie that draft will no longer by updated?


GQ2: In the use-cases/examples, it seems like every "action" triggers a SIP message (request or response). Is the intention that an "action" is always associated with a SIP message? Before we decide upon a solution, I think we should have a definition/requirement for "action".

GQ3: Section 5.2 says that a UA SHOULD indicate support of the extension. Again, referring to the evil of SHOULDs when it comes to conformance testing, please indicate when the SHOULD does not apply (or use MUST instead).


GQ4: Section 5.2 also seems to refer to a feature tag. Why do we need both an option-tag and feature-tag to indicate support of this?



REFER specific:
===============

The following issues/questions need to be addressed if we want to go ahead with a REFER based solution.

RQ1: Section 2 says that REFER can not be used to place a call on hold, and in the examples you use an "action" to terminate a call. But, as far as I know a REFER can be used to trigger any kind of SIP request (including re-INVITE, CANCEL etc). This was discussed (and confirmed, AFAIK) when we discussed draft-audet-sipping-feature-ref.


RQ2: Eventhough the Refer-To ABNF allows for URNs, the text in section 2.1 of RFC 3515 says that it is used to carry a URL. However, the rest of the document talks about Refer-To containing a URI, which would allow also a URN, so I guess we just need to verify that a URN is ok.


RQ3: RFC 3515 says that Refer-To contains "a resource to be contacted", and that the REFER recipient (identified by the Request-URI) should
   contact a third party using the contact information provided in the request.

In your draft, Refer-To does not contain such information.

I guess one alternative could be to use a separate header field to indicate the action.


RQ4: If the action in the REFER is used to trigger a SIP response (or, no SIP message at all (see GQ2)), what will the sipfrag message body in the NOTIFY contain? Note that RFC 3515 requires the NOTIFY to contain a sipfrag body.



Alternative mechanisms:
=======================

AQ1 (Alternative): In case the "action" request can be sent using an established dialog, have you considered the usage of an Info Package?


Regards,

Christer



 

> -----Original Message-----
> From: dispatch-bounces@ietf.org 
> [mailto:dispatch-bounces@ietf.org] On Behalf Of Shekh-Yusef, 
> Rifaat (Rifaat)
> Sent: 14. tammikuuta 2011 20:41
> To: dispatch@ietf.org
> Subject: [dispatch] SIP Action Referral
> 
> 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.
> 
> 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
>