Subject: Re: [splices] Using Two Separate Devices to Start a Conversation proposal

From: Paul Kyzivat <[email-masked]>
Date: Fri, 01 Jul 2011 08:13:54 -0400

On 6/30/2011 6:06 PM, Worley, Dale R (Dale) wrote:
>>> As Dale mentioned, this also depends on the other end doing the "right
>>> thing" with this case. It is a leap of faith to assume it will realize it
>>> should accept both streams and use one for input and the other for output.
>>>
>>> ISTM its at least as likely that it would accept the first stream, reject
>>> the second, and then have only a one-way "conversation".
>>
>> OK, I understand the problem right now.  The problem is that this is a
>> special kind of "Join" operation.  It is kind of a join, but not
>> quite.
>>
>> The operation we are after is perhaps similar to 3.3.8 Far-Fork in RFC 5850:
>>
>> I suspect instead of Join, we need a new primitive, lets call it
>> Splice or Merge which requests the UAS to add the media in the INVITE
>> into the dialog that is referenced.
>
> OK, now I see the problem with using Join.
>
> UA A1 sends an INVITE (requesting only audio) to UA B (which supports
> both audio and video).
>
> UA A2 sends an INVITE (requesting only video) to UA B (which supports
> both audio and video), with Join to the first dialog.
>
> Then we should expect that UA B will send its audio to A1 and its
> video to A2, within the semantics of Join.
>
> The difficulty is that UA B still sees the situation as two different
> dialogs.  E.g., if A1 sends a REFER/Refer-To: C to B, the A1-B dialog
> will be replaced by the C-B dialog, but the A2-B dialog will be
> undisturbed.
>
> Which is not the behavior we want if we are trying to logically bond
> A1 and A2 to act as a single UA.
>
> Using Join would have been convenient as it is already defined, and
> theoretically, UAs already support it.

That would be the problem if the user at A orchestrates A1 and A1 to 
establish a "call" to B. This is once again a problem because there is 
no one UA acting on behalf of A and holding the complete dialog to B.

It would not be a problem if you had A1 holding one audio/video dialog 
with B, doing the audio itself and having another dialog with A2 for 
video. That would be true regardless of how the dialog with A2 was 
established - even if it was a join from A2 to A1.

	Thanks,
	Paul

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Fri, 1 Jul 2011 15:26:09 -0400

Which reminds me of a requirement that should be in the draft:  The mechanism should work even if both endpoints are using it at the same time.

Dale