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

"Worley, Dale R (Dale)" <> Mon, 06 June 2011 19:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CB2271F0C46 for <>; Mon, 6 Jun 2011 12:19:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -103.599
X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9RpQvibvNp0i for <>; Mon, 6 Jun 2011 12:19:52 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id ED9591F0C3E for <>; Mon, 6 Jun 2011 12:19:51 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AmgFAL0n7U3GmAcF/2dsb2JhbABTmwmLHXeuFgKbPYYhBJVehBSGXQ
X-IronPort-AV: E=Sophos;i="4.65,327,1304308800"; d="scan'208";a="250024807"
Received: from unknown (HELO ([]) by with ESMTP; 06 Jun 2011 15:19:50 -0400
X-IronPort-AV: E=Sophos;i="4.65,327,1304308800"; d="scan'208";a="629939402"
Received: from (HELO ([]) by with ESMTP; 06 Jun 2011 15:19:50 -0400
Received: from ([]) by ([2002:870b:3414::870b:3414]) with mapi; Mon, 6 Jun 2011 15:19:49 -0400
From: "Worley, Dale R (Dale)" <>
To: Peter Musgrave <>, "Shekh-Yusef, Rifaat (Rifaat)" <>
Date: Mon, 6 Jun 2011 15:19:49 -0400
Thread-Topic: [splices] Using Two Separate Devices to Start a Conversation proposal
Thread-Index: AcwjtOq2/o5HtTYwSbSjFyK/UcGWQQAyJpIS
Message-ID: <>
References: <AcwcBjEKPHRsQSI9R9CEF7Om5nHptA==> <>, <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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: Mon, 06 Jun 2011 19:19:52 -0000

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.