IETF Logo Mail Archive

Re: [rtcweb] DTLS, DTLS-SRTP, and 5-tuples

"Makaraju, Maridi Raju (Raju)" <Raju.Makaraju@alcatel-lucent.com> Thu, 05 March 2015 16:25 UTC

Return-Path: <Raju.Makaraju@alcatel-lucent.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 836E51A1B0E for <rtcweb@ietfa.amsl.com>; Thu, 5 Mar 2015 08:25:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.909
X-Spam-Level:
X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 dvQzjNvVw7pJ for <rtcweb@ietfa.amsl.com>; Thu, 5 Mar 2015 08:25:49 -0800 (PST)
Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (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 D449A1A0151 for <rtcweb@ietf.org>; Thu, 5 Mar 2015 08:15:23 -0800 (PST)
Received: from us70tusmtp1.zam.alcatel-lucent.com (unknown [135.5.2.63]) by Websense Email Security Gateway with ESMTPS id 638A09B763733; Thu, 5 Mar 2015 16:15:18 +0000 (GMT)
Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id t25GFJgf020447 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 5 Mar 2015 11:15:20 -0500
Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.56]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.03.0195.001; Thu, 5 Mar 2015 11:15:19 -0500
From: "Makaraju, Maridi Raju (Raju)" <Raju.Makaraju@alcatel-lucent.com>
To: Roman Shpount <roman@telurix.com>
Thread-Topic: [rtcweb] DTLS, DTLS-SRTP, and 5-tuples
Thread-Index: AQHQVqbPY/4BaRkZfUWL2bRYyondfJ0M/70AgAACNQCAAA6BAIAAAZIAgAABcAD///pPYIAAvE4AgAAwswCAAAYfgIAABG+AgAAGSwD//8v1EIAAWVSA//+t/5AADA4WgAAIqw4A
Date: Thu, 05 Mar 2015 16:15:19 +0000
Deferred-Delivery: Thu, 5 Mar 2015 16:15:00 +0000
Message-ID: <E1FE4C082A89A246A11D7F32A95A17828E7273B4@US70UWXCHMBA02.zam.alcatel-lucent.com>
References: <54F74B02.1070902@jive.com> <CAD5OKxs8JYG3-Vvndi59ZrdPE7UTj22ozD4tcWTHgzWrHv=q7Q@mail.gmail.com> <54F756B2.60408@jive.com> <7594FB04B1934943A5C02806D1A2204B1D726AD8@ESESSMB209.ericsson.se> <CAD5OKxu7py3HbrFjxTDZS5ECFzx7vd=wpjve-gT6gWwksjEu+g@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B1D726B71@ESESSMB209.ericsson.se> <CABcZeBO1O6sA8MqvWkCDu3RPLz5-P2G65Us28i0baOavDnRT7Q@mail.gmail.com> <CAD5OKxuWCdgMR5Kxjv9BSwZ3Jm9kGXx9Pi-9FrfsnuQZ_91jAA@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B1D726DC1@ESESSMB209.ericsson.se> <CALiegfkipJhsy7-40+=d9xMUf4RJGdn3_fABL3NN2KuFNvS2BA@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B1D727570@ESESSMB209.ericsson.se> <CALiegfmfvz3NWSjcovGBytiOTbR6kFfyh0vx5cXoMJtytfGzRA@mail.gmail.com> <CAD5OKxsu3D0xHY-zYbDu1hyH_+4=3mWDvW2i98WCVZ+29BpKCw@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B1D728297@ESESSMB209.ericsson.se> <CALiegf=uPN+g546Ucv9s89z14cUTEme55y7B1siXZe97yj7Lig@mail.gmail.com> <E1FE4C082A89A246A11D7F32A95A17828E726EEC@US70UWXCHMBA02.zam.alcatel-lucent.com> <CALiegf=oVWk-8UcbQE2Edh=QSXSRUnSC=X-WMyGpvHYQ9SD1yg@mail.gmail.com> <E1FE4C082A89A246A11D7F32A95A17828E726F9B@US70UWXCHMBA02.zam.alcatel-lucent.com> <CAD5OKxvY6mBz2PjFEwUOhuCuEXoC_8FFjZO-HMyGxkXfZx7g=A@mail.gmail.com>
In-Reply-To: <CAD5OKxvY6mBz2PjFEwUOhuCuEXoC_8FFjZO-HMyGxkXfZx7g=A@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.5.27.17]
Content-Type: multipart/alternative; boundary="_000_E1FE4C082A89A246A11D7F32A95A17828E7273B4US70UWXCHMBA02z_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtcweb/GcCB3ldQhWaz9scvYV6KHEmju5w>
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] 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: Thu, 05 Mar 2015 16:25:51 -0000

On Thu, Mar 5, 2015 at 8:26 AM, Makaraju, Maridi Raju (Raju) <Raju.Makaraju@alcatel-lucent.com<mailto:Raju.Makaraju@alcatel-lucent.com>> wrote:
This is not allowed by http://tools.ietf.org/html/rfc5245#section-8.1.1.2 , unless webrtc overrides it.
A can only send DTLS once final nomination, which happens after all valid pairs are found, is done.

I think you are misreading http://tools.ietf.org/html/rfc5245#section-8.1.1.2: An end point can start sending media once a valid pair is discovered for each component (which is actually one component in case of bundle, one component per m= line in case of no bundle and rtcp-mux, and two components per m= line in case of neither). New valid pairs can still be found when media is being sent and media should be switched to the valid pair with the highest priority. When all the pairs are checked the final nomination request is sent, but the media will start flowing way before that. Alternative would be almost unusable since pair of two private IPs for two end-point each behind NAT will never get nominated and it will take a long time to time out, preventing media from flowing long after call is connected.
<Raju>
You are right and I completely agree with you [1]. Sorry, I overlooked this.

[1] http://tools.ietf.org/html/rfc5245#section-11.1.3
11.1.3<http://tools.ietf.org/html/rfc5245#section-11.1.3>.  Procedures for All Implementations

   ICE has interactions with jitter buffer adaptation mechanisms.  An
   RTP stream can begin using one candidate, and switch to another one,
   though this happens rarely with ICE.  The newer candidate may result
   in RTP packets taking a different path through the network -- one
   with different delay characteristics.

</Raju>

BR
Raju

v2.23.0 | Report a Bug | By Email