Subject: [splices] Answering an A/V Call Using Two Separate Devices proposal

From: "Shekh-Yusef, Rifaat (Rifaat)" <[email-masked]>
Date: Sat, 21 May 2011 08:56:01 -0400

Hi,

We are still working on a new version of the INVOKE document that removes the implicit subscription.

Meanwhile I would like to continue the discussion of the various possible uses cases.
The following is a proposal for Answering an A/V Call Using Two Separate Devices.

Regards,
 Rifaat

   Alice                 Alice                Proxy                  Bob
    PC                 Desk Phone                                      
    |                     |                     |                     |
    |                     |                     |                     |
Both Alice's devices subscribe to the reg event package, which allows each device to 
discover the capabilities of the other device based on the feature tags provided by each device.
The Desk Phone knows that the PC supports Video, while the PC knows that the Desk Phone only supports audio.
    |                     |                     |                     |
    |                     | SUBSCRIBE reg       |                     |
    |                     |-------------------->|                     |
    |                     | 200 OK              |                     |
    |                     |<--------------------|                     |
    |                     |                     |                     |
    | SUBSCRIBE reg       |                     |                     |
    |------------------------------------------>|                     |
    | 200 OK              |                     |                     |
    |<------------------------------------------|                     |
    |                     |                     |                     |
    |                     |                     |                     |
The two devices also subscribe to the dialog of each other.
    |                     |                     |                     |
    |                     |                     |                     |
    | SUBSCRIBE dialog    |                     |                     |
    |-------------------->|                     |                     |
    | 200 OK              |                     |                     |
    |<--------------------|                     |                     |
    |                     |                     |                     |
    | SUBSCRIBE dialog    |                     |                     |
    |<--------------------|                     |                     |
    | 200 OK              |                     |                     |
    |-------------------->|                     |                     |
    |                     |                     |                     |
    |                     |                     |                     |
The scenario starts with an A/V call from Bob to Alice
    |                     |                     |                     |
    |                     |                     | INVITE Alice [A/V]  |
    |                     |                     |<--------------------|
    |                     | INVITE Alice [A/V]  |                     |
    |                     |<--------------------|                     |
    | INVITE Alice [A/V]  |                     |                     |
    |<------------------------------------------|                     |
    |                     |                     |                     |

(*)

Let's assume that Alice used her PC to answer the incoming call
The PC instructs the phone to answer the audio call    
    |                     |                     |                     |
    | INVOKE Action: urn:invoke:call:answer;media=audio;transducer=speaker|headset
    |-------------------->|                     |                     |
    | 200 OK              |                     |                     |
    |<--------------------|                     |                     |
    |                     |                     |                     |
    |                     | 200 OK [Audio]      |                     |
    |                     |-------------------->|                     |
    |                     |                     | 200 OK [Audio]      |
    |                     |                     |-------------------->|
    | CANCEL              |                     |                     |
    |<------------------------------------------|                     |
    |                     |                     |                     |
    |                     |<---dialog1------------------------------->|
    |                     |                     |                     |
    |                     |<======audio==============================>|
    |                     |                     |                     |
    |                     |                     |                     |
The PC then adds Video to the existing audio call.
    |                     |                     |                     |
    | INVITE with Join [Video]                  |                     |
    |-------------------->|                     |                     |
    | 100                 |                     |                     |
    |<--------------------|                     |                     |
    |                     | re-INVITE [A/V]     |                     |
    |                     |-------------------->|                     |
    |                     |                     | re-INVITE [A/V]     |
    |                     |                     |-------------------->|
    |                     |                     | 200 OK [A/V]        |
    |                     | 200 OK [A/V]        |<--------------------|
    |                     |<--------------------|                     |
    | 200 OK [Video]      |                     |                     |
    |<--------------------|                     |                     |
    |                     |                     |                     |
    |<------dialog2------>|<---dialog1------------------------------->|
    |                     |                     |                     |
    |                     |<======audio==============================>|
    |<============================video==============================>|
    |                     |                     |                     |
    |                     |                     |                     |

The scenario continues after the (*) above
Let's assume that Alice used her phone to answer the incoming call.
The phone answers the audio call
    |                     |                     |                     |
    |                     | 200 OK [Audio]      |                     |
    |                     |-------------------->|                     |
    |                     |                     | 200 OK [Audio]      |
    |                     |                     |-------------------->|
    | CANCEL              |                     |                     |
    |<------------------------------------------|                     |
    |                     |                     |                     |
    |                     |<---dialog1------------------------------->|
    |                     |                     |                     |
    |                     |<======audio==============================>|
    |                     |                     |                     |
    |                     |                     |                     |
The phone then instructs the PC to initiate a video call to join the existing call
    |                     |                     |                     |
    | INVOKE Action: urn:invoke:call:join;media=video;dialog=dialog1
    |<--------------------|                     |                     |
    | 200 OK              |                     |                     |
    |-------------------->|                     |                     |
    |                     |                     |                     |
The PC then adds Video to the existing audio call.
    |                     |                     |                     |
    | INVITE with Join [Video]                  |                     |
    |-------------------->|                     |                     |
    | 100                 |                     |                     |
    |<--------------------|                     |                     |
    |                     | re-INVITE [A/V]     |                     |
    |                     |-------------------->|                     |
    |                     |                     | re-INVITE [A/V]     |
    |                     |                     |-------------------->|
    |                     |                     | 200 OK [A/V]        |
    |                     | 200 OK [A/V]        |<--------------------|
    |                     |<--------------------|                     |
    | 200 OK [Video]      |                     |                     |
    |<--------------------|                     |                     |
    |                     |                     |                     |
    |<------dialog2------>|<---dialog1------------------------------->|
    |                     |                     |                     |
    |                     |<======audio==============================>|
    |<============================video==============================>|
    |                     |                     |                     |

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 21 May 2011 23:15:11 -0400

I guess all of that can work. But for the last part, if the phone knows 
enough to send the invoke to the pc, why can't it just send an INVITE to 
the pc?

	Thanks,
	Paul

On 5/21/2011 8:56 AM, Shekh-Yusef, Rifaat (Rifaat) wrote:
> _______________________________________________
> splices mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/splices
>

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 22 May 2011 17:08:45 -0400

On 5/22/2011 2:40 PM, Shekh-Yusef, Rifaat (Rifaat) wrote:
> Because a new INVITE will probably cause the PC to present the user with a UI component and wait for the users input.

Well, I suppose you would want the PC to indicate what is going on in 
the UI in *some* way. But probably not exactly the same as getting a new 
call.

That could be handled via appropriate Alert-Info. To some extent this is 
a matter of taste. I am inclined to prefer an economy of mechanism, and 
I think the alert-info feels like less mechanism than the particular 
INVOKE mechanism used in this scenario. (The invoke mechanism used here 
requires the phone to assume that the PC is aware of the dialog, and 
able to associate it with the appropriate contact address for doing the 
invite.)

	Thanks,
	Paul

> Regards,
>   Rifaat
>
>
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On Behalf Of
>> Paul Kyzivat
>> Sent: Saturday, May 21, 2011 11:15 PM
>> To: [email-masked]
>> Subject: Re: [splices] Answering an A/V Call Using Two Separate Devices
>> proposal
>>
>>>       | INVOKE Action:
>> urn:invoke:call:answer;media=audio;transducer=speaker|headset

---

From: "Shekh-Yusef, Rifaat (Rifaat)" <[email-masked]>
Date: Sun, 22 May 2011 14:40:07 -0400

Regards,
 Rifaat

---

From: "Shekh-Yusef, Rifaat (Rifaat)" <[email-masked]>
Date: Sun, 22 May 2011 20:49:05 -0400

You are then proposing the following:

Alice used her *phone* to answer the incoming call
    |                     |                     |                     |
    |                     | 200 OK [Audio]      |                     |
    |                     |-------------------->|                     |
    |                     |                     | 200 OK [Audio]      |
    |                     |                     |-------------------->|
    | CANCEL              |                     |                     |
    |<------------------------------------------|                     |
    |                     |                     |                     |
    |                     |<---dialog1------------------------------->|
    |                     |<======audio==============================>|
    |                     |                     |                     |
    | INVITE Alert-Info and [Video]             |                     |
    |<--------------------|                     |                     |

What happens here?
Will the user be required to take an action on the PC to accept the INVITE?
Or you are expecting the PC to provide an answer without user intervention?

    | 200 OK [Video]      |                     |                     |
    | ACK                 |                     |                     |

> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Sunday, May 22, 2011 5:09 PM
> To: Shekh-Yusef, Rifaat (Rifaat)
> Cc: [email-masked]
> > Because a new INVITE will probably cause the PC to present the user with a
> UI component and wait for the users input.
>
> >>> The Desk Phone knows that the PC supports Video, while the PC knows that
> the
> >> Desk Phone only supports audio.
> >>>       |                     |                     |                     |
> >>>       |                     | SUBSCRIBE reg       |                     |

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 22 May 2011 23:03:02 -0400

> Alice used her *phone* to answer the incoming call

Could  be handled various ways.

The alert-info could suggest auto-answer. (The PC *honoring* such a 
request might be conditional on who it comes. But even if not honored 
for auto-answer it might still alert *differently*.) If it wasn't 
auto-answered, and returned 180, it could be followed up with an INVOKE 
to force the answer.

	Thanks,
	Paul

---

From: "Shekh-Yusef, Rifaat (Rifaat)" <[email-masked]>
Date: Mon, 23 May 2011 08:56:18 -0400

I do not see how this proposal is "less mechanism" than the original proposal, but I tend to agree with you that this might be "a matter of taste".

Regards,
 Rifaat

________________________________________
From: Paul Kyzivat [[email-masked]]
Sent: Sunday, May 22, 2011 11:03 PM
To: Shekh-Yusef, Rifaat (Rifaat)
Cc: [email-masked]
Subject: Re: [splices] Answering an A/V Call Using Two Separate Devices proposal

        Thanks,
        Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 23 May 2011 09:07:37 -0400

> I do not see how this proposal is "less mechanism" than the original proposal, but I tend to agree with you that this might be "a matter of taste".

The devil is in the details here, and we don't have enough details.
So its all in the set of assumptions one is making.

In the end we probably aren't going to standardize services - just 
mechanisms for creating services. But perhaps we will have an "examples" 
doc that shows how the mechanisms might be used to create a range of 
interesting services such as these. If so, I would think we would need 
to work through each one in detail, carefully defining all the 
assumptions about the environment.

And that is really what it takes to decide on each particular "action", 
because those seem to be rather specialized. At the moment I don't have 
a vision of a clear and obvious set of actions that enable all the 
interesting services. Its more a matter of crafting an action to support 
one or a few services. I wish it was more clear cut than that. Maybe it 
will become so with more study.

	Thanks,
	Paul

---

From: Peter Musgrave <[email-masked]>
Date: Tue, 24 May 2011 08:41:52 -0400

I agree with Paul that:
1) This works ok.
2) INVOKE is more mechanism than a new header. [A method is a bigger deal
than a header]

I'd also observe in a "real politik" sense that the potential energy barrier
to geting a new SIP method in place will likely be significant. I would
expect it would have to be a dispatch-ed WG all on it's own. People will
decide to either use it to solve world hunger - or decide that it is the
root of all evil.

Under "out there" ideas - would it be possible to put the Action header in a
PUBLISH? Would this allow the same signalling semantics as INVOKE without
the need for a new method?

Peter Musgrave

On Mon, May 23, 2011 at 9:07 AM, Paul Kyzivat <[email-masked]> wrote:

>> I do not see how this proposal is "less mechanism" than the original
>> proposal, but I tend to agree with you that this might be "a matter of
>> taste".
>>
>
> mechanisms for creating services. But perhaps we will have an "examples" doc
> that shows how the mechanisms might be used to create a range of interesting
> services such as these. If so, I would think we would need to work through
> each one in detail, carefully defining all the assumptions about the
> environment.
>
> because those seem to be rather specialized. At the moment I don't have a
> vision of a clear and obvious set of actions that enable all the interesting
> services. Its more a matter of crafting an action to support one or a few
> services. I wish it was more clear cut than that. Maybe it will become so
> with more study.
>
>        Thanks,
>        Paul
>
>
>  Regards,
>>  Rifaat
>>
>>
>>
>>>>>> From: [email-masked] [mailto:[email-masked]] On
>>>>>> Behalf
>>>>>>
>>>>> Of
>>>>
>>>>> Paul Kyzivat
>>>>>>> We are still working on a new version of the INVOKE document that
>>>>>>> removes
>>>>>>>
>>>>>> the implicit subscription.
>>>>>>
>>>>>>>
>>>>>>> Meanwhile I would like to continue the discussion of the various
>>>>>>> possible
>>>>>>>
>>>>>> uses cases.
>>>>>>
>>>>>>> The following is a proposal for Answering an A/V Call Using Two
>>>>>>> Separate
>>>>>>>
>>>>>> Devices.
>>>>>>
>>>>>>>
>>>>>>> Regards,
>>>>>>>     Rifaat
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>       Alice                 Alice                Proxy
>>>>>>>    Bob
>>>>>>>        PC                 Desk Phone
>>>>>>>        |                     |                     |
>>>>>>>     |
>>>>>>>        |                     |                     |
>>>>>>>     |
>>>>>>> Both Alice's devices subscribe to the reg event package, which allows
>>>>>>> each
>>>>>>>
>>>>>> device to
>>>>>>
>>>>>>> discover the capabilities of the other device based on the feature
>>>>>>> tags
>>>>>>>
>>>>>> provided by each device.
>>>>>>
>>>>>>>        |                     |                     |
>>>>>>>     |
>>>>>>>        |                     | SUBSCRIBE reg       |
>>>>>>>     |
>>>>>>>        |                     | 200 OK              |
>>>>>>>     |
>>>>>>>        |                     |                     |
>>>>>>>     |
>>>>>>>        | SUBSCRIBE reg       |                     |
>>>>>>>     |
>>>>>>>        | 200 OK              |                     |
>>>>>>>     |
>>>>>>>        |                     |                     |
>>>>>>>     |
>>>>>>>        |                     |                     |
>>>>>>>     |
>>>>>>>        |                     |                     |
>>>>>>>     |
>>>>>>>        |                     |                     |
>>>>>>>     |
>>>>>>>        | SUBSCRIBE dialog    |                     |
>>>>>>>     |
>>>>>>>        | 200 OK              |                     |
>>>>>>>     |
>>>>>>>        |                     |                     |
>>>>>>>     |
>>>>>>>        | SUBSCRIBE dialog    |                     |
>>>>>>>     |
>>>>>>>        | 200 OK              |                     |
>>>>>>>     |
>>>>>>>        |                     |                     |
>>>>>>>     |
>>>>>>>        |                     |                     |
>>>>>>>     |
>>>>>>>        |                     |                     |
>>>>>>>     |
>>>>>>>        |                     |                     |
>>>>>>>     |
>>>>>>>        |                     |                     |
>>>>>>>     |
>>>>>>>        | 200 OK              |                     |
>>>>>>>     |
>>>>>>>        |                     |                     |
>>>>>>>     |
>>>>>>>        |                     | 200 OK [Audio]      |
>>>>>>>     |
>>>>>>>        |                     |                     | 200 OK [Audio]
>>>>>>>    |
>>>>>>>        | CANCEL              |                     |
>>>>>>>     |
>>>>>>>        |                     |                     |
>>>>>>>     |
>>>>>>>        |
>>>>>>> |<---dialog1------------------------------->|
>>>>>>>        |                     |                     |
>>>>>>>     |
>>>>>>>        |
>>>>>>> |<======audio==============================>|
>>>>>>>        |                     |                     |
>>>>>>>     |
>>>>>>>        |                     |                     |
>>>>>>>     |
>>>>>>>        |                     |                     |
>>>>>>>     |
>>>>>>>        | 100                 |                     |
>>>>>>>     |
>>>>>>>        |                     | re-INVITE [A/V]     |
>>>>>>>     |
>>>>>>>        |                     |                     | re-INVITE [A/V]
>>>>>>>     |
>>>>>>>        |                     |                     | 200 OK [A/V]
>>>>>>>    |
>>>>>>>        | 200 OK [Video]      |                     |
>>>>>>>     |
>>>>>>>        |                     |                     |
>>>>>>>     |
>>>>>>>        |                     |                     |
>>>>>>>     |
>>>>>>>        |
>>>>>>> |<======audio==============================>|
>>>>>>>
>>>>>>>        |                     |                     |
>>>>>>>     |
>>>>>>>        |                     |                     |
>>>>>>>     |
>>>>>>>        |                     |                     |
>>>>>>>     |
>>>>>>>        |                     | 200 OK [Audio]      |
>>>>>>>     |
>>>>>>>        |                     |                     | 200 OK [Audio]
>>>>>>>    |
>>>>>>>        | CANCEL              |                     |
>>>>>>>     |
>>>>>>>        |                     |                     |
>>>>>>>     |
>>>>>>>        |
>>>>>>> |<---dialog1------------------------------->|
>>>>>>>        |                     |                     |
>>>>>>>     |
>>>>>>>        |
>>>>>>> |<======audio==============================>|
>>>>>>>        |                     |                     |
>>>>>>>     |
>>>>>>>        |                     |                     |
>>>>>>>     |
>>>>>>> The phone then instructs the PC to initiate a video call to join the
>>>>>>>
>>>>>> existing call
>>>>>>
>>>>>>>        |                     |                     |
>>>>>>>     |
>>>>>>>        | INVOKE Action:
>>>>>>> urn:invoke:call:join;media=video;dialog=dialog1
>>>>>>>        | 200 OK              |                     |
>>>>>>>     |
>>>>>>>        |                     |                     |
>>>>>>>     |
>>>>>>>        |                     |                     |
>>>>>>>     |
>>>>>>>        | 100                 |                     |
>>>>>>>     |
>>>>>>>        |                     | re-INVITE [A/V]     |
>>>>>>>     |
>>>>>>>        |                     |                     | re-INVITE [A/V]
>>>>>>>     |
>>>>>>>        |                     |                     | 200 OK [A/V]
>>>>>>>    |
>>>>>>>        | 200 OK [Video]      |                     |
>>>>>>>     |
>>>>>>>        |                     |                     |
>>>>>>>     |
>>>>>>>        |                     |                     |
>>>>>>>     |
>>>>>>>        |
>>>>>>> |<======audio==============================>|
>>>>>>>
>>>>>>>        |                     |                     |
>>>>>>>     |

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 24 May 2011 09:11:14 -0400

Peter,

IMO the "action mechanism" will be controversial regardless of how it is 
encoded. And it will have largely the same impact on implementations.
(It is a significant extension of the scope of SIP.)

I don't think that trying to "hide" it will make things better. And as 
best I understand it doesn't fit the semantics of PUBLISH. (Publish is 
intimately tied to the state model of an event package. Maybe if the 
event package is carefully designed you could make a case for this. But 
I'm dubious.)

I think the kind of use cases that Rifaat is posing are good as a 
starting point. But after some of that I think one of the next steps 
must be carefully defining the scope of this new action mechanism. And I 
expect that to be difficult. Right now it seems to be a pot into which 
you can put *anything*. I think we need to get to the point where it is 
clear what sorts of things are valid actions, and which are not. I 
expect this will involve defining an extended environment for a UA, of 
things it needs to manipulate. (Stuff like speakers, microphones, 
displays, buttons, multiple dialogs, ...) We might get a head start by 
exploring what CTI features are defined in other protocols.

	Thanks,
	Paul

On 5/24/2011 8:41 AM, Peter Musgrave wrote:
> I agree with Paul that:
> 1) This works ok.
> 2) INVOKE is more mechanism than a new header. [A method is a bigger
> deal than a header]
>
> I'd also observe in a "real politik" sense that the potential energy
> barrier to geting a new SIP method in place will likely be significant.
> I would expect it would have to be a dispatch-ed WG all on it's own.
> People will decide to either use it to solve world hunger - or decide
> that it is the root of all evil.
>
> Under "out there" ideas - would it be possible to put the Action header
> in a PUBLISH? Would this allow the same signalling semantics as INVOKE
> without the need for a new method?
>
> Peter Musgrave
>
> On Mon, May 23, 2011 at 9:07 AM, Paul Kyzivat <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>
>
>         I do not see how this proposal is "less mechanism" than the
>         original proposal, but I tend to agree with you that this might
>         be "a matter of taste".
>
>
>     mechanisms for creating services. But perhaps we will have an
>     "examples" doc that shows how the mechanisms might be used to create
>     a range of interesting services such as these. If so, I would think
>     we would need to work through each one in detail, carefully defining
>     all the assumptions about the environment.
>
>     And that is really what it takes to decide on each particular
>     "action", because those seem to be rather specialized. At the moment
>     I don't have a vision of a clear and obvious set of actions that
>     enable all the interesting services. Its more a matter of crafting
>     an action to support one or a few services. I wish it was more clear
>     cut than that. Maybe it will become so with more study.
>
>             Thanks,
>             Paul
>
>
>         Regards,
>           Rifaat
>
>
>
>         From: Paul Kyzivat [[email-masked] <mailto:[email-masked]>]
>         Cc: [email-masked] <mailto:[email-masked]>
>                   |                     |                     | 200 OK
>             [Audio]      |
>             re-INVITE [A/V]     |
>                   |                     |                     | 200 OK
>             [A/V]        |
>                   | ACK                 |                     |
>                 From: Paul Kyzivat [mailto:[email-masked]
>                 <mailto:[email-masked]>]
>                 Cc: [email-masked] <mailto:[email-masked]>
>                         From: [email-masked]
>                         <mailto:[email-masked]>
>                         [mailto:[email-masked]
>                         <mailto:[email-masked]>] On Behalf
>
>                 Of
>
>                         Paul Kyzivat
>                         To: [email-masked] <mailto:[email-masked]>
>                             We are still working on a new version of the
>                             INVOKE document that removes
>
>                             Meanwhile I would like to continue the
>                             discussion of the various possible
>
>                         uses cases.
>
>                             The following is a proposal for Answering an
>                             A/V Call Using Two Separate
>
>                         Devices.
>
>
>                             Regards,
>                                  Rifaat
>
>
>
>                                    Alice                 Alice
>                                   Proxy                  Bob
>                                     PC                 Desk Phone
>                                     |                     |
>                                      |                     |
>                                     |                     |
>                                      |                     |
>                             Both Alice's devices subscribe to the reg
>                             event package, which allows each
>
>                         device to
>
>                             discover the capabilities of the other
>                             device based on the feature tags
>
>                         provided by each device.
>
>                                     |                     |
>                                      |                     |
>                                     |                     | SUBSCRIBE
>                             reg       |                     |
>                             |-------------------->|                     |
>                                     |                     | 200 OK
>                                     |                     |
>                                     |
>                             |<--------------------|                     |
>                                     |                     |
>                                      |                     |
>                                     | SUBSCRIBE reg       |
>                                      |                     |
>
>                                     | 200 OK              |
>                                      |                     |
>                                     |                     |
>                                      |                     |
>                                     |                     |
>                                      |                     |
>                                     |                     |
>                                      |                     |
>                                     |                     |
>                                      |                     |
>                                     | SUBSCRIBE dialog    |
>                                      |                     |
>                                     | 200 OK              |
>                                      |                     |
>                                     |                     |
>                                      |                     |
>                                     | SUBSCRIBE dialog    |
>                                      |                     |
>                                     | 200 OK              |
>                                      |                     |
>                                     |                     |
>                                      |                     |
>                                     |                     |
>                                      |                     |
>                                     |                     |
>                                      |                     |
>                             |<--------------------|                     |
>                                     | INVITE Alice [A/V]  |
>                                      |                     |
>
>                                     |                     |
>                                      |                     |
>                                     |                     |
>                                      |                     |
>                                     | 200 OK              |
>                                      |                     |
>                                     |                     |
>                                      |                     |
>                                     |                     | 200 OK
>                             [Audio]      |                     |
>                             |-------------------->|                     |
>                                     |                     |
>                                      | 200 OK [Audio]      |
>                                     |                     |
>                                      |-------------------->|
>                                     | CANCEL              |
>                                      |                     |
>
>                                     |                     |
>                                      |                     |
>                                     |                     |
>                                      |                     |
>                                     |                     |
>                                      |                     |
>                                     |                     |
>                                      |                     |
>                                     |                     |
>                                      |                     |
>                                     | 100                 |
>                                      |                     |
>                                     |                     | re-INVITE
>                             [A/V]     |                     |
>                             |-------------------->|                     |
>                                     |                     |
>                                      | re-INVITE [A/V]     |
>                                     |                     |
>                                      |-------------------->|
>                                     |                     |
>                                      | 200 OK [A/V]        |
>                                     |                     | 200 OK [A/V]
>                                     |<--------------------|
>                                     |
>                             |<--------------------|                     |
>                                     | 200 OK [Video]      |
>                                      |                     |
>                                     |<--------------------|
>                                      |                     |
>                                     |                     |
>                                      |                     |
>
>                                     |                     |
>                                      |                     |
>                                     |                     |
>                                      |                     |
>                                     |                     |
>                                      |                     |
>                                     |                     |
>                                      |                     |
>                                     |                     | 200 OK
>                             [Audio]      |                     |
>                             |-------------------->|                     |
>                                     |                     |
>                                      | 200 OK [Audio]      |
>                                     |                     |
>                                      |-------------------->|
>                                     | CANCEL              |
>                                      |                     |
>
>                                     |                     |
>                                      |                     |
>                                     |                     |
>                                      |                     |
>                                     |                     |
>                                      |                     |
>                                     |                     |
>                                      |                     |
>                                     |                     |
>                                      |                     |
>                                     | 200 OK              |
>                                      |                     |
>                                     |                     |
>                                      |                     |
>                                     |                     |
>                                      |                     |
>                                     | 100                 |
>                                      |                     |
>                                     |                     | re-INVITE
>                             [A/V]     |                     |
>                             |-------------------->|                     |
>                                     |                     |
>                                      | re-INVITE [A/V]     |
>                                     |                     |
>                                      |-------------------->|
>                                     |                     |
>                                      | 200 OK [A/V]        |
>                                     |                     | 200 OK [A/V]
>                                     |<--------------------|
>                                     |
>                             |<--------------------|                     |
>                                     | 200 OK [Video]      |
>                                      |                     |
>                                     |<--------------------|
>                                      |                     |
>                                     |                     |
>                                      |                     |
>
>                                     |                     |
>                                      |                     |
>                                     |                     |
>                                      |                     |
>                             [email-masked] <mailto:[email-masked]>
>                         [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: Peter Musgrave <[email-masked]>
Date: Tue, 24 May 2011 10:22:28 -0400

Hi Paul,

I agree the mechanism is fundamentally controversial and the best way to
face this is to define the scope very carefully and narrowly.

Was the use of CSTA-3 ever discussed? I had a passing acquaintance with this
a couple of years ago and some of what splices needs might come from there.
Even if not directly relevant it does provide one perspective on the kinds
of control primitives which come into play. (I used
http://www.ecma-international.org/activities/Communications/TG11/CSTAoverview.pdfto
remind myself of some of what it encompassed). While CSTA-3 looks good
to
me "on paper" - I lack real implementation experience with it - so I would
be interested to hear if anyone has input on this.

Peter

On Tue, May 24, 2011 at 9:11 AM, Paul Kyzivat <[email-masked]> wrote:

> I don't think that trying to "hide" it will make things better. And as best
> I understand it doesn't fit the semantics of PUBLISH. (Publish is intimately
> tied to the state model of an event package. Maybe if the event package is
> carefully designed you could make a case for this. But I'm dubious.)
>
> I think the kind of use cases that Rifaat is posing are good as a starting
> point. But after some of that I think one of the next steps must be
> carefully defining the scope of this new action mechanism. And I expect that
> to be difficult. Right now it seems to be a pot into which you can put
> *anything*. I think we need to get to the point where it is clear what sorts
> of things are valid actions, and which are not. I expect this will involve
> defining an extended environment for a UA, of things it needs to manipulate.
> (Stuff like speakers, microphones, displays, buttons, multiple dialogs, ...)
> We might get a head start by exploring what CTI features are defined in
> other protocols.
>
>        Thanks,
>        Paul
>
>
>>        From: Paul Kyzivat [[email-masked] <mailto:[email-masked]
>> >]
>>
>>            |-------------------->|
>>            |-------------------->|
>>                                     |<--------------------|
>>                                     |-------------------->|
>>                                     |-------------------->|

---

From: "Shekh-Yusef, Rifaat (Rifaat)" <[email-masked]>
Date: Wed, 25 May 2011 08:32:31 -0400

Hi Peter,

>2) INVOKE is more mechanism than a new header. [A method is a bigger deal than a header]
Did you really think that I do not understand that defining a method is a bigger deal than defining a header? :)
My comment was about the specifics of the call flow and has nothing to do with defining a method or a header.

Regards,
Rifaat

From: Peter Musgrave [mailto:[email-masked]]
Sent: Tuesday, May 24, 2011 8:42 AM
To: Paul Kyzivat
Cc: Shekh-Yusef, Rifaat (Rifaat); [email-masked]
Subject: Re: [splices] Answering an A/V Call Using Two Separate Devices proposal

I agree with Paul that:
1) This works ok.
2) INVOKE is more mechanism than a new header. [A method is a bigger deal than a header]

I'd also observe in a "real politik" sense that the potential energy barrier to geting a new SIP method in place will likely be significant. I would expect it would have to be a dispatch-ed WG all on it's own. People will decide to either use it to solve world hunger - or decide that it is the root of all evil.

Under "out there" ideas - would it be possible to put the Action header in a PUBLISH? Would this allow the same signalling semantics as INVOKE without the need for a new method?

Peter Musgrave
On Mon, May 23, 2011 at 9:07 AM, Paul Kyzivat <[email-masked]<mailto:[email-masked]>> wrote:

In the end we probably aren't going to standardize services - just mechanisms for creating services. But perhaps we will have an "examples" doc that shows how the mechanisms might be used to create a range of interesting services such as these. If so, I would think we would need to work through each one in detail, carefully defining all the assumptions about the environment.

And that is really what it takes to decide on each particular "action", because those seem to be rather specialized. At the moment I don't have a vision of a clear and obvious set of actions that enable all the interesting services. Its more a matter of crafting an action to support one or a few services. I wish it was more clear cut than that. Maybe it will become so with more study.

       Thanks,
       Paul

Regards,
 Rifaat

________________________________________
From: Paul Kyzivat [[email-masked]<mailto:[email-masked]>]
Sent: Sunday, May 22, 2011 11:03 PM
To: Shekh-Yusef, Rifaat (Rifaat)
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [splices] Answering an A/V Call Using Two Separate Devices proposal

What happens here?

        Thanks,
        Paul
     | 200 OK [Video]      |                     |                     |

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Sunday, May 22, 2011 5:09 PM
To: Shekh-Yusef, Rifaat (Rifaat)
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [splices] Answering an A/V Call Using Two Separate Devices
proposal

       Thanks,
       Paul
Regards,
   Rifaat

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf
Of
Paul Kyzivat
Sent: Saturday, May 21, 2011 11:15 PM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [splices] Answering an A/V Call Using Two Separate Devices
proposal

    Thanks,
    Paul

We are still working on a new version of the INVOKE document that removes
the implicit subscription.

Meanwhile I would like to continue the discussion of the various possible
uses cases.
The following is a proposal for Answering an A/V Call Using Two Separate
Devices.

Regards,
    Rifaat

      Alice                 Alice                Proxy                  Bob
       PC                 Desk Phone
       |                     |                     |                     |
       |                     |                     |                     |
Both Alice's devices subscribe to the reg event package, which allows each
device to
discover the capabilities of the other device based on the feature tags
provided by each device.

(*)

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

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

---

From: Simon Pietro Romano <[email-masked]>
Date: Wed, 25 May 2011 17:21:53 +0200

I *personally* agree with Rifaat. Let's first discuss the overall 
approach of the call flow and then decide on the best venue where to 
carry out such work.
This said, and based on the discussion we are having on the list, I bend 
towards considering INVOKE as a straightforward "mechanism" which I 
would be glad to see supported.

Simon

Il 25/05/2011 14:32, Shekh-Yusef, Rifaat (Rifaat) ha scritto:
> Did you really think that I do not understand that defining a method 
> is a bigger deal than defining a header? J
>
> *From:*Peter Musgrave [mailto:[email-masked]]
> *Sent:* Tuesday, May 24, 2011 8:42 AM
> *To:* Paul Kyzivat
> *Cc:* Shekh-Yusef, Rifaat (Rifaat); [email-masked]
> *Subject:* Re: [splices] Answering an A/V Call Using Two Separate 
> Devices proposal
>
> I agree with Paul that:
>
> 1) This works ok.
>
> barrier to geting a new SIP method in place will likely be 
> significant. I would expect it would have to be a dispatch-ed WG all 
> on it's own. People will decide to either use it to solve world hunger 
> - or decide that it is the root of all evil.
>
> Under "out there" ideas - would it be possible to put the Action 
> header in a PUBLISH? Would this allow the same signalling semantics as 
> INVOKE without the need for a new method?
>
> Peter Musgrave
>
> "examples" doc that shows how the mechanisms might be used to create a 
> range of interesting services such as these. If so, I would think we 
> would need to work through each one in detail, carefully defining all 
> the assumptions about the environment.
>
> "action", because those seem to be rather specialized. At the moment I 
> don't have a vision of a clear and obvious set of actions that enable 
> all the interesting services. Its more a matter of crafting an action 
> to support one or a few services. I wish it was more clear cut than 
> that. Maybe it will become so with more study.
>
>        Thanks,
>        Paul
>
>     Regards,
>      Rifaat
>
>
>
>     From: [email-masked] <mailto:[email-masked]>
>                |                     |                     | re-INVITE
>                |                     |                     | re-INVITE

-- 
                             _\\|//_
                             ( O-O )
    ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
                     Simon Pietro Romano
               Universita' di Napoli Federico II
                  Computer Science Department
         Phone: +39 081 7683823 -- Fax: +39 081 7684219
                 e-mail: [email-masked]
           http://www.comics.unina.it/simonpietro.romano

     <<Molti mi dicono che lo scoraggiamento è l'alibi degli
    idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte.
                          oooO
    ~~~~~~~~~~~~~~~~~~~~~~(   )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
                           \ (    (   )
                            \_)    ) /
                                  (_/