Re: [dispatch] SIP Action Referral

["Shekh-Yusef, Rifaat (Rifaat)" <[e-mail]>]

Hi Christer,

Thanks for your detailed review and comments.
See my comments inline...

Regards,
 Rifaat


> -----Original Message-----
> From: Christer Holmberg [mailto:[e-mail]]
> Sent: Monday, January 17, 2011 7:19 AM
> To: Shekh-Yusef, Rifaat (Rifaat); [e-mail]
> Subject: RE: [dispatch] SIP Action Referral
> 
> 
> 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?
> 
Yes. Thanks for mentioning this; I should have mentioned this in the email or/and in the draft. 
I will fix that in the next version of the draft.

> 
> 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".
> 
Can you propose some text for that?


> 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).
> 
Good point. I will change it to MUST.

> 
> 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?
> 
For actions that are not in the context of an existing dialog.
While we did not provide an example for such a use case, we did not want to limit these actions to existing dialogs only.

> 
> 
> 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.
> 
Take a look at the call flow on page 20. How would a standard REFER request be able to ask the REFER-Recipient to send a 480 reponse?
For the hold use case, let's take a look at the example in section 3.3.2.Let's say that Alice wants to put the call on hold using her Desk Phone. 
How would you do that with a REFER with a re-INVITE?

> 
> 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.
> 
Good point.

> 
> 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.
> 
Yes, this is an extension to 3515.


> 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.
> 
RFC 3515, Section 2.4.5, The Body of the NOTIFY, states the following:
"Note that if the reference was to a non-SIP URI, status in any NOTIFYs to the referrer must still be in the form of SIP Response Status-Lines."

> 
> 
> 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?
> 
I think that's been discussed in the past and deemed inappropriate.
Remember that some of the actions might be outside of an existing dialog.


> 
> Regards,
> 
> Christer
> 
> 
> 
> 
> 
> > -----Original Message-----
> > From: [e-mail]
> > [mailto:[e-mail]] On Behalf Of Shekh-Yusef,
> > Rifaat (Rifaat)
> > Sent: 14. tammikuuta 2011 20:41
> > To: [e-mail]
> > 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:[e-mail]]
> > Sent: Friday, January 14, 2011 8:15 AM
> > To: Shekh-Yusef, Rifaat (Rifaat)
> > Cc: [e-mail]; [e-mail];
> > [e-mail]
> > 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/dispatch
> >