Re: [dispatch] SIP Action Referral

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

Inline...

> -----Original Message-----
> From: Christer Holmberg [mailto:[e-mail]]
> Sent: Wednesday, January 19, 2011 5:39 AM
> To: Shekh-Yusef, Rifaat (Rifaat); [e-mail]
> Subject: RE: [dispatch] SIP Action Referral
> 
> 
> 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?
> 
[Rifaat] What I am trying to say is that an application can use the presence of an option tag in the Supported header to discover if a UA support this specification if that UA is currently involved in a dialog. Otherwise, the application needs the feature tag to discover the UA's capabilities.

> >>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?
> 
[Rifaat] "100 Trying" for indicating that the REFER-Recipient is trying to perform the requested action.
"200 OK" for indicating that the REFER-Recipient has completed the requested action.


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