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

Gonzalo Camarillo <> Thu, 30 June 2011 06:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2B36711E813D for <>; Wed, 29 Jun 2011 23:06:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -106.569
X-Spam-Status: No, score=-106.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id sWBIWGtb3UY5 for <>; Wed, 29 Jun 2011 23:06:49 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 517E411E8131 for <>; Wed, 29 Jun 2011 23:06:49 -0700 (PDT)
X-AuditID: c1b4fb39-b7bfdae000005125-47-4e0c1278be74
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id AB.79.20773.8721C0E4; Thu, 30 Jun 2011 08:06:48 +0200 (CEST)
Received: from [] ( by ( with Microsoft SMTP Server id; Thu, 30 Jun 2011 08:06:48 +0200
Message-ID: <>
Date: Thu, 30 Jun 2011 09:06:47 +0300
From: Gonzalo Camarillo <>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv: Gecko/20110616 Thunderbird/3.1.11
MIME-Version: 1.0
To: Paul Kyzivat <>
References: <> <> <> <> <> <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.1.1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: AAAAAA==
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: Thu, 30 Jun 2011 06:06:50 -0000

Hi Paul,

yes, Join was considered at that point. As you say, the semantics are
similar to Join but not identical (specially with respect of how things
are presented to the user). Overloading Join may not be the best way to

If you are concerned with supporting another primitive in addition to
Join, the code base for Join and the new primitive would be almost



On 21/06/2011 3:32 PM, Paul Kyzivat wrote:
> 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.
> 	Thanks,
> 	Paul
> 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