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

"Worley, Dale R (Dale)" <dworley@avaya.com> Mon, 06 June 2011 19:10 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 249E211E81C9 for <splices@ietfa.amsl.com>; Mon, 6 Jun 2011 12:10:35 -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 g8lF-jskBWIW for <splices@ietfa.amsl.com>; Mon, 6 Jun 2011 12:10:34 -0700 (PDT)
Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 9B6EA11E816B for <splices@ietf.org>; Mon, 6 Jun 2011 12:10:34 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AmgFANwl7U3GmAcF/2dsb2JhbABTmwmLHXeuJgKbPIYhBJVehBSGXQ
X-IronPort-AV: E=Sophos;i="4.65,327,1304308800"; d="scan'208";a="283498985"
Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 06 Jun 2011 15:10:31 -0400
X-IronPort-AV: E=Sophos;i="4.65,327,1304308800"; d="scan'208";a="629936578"
Received: from dc-us1hcex2.us1.avaya.com (HELO DC-US1HCEX2.global.avaya.com) ([135.11.52.21]) by co300216-co-erhwest-out.avaya.com with ESMTP; 06 Jun 2011 15:10:31 -0400
Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.192]) by DC-US1HCEX2.global.avaya.com ([::1]) with mapi; Mon, 6 Jun 2011 15:10:31 -0400
From: "Worley, Dale R (Dale)" <dworley@avaya.com>
To: Peter Musgrave <musgravepj@gmail.com>, "Shekh-Yusef, Rifaat (Rifaat)" <rifatyu@avaya.com>
Date: Mon, 6 Jun 2011 15:07:29 -0400
Thread-Topic: [splices] Using Two Separate Devices to Start a Conversation proposal
Thread-Index: AcwjtOq2/o5HtTYwSbSjFyK/UcGWQQAyBCI4
Message-ID: <CD5674C3CD99574EBA7432465FC13C1B222907E9A1@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:10:35 -0000

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

I have concerns about this approach. Fundamentally the RTP stream is not symmetric (in the sense of RFC4961). This has consequences for NAT traversal, general interoperability and media path security schemes like ZRTP.
_______________________________________________

I have to agree and disagree...  As Rifaat diagrammed it, the call should work, as it uses already-defined SIP facilities.  Indeed, it's rather clever, I'd never thought of joining a sendonly dialog with a recvonly dialog.  There are some limitations, in that we depend on the far-end UA to execute the join in the way we want.

The problems you raise, those of asymmetric RTP, already exist -- One can make a sendonly audio call, or a recvonly audio call.  We need to ensure that NAT traversal and ZRTP work correctly when  media stream is set up to be one-way.

Dale