Subject: [splices] Answering a Call Using Two Separate Devices proposal

From: "Shekh-Yusef, Rifaat (Rifaat)" <[email-masked]>
Date: Fri, 22 Apr 2011 12:02:56 -0400

Hi,

I would like to discuss the following proposal for addressing the scenario of answering a call using two separate devices:

   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 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                      |
    |-------------------->|                     |                     |
    | 200 OK              |                     |                     |
    |<--------------------|                     |                     |
    |                     |                     |                     |
    |                     | 200 OK [Audio]      |                     |
    |                     |-------------------->|                     |
    |                     |                     | 200 OK [Audio]      |
    |                     |                     |-------------------->|
    | CANCEL              |                     |                     |
    |<------------------------------------------|                     |
    |                     |                     |                     |
    |                     |<---dialog1------------------------------->|
    |                     |                     |                     |
    |                     |<======audio==============================>|
    |                     |                     |                     |
    |                     |                     |                     |
    
(*)

    |                     |                     |                     |
    |                     |                     |                     |
    |                     |                     |                     |
The following is a re-INVITE from the remote party (Bob) to add video 
to the existing audio call
    |                     |                     |                     |
    |                     |                     | INVITE Alice [A/V]  |
    |                     |                     |<--------------------|
    |                     | INVITE Alice [A/V]  |                     |
    |                     |<--------------------|                     |
    |                     | 100 Trying          |                     |
    |                     |-------------------->|                     |
    |                     |                     | 100 Trying          |
    |                     |                     |-------------------->|
    |                     |                     |                     |
The Desk Phone cannot handle video, but it knows that the PC can handle
video, so the Desk Phone initiates a new video INVITE to the PC.
    |                     |                     |                     |
    | INVITE [Video]      |                     |                     |
    |<--------------------|                     |                     |
    | 180                 |                     |                     |
    |-------------------->|                     |                     |
    |                     |                     |                     |
The user can either answer the video call using his PC, or his Desk Phone.
If the user chose to answer the incoming video call using his Desk Phone,
the following REFER will be sent to the PC:
    |                     |                     |                     |
    | REFER Refer-To: urn:sip-action:call:answer                      |
    |<--------------------|                     |                     |
    | 200 OK              |                     |                     |
    |-------------------->|                     |                     |
    |                     |                     |                     |
    | 200 OK [Video]      |                     |                     |
    |-------------------->|                     |                     |
    |                     |                     |                     |
    |                     | 200 OK [A/V]        |                     |
    |                     |-------------------->|                     |
    |                     |                     | 200 OK [A/V]        |
    |                     |                     |-------------------->|
    |                     |                     |                     |
    |<----dialog2-------->|<---dialog1------------------------------->|
    |                     |                     |                     |
    |                     |<======audio==============================>|
    |<============================video==============================>|
    |                     |                     |                     |
    |                     |                     |                     |

Now let's assume that Alice is the side that wants to add video to the 
existing audio call. The scenario continues after the (*) above.

Alice uses her PC and attempt to initiate a new video call. Because the 
PC is aware that another device is logged in using the same AOR, it will
try to find if there is any existing dialog on the other device by 
subscribing to the dialog event package
    |                     |                     |                     |
    | SUBSCRIBE dialog    |                     |                     |
    |-------------------->|                     |                     |
    | 200 OK              |                     |                     |
    |<--------------------|                     |                     |
    | NOTIFY              |                     |                     |
    |<--------------------|                     |                     |
    | OK                  |                     |                     |
    |-------------------->|                     |                     |
    |                     |                     |                     |
The PC discovers that there is an existing dialog between the Desk Phone 
and Bob and present this to Alice for her to choose if she wants to 
attach the new video call to the existing audio call or not. In this 
case Alice chose to attach the new video call to the existing audio call
    |                     |                     |                     |
    |                     |                     |                     |
    | INVITE [Video]      |                     |                     |
    |        Target-Dialog: dialog1             |                     |
    |-------------------->|                     |                     |
    | 100                 |                     |                     |
    |<--------------------|                     |                     |
    |                     | re-INVITE [A/V]     |                     |
    |                     |-------------------->|                     |
    |                     |                     | re-INVITE [A/V]     |
    |                     |                     |-------------------->|
    |                     |                     | 200 OK [A/V]        |
    |                     | 200 OK [A/V]        |<--------------------|
    |                     |<--------------------|                     |
    | 200 OK [Video]      |                     |                     |
    |<--------------------|                     |                     |
    |                     |                     |                     |
    |                     |                     |                     |
    |<----dialog2-------->|<---dialog1------------------------------->|
    |                     |                     |                     |
    |                     |<======audio==============================>|
    |<============================video==============================>|
    |                     |                     |                     |
    |                     |                     |                     |
    |                     |                     |                     |

Regards,
 Rifaat

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 22 Apr 2011 13:26:41 -0400

> the Desk Phone only supports audio.

You mean Alice used her PC to instruct her phone to answer the call.
For the point you are making, it would be equally fine if she had simply 
picked up the phone.

How do you assume the phone is rendering the audio when instructed to 
answer this way. Sending/receiving from the handset isn't very useful 
when its on the cradle. Do you assume speaker phone, or that Alice has a 
headset connected to the phone? (If the latter, why not simply connect 
the headset to the PC?)

>      | REFER Refer-To: urn:sip-action:call:answer                      |

Seems reasonable.

>      | INVITE [Video]      |                     |                     |

I don't fully understand what you have in mind here.
Somehow Alice must become aware that video has been offered and she must 
do something to accept it. From the diagram I gather that you expect 
some sort of alert on the PC, so answering it from the PC makes sense.

For Alice to answer from the phone there must be some way to do so.
Presumably there would have to be some UI on the phone providing a means 
to "accept video". Most likely that means there will be some sort of 
alerting on the phone too. (But maybe not *ringing*.)

>      | REFER Refer-To: urn:sip-action:call:answer                      |

Otherwise the above all makes sense.

> subscribing to the dialog event package

This doesn't quite make sense to me - at least the wording.
The PC has a fairly rich UI, and it could *already* know about the call 
in progress. And certainly Alice knows she wants to add video to an 
existing call rather than make a new call. So I would expect the 
interaction between Alice and her PC to first be one of discovering the 
existing call that *could* be joined, and then requesting to join. 
(Alternatively Alice might decide she doesn't want to join that call - 
that she wants to make an independent call from the PC to somebody else.)

>      | SUBSCRIBE dialog    |                     |                     |

I would tweak this - the invite should use Join.

Otherwise this sounds right on to me.

Its an example of what I have been talking about all along. You've 
described it well.

	Thanks,
	Paul

---

From: "Shekh-Yusef, Rifaat (Rifaat)" <[email-masked]>
Date: Fri, 22 Apr 2011 15:09:06 -0400

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Paul Kyzivat
> Sent: Friday, April 22, 2011 1:27 PM
> To: [email-masked]
> Subject: Re: [splices] Answering a Call Using Two Separate Devices proposal
> 
> 
> 
> > I would like to discuss the following proposal for addressing the scenario
> of answering a call using two separate devices:
> >
> >
> >     Alice                 Alice                Proxy                  Bob
> >      PC                 Desk Phone
> >      |                     |                     |                     |
> >      |                     |                     |                     |
Yes.

> headset connected to the phone? (If the latter, why not simply connect
My initial thought was to use the speaker phone, but you raise a good point here.
Maybe we need to add a parameter to the URN to indicate which transducer to use, e.g
REFER Refer-To: urn:sip-action:call:answer;transducer=speaker|headset

Alice answered the call on her Desk Phone because she knows it has a better audio quality.
Why do you want to connect the headset to the PC?

> alerting on the phone too. (But maybe not *ringing*.)
Yes, that is exactly what I had in mind.

> that she wants to make an independent call from the PC to somebody else.)
Remember that this scenario starts after the (*) above, which means that 
the PC is not aware of the existing call between the Desk Phone and Bob. 
Of course Alice is aware of that call and expects the PC to discover 
that when Alice clicks on her PC and opens the UI that allows here to initiate 
a video call.

> I would tweak this - the invite should use Join.
Yeah, good point.

> Its an example of what I have been talking about all along. You've
Ok, great!

> 	Thanks,
> 	Paul
> _______________________________________________
> splices mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/splices

---

From: Peter Musgrave <[email-masked]>
Date: Fri, 22 Apr 2011 17:00:11 -0400

Hi Rifaat,

Overall I think this works. 

1) Use of INVITE from phone to PC to signal addition of video:

The current mechanism (with an new INVITE to the PC from the phone) seems likely to me to cause the call to ring on the PC - and I think having a call that is already in progress ring a second device as a means of signalling the availability of video will not be the ideal user experience (or perhaps when the device sees an INVITE with video and no audio it knows not to alert the user in the usual way?)

One alternative would be:

When the accept on the PC results in the:
    | REFER Refer-To: urn:sip-action:call:answer    
                  |
message from the PC to the phone does it make sense for the PC to subscribe to the dialog-state of the call at this point? (In fact would it hurt to have the coupled devices always subscribed to each other's dialog state?)

Then when a reINVITE with video is offered the PC will receive a notification and it can offer the user a choice to accept the call there - with some pop-up and beep (or whatever). If the user accepts then it could send a REFER to the phone to make it offer video to the PC. (I first thought of using an INVITE with JOIN from PC to phone - but then the video offer comes from the PC and forces the phone to build a video answer based on the PCs offer - which seems a bad idea). 

2) As an aside, how does lipsync on sending and playout get handled in this configuration? 

Regards, 

Peter Musgrave

---

From: "Shekh-Yusef, Rifaat (Rifaat)" <[email-masked]>
Date: Fri, 22 Apr 2011 18:42:33 -0400

> From: Peter Musgrave [mailto:[email-masked]]
> Sent: Friday, April 22, 2011 5:00 PM
> To: Shekh-Yusef, Rifaat (Rifaat)
> Cc: Paul Kyzivat; [email-masked]
> The current mechanism (with an new INVITE to the PC from the phone) seems
> likely to me to cause the call to ring on the PC - and I think having a call
> that is already in progress ring a second device as a means of signalling the
> availability of video will not be the ideal user experience 
>
I personally think it is a reasonable user experience, but I can go either way on this.
Do other people have an opinion on this?

(or perhaps when
> the device sees an INVITE with video and no audio it knows not to alert the
> user in the usual way?)
> 
This might be one way to address that.

> message from the PC to the phone does it make sense for the PC to subscribe to
> the dialog-state of the call at this point? (In fact would it hurt to have the
> coupled devices always subscribed to each other's dialog state?)
> 
I just wanted to optimize the use of these subscriptions and avoid any unnecessary ones until it is really needed.
But in general, it seems like a reasonable approach to me.
Anybody else has some thoughts on this? 

> Then when a reINVITE with video is offered the PC will receive a notification
> and it can offer the user a choice to accept the call there - with some pop-up
> and beep (or whatever). If the user accepts then it could send a REFER to the
> phone to make it offer video to the PC. (I first thought of using an INVITE
> with JOIN from PC to phone - but then the video offer comes from the PC and
> forces the phone to build a video answer based on the PCs offer - which seems
> a bad idea).
> 
It complicates matters a little bit, but it would work.

> 2) As an aside, how does lipsync on sending and playout get handled in this
I have some thoughts around this, but not enough to be able to put a proposal on the table.
If you or anybody else has some thoughts on this, I would appreciate it if you can share it with us.

---

From: Peter Musgrave <[email-masked]>
Date: Fri, 22 Apr 2011 19:17:38 -0400

Hi,

> It complicates matters a little bit, but it would work.

I agree it's inelegant. 

How about an INVITE from the PC to the phone with delayed offer (i.e. no SDP in INVITE) and a JOIN?

Peter Musgrave

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 22 Apr 2011 19:44:04 -0400

> REFER Refer-To: urn:sip-action:call:answer;transducer=speaker|headset

That is a whole can of worms.
But its perhaps one that needs to be opened.

> Why do you want to connect the headset to the PC?

I thought the quality difference, if any, would be due to the 
transducers. So the phone could be better than the speakers on the PC. 
But if you are talking about a headset, then does it matter which its 
connected to?

But this is irrelevant to the discussion.

> that when Alice clicks on her PC and opens the UI that allows here to initiate

I said it *could* know about the call. Specifically, it could monitor 
the dialog package all the time. Or it might just do so after it has 
received an invite and then been canceled before answering - noting the 
phone got the call.

Its all hypothetical of course - its part of the application design for 
the PC.

But I do think its useful to explore the use cases and find some that 
are really compelling. So poking into the details might be relevant.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 22 Apr 2011 20:07:44 -0400

> Do other people have an opinion on this?

IMO when the offer to escalate to video is received, the user will 
typically need *some* kind indication and control. Absent some 
predefined policy, it seems reasonable to "alert", though its probably 
not reasonable to alert via a loud jangly noise. :-)

The Alert-Info urn mechanism is designed to support this sort of thing.
And I think that is preferable to the PC trying to "figure out" what it 
should do.

Policy can bypass this in various ways:
- accept video by default, but in recvonly mode until the user
   does something overt to initiate sending video

- accept video by default, but send some canned image rather
   than live video of the user.

> Anybody else has some thoughts on this?

I think this can vary.
Some might not want their PC doing stuff like this all the time.
But if you permit it, you can get a nicer user experience.

>> phone to make it offer video to the PC.

IIUC, you are then back to trying to do session establishment with 
sub/not - bad idea.

Perhaps it could REFER the phone to get it to send an invite to the PC, 
but that gets complicated.

>> (I first thought of using an INVITE

Not evident why that is so bad.
Or the PC could send an offerless invite to the phone, and the 
capabilities in the contact would let the phone know to offer video.

> If you or anybody else has some thoughts on this, I would appreciate it if you can share it with us.

That could be difficult. Not a subject I know about.

	Thanks,
	Paul

---

From: Peter Musgrave <[email-masked]>
Date: Fri, 22 Apr 2011 19:17:38 -0400

Hi,

I agree it's inelegant. 

Peter Musgrave

---

From: Peter Musgrave <[email-masked]>
Date: Sat, 23 Apr 2011 07:17:16 -0400

> But if you permit it, you can get a nicer user experience.

In the absence of this subscription ISTM the phone cannot know the PC is present (or that the call application is running). In this case would it send the INVITE to the PC and then use the lack of a TRYING to conclude that video should be rejected ?

I agree with your point that putting SUB/NOT in the session establishment path when adding video is not a good idea.

Peter

---

From: [email-masked]
Date: Mon, 25 Apr 2011 12:26:42 +0800

Hi,

The base of the handling one session between two separate devices is to 
coordinate the two separate devices. 

Comparing with the 3pcc, refer action(draft-yusef-dispatch-action-ref-00) 
is a new way. And I think it is interesting.

But considering Alice can handle the two devices at the same time, I think 
Alice can answer the call using PC without the refer-action indication by 
the desk phone.

Then, during the adding video stream stage, Alice's desk phone send 
INVITE(with video) to Alice's PC. I think Alice PC can accept the INVITE 
request by Alice's manual action, while not by the refer-action 
indication. 

One discussion here: the INVITE sent by Alice's desk phone would make the 
SDP from Bob's Re-INVITE. This is something like 3pcc, a simple desk phone 
can not have such feature. So, when the session has been anchored on some 
traditional SIP desk phone, AS(3pcc) seams MUST be need.

Thanks,

Gao

[email-masked] 写于 2011-04-23 00:02:56:

> Hi,
> 
> I would like to discuss the following proposal for addressing the 
> scenario of answering a call using two separate devices:
> 
> 
>    Alice                 Alice                Proxy                  Bob
>     PC                 Desk Phone 
>     |                     |                     |                     |
>     |                     |                     |                     |

>     |        Target-Dialog: dialog1             |                     |

--------------------------------------------------------
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: Paul Kyzivat <[email-masked]>
Date: Mon, 25 Apr 2011 08:44:12 -0400

On 4/25/2011 12:26 AM, [email-masked] wrote:
> 
> Hi,
> 
> The base of the handling one session between two separate devicesis to 
> Comparing with the 3pcc, refer 
> action(draft-yusef-dispatch-action-ref-00) is a new way. And I think it 
> is interesting.
> 
> But considering Alice can handle the two devicesat the same time, I 
> think Alice can answer the call using PC without the refer-action 
> indication by the desk phone.

I'm not sure what you mean here.
In the original scenario, I think "Alice answers the call using the PC"
means that Alice interacts with the PC in order to cause the desk phone
to answer.

Without using something like refer-action, the PC could only answer the
call itself, thus putting audio on the PC rather than the phone. That's
fine if its what Alice wants, but its a different scenario.

> request by Alice's manual action, while not by the refer-action indication.

Yes, that is certainly possible.
What is tricky is what appears on the UI of the PC in this circumstance.
Some possibilities:
- appears as a "normal" (new) video call from Alice
- appears as a "normal" (new) video call from Bob
- appears as something special - a request for video support
  from the desk phone.

To get this to be anything but the first of the above will require
*something* we don't currently have.

> One discussion here: the INVITE sent by Alice's desk phone would make 
> the SDP from Bob's Re-INVITE. This is something like 3pcc,

Yes.

> a simple desk 
> phone can not have such feature. So, when the session has been anchored 
> on some traditional SIP desk phone, AS(3pcc) seams MUST be need.

*something* with the intelligence to coordinate multiple devices, and
with an awareness of what devices are available to be coordinated, must
be present.

Anybody who wants such a capability will need to arrange to have a
suitable device available. It could be a UA owned by the user (e.g. a PC
with sufficient software, or a smart phone), or it could be a service
residing at or near the user's registrar. In this respect it isn't much
different from an answering machine.

	Thanks,
	Paul

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 27 Apr 2011 14:09:28 +0200

Rifaat,

This involves sending SIP requests (REFER, INVITE, SUBSCRIBE) directly between Alice's two devices. What about NAT and firewall issues, if the two devices are not in the same network area? For example, phone on 3G, PC on WiFi? Don't the requests need to go via a proxy?

John 

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Shekh-Yusef, 
> Rifaat (Rifaat)
> Sent: 22 April 2011 17:03
> To: [email-masked]
> Subject: [splices] Answering a Call Using Two Separate 
> Devices proposal
> 
> Hi,
> 
> I would like to discuss the following proposal for addressing 
> the scenario of answering a call using two separate devices:
> 
> 
>    Alice                 Alice                Proxy           
>        Bob
>     PC                 Desk Phone                             
>          
>     |                     |                     |             
>         |
>     |                     |                     |             
>         |
>     |                     |                     |             
>     |                     | SUBSCRIBE reg       |             
>     |                     | 200 OK              |             
>     |                     |                     |             
>     | SUBSCRIBE reg       |                     |             
>     | 200 OK              |                     |             
>     |                     |                     |             
>     |                     |                     |             
>     |                     |                     |             
>     |                     |                     |             
>     |                     |                     |             
>     | 200 OK              |                     |             
>     |                     |                     |             
>     |                     | 200 OK [Audio]      |             
>     |                     |                     | 200 OK 
> [Audio]      |
>     | CANCEL              |                     |             
>     |                     |                     |             
> |<---dialog1------------------------------->|
>     |                     |                     |             
>         |
>     |                     
> |<======audio==============================>|
>     |                     |                     |             
>         |
>     |                     |                     |             
>         |
>     
> (*)
> 
>     |                     |                     |             
>         |
>     |                     |                     |             
>         |
>     |                     |                     |             
>         |
>     |                     |                     |             
>     |                     | 100 Trying          |             
>     |                     |                     | 100 Trying  
>     |                     |                     |             
>     |                     |                     |             
>     | INVITE [Video]      |                     |             
>     | 180                 |                     |             
>     |                     |                     |             
>     |                     |                     |             
>     | 200 OK              |                     |             
>     |                     |                     |             
>     | 200 OK [Video]      |                     |             
>     |                     |                     |             
>     |                     | 200 OK [A/V]        |             
>     |                     |                     | 200 OK 
> [A/V]        |
>     |                     |                     |             
>     |                     |                     |             
> |<======audio==============================>|
>     
>     |                     |                     |             
>     |                     |                     |             
>     |                     |                     |             
>     | SUBSCRIBE dialog    |                     |             
>     | 200 OK              |                     |             
>     | NOTIFY              |                     |             
>     | OK                  |                     |             
>     |                     |                     |             
>     |                     |                     |             
>     |                     |                     |             
>     | INVITE [Video]      |                     |             
>     | 100                 |                     |             
>     |                     | re-INVITE [A/V]     |             
>     |                     |                     | re-INVITE 
> [A/V]     |
>     |                     |                     | 200 OK 
> [A/V]        |
>     | 200 OK [Video]      |                     |             
>     |                     |                     |             
>     |                     |                     |             
>     |                     |                     |             
> |<======audio==============================>|
>     
>     |                     |                     |             
>     |                     |                     |             
>     |                     |                     |

---

From: "Shekh-Yusef, Rifaat (Rifaat)" <[email-masked]>
Date: Wed, 27 Apr 2011 11:49:34 -0400

> Sent: Monday, April 25, 2011 8:44 AM
> To: [email-masked]

I think that we should try to achieve the second option of the 3 options you listed above.

How about if the PC subscribes to the Desk Phone dialog event package with include-session-description, combined with Peter's idea of slow start INVITE with Join from the PC, as follows:

    | SUBSCRIBE Event: dialog;include-session-description             |
    |-------------------->|                     |                     |
    | 200                 |                     |                     |
    |<--------------------|                     |                     |
    | NOTIFY [100 Trying] |                     |                     |
    |<--------------------|                     |                     |
    | OK                  |                     |                     |
    |-------------------->|                     |                     |

(*)
    |                     |                     |                     |
    |                     |                     |                     |
    |                     |                     |                     |
The following is a re-INVITE from the remote party (Bob) to add video 
to the existing audio call
    |                     |                     |                     |
    |                     |                     | INVITE Alice [A/V]  |
    |                     |                     |<--------------------|
    |                     | INVITE Alice [A/V]  |                     |
    |                     |<--------------------|                     |
    |                     | 100 Trying          |                     |
    |                     |-------------------->|                     |
    |                     |                     | 100 Trying          |
    |                     |                     |-------------------->|
    |                     |                     |                     |
    |                     |                     |                     |
The PC gets a notification of the new incoming call and the fact that it 
is video call.
    | NOTIFY dialog-info with session description                     |
    |<--------------------|                     |                     |
    | 200 OK              |                     |                     |
    |-------------------->|                     |                     |
    |                     |                     |                     |
The PC prompts the user and waits for his response. When the user 
accepts the request, the PC initiates a slow start INVITE to the Desk 
Phone as follows:
    |                     |                     |                     |
    | INVITE Join dialog1 |                     |                     |
    |-------------------->|                     |                     |
    | 200 [Video]         |                     |                     |
    |<--------------------|                     |                     |
    | ACK [Video]         |                     |                     |
    |-------------------->|                     |                     |
    |                     | 200 OK [A/V]        |                     |
    |                     |-------------------->|                     |
    |                     |                     | 200 OK [A/V]        |
    |                     |                     |-------------------->|
    |                     |                     |                     |

Regards,
 Rifaat

---

From: "Shekh-Yusef, Rifaat (Rifaat)" <[email-masked]>
Date: Wed, 27 Apr 2011 11:56:59 -0400

Hi John,

I was not trying to suggest that all these requests will go directly between the devices without going through a proxy.
I just did not see the need to explicitly show that because it does not add anything to the scenario and to simplify the call flow.

Regards,
 Rifaat

> From: Elwell, John [mailto:[email-masked]]
> Sent: Wednesday, April 27, 2011 8:09 AM
> To: Shekh-Yusef, Rifaat (Rifaat); [email-masked]
> Subject: RE: Answering a Call Using Two Separate Devices proposal
> 
> Rifaat,
> 
> This involves sending SIP requests (REFER, INVITE, SUBSCRIBE) directly between
> Alice's two devices. What about NAT and firewall issues, if the two devices
> are not in the same network area? For example, phone on 3G, PC on WiFi? Don't
> the requests need to go via a proxy?
> 
> John
>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 27 Apr 2011 13:34:40 -0400

inline

> I think that we should try to achieve the second option of the 3 options you listed above.

Well, the 2nd is "better" than the first, but the third is better than 
the second. So if it can be achieved, all the better.

>      | SUBSCRIBE Event: dialog;include-session-description             |

Its a leap of faith here to assume that the phone will realize what it 
is expected to do when there is no offer in the invite.

Clearly it has to offer *something*. So *maybe* when the invite has Join 
it will know it should offer something related to the current call. But 
at the least it has the option of offering either just video, or audio 
plus video. And in some sense it is a policy decision which it should do.

I think we need to find a way to eliminate the leaps of faith, and 
replace with some plausible procedures coupled with some reasonable 
policy knobs.

	Thanks,
	Paul

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 28 Apr 2011 09:34:05 +0200

Rifaat,

OK, that's fine. Presumably a GRUU would be used to address the specific device.

John 

> From: Shekh-Yusef, Rifaat (Rifaat) [mailto:[email-masked]] 
> Sent: 27 April 2011 16:57
> To: Elwell, John; [email-masked]
> I was not trying to suggest that all these requests will go 
> directly between the devices without going through a proxy.
> I just did not see the need to explicitly show that because 
> it does not add anything to the scenario and to simplify the 
> call flow.
> 
> Regards,
>  Rifaat
> 
>  
>