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

"Worley, Dale R (Dale)" <dworley@avaya.com> Mon, 06 June 2011 19:19 UTC

Return-Path: <dworley@avaya.com>
X-Original-To: splices@ietfa.amsl.com
Delivered-To: splices@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB2271F0C46 for <splices@ietfa.amsl.com>; Mon, 6 Jun 2011 12:19:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.599
X-Spam-Level:
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 mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9RpQvibvNp0i for <splices@ietfa.amsl.com>; Mon, 6 Jun 2011 12:19:52 -0700 (PDT)
Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id ED9591F0C3E for <splices@ietf.org>; 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 co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com 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 dc-us1hcex1.us1.avaya.com (HELO DC-US1HCEX1.global.avaya.com) ([135.11.52.20]) by co300216-co-erhwest-out.avaya.com with ESMTP; 06 Jun 2011 15:19:50 -0400
Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.192]) by DC-US1HCEX1.global.avaya.com ([2002:870b:3414::870b:3414]) with mapi; Mon, 6 Jun 2011 15:19:49 -0400
From: "Worley, Dale R (Dale)" <dworley@avaya.com>
To: Peter Musgrave <musgravepj@gmail.com>, "Shekh-Yusef, Rifaat (Rifaat)" <rifatyu@avaya.com>
Date: Mon, 06 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: <CD5674C3CD99574EBA7432465FC13C1B222907E9A2@DC-US1MBEX4.global.avaya.com>
References: <AcwcBjEKPHRsQSI9R9CEF7Om5nHptA==> <6369CB70BFD88942B9705AC1E639A33822CCE270F5@DC-US1MBEX4.global.avaya.com>, <BANLkTin+7fnDjmsfZVWKsmt631B7toRYVw@mail.gmail.com>
In-Reply-To: <BANLkTin+7fnDjmsfZVWKsmt631B7toRYVw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "splices@ietf.org" <splices@ietf.org>
Subject: Re: [splices] Using Two Separate Devices to Start a Conversation proposal
X-BeenThere: splices@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Loosely-coupled SIP Devices \(splices\) working group discussion list" <splices.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/splices>, <mailto:splices-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/splices>
List-Post: <mailto:splices@ietf.org>
List-Help: <mailto:splices-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/splices>, <mailto:splices-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 06 Jun 2011 19:19:52 -0000

________________________________________
From: splices-bounces@ietf.org [splices-bounces@ietf.org] On Behalf Of Peter Musgrave [musgravepj@gmail.com]

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