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

Paul Kyzivat <> Fri, 01 July 2011 12:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0723A11E880D for <>; Fri, 1 Jul 2011 05:37:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -110.599
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Cp7Q58Ajt7hz for <>; Fri, 1 Jul 2011 05:37:37 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id C5A8311E882F for <>; Fri, 1 Jul 2011 05:13:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; 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 ([]) by with ESMTP; 01 Jul 2011 12:13:56 +0000
Received: from [] ([]) by (8.14.3/8.14.3) with ESMTP id p61CDtDe023041 for <>; Fri, 1 Jul 2011 12:13:56 GMT
Message-ID: <>
Date: Fri, 01 Jul 2011 08:13:54 -0400
From: Paul Kyzivat <>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv: Gecko/20110616 Thunderbird/3.1.11
MIME-Version: 1.0
References: <> <> <> <> <> <>, <> <>
In-Reply-To: <>
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-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Loosely-coupled SIP Devices \(splices\) working group discussion list" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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.