IETF Logo Mail Archive

Re: [MMUSIC] draft-uberti-mmusic-nombis and (D)TLS

Jonathan Lennox <jonathan@vidyo.com> Mon, 23 March 2015 04:08 UTC

Return-Path: <jonathan@vidyo.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3ABB91A87C8 for <mmusic@ietfa.amsl.com>; Sun, 22 Mar 2015 21:08:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.966
X-Spam-Level:
X-Spam-Status: No, score=-0.966 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_55=0.6, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j1YvFxXgueMa for <mmusic@ietfa.amsl.com>; Sun, 22 Mar 2015 21:08:27 -0700 (PDT)
Received: from mx0a-00198e01.pphosted.com (mx0a-00198e01.pphosted.com [67.231.149.202]) by ietfa.amsl.com (Postfix) with ESMTP id D08F01A87CC for <mmusic@ietf.org>; Sun, 22 Mar 2015 21:08:27 -0700 (PDT)
Received: from pps.filterd (m0073109.ppops.net [127.0.0.1]) by mx0a-00198e01.pphosted.com (8.14.7/8.14.7) with SMTP id t2N48OCS015587; Mon, 23 Mar 2015 00:08:24 -0400
Received: from mail.vidyo.com ([162.209.16.214]) by mx0a-00198e01.pphosted.com with ESMTP id 1t74r624th-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Mon, 23 Mar 2015 00:08:24 -0400
Received: from 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77]) by 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62%13]) with mapi id 14.03.0195.001; Sun, 22 Mar 2015 23:08:23 -0500
From: Jonathan Lennox <jonathan@vidyo.com>
To: Justin Uberti <juberti@google.com>
Thread-Topic: [MMUSIC] draft-uberti-mmusic-nombis and (D)TLS
Thread-Index: AQHQZDiamTN6MOX7KUKlkksav4ltlJ0oqfiAgADcRICAABFtgIAALmuAgAADTQA=
Date: Mon, 23 Mar 2015 04:08:22 +0000
Message-ID: <C93DA598-9BF3-4199-B582-0B47297C66FA@vidyo.com>
References: <550E0F1A.2090303@ericsson.com> <BLU406-EAS2095DB481DB8142DA8BC0BB930C0@phx.gbl> <7594FB04B1934943A5C02806D1A2204B1D7729E2@ESESSMB209.ericsson.se> <CAD5OKxtB5qWQ1yYdGEOdKD55y0HPTGkY_hP0uV=PXEkRnZfcBg@mail.gmail.com> <CAOJ7v-0pQ=smq1EzpMrQBULm+mjscDXf=fpapdvMWtVX4FkWVw@mail.gmail.com>
In-Reply-To: <CAOJ7v-0pQ=smq1EzpMrQBULm+mjscDXf=fpapdvMWtVX4FkWVw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [31.133.147.245]
Content-Type: multipart/alternative; boundary="_000_C93DA5989BF34199B5820B47297C66FAvidyocom_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.33, 0.0.0000 definitions=2015-03-23_01:2015-03-20,2015-03-22,1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1503230045
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/OAmJ4i6qqEbMQAtVisIZDXt1tlc>
Cc: mmusic <mmusic@ietf.org>, Ari Keränen <ari.keranen@ericsson.com>, "draft-uberti-mmusic-nombis@tools.ietf.org" <draft-uberti-mmusic-nombis@tools.ietf.org>, Christer Holmberg <christer.holmberg@ericsson.com>
Subject: Re: [MMUSIC] draft-uberti-mmusic-nombis and (D)TLS
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic/>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 23 Mar 2015 04:08:29 -0000

The virtual connection is, I think, a single component of what RFC 5245 and draft-ietf-mmusic-rfc5245bis-04 call a “media stream”.  (This will be clearer, I think, if you think about non-muxed RTP/RTCP.)

Unfortunately, the “ICE media stream" terminology in 5245 conflicts rather badly with the RTP Taxonomy, so we may want to come up with something better.

In SDP, the virtual connection is identified by a BUNDLE group if you’re using BUNDLE, or an m-line if not; and in either case sharing the same component ID, and considering both sides of the offer/answer exchange (to handle forking cases).


On Mar 22, 2015, at 10:56 PM, Justin Uberti <juberti@google.com<mailto:juberti@google.com>> wrote:

Alas, an ICE ufrag doesn't uniquely identify an ICE virtual connection; with ICE forking you can have N virtual connections from the same ufrag.

A lfrag:rfrag tuple is closer, but even this does not work, because a) an ICE restart changes lfrag/rfrag without invalidating the connection, and b) because a ufrag can be shared across multiple m= lines (and thereby ICE connections).

The closest thing is m-line, keeping in mind that bundled m-lines use the virtual connection of the m-line onto which they are bundled.

On Sun, Mar 22, 2015 at 6:10 PM, Roman Shpount <roman@telurix.com<mailto:roman@telurix.com>> wrote:
On Sun, Mar 22, 2015 at 8:08 PM, Christer Holmberg <christer.holmberg@ericsson.com<mailto:christer.holmberg@ericsson.com>> wrote:

What was discussed in RTCWEB was to, instead of binding a DTLS connection to a 5-tuple, bind it to a "virtual connection". A "virtual connection" would be the set of all candidate pairs associated with a.... something.

Whether "something" is an m- line, a BUNDLE group, a complete SDP, or something else, hasn't been discussed - as far as I remember (please correct me if I'm wrong).


I was proposing that "something" is ICE ufrag, i.e. all 5-tuples for which a ICE/STUN bind request with the particular ufrag is received gets associated with the same "virtual" connection.
_____________
Roman Shpount


_______________________________________________
mmusic mailing list
mmusic@ietf.org<mailto:mmusic@ietf.org>
https://www.ietf.org/mailman/listinfo/mmusic

v2.23.0 | Report a Bug | By Email