Re: [dispatch] SIP Action Referral

[Christer Holmberg <[e-mail]>]

Hi Rifaat, 

>>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?

I don't have a definition of "action" at this point, but I think it is something the community needs to agree upon before choosing a mechanism.

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

I am not sure I understand. Why can't you use e.g. an option-tag both inside and outside an existing dialog?

>>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?

It wouldn't. I said that a REFER can be used to trigger a REQUEST :)

>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?

You send a REFER, indicate which dialog it applies to, and provide (using embedded headers) whatever information (e.g. SDP direction attribute) that needs to 
be include in the re-INVITE. 

I am not saying that is a better way to do it, simply that it is not correct to indicate that it is not possible :)


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

You need to be very clear of that.

Also, we need to discuss whether it's an extension, or an update, because you more or less change the semantics of Refer-To.

You also need to cover backward compability (bwc) issues, and e.g. describe what happens if entities that do not support this receive a REFER. I guess it should not be a problem, and the REFER most likely will be rejected, but it needs to be described.

>>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."

Exactly. So, if the REFER is used to trigger a SIP response (or, no SIP message at all), what Status-Line would you include?

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

Yes.

So, I think we first would need to focus on the requirements (e.g. being able to trigger action outside a dialog), and the definition of "action". I also think the proposed charter should focus on those things, and not on a specific solution.

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
> > >
>