IETF Logo Mail Archive

Re: [MMUSIC] Bundling data channel and RTP? - Text proposal

Christer Holmberg <christer.holmberg@ericsson.com> Wed, 27 May 2015 17:17 UTC

Return-Path: <christer.holmberg@ericsson.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 82DB11A87BD for <mmusic@ietfa.amsl.com>; Wed, 27 May 2015 10:17:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] 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 51kwMBn_q0WH for <mmusic@ietfa.amsl.com>; Wed, 27 May 2015 10:17:30 -0700 (PDT)
Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DE571A87BB for <mmusic@ietf.org>; Wed, 27 May 2015 10:17:29 -0700 (PDT)
X-AuditID: c1b4fb30-f798d6d0000009ec-7e-5565fc276cbb
Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id AA.56.02540.72CF5655; Wed, 27 May 2015 19:17:27 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.71]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.03.0210.002; Wed, 27 May 2015 19:17:26 +0200
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Roman Shpount <roman@telurix.com>, "Makaraju, Maridi Raju (Raju)" <Raju.Makaraju@alcatel-lucent.com>
Thread-Topic: [MMUSIC] Bundling data channel and RTP? - Text proposal
Thread-Index: AdCWueoLsROxlWDYR6SbmQrUuOlHngAPEbUAAFSKmYAABF7jcAABvZYAAAgnpwAAB+VBBw==
Date: Wed, 27 May 2015 17:17:25 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1D8689E9@ESESSMB209.ericsson.se>
References: <7594FB04B1934943A5C02806D1A2204B1D852384@ESESSMB209.ericsson.se> <55634C34.4080304@alum.mit.edu> <5565838D.2020005@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D866141@ESESSMB209.ericsson.se> <E1FE4C082A89A246A11D7F32A95A17828E7D3EEB@US70UWXCHMBA02.zam.alcatel-lucent.com>, <CAD5OKxuEpmMVfScf62bs=y+9PyYbejfa2OmsHYq=dStTZmjdVg@mail.gmail.com>
In-Reply-To: <CAD5OKxuEpmMVfScf62bs=y+9PyYbejfa2OmsHYq=dStTZmjdVg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D8689E9ESESSMB209erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprOIsWRmVeSWpSXmKPExsUyM+Jvra76n9RQgwOzhC2+vG9ksZi6/DGL xYoNB1gtGjZeYbWYcWEqswOrR+uzvawef99/YPJYsuQnk8eK8zNZPG5NKQhgjeKySUnNySxL LdK3S+DK+H76BmPBVOOK5TvuMzcw/tLuYuTkkBAwkdj0u58RwhaTuHBvPVsXIxeHkMBRRokz Mz8xQziLGSWmLb7N1MXIwcEmYCHR/Q+sWUQgS+LS/d1MIDazQA+jxKrzOSC2sICLxK8lPSwQ Na4SK57/ZoawwyQeT7oCFmcRUJW4+3A2G4jNK+Ar8XX1C0aIXa+ZJB7vegmW4BQIlGjrewrW wAh03fdTa6CWiUs0fVnJCnG1gMSSPeeZIWxRiZeP/7FC1ORLNK+ewQ6xQFDi5MwnLBMYRWYh aZ+FpGwWkjKIuIHEl/e3oWxtiWULXzND2PoS3e9PMyGLL2BkX8UoWpxanJSbbmSkl1qUmVxc nJ+nl5dasokRGJMHt/w22MH48rnjIUYBDkYlHl4F1dRQIdbEsuLK3EOM0hwsSuK8nl0hoUIC 6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoYq/OvGklM+Jx3+NQmMZb5jZxrp3UYrNNm/7a9SDNu TbrJr/lnzJXPlOYyqqS/ME/UCLKMlQ1rFWEs+pU777VhutJyxibrs2XHS17PW7uC5cLm0zee CJ2xM5IxueARXCGwpDnL2uPZYsPfRlOUBeV5DqQf6X74poWj1fPCm+yFcb3GP7nY939QYinO SDTUYi4qTgQAjhQpFaoCAAA=
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/PjHycnUs19wbPu4BOeqQ-dkqWsw>
Cc: "mmusic@ietf.org" <mmusic@ietf.org>, "pkyzivat@alum.mit.edu" <pkyzivat@alum.mit.edu>
Subject: Re: [MMUSIC] Bundling data channel and RTP? - Text proposal
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: Wed, 27 May 2015 17:17:32 -0000

Hi,

I guess we could add some text to the DTLS Considerations section.

Regards,

Christer

Sent from my Windows Phone
________________________________
From: Roman Shpount<mailto:roman@telurix.com>
Sent: ‎27/‎05/‎2015 23:31
To: Makaraju, Maridi Raju (Raju)<mailto:Raju.Makaraju@alcatel-lucent.com>
Cc: Christer Holmberg<mailto:christer.holmberg@ericsson.com>; Christian Groves<mailto:Christian.Groves@nteczone.com>; mmusic@ietf.org<mailto:mmusic@ietf.org>; pkyzivat@alum.mit.edu<mailto:pkyzivat@alum.mit.edu>
Subject: Re: [MMUSIC] Bundling data channel and RTP? - Text proposal



On Wed, May 27, 2015 at 7:37 AM, Makaraju, Maridi Raju (Raju) <Raju.Makaraju@alcatel-lucent.com<mailto:Raju.Makaraju@alcatel-lucent.com>> wrote:
> >One interesting question that Albrecht brought up in a separate email
> discussion is what happens if you first establish a >DTLS association
> for datachannel and then at a later stage you add SRTP media? I take it
> that you'd have to re-establish >the DTLS connection and perform a
> handshake using the "use_srtp" extension. That makes transitioning
> messy.
>
> There is a related (not BUNDLE specific) discussion on when one is
> allowed to re-establish a DTLS connection, and the idea (I don't have
> the exact details in front of me) is that it can happen only when an IP
> address or port changes. That obviously does not have to occur if you
> add SRTP.
[Raju]
Will there be an issue if "use_srtp" extension is always included even when
SRTP media is not present at that time? I don't see any issue.
This is how Chrome works today; it always includes the extension.


I agree, DTLS session should always be setup with "use_srtp" extension. There is little or no additional overhead, but this removes the latency required for a new DTLS session when and if SRTP is added. Since there is no new DTLS session there is no need for a new underlying transport and additional IPs. Nice and clean.

This should probably be stated somewhere in the document.
_____________
Roman Shpount

v2.23.0 | Report a Bug | By Email