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

Paul Kyzivat <pkyzivat@cisco.com> Fri, 01 July 2011 12:37 UTC

Return-Path: <pkyzivat@cisco.com>
X-Original-To: splices@ietfa.amsl.com
Delivered-To: splices@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0723A11E880D for <splices@ietfa.amsl.com>; Fri, 1 Jul 2011 05:37:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Level:
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cp7Q58Ajt7hz for <splices@ietfa.amsl.com>; Fri, 1 Jul 2011 05:37:37 -0700 (PDT)
Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by ietfa.amsl.com (Postfix) with ESMTP id C5A8311E882F for <splices@ietf.org>; Fri, 1 Jul 2011 05:13:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=2232; q=dns/txt; s=iport; t=1309522437; x=1310732037; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=Nx/hXFrgX4yaJUXOzlXqsXptJq/yQ6J5hE94MO6b7e0=; b=XHt4g/BMMsrhlPdj1woo1Hi0EpSG969NjetQ+RpTX6PD8VZWPtOt5pjr v4kWyBo7uzWjQolaXZK/ojk8GC45OWed9/xnHx0YTjS3U0oBtPEnmitGP DNZn/B1XUqjLGoCUjTnnG2Y8RIUihJ2twO9UODlulub9x4848FbIuyppq M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgMIAKW5DU6tJXHA/2dsb2JhbABSmG2Oc3erEp1/hjIEkjKEdotX
X-IronPort-AV: E=Sophos;i="4.65,458,1304294400"; d="scan'208";a="288705518"
Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by sj-iport-4.cisco.com with ESMTP; 01 Jul 2011 12:13:56 +0000
Received: from [10.86.252.117] ([10.86.252.117]) by rcdn-core2-5.cisco.com (8.14.3/8.14.3) with ESMTP id p61CDtDe023041 for <splices@ietf.org>; Fri, 1 Jul 2011 12:13:56 GMT
Message-ID: <4E0DBA02.4040309@cisco.com>
Date: Fri, 01 Jul 2011 08:13:54 -0400
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11
MIME-Version: 1.0
To: splices@ietf.org
References: <6369CB70BFD88942B9705AC1E639A33822CCE270F5@DC-US1MBEX4.global.avaya.com> <BANLkTin+7fnDjmsfZVWKsmt631B7toRYVw@mail.gmail.com> <CD5674C3CD99574EBA7432465FC13C1B222907E9A1@DC-US1MBEX4.global.avaya.com> <1C6C5AB3-6085-4CCA-9F1D-8BA5D98ED651@gmail.com> <4DED2EFA.20004@cisco.com> <BANLkTimfP2EaJZtPcjOp6s4v+Gk87vetGw@mail.gmail.com>, <4E0051B1.1030007@ericsson.com> <CD5674C3CD99574EBA7432465FC13C1B222B1F571D@DC-US1MBEX4.global.avaya.com>
In-Reply-To: <CD5674C3CD99574EBA7432465FC13C1B222B1F571D@DC-US1MBEX4.global.avaya.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [splices] Using Two Separate Devices to Start a Conversation proposal
X-BeenThere: splices@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Loosely-coupled SIP Devices \(splices\) working group discussion list" <splices.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/splices>, <mailto:splices-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/splices>
List-Post: <mailto:splices@ietf.org>
List-Help: <mailto:splices-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/splices>, <mailto:splices-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 01 Jul 2011 12:37:38 -0000

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