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

"Worley, Dale R (Dale)" <dworley@avaya.com> Mon, 06 June 2011 19:52 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 F1B291F0C5B for <splices@ietfa.amsl.com>; Mon, 6 Jun 2011 12:52:31 -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 BDWY2YQwpz4j for <splices@ietfa.amsl.com>; Mon, 6 Jun 2011 12:52:30 -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 3340D1F0C44 for <splices@ietf.org>; Mon, 6 Jun 2011 12:52:28 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EAGUu7U2HCzI1/2dsb2JhbABTph93iHGlFgKbQoYhBJVeinE
X-IronPort-AV: E=Sophos;i="4.65,327,1304308800"; d="scan'208";a="250030396"
Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 06 Jun 2011 15:52:27 -0400
X-IronPort-AV: E=Sophos;i="4.65,327,1304308800"; d="scan'208";a="660036652"
Received: from unknown (HELO DC-US1HCEX3.global.avaya.com) ([135.11.52.22]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 06 Jun 2011 15:52:26 -0400
Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.192]) by DC-US1HCEX3.global.avaya.com ([135.11.52.22]) with mapi; Mon, 6 Jun 2011 15:52:25 -0400
From: "Worley, Dale R (Dale)" <dworley@avaya.com>
To: Alan Johnston <alan.b.johnston@gmail.com>
Date: Mon, 06 Jun 2011 15:49:12 -0400
Thread-Topic: [splices] Using Two Separate Devices to Start a Conversation proposal
Thread-Index: AcwkgQNKZ2qvuGW3Rser97Y8kRSXBQAAcvbw
Message-ID: <CD5674C3CD99574EBA7432465FC13C1B222907E9A8@DC-US1MBEX4.global.avaya.com>
References: <AcwcBjEKPHRsQSI9R9CEF7Om5nHptA==> <6369CB70BFD88942B9705AC1E639A33822CCE270F5@DC-US1MBEX4.global.avaya.com> <BANLkTin+7fnDjmsfZVWKsmt631B7toRYVw@mail.gmail.com> <CD5674C3CD99574EBA7432465FC13C1B222907E9A1@DC-US1MBEX4.global.avaya.com>, <1C6C5AB3-6085-4CCA-9F1D-8BA5D98ED651@gmail.com>
In-Reply-To: <1C6C5AB3-6085-4CCA-9F1D-8BA5D98ED651@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:52:32 -0000

> If I understand correctly, there will be two separate RTP streams,
> two m= lines?

There will be two m= lines, but it is one m= line in one dialog, and
another m= line in the other dialog.

> If this is the case, then two separate NAT traversal mechanisms will
> be used (i.e. ICE rubs twice or two relays used). As far as ZRTP or
> other media path keying protocols, each session will be keyed
> separately. With ZRTP the endpoint will see two different ZIDs.
> This does unfortunately mean two Diffie Hellman calculations.

I think the envisioned problem is with simpler NAT traversal
mechanisms which do not use ICE, but rather depend on the RTP packets
traveling "out" through the NAT to establish and maintain an inward
mapping "pinhole".  That won't work with one-way media, or rather,
inward-only media.

> Since these are separate sessions, each will have an RTCP session as
> well, and these may need NAT traversal as well.

> So this will work, but things like logging and quality reporting
> will be quite complicated.

Hmmm...  In this case, they won't be any harder than they would be in
a three-way ad-hoc conference call.

Dale