Re: [rtcweb] RFC 5763 Section 6.7.1 (was DTLS, DTLS-SRTP, and 5-tuples)
Jonathan Lennox <jonathan@vidyo.com> Fri, 27 March 2015 16:39 UTC
Return-Path: <jonathan@vidyo.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64EA11A0363; Fri, 27 Mar 2015 09:39:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.566
X-Spam-Level:
X-Spam-Status: No, score=-1.566 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, 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 L-_xL9oC0WpZ; Fri, 27 Mar 2015 09:39:57 -0700 (PDT)
Received: from mx0b-00198e01.pphosted.com (mx0b-00198e01.pphosted.com [67.231.157.197]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 383F01A0252; Fri, 27 Mar 2015 09:39:57 -0700 (PDT)
Received: from pps.filterd (m0073110.ppops.net [127.0.0.1]) by mx0b-00198e01.pphosted.com (8.14.7/8.14.7) with SMTP id t2RGVkSL027843; Fri, 27 Mar 2015 12:39:56 -0400
Received: from mail.vidyo.com ([162.209.16.214]) by mx0b-00198e01.pphosted.com with ESMTP id 1t74r6ceah-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 27 Mar 2015 12:39:56 -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; Fri, 27 Mar 2015 11:39:55 -0500
From: Jonathan Lennox <jonathan@vidyo.com>
To: "rtcweb@ietf.org" <rtcweb@ietf.org>, mmusic <mmusic@ietf.org>
Thread-Topic: [rtcweb] RFC 5763 Section 6.7.1 (was DTLS, DTLS-SRTP, and 5-tuples)
Thread-Index: AQHQaKux5rrdwp+DGkCKzQY17awJSp0w28gA
Date: Fri, 27 Mar 2015 16:39:54 +0000
Message-ID: <A9BD5845-7508-4A7C-925F-915799D3F73A@vidyo.com>
References: <CAOW+2dvHbmDkwqK5tNsdOqkc0EjwW5vhBb6JqL+SehWm40-FLw@mail.gmail.com>
In-Reply-To: <CAOW+2dvHbmDkwqK5tNsdOqkc0EjwW5vhBb6JqL+SehWm40-FLw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [31.133.177.80]
Content-Type: multipart/alternative; boundary="_000_A9BD584575084A7C925F915799D3F73Avidyocom_"
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-27_05:2015-03-27,2015-03-27,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-1503270161
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtcweb/ZpGXOGZ4qzrfmQJV8CFJC4UwkfE>
Subject: Re: [rtcweb] RFC 5763 Section 6.7.1 (was DTLS, DTLS-SRTP, and 5-tuples)
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 27 Mar 2015 16:39:58 -0000
On Mar 26, 2015, at 6:41 PM, Bernard Aboba <bernard.aboba@gmail.com<mailto:bernard.aboba@gmail.com>> wrote: RFC 5763 Section 6.7.1 explains much of what we've been talking about on this thread. 6.7.1<http://tools.ietf.org/html/rfc5763#section-6.7.1>. ICE Interaction Interactive Connectivity Establishment (ICE), as specified in [RFC5245<http://tools.ietf.org/html/rfc5245>] provides a methodology of allowing participants in multimedia sessions to verify mutual connectivity. When ICE is being used, the ICE connectivity checks are performed before the DTLS handshake begins. Note that if aggressive nomination mode is used, multiple candidate pairs may be marked valid before ICE finally converges on a single candidate pair. Implementations MUST treat all ICE candidate pairs associated with a single component as part of the same DTLS association. Thus, there will be only one DTLS handshake even if there are multiple valid candidate pairs. Note that this may mean adjusting the endpoint IP addresses if the selected candidate pair shifts, just as if the DTLS packets were an ordinary media stream (Adding MMUSIC.) The one recommendation I’d make for this problem is that one of the DTLS-SCTP drafts (probably ietf-mmusic-sctp-sdp, I guess?) should repeat this text from 5763.
- [rtcweb] RFC 5763 Section 6.7.1 (was DTLS, DTLS-S… Bernard Aboba
- Re: [rtcweb] RFC 5763 Section 6.7.1 (was DTLS, DT… Roman Shpount
- Re: [rtcweb] RFC 5763 Section 6.7.1 (was DTLS, DT… Simon Perreault
- Re: [rtcweb] RFC 5763 Section 6.7.1 (was DTLS, DT… Jonathan Lennox