Subject: [dispatch] SIP Action Referral

From: "Shekh-Yusef, Rifaat (Rifaat)" <[email-masked]>
Date: Fri, 14 Jan 2011 13:41:05 -0500

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:[email-masked]] 
Sent: Friday, January 14, 2011 8:15 AM
To: Shekh-Yusef, Rifaat (Rifaat)
Cc: [email-masked]; [email-masked]; [email-masked]
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.

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 15 Jan 2011 22:59:13 -0500

> 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

> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch
>

---

From: "Shekh-Yusef, Rifaat (Rifaat)" <[email-masked]>
Date: Sun, 16 Jan 2011 09:42:00 -0500

Hi Paul,

Thanks for reviewing the document and providing us with your feedback.
See my comments inline...

Regards,
 Rifaat

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Paul Kyzivat
> Sent: Saturday, January 15, 2011 10:59 PM
> To: [email-masked]
> Subject: Re: [dispatch] SIP Action Referral
> 
> 
> 
> > 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.

[Rifaat] For that reason we are stating that for any new action to be added there is a need for an IETF review.

> enumeration of actions included in section 4.2.
[Rifaat] Good catch. Thanks.

> dialog with the phone, perhaps from the PC.

[Rifaat] One way to address your concern here is to keep the dialog created by the REFER request open.
But Yes, I agree that there is more work to be done on this use case.

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

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 17 Jan 2011 13:19:19 +0100

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

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Shekh-Yusef, 
> Rifaat (Rifaat)
> Sent: 14. tammikuuta 2011 20:41
> To: [email-masked]
> 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.
> 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.
>

---

From: "Shekh-Yusef, Rifaat (Rifaat)" <[email-masked]>
Date: Tue, 18 Jan 2011 15:41:49 -0500

Hi Christer,

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

Regards,
 Rifaat

> From: Christer Holmberg [mailto:[email-masked]]
> Sent: Monday, January 17, 2011 7:19 AM
> To: Shekh-Yusef, Rifaat (Rifaat); [email-masked]
> Subject: RE: [dispatch] SIP Action Referral
> 
> 
> Hi,
> 
> 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.

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

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

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 19 Jan 2011 09:50:28 +0200

Hi,

> 3.3.2.  Answer an A/V call on two separate devices

these two sections are very much related to the work the SPLICES WG is
doing. SPLICES deals with scenarios like the ones described in both
sections. In fact, most of the discussions so far have dealt with how to
implement scenarios similar to the one described in Section 3.3.2.

Cheers,

Gonzalo

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 19 Jan 2011 11:39:06 +0100

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

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

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

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.

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

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

> > > [mailto:[email-masked]] On Behalf Of 
> Shekh-Yusef, Rifaat 
> > > (Rifaat)
> > > 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.
> > > 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.
> > >

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 19 Jan 2011 09:03:54 -0500

> implement scenarios similar to the one described in Section 3.3.2.

I recognized that, but at the time I was replying I didn't remember the 
current name for that wg. :-(

I certainly agree that the scenario is an interesting one.
And maybe this mechanism can play a role in supporting it.
But as you can tell, I remain skeptical that this mechanism is 
sufficient for the task. But that will be determined in the process of 
fleshing out the missing detail.

	Thanks,
	Paul

---

From: "Shekh-Yusef, Rifaat (Rifaat)" <[email-masked]>
Date: Wed, 19 Jan 2011 11:14:42 -0500

Hi Paul,

Let's take a look at the following scenario, which starts with an audio call and then video is added to the existing audio call:

   Alice                 Alice                Proxy                  Bob
    PC                 Desk Phone                                      
    |                     |                     |                     |
The scenario starts with an audio call from Bob to Alice
    |                     |                     |                     |
    |                     |                     | INVITE Alice [Audio]|
    |                     |                     |<--------------------|
    |                     | INVITE Alice [Audio]|                     |
    |                     |<--------------------|                     |
    | INVITE Alice [Audio]|                     |                     |
    |<------------------------------------------|                     |
    |                     |                     |                     |
Let's assume that Alice used her PC to answer the call    
    |                     |                     |                     |
    | REFER Refer-To: urn:sip-action:call:answer                      |
    |-------------------->|                     |                     |
    | 202                 |                     |                     |
    |<--------------------|                     |                     |
    |                     |                     |                     |
    | NOTIFY [100 Trying] |                     |                     |
    |        Subscription-State: active; expires=whatever             |
    |<--------------------|                     |                     |
    | 200 OK              |                     |                     |
    |-------------------->|                     |                     |
    |                     | 200 OK [Audio]      |                     |
    |                     |-------------------->|                     |
    |                     |                     | 200 OK [Audio]      |
    |                     |                     |-------------------->|
    |                     |                     |                     |
The following NOTIFY will confirm the audio answer, but it will NOT terminate the dialog.
    |                     |                     |                     |
    | NOTIFY [200 OK]     |                     |                     |
    |        Subscription-State: active; expires=whatever             |
    |<--------------------|                     |                     |
    | 200 OK              |                     |                     |
    |-------------------->|                     |                     |
    |                     |                     |                     |
    | CANCEL              |                     |                     |
    |<------------------------------------------|                     |
    |                     |                     |                     |
    |<------dialog2------>|<---dialog1------------------------------->|
    |                     |                     |                     |
    |                     |<======audio==============================>|
    |                     |                     |                     |
    |                     |                     |                     |
    |                     |                     |                     |
The following is a re-INVITE to add video to the existing audio call
    |                     |                     |                     |
    |                     |                     | INVITE Alice [A/V]  |
    |                     |                     |<--------------------|
    |                     | INVITE Alice [A/V]  |                     |
    |                     |<--------------------|                     |
    |                     |                     |                     |
The following REFER can be in-dialog, or out of dialog with a Target-Dialog header
    |                     |                     |                     |
    | REFER Refer-To: urn:sip-action:video:answer                     |
    |       [Video Offer] |                     |                     |
    |<--------------------|                     |                     |
    | 202                 |                     |                     |
    |-------------------->|                     |                     |
    |                     |                     |                     |
    | NOTIFY [100 Trying] |                     |                     |
    |-------------------->|                     |                     |
    | 200 OK              |                     |                     |
    |<--------------------|                     |                     |
    |                     |                     |                     |
Alice decided to accept the Video call
    |                     |                     |                     |
    | NOTIFY [200 OK [Video SDP answer]]        |                     |
    |-------------------->|                     |                     |
    | 200 OK              |                     |                     |
    |<--------------------|                     |                     |
    |                     |                     |                     |
    |                     | 200 OK [A/V]        |                     |
    |                     |-------------------->|                     |
    |                     |                     | 200 OK [A/V]        |
    |                     |                     |-------------------->|
    |                     |                     |                     |
    |                     |<======audio==============================>|
    |<============================video==============================>|
    |                     |                     |                     |

Any thoughts?

Regards,
 Rifaat

> Sent: Wednesday, January 19, 2011 9:04 AM
> To: Gonzalo Camarillo
> Cc: [email-masked]

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 19 Jan 2011 11:52:35 -0500

Rifaat,

>      |                     |                     | INVITE Alice [Audio]|

I'm with you this far.

>      |                     |                     | INVITE Alice [A/V]  |

This is where it starts to get obscure.

For one thing, the phone has to know to do this. So it must be an 
intelligent device that knows about video, and that it doesn't do video 
itself but rather delegates it in this particular way.

You can postulate anything you want, but it seems a bit much to expect 
such intelligence from the basic phone. Makes a lot more sense to me to 
put the intelligence in the PC.

Anyway, assuming the phone is that smart, *it* is now initiating an 
action referral toward the PC. I gather it chose that destination 
because the PC has the ongoing refer dialog with it. What is there about 
the prior urn:sip-action:call:answer that causes the phone to think the 
sender of that referral might be able to accept video, using this 
mechanism? Was there some sort of capability negotiation during the 
earlier REFER?

>      | NOTIFY [100 Trying] |                     |                     |

There has been no invite by the PC, so this 100 Trying is entirely 
synthetic. IOW this is postulating a "virtual invite", right?

>      | 200 OK              |                     |                     |

Maybe there should have been a "virtual 180" first while Alice is 
alerted to the desire for video?

>      | NOTIFY [200 OK [Video SDP answer]]        |                     |

So now we have the virtual 200 OK to the virtual invite?

What if the "offer" carried in the REFER was of form that required an 
additional o/a exchange? (E.g. preconditions.) Would we carry extended 
o/a exchanges over this refer subscription?

You do realize how complex the specification of o/a exchanges has 
become. And Bob is expecting that to work in an entirely normal way. All 
of that mechanism will need to be recast to work over the refer 
subscription. In effect you are proposing to establish an 
invite-dialog-usage between the PC and the phone while tunneling all the 
messages over a subscription. How can this be better than actually 
establishing an invite-dialog between the PC and the phone?

I would offer an alternative:

- at the first (forked) invite, the pc could send another invite to
   the phone with the audio m-line. It then might use sip action
   referral to tell the phone to answer its call and reject the
   original one. ANd perhaps even to alter the phone display of
   who the caller is.

- then the pc will get the reinvite with A/V. It can keep the
   video to itself, while continuing to get the audio from the phone.

	Thanks,
	Paul

---

From: Salvatore Loreto <[email-masked]>
Date: Wed, 19 Jan 2011 19:57:25 +0100

Hi,

I tend to agree this draft is very much related to the SPLICE wg.
Indeed during the discussion of draft:
http://tools.ietf.org/id/draft-loreto-splices-disaggregated-media-00.txt
people have foresee REFER as a possible method to solve the use cases 
showed in the draft.
This draft really give a first answer on how REFER can be extended to 
solve the disaggregated media scenario.

Moreover one advantage of the Loosely Coupled UAs scenario you have in 
Section 3.2 and in the
example in Section 3.3 is that
in your case the side that want to use a Loosely Coupled UAs scenario 
does not put any
extra requirements on the other side,
where in the Disaggregated Framework the other side have to correlate 
the different dialogs
coming from the different Loosely Coupled UAs!
That also remove the need to correlate different session in order to let 
them the different sessions
appear as a single conversation to the other side.

Finally, I agree with Paul that there is the need to design a sort of 
distributed call control
and decide how the different Loosely Coupled UAs exchange call related 
information during
an on going call, and what are the information that need to be exchanged.

I will be happy to help you in move forward this work.

cheers
/Sal

-- 
Salvatore Loreto
www.sloreto.com

---

From: Salvatore Loreto <[email-masked]>
Date: Wed, 19 Jan 2011 20:02:30 +0100

On 1/18/11 9:41 PM, Shekh-Yusef, Rifaat (Rifaat) wrote:
>> >  To: Shekh-Yusef, Rifaat (Rifaat);[email-masked]
..
> Can you propose some text for that?
I don't think an "action" is something that only triggers a SIP message

I would define an action as:

"an event, or a series of events, that modify the state of a UA.
The modification can happen at different lever: SIP, User Interface etc."

cheers
/Sal

-- 
Salvatore Loreto
www.sloreto.com

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 19 Jan 2011 21:48:23 +0100

Hi,

I also have some issues with this example, and how it's implemented.

Because, when the A/V re-INVITE comes, you don't use REFER to trigger an action, but to inform Alice PC about the received offer. Then Alice PC uses a NOTIFY to trigger the sending of the 200 OK with the answer.

Regards,

Christer

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Paul Kyzivat [[email-masked]]
Sent: Wednesday, January 19, 2011 6:52 PM
To: Shekh-Yusef, Rifaat (Rifaat)
Cc: [email-masked]
Subject: Re: [dispatch] SIP Action Referral

Rifaat,

I'm with you this far.

        Thanks,
        Paul

---

From: Alan Johnston <[email-masked]>
Date: Wed, 19 Jan 2011 14:50:19 -0600

I agree that some actions are definitely not SIP events but local events on
the UA.  For example, mute speaker or microphone.  Or to trigger local
mixing operation, such as a join of two existing dialogs.

- Alan -

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 20 Jan 2011 11:14:21 +0200

Hi,

note that we have a whole WG (SPLICES) to deal with this type of
scenarios. So, nobody thinks resolving them is that easy. This draft
could very well be one piece of the whole solution.

In any case, discussions about this type of scenario so far have been
around the fact that some people find it acceptable that UAs need to be
upgraded in order to support new mechanisms while others believe that
any mechanism should work with legacy UAs. The former group likes
REFER-like mechanisms where both UAs need to understand the mechanism
while the latter group prefers 3pcc-like mechanisms where only one
entity needs to understand the mechanism. The SPLICES WG has not reached
consensus on this issue yet. So, further discussions are appreciated.

Cheers,

Gonzalo

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 20 Jan 2011 09:35:19 -0500

I generally agree with what Gonzalo is saying below.
But to clarify a bit:

I don't think anybody believes that federating multiple devices can be 
accomplished without upgrading *any* UAs. The difference of opinion is 
more around *which* UAs need to be upgraded - all of those 
participating, or only a subset, and if a subset, which subset.

This seems to sort out into the following alternatives:

- one upgraded UA coordinates the federation of some
   other not-necessarily-upgraded UAs to present the
   appearance of a single multimedia UA in a dialog with
   some other multi-media, not-necessarily-upgraded UA

- a group of upgraded UAs federate with one another to present the
   appearance of a single multimedia UA in a dialog with
   some other multi-media, not-necessarily-upgraded UA

- an upgraded UA coordinates dialogs with multiple
   not-necessarily-upgraded UAs to present the appearance
   of a multimedia dialog to its own user.j

IMO the possibility of widespread adoption is maximized by minimizing 
the number of pieces that need to be upgraded.

	Thanks,
	Paul

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 20 Jan 2011 17:56:12 +0200

Hi Paul,

yes, it is clear that a 3pcc-like mechanism has certain advantages, like
the one you mention below about easy deployment. The discussion is more
about whether we need another mechanism (REFER-like, with its advantages
and disadvantages over the 3pcc-like one) or we should just be happy
with just the 3pcc-like mechanism.

Cheers,

Gonzalo

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 20 Jan 2011 14:30:16 -0500

I agree that some other mechanism might also be helpful in some cases. I 
just don't see it as a substitute for an invite-dialog-usage when there 
is a need to do o/a negotiation.

	Thanks,
	Paul

---

From: [email-masked]
Date: Fri, 21 Jan 2011 10:58:15 +0800

Hi Gonzalo,

Comparing the 3pcc-like mechanism and the REFER-like mechanism by current 
use cases and discussion, 

I think the 3pcc-like mechanism has such advantages:
1. easy for deployment(as the requirement agout the end equipment is 
relatively low);
2. easy for control and operating(as the main logic could be in the 3pcc 
AS).

I think the REFER-like mechanism has such advantage:
1. no need for central control point.(So, it is fit for Internet usage or 
some enterprise usage.)

As the use cases and background is about services-like or value-added 
services-like things, so the choice could be abstracted as "call control 
using current signalling" or "directing enhancement for signalling". 
Considering the endless services, I prefer the way of "call control using 
current signalling". That is the 3pcc-like mechanism.

Thanks,

Gao

> > the number of pieces that need to be upgraded.

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

---

From: "Shekh-Yusef, Rifaat (Rifaat)" <[email-masked]>
Date: Sat, 22 Jan 2011 19:10:06 -0500

Gonzalo,

I agree that these are complex scenarios that better be discussed in the SPLICES WG.

Paul,

See inline for few replies to some of your comments below.

Regards,
 Rifaat

> From: Gonzalo Camarillo [mailto:[email-masked]]
> Sent: Thursday, January 20, 2011 4:14 AM
> To: Paul Kyzivat
> Cc: Shekh-Yusef, Rifaat (Rifaat); [email-masked]
> >> Let's take a look at the following scenario, which starts with an audio
> call and then video is added to the existing audio call:
> >>
> >>     Alice                 Alice                Proxy                  Bob
> >>      PC                 Desk Phone
> >>      |                     |                     |                     |
[Rifaat] If you want to be able to deliver advanced features then you need intelligent devices.

> > put the intelligence in the PC.
[Rifaat] That is true in the 3pcc model where the controller that has the intelligence.
For very complex features I think we can expect the phone to be more than just a basic phone.

> > mechanism? Was there some sort of capability negotiation during the
[Rifaat] I think the 'video' feature tag should be sufficient. Would it not?

> > synthetic. IOW this is postulating a "virtual invite", right?
[Rifaat] Not really.
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."
The 100 Trying in this case is just an indication that the PC is trying to perform the requested action.

> > alerted to the desire for video?
[Rifaat] I do not see a need for this because there was no INVITE.

> > So now we have the virtual 200 OK to the virtual invite?
[Rifaat] The 200 OK in this case is just an indication that the PC has completed the requested action.

> > establishing an invite-dialog between the PC and the phone?
[Rifaat] Good point. And the following alternative you are proposing is an interesting idea that worth exploring in the SPLICES WG.

---

From: "Shekh-Yusef, Rifaat (Rifaat)" <[email-masked]>
Date: Sun, 23 Jan 2011 08:48:19 -0500

Inline...

> Sent: Wednesday, January 19, 2011 5:39 AM
> 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.
> 
[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.

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

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

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 23 Jan 2011 15:34:40 +0100

Hi,

>>>While we did not provide an example for such a use case, we did not 
>>>want to limit these actions to existing dialogs only.
>> 
>[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.

I guess I should have been more clear. What I meant was that you could use the existing sip.extensions feature tag, and use the new option-tag as value for that feature tag.

>>>>REFER specific:
>>>>===============
>>>>
>>>>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.
>>>>
>>>"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?
> 

Ok. So, each "action" then needs to define what Status-Lines to send.

Regards,

Christer

---

From: "Shekh-Yusef, Rifaat (Rifaat)" <[email-masked]>
Date: Sun, 23 Jan 2011 09:58:50 -0500

> Sent: Sunday, January 23, 2011 9:35 AM
> >[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
> I guess I should have been more clear. What I meant was that you could use the
> existing sip.extensions feature tag, and use the new option-tag as value for
> that feature tag.
> 
[Rifaat] Good point. I am fine with that.

> Ok. So, each "action" then needs to define what Status-Lines to send.
[Rifaat] What I meant is that these "100 Trying" and "200 OK" are generic to all actions.
Why do you think that they should to be "action" specific?

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 23 Jan 2011 21:18:07 +0100

Hi,

>Why do you think that they should to be "action" specific?

Today, when you send a REFER, it triggers a request, and what comes back in the NOTIFY is the response to that triggered request.

That is not the case when the REFER triggers a *response*. It seems like you suggest that what comes back in the NOTIFY is the response that the REFER triggered. Right?

Regards,

Christer

---

From: "Shekh-Yusef, Rifaat (Rifaat)" <[email-masked]>
Date: Sun, 23 Jan 2011 17:50:26 -0500

> Sent: Sunday, January 23, 2011 3:18 PM
> >>>"200 OK" for indicating that the REFER-Recipient has completed the
> requested
> >>>action.
> >>
> Today, when you send a REFER, it triggers a request, and what comes back in
> the NOTIFY is the response to that triggered request.
> 
> That is not the case when the REFER triggers a *response*. It seems like you
> suggest that what comes back in the NOTIFY is the response that the REFER
> triggered. Right?
> 
Yes. Any additional application specific information may be placed in the body of the sipfrag request.

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 23 Jan 2011 22:43:40 -0500

> See inline for few replies to some of your comments below.

I've added some further comments...

> [Rifaat] If you want to be able to deliver advanced features then you need intelligent devices.

You need *some* intelligent devices, but hopefully they don't *all* have 
to be intelligent.

ISTM that a key decision is *where* it makes most sense to have the 
intelligence. Of course there may be more than one answer to that 
question, but then one has to decide how many approaches are worth pursuing.

> For very complex features I think we can expect the phone to be more than just a basic phone.

Yes, clearly cell phones are intelligent devices.
If so, I guess it could do 3pcc too. Then maybe the PC is the "dumb" 
device in the scenario.

> [Rifaat] I think the 'video' feature tag should be sufficient. Would it not?

I think this is something of a stretch. I suppose a video feature tag 
would say something about the device within the dialog in which it was 
presented. But its a leap to conclude it applies to a reciprocal 
arrangement. This *could* be shaped into something, and maybe that is 
part of the work of defining "Action Referral". But I think it is 
starting to should like a much broader framework, for a new model of 
"call control", or maybe "device control". Its a bigger thing than I 
first thought you were proposing.

> The 100 Trying in this case is just an indication that the PC is trying to perform the requested action.

OK. The whole concept of using SIPfrags to report the status of non-sip 
actions is an area that hasn't ever been fleshed out. In absence of 
details I suppose we all draw our own inferences about what it means.

> [Rifaat] I do not see a need for this because there was no INVITE.

I'm groping here for a model of "call control" over this "action 
referral" subscription dialog.

> [Rifaat] The 200 OK in this case is just an indication that the PC has completed the requested action.

Presumably there is then some expectation of continued state - that the 
video stream has been established and remains functional. Right?

> [Rifaat] Good point. And the following alternative you are proposing is an interesting idea that worth exploring in the SPLICES WG.

OK.

	Thanks,
	Paul

---

From: "Shekh-Yusef, Rifaat (Rifaat)" <[email-masked]>
Date: Tue, 25 Jan 2011 19:52:37 -0500

> If so, I guess it could do 3pcc too. Then maybe the PC is the "dumb"
I definitely agree that we can expect the PC to be an intelligent entity, and I agree that in this scenario it probably makes more sense to allow the PC to drive the phone. But I do not get to the conclusion that for all complex features I need only one intelligent device, while the rest can be dumb devices controlled by that intelligent entity.

> arrangement. 
Why reciprocal? 
In the case described above, the user answered the call using his PC.
The PC should be able to add the 'video' feature tag to the Contact header of the REFER request to indicate that it supports video. 
Is that something of a stretch?

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 25 Jan 2011 20:25:21 -0500

> I definitely agree that we can expect the PC to be an intelligent entity, and I agree that in this scenario it probably makes more sense to allow the PC to drive the phone. But I do not get to the…

Certainly one can imagine features that require extra intelligence in 
more than one of the coordinated devices. If its really necessary, then 
so be it.

But if extra intelligence is not necessary in more than one device to 
accomplish the task, and if one could imagine preexisting devices being 
sufficient, then designing the feature so that those less functional 
devices can play will ease the adoption of the new functionality.

Generally its easier to get new features deployed on a PC than on other 
devices, and if a PC is to be involved, it typically has the most 
flexible UI, so its a natural place to put the control. Of course 
today's smart phones can also be readily extended with new Apps, so they 
may also be candidates for the control role, but they still suffer from 
restricted UIs. But still a good candidate for control if nothing better 
is around.

But consider offloading video to a TV. Just getting them to implement 
SIP in "smart" TVs or cable boxes will be a stretch. Minimizing added 
functionality will increase the possibility of an operational system.

> Is that something of a stretch?

The "video" feature tag means that the device supports video media.
It doesn't mean that it supports control of video using the action 
referral mechanism.

The reciprocal I spoke of is assuming that because the PC used the 
action referral mechanism toward the phone implies that it will accept 
action referral requests *from* the phone.

Take that logic one step further:

Suppose I were to subscribe to the dialog event package on your phone, 
and in the Contact of my subscription I added a video feature tag. Would 
that be reason for you to assume that it would make sense for you to do 
an action referral to that contact to display video? Or to send a SIP 
Invite to do video?

If you want the PC to tell the phone to answer the call but delegate 
video, then I think you need to explicitly tell it *where* to delegate 
the video. (After all, the one sending the action referral is the one in 
control.) But I don't off hand see how to do that. Inverting the 
control, so the PC invites the phone, is "easier" because it has all the 
information about what it wants to do.

	Thanks,
	Paul

---

From: "Mike Hammer (hmmr)" <[email-masked]>
Date: Wed, 26 Jan 2011 07:52:25 -0600

Perhaps, someone should estimate the "intelligence" requirements of the
devices you intend to control.  Then one could determine how many of the
appliances meet those requirements and thus could be controlled.  For
example, could a 42" LCD screen attached to a wall with some near field
communications have enough to participate?  Or would it need to be
attached to a setup box?

I would venture that in the Internet of Things, that not all devices
would meet your requirements.

Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Shekh-Yusef, Rifaat (Rifaat)
Sent: Tuesday, January 25, 2011 7:53 PM
To: Paul Kyzivat (pkyzivat)
Cc: [email-masked]
Subject: Re: [dispatch] SIP Action Referral

> > [Rifaat] That is true in the 3pcc model where the controller that
has the
> intelligence.
> > For very complex features I think we can expect the phone to be more
than
> just a basic phone.
I definitely agree that we can expect the PC to be an intelligent
entity, and I agree that in this scenario it probably makes more sense
to allow the PC to drive the phone. But I do not get to the conclusion
that for all complex features I need only one intelligent device, while
the rest can be dumb devices controlled by that intelligent entity.

Why reciprocal? 
In the case described above, the user answered the call using his PC.
The PC should be able to add the 'video' feature tag to the Contact
header of the REFER request to indicate that it supports video. 
Is that something of a stretch?

---

From: "Shekh-Yusef, Rifaat (Rifaat)" <[email-masked]>
Date: Thu, 27 Jan 2011 14:40:24 -0500

Hi Mike, Paul

Thanks for your comments.

The current version of the draft is focused on telephony features, and intentionally did not try to address the Internet of Things area.

But this is an interesting area and I am interested on hearing more of your thoughts about it.

Mike wrote:
> For example, could a 42" LCD screen attached to a wall with some near field

It seems that some smart TVs already support Skype and other widgets. 
http://www.which.co.uk/technology/tv-and-dvd/reviews-ns/skype-on-tv/
Why do you think that it is a stretch to expect a smart TV to support SIP?

Thanks,
 Rifaat

> From: Mike Hammer (hmmr) [mailto:[email-masked]]
> Sent: Wednesday, January 26, 2011 8:52 AM
> To: Shekh-Yusef, Rifaat (Rifaat); Paul Kyzivat (pkyzivat)
> Cc: [email-masked]

---

From: "Mike Hammer (hmmr)" <[email-masked]>
Date: Thu, 27 Jan 2011 15:37:06 -0600

I am not saying that you can't put such intelligence in TVs.

I am suggesting that the market could be bigger if media endpoints
didn't have to be full-blown signaling endpoints.

Also, that if you define the compute/storage requirements, media
endpoints could determine if the COGS are worth the effort to
participate.

Mike

-----Original Message-----
From: Shekh-Yusef, Rifaat (Rifaat) [mailto:[email-masked]] 
Sent: Thursday, January 27, 2011 2:40 PM
To: Mike Hammer (hmmr); Paul Kyzivat (pkyzivat)
Cc: [email-masked]
Subject: RE: [dispatch] SIP Action Referral

Hi Mike, Paul

The current version of the draft is focused on telephony features, and
intentionally did not try to address the Internet of Things area.

But this is an interesting area and I am interested on hearing more of
your thoughts about it.

It seems that some smart TVs already support Skype and other widgets. 
http://www.which.co.uk/technology/tv-and-dvd/reviews-ns/skype-on-tv/
Why do you think that it is a stretch to expect a smart TV to support
SIP?

Thanks,
 Rifaat

> > >>> such intelligence from the basic phone. Makes a lot more sense
to
> me to
> > >>> because the PC has the ongoing refer dialog with it. What is
there
> about
> > > [Rifaat] I think the 'video' feature tag should be sufficient.
Would
> it not?

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 28 Jan 2011 09:30:48 -0500

I also agree that you *could* do these things. And once there is a 
specification, maybe many *new* developments will support it. Yet then 
the features will only be available when all the pieces are new 
*enough*. Anything that was already deployed won't have that support and 
thus won't play.

If you can make use of devices with "vanilla" sip support, then the 
number of potential players will be expanded.

I realize this isn't a problem with cell phones, since everyone throws 
them away and gets new ones every two years. :-) But that isn't true of 
everything. (I don't buy a new TV every year or two.)

	Thanks,
	Paul