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

Paul Kyzivat <> Mon, 06 June 2011 19:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 05D2A1F0C4C for <>; Mon, 6 Jun 2011 12:36:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -110.119
X-Spam-Status: No, score=-110.119 tagged_above=-999 required=5 tests=[AWL=0.480, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id iO8cZ9g+halX for <>; Mon, 6 Jun 2011 12:36:46 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 5A3661F0C44 for <>; Mon, 6 Jun 2011 12:36:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=2548; q=dns/txt; s=iport; t=1307389006; x=1308598606; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=pjldlZr2wirfQXj54EGiN8ZmDDr+QlvqqgAuw/CdXKE=; b=WGatn6X/kZz5s6enHgPWulxbB0HpmKriyArkrf8zhqIuFVKUyhwgP4CI ZkCXznN9KYFvFHBUL7jnNNDGygoiKads+0vAZIIJlEg5XR3JNTAOSSPu8 2q1yFJNV9XoQr9rH6Qz+YK0YJilE3IoXtZAP1V5QLgV3/BNHicJ1PCS9Z Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AjkHAEkr7U2tJXHA/2dsb2JhbABTmAWOIXerUZ4AhiEEkHmESIQxhl0
X-IronPort-AV: E=Sophos;i="4.65,327,1304294400"; d="scan'208";a="235437844"
Received: from ([]) by with ESMTP; 06 Jun 2011 19:36:45 +0000
Received: from [] ( []) by (8.14.3/8.14.3) with ESMTP id p56Jair9002754 for <>; Mon, 6 Jun 2011 19:36:45 GMT
Message-ID: <>
Date: Mon, 06 Jun 2011 15:36:44 -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
References: <AcwcBjEKPHRsQSI9R9CEF7Om5nHptA==> <>, <> <>
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: Mon, 06 Jun 2011 19:36:47 -0000

IMO it is *undesirable* to require that there be a common point through 
which all the media to/from that end must flow. Its especially 
problematic if the "intelligent" device that would have the capability 
to do this is bandwidth limited - as could be the case with mobile phones.

Maybe this can be tolerated if we can find nothing better. Or maybe it 
can be a fallback approach if something else doesn't work. But I'd hate 
to see defining that as *the* approach without trying to find a way to 
avoid it.


On 6/6/2011 3:19 PM, Worley, Dale R (Dale) wrote:
> ________________________________________
> From: [] On Behalf Of Peter Musgrave []
> I think an approach in which one of the loosely coupled endpoints acts as a media relay would eliminate all these issues. It can then source and sink audio on the same port to the external device and provide the appearance of symmetric RTP.
> _______________________________________________
> I like the approach of having an aggregation controller, probably incorporated into one of the UAs, that coordinates the other aggregated UAs using 3PCC techniques.  (Either relaying the RTP, or manipulating the SDP to connect each source and sink.)
> Of course, the aggregation controller has to handle all the "macro" call-control actions, such as receiving and acting on REFER, sending REFER, receiving and acting on INVITE-Replaces and INVITE-Join, etc.  Interestingly, all of the proposals require that one UA or the other handle all of these circumstances, although with a 3PCC aggregation controller, the need for designing how to handle these actions is more obvious.
> The one additional operation is how does an aggregation controller hand over a call to another aggregation controller?  The aggregation process contains quite a bit of state (although some of it is reported in the dialog events of the aggregation controller).
> BTW, here is a case which shows why it is better to have  the aggregation process done entirely at one end of the call:  Consider two aggregated clusters of UAs maintaining a dialog between themselves.  If a UA had to be aware of the aggregation at the far end of the call, along with the aggregation it was participating in on the near end, the logic would be incredibly complicated.
> Dale
> _______________________________________________
> splices mailing list