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

Paul Kyzivat <> Tue, 21 June 2011 12:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 34A2B11E807A for <>; Tue, 21 Jun 2011 05:32:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -110.459
X-Spam-Status: No, score=-110.459 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mneFxkw6iOIH for <>; Tue, 21 Jun 2011 05:32:17 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 67F1911E8079 for <>; Tue, 21 Jun 2011 05:32:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=2453; q=dns/txt; s=iport; t=1308659537; x=1309869137; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=0UDzs40uR+aLjDu7XyvYjQIs01eIUeCCZmwzSjAtdqo=; b=HLs0017cbxC3GePm6Ka2Yg60penCSnN3MPQr1bbcSPyPqwrR0vSPX5J8 7qUDT5fAx3YmIyofxgx+Dlinyp2m7q+eNrr1xmcdWk7Foqn9buXt98KWt z6edeChW8Lns4yLMmf25V9qhP/PP1X7qDG1c+K+t2yjfhrj9aw7n1wXn5 I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EALyOAE6tJXHB/2dsb2JhbABUpm53qkCeRIYqBJFmhGKLQA
X-IronPort-AV: E=Sophos;i="4.65,401,1304294400"; d="scan'208";a="237615339"
Received: from ([]) by with ESMTP; 21 Jun 2011 12:32:16 +0000
Received: from [] ( []) by (8.14.3/8.14.3) with ESMTP id p5LCWFSm005568; Tue, 21 Jun 2011 12:32:15 GMT
Message-ID: <>
Date: Tue, 21 Jun 2011 08:32:15 -0400
From: Paul Kyzivat <>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv: Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
To: Gonzalo Camarillo <>
References: <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "" <>
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: Tue, 21 Jun 2011 12:32:18 -0000

IMO there is nothing wrong with using Join to bring together one dialog 
with audio and another with video. I don't see why we would create 
another mechanism when that one is there to be used. Certainly it is a 
degenerate case of Join, but there is nothing wrong with degenerate cases.

Of course there might be UAs that are capable of supporting the case 
where the media in the dialogs is disjoint, but not the case where there 
is common media in the dialogs that must be mixed. But surely we can 
find an error code to cover that case.

The key issue here is what UA we expect to support this capability. IMO 
a user that wants to "splice" some of its devices together should take 
the responsibility of finding a UA that can handle the coordination, 
rather than depending upon the far end to do it.


On 6/21/2011 4:09 AM, Gonzalo Camarillo wrote:
> Hi Alan,
>>> 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.
> Yes... this is exactly what we proposed 5 years ago in one of the drafts
> that, eventually, led to the creation of the SPLICES WG:
> The idea was that the media streams of a given session could be
> established using more than one SIP dialog.
> Note that most SPLICES-related discussions up to a couple of months ago
> were based on the fact that such a mechanism (i.e., using different
> dialogs to establish a single session) would require support from the
> remote end point. That is also the point Paul made in his comment above.
> I personally would be OK with a mechanism along these lines, though.
> Cheers,
> Gonzalo