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

From: Christer Holmberg <[email-masked]>
Date: Mon, 25 May 2015 07:14:46 +0000

Hi,

Below is a suggestion for a "DTLS considerations" section. Let me know if you think there are more rules/restrictions that we should document.

--------------------

X.  DTLS Considerations

	One or more media streams within a BUNDLE group can use
	the Datagram Transport Layer Security (DTLS) protocol [RFC6347]
	in order to encrypt the data, or to negotiate encryption keys
	if another encryption mechanism is used to encrypt media.

	When DTLS is used for more than one media stream within a BUNDLE
	group, the following rules apply:

	o  A single DTLS association [RFC6347] MUST be used for all media
	using DTLS; and
	
   	o  Each media protocol using DTLS MUST use the same mechanism for
	determining which endpoint (the offerer or answerer) becomes DTLS client and DTLS server.

--------------------

Regards,

Christer   

-----Original Message-----
From: mmusic [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: 25 May 2015 04:59
To: Christian Groves; [email-masked]
Subject: Re: [MMUSIC] Bundling data channel and RTP?

Hi,

I wonder whether we should have a "DTLS considerations" section in BUNDLE, and specify that all bundled media MUST use the same DTLS connection for key management, encryption etc.

Would it even be possible to establish multiple DTLS connections on a single 5-tuple?

Regards,

Christer

-----Original Message-----
From: mmusic [mailto:[email-masked]] On Behalf Of Christian Groves
Sent: 22 May 2015 10:20
To: [email-masked]
Subject: Re: [MMUSIC] Bundling data channel and RTP?

Hello Magnus and Martin,

Thanks for confirming that.

It would be good to cover bundling the SRTP and DTLS/SCTP m-lines the BUNDLE and JSEP drafts.

Regards, Christian

On 20 May 2015 at 17:21, Christian Groves<[email-masked]>  wrote:

> Can anyone confirm the intention that a single DTLS connection is used 
> for SRTP key exchange and also SCTP packets?

Yes, the record layer carries SCTP and exporters from the same session are used to key SRTP.

On 21/05/2015 7:34 PM, Magnus Westerlund wrote:
> Christian Groves skrev den 2015-05-21 02:21:
>> Can anyone confirm the intention that a single DTLS connection is 
>> used for SRTP key exchange and also SCTP packets?
>>
>> draft-ietf-rtcweb-transports-08 indicates:
>>
>> /WebRTC implementations MUST support multiplexing of DTLS and RTP over//
>> //   the same port pair, as described in the DTLS_SRTP specification//
>> //   [RFC5764], section 5.1.2.  All application layer protocol 
>> payloads//
>> //   over this DTLS connection are SCTP packets./
>>
>> To me this implies a single DTLS connection. However in RFC5764 
>> clause
>> 4.1 it says:
>> /Once the "use_srtp" extension is negotiated, the RTP or RTCP//
>> //   application data is protected solely using SRTP. Application 
>> data is//
>> //   never sent in DTLS record-layer "application_data" packets.  
>> Rather,//
>> //   complete RTP or RTCP packets are passed to the DTLS stack, which//
>> //   passes them to the SRTP stack, which protects them appropriately.//
>> /
>> In the second sentence "application data" is not qualified with "RTP 
>> or RTCP" so it could be taken that its not possible to use the DTLS 
>> connection for anything else. However I take it that as the rest of 
>> the paragraph talks about RTP or RTCP that these were meant when 
>> application data is mentioned?
>>
>> Can only one add some clarity?
>>
>
> Yes, that is clearly the intention as I understand it in WebRTC.
>
> Cheers
>
> Magnus Westerlund
>
> ----------------------------------------------------------------------
> Services, Media and Network features, Ericsson Research EAB/TXM
> ----------------------------------------------------------------------
> Ericsson AB                 | Phone  +46 10 7148287
> Färögatan 6                 | Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden | mailto: [email-masked]
> ----------------------------------------------------------------------
>
>

_______________________________________________
mmusic mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mmusic

_______________________________________________
mmusic mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mmusic

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 25 May 2015 12:22:12 -0400

> Below is a suggestion for a "DTLS considerations" section. Let me know if you think there are more rules/restrictions that we should document.

My reply to your other message implies that it is probably important to 
say more than this.

Also, I *think* it is possible to mix RTP over UDP with RTP over DTLS in 
the same bundle. (Though I can't think of any utility to doing so.) I 
don't think what you say below is inconsistent with that, but it might 
be good to think through the implications.

	Thanks,
	Paul

---

From: Christian Groves <[email-masked]>
Date: Wed, 27 May 2015 18:42:53 +1000

Hello Christer,

With respect to the text below I don't think you need the "When DTLS is 
used for more than one media stream within a BUNDLE group". All you need 
to say is that there may only be one DTLS association per BUNDLE. Also 
it could be more confusing to mention more than one media stream, 
because SRTP doesn't use DTLS for the media stream, only key exchange.

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.

Regards, Christian

On 26/05/2015 2:22 AM, Paul Kyzivat wrote:
>> Below is a suggestion for a "DTLS considerations" section. Let me 
>> know if you think there are more rules/restrictions that we should 
>> document.
>
> My reply to your other message implies that it is probably important 
> to say more than this.
>
> Also, I *think* it is possible to mix RTP over UDP with RTP over DTLS 
> in the same bundle. (Though I can't think of any utility to doing so.) 
> I don't think what you say below is inconsistent with that, but it 
> might be good to think through the implications.
>
>     Thanks,
>     Paul
>
>> --------------------
>>
>> X.  DTLS Considerations
>>
>> I wonder whether we should have a "DTLS considerations" section in 
>> BUNDLE, and specify that all bundled media MUST use the same DTLS 
>> connection for key management, encryption etc.
>>
>> On 20 May 2015 at 17:21, Christian 
>> Groves<[email-masked]>  wrote:
>>

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 27 May 2015 08:54:26 +0000

Hi Christian,

>With respect to the text below I don't think you need the "When DTLS is used for more than one media stream within a >BUNDLE group". All you need to say is that there may only be one DTLS association per BUNDLE. Also it could be more >confusing to mention more than one media stream, because SRTP doesn't use DTLS for the media stream, only key >exchange.

Sounds good.

>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.

Roman/Justin/Martin/Paul/whoever-cares-about-this, do you have an opinion?

Regards,

Christer

On 26/05/2015 2:22 AM, Paul Kyzivat wrote:
>>>> In the second sentence "application data" is not qualified with 
>>>> "RTP or RTCP" so it could be taken that its not possible to use the 
>>>> DTLS connection for anything else. However I take it that as the 
>>>> rest of the paragraph talks about RTP or RTCP that these were meant 
>>>> when application data is mentioned?
>>>>
>>> --------------------------------------------------------------------
>>> -- Services, Media and Network features, Ericsson Research EAB/TXM

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Wed, 27 May 2015 11:37:52 +0000

> 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.

BR
Raju

---

From: Roman Shpount <[email-masked]>
Date: Wed, 27 May 2015 11:31:22 -0400

> 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

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 27 May 2015 17:17:25 +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:[email-masked]>
Sent: ‎27/‎05/‎2015 23:31
To: Makaraju, Maridi Raju (Raju)<mailto:[email-masked]>
Cc: Christer Holmberg<mailto:[email-masked]>; Christian Groves<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [MMUSIC] Bundling data channel and RTP? - Text proposal

[Raju]

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.

---

From: Christian Groves <[email-masked]>
Date: Thu, 28 May 2015 10:06:18 +1000

To be clear this means that the SRTP and SRTCP ( (because of the 
possibility of RTP/RTCP muxing) key negotiation occurs even before 
RTP/STRP media is added to the BUNDLE, and the keying material for both 
are maintained for the life of the BUNDLE? If the keys are unused they 
wouldn't expire because max lifetime is based on the number of protected 
packets.

Christian

On 28/05/2015 3:17 AM, Christer Holmberg wrote:
> ------------------------------------------------------------------------
> From: Roman Shpount <mailto:[email-masked]>
> To: Makaraju, Maridi Raju (Raju) <mailto:[email-masked]>
> Cc: Christer Holmberg <mailto:[email-masked]>; 
> Christian Groves <mailto:[email-masked]>; 
> [email-masked] <mailto:[email-masked]>; [email-masked] 
> <mailto:[email-masked]>
> On Wed, May 27, 2015 at 7:37 AM, Makaraju, Maridi Raju (Raju) 
> <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
> 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.
>

---

From: Roman Shpount <[email-masked]>
Date: Wed, 27 May 2015 22:20:25 -0400

If  "use_srtp" extension is specified, there is going to be SRTP/SRTCP
keying material present and associated with each DTLS cipher state. If DTLS
re-handshake occurs within the same session, the new RTP/RTCP keying
material will be negotiated. Since no SRTP/SRTCP packets would be exchanged
before SRTP/SRTCP stream was added to the bundle, these packets would not
contribute to cipher state expiration. Cipher state can still expire due to
the number of data packets transmitted or time, which can still cause new
SRTP/SRTCP keying material to be negotiated.

Technically speaking either DTLS client or server can initiate a
re-handshake at any time. It is an implementation detail on what would
cause a re-handshake, and it can be done based on the number of packets
sent or received, or based on time. If re-handshake is done based on the
number of packets, both SRTP/SRTCP and data packets should have separate
counters and cause a re-handshake once a certain value is passed.

As far as I know, DTLS re-handshake is not currently supported by either
Chrome or Firefox, which means keying material for both data and SRTP/SRTCP
will stay the same for the duration of the session.
_____________
Roman Shpount

On Wed, May 27, 2015 at 8:06 PM, Christian Groves <
[email-masked]> wrote:

> possibility of RTP/RTCP muxing) key negotiation occurs even before RTP/STRP
> media is added to the BUNDLE, and the keying material for both are
> maintained for the life of the BUNDLE? If the keys are unused they wouldn't
> expire because max lifetime is based on the number of protected packets.
>
> Christian
>
>> To: Makaraju, Maridi Raju (Raju) <mailto:[email-masked]
>> >
>> Cc: Christer Holmberg <mailto:[email-masked]>; Christian
>> Groves <mailto:[email-masked]>; [email-masked] <mailto:
>> [email-masked]>; [email-masked] <mailto:[email-masked]>
>> [email-masked] <mailto:[email-masked]>>
>> wrote:
>>

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 28 May 2015 06:30:48 +0000

Hi Roman,

So, if I understand you correctly, we do *NOT* need to mandate inclusion of “use_srtp” until SRTP/SRTCP is actually used. However, we could still RECOMMEND it, in order to avoid a re-handshake for that purpose when SRTP/SRTCP is added.

Regards,

Christer

From: Roman Shpount [mailto:[email-masked]]
Sent: 28 May 2015 05:20
To: Christian Groves
Cc: Christer Holmberg; Makaraju, Maridi Raju (Raju); [email-masked]; [email-masked]
Subject: Re: [MMUSIC] Bundling data channel and RTP? - Text proposal

If  "use_srtp" extension is specified, there is going to be SRTP/SRTCP keying material present and associated with each DTLS cipher state. If DTLS re-handshake occurs within the same session, the new RTP/RTCP keying material will be negotiated. Since no SRTP/SRTCP packets would be exchanged before SRTP/SRTCP stream was added to the bundle, these packets would not contribute to cipher state expiration. Cipher state can still expire due to the number of data packets transmitted or time, which can still cause new SRTP/SRTCP keying material to be negotiated.

Technically speaking either DTLS client or server can initiate a re-handshake at any time. It is an implementation detail on what would cause a re-handshake, and it can be done based on the number of packets sent or received, or based on time. If re-handshake is done based on the number of packets, both SRTP/SRTCP and data packets should have separate counters and cause a re-handshake once a certain value is passed.

As far as I know, DTLS re-handshake is not currently supported by either Chrome or Firefox, which means keying material for both data and SRTP/SRTCP will stay the same for the duration of the session.
_____________
Roman Shpount

On Wed, May 27, 2015 at 8:06 PM, Christian Groves <[email-masked]<mailto:[email-masked]>> wrote:
To be clear this means that the SRTP and SRTCP ( (because of the possibility of RTP/RTCP muxing) key negotiation occurs even before RTP/STRP media is added to the BUNDLE, and the keying material for both are maintained for the life of the BUNDLE? If the keys are unused they wouldn't expire because max lifetime is based on the number of protected packets.

Christian

Regards,

Christer

Sent from my Windows Phone
------------------------------------------------------------------------
From: Roman Shpount <mailto:[email-masked]<mailto:[email-masked]>>
Sent: ‎27/‎05/‎2015 23:31
To: Makaraju, Maridi Raju (Raju) <mailto:[email-masked]<mailto:[email-masked]>>
Cc: Christer Holmberg <mailto:[email-masked]<mailto:[email-masked]>>; Christian Groves <mailto:[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
Subject: Re: [MMUSIC] Bundling data channel and RTP? - Text proposal

    > address or port changes. That obviously does not have to occur
    if you
    [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.

---

From: "GUBALLA, JENS (JENS)" <[email-masked]>
Date: Thu, 28 May 2015 11:31:00 +0000

Hi Christer,

> Hi Roman,
> 
> 
> 
> So, if I understand you correctly, we do *NOT* need to mandate inclusion of
> “use_srtp” until SRTP/SRTCP is actually used. However, we could still
> RECOMMEND it, in order to avoid a re-handshake for that purpose when
> SRTP/SRTCP is added.
[JG] You should take into account that renegotiation will be removed from TLS1.3, refer to https://tools.ietf.org/html/draft-ietf-tls-tls13-05.

BTW, I prefer the term "renegotiation" over "re-handshake" or "re-keying", refer to https://tools.ietf.org/html/draft-guballa-tls-terminology-01.

Best regards,
Jens

> If  "use_srtp" extension is specified, there is going to be SRTP/SRTCP keying
> material present and associated with each DTLS cipher state. If DTLS re-
> handshake occurs within the same session, the new RTP/RTCP keying material
> will be negotiated. Since no SRTP/SRTCP packets would be exchanged before
> SRTP/SRTCP stream was added to the bundle, these packets would not contribute
> to cipher state expiration. Cipher state can still expire due to the number of
> data packets transmitted or time, which can still cause new SRTP/SRTCP keying
> material to be negotiated.
> 
> Technically speaking either DTLS client or server can initiate a re-handshake
> at any time. It is an implementation detail on what would cause a re-
> handshake, and it can be done based on the number of packets sent or received,
> or based on time. If re-handshake is done based on the number of packets, both
> SRTP/SRTCP and data packets should have separate counters and cause a re-
> handshake once a certain value is passed.
> 
> On Wed, May 27, 2015 at 8:06 PM, Christian Groves
> <[email-masked]> wrote:
> 
> media is added to the BUNDLE, and the keying material for both are maintained
> for the life of the BUNDLE? If the keys are unused they wouldn't expire
> because max lifetime is based on the number of protected packets.
> 
> 	Christian
>

---

From: Roman Shpount <[email-masked]>
Date: Thu, 28 May 2015 19:01:29 -0400

Christer,

Based on the currents TLS specifications you do *NOT* need to mandate
inclusion of “use_srtp” until SRTP/SRTCP is actually used. If this
extension is not specified you can renegotiate the session with the
extension enabled. We should still recommend it, in order to avoid
 a renegotiation for that purpose when SRTP/SRTCP is added. Also, all
current implementation will not inter-operate unless “use_srtp” extension
was included from the start, since they do not support renegotiation.

I am not the member of TLS working group and TLS 1.3 is still fairly early
to completely specify how it operates. In particular, it does not include
any mechanism for key material update. I am not 100% sure what is going to
be supported there and if extensions can be added and removed for an
existing DTLS session.

Given that:
1. existing implementations will not inter-operate with anything that does
renegotiation (and, I have a strong suspicion anything that does not enable
"use_srtp" extension)
2. renegotiation required to add "use_srtp" extension would add an extra
round trip
3. overhead of always having "use_srtp" extensions is minimal

I would suggest "use_srtp" extension must always be enabled for DTLS
session used in bundle.

_____________
Roman Shpount

On Thu, May 28, 2015 at 7:31 AM, GUBALLA, JENS (JENS) <
[email-masked]> wrote:

> [JG] You should take into account that renegotiation will be removed from
> TLS1.3, refer to https://tools.ietf.org/html/draft-ietf-tls-tls13-05.
>
> BTW, I prefer the term "renegotiation" over "re-handshake" or "re-keying",
> refer to https://tools.ietf.org/html/draft-guballa-tls-terminology-01.
>
> Best regards,
> Jens
>
> >
> >
> >
> > Regards,
> >
> >
> >
> > Christer
> >
> >
> >
> keying
> re-handshake
> RTP/STRP
> maintained

---

From: Roman Shpount <[email-masked]>
Date: Thu, 28 May 2015 19:05:36 -0400

P.S. I forgot to include, as a reason to always mandate "use_srtp"
extension, that ability to add extensions on the fly can be removed in TLS
1.3.

_____________
Roman Shpount

On Thu, May 28, 2015 at 7:01 PM, Roman Shpount <[email-masked]> wrote:

>> BTW, I prefer the term "renegotiation" over "re-handshake" or
>> "re-keying", refer to
>> https://tools.ietf.org/html/draft-guballa-tls-terminology-01.
>>
>> Best regards,
>> Jens
>>
>> >
>> >
>> >
>> > Regards,
>> >
>> >
>> >
>> > Christer
>> >
>> >
>> >

---

From: Martin Thomson <[email-masked]>
Date: Thu, 28 May 2015 16:06:35 -0700

> be supported there and if extensions can be added and removed for an

I expect that TLS 1.3 will specify a rekeying mechanism, but only for
its own records (in this context, that means SCTP).  Things that
depend on exporters (like DTLS-SRTP) will likely get a single, stable
value.

I agree with your analysis regarding use_srtp.  We certainly behave that way.

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 29 May 2015 05:24:03 +0000

Hi,

> P.S. I forgot to include, as a reason to always mandate "use_srtp" extension, that ability to add extensions on 
> the fly can be removed in TLS 1.3.
>
>Christer,
>
>inclusion of “use_srtp” until SRTP/SRTCP is >actually used. If this extension 
>is not specified you can renegotiate the session with the extension enabled. 
>We should still recommend it, in order to avoid  a renegotiation for that 
>purpose when SRTP/SRTCP is added. Also, all current implementation will 
>not inter-operate unless “use_srtp” extension was included from the 
>start, since they do not support renegotiation.
>
>any mechanism for key material update. I am not 100% sure what is 
>going to be supported there and if extensions can be added and removed 
>for an existing DTLS session.
>
>Given that:
>renegotiation (and, I have a strong suspicion anything that does not enable "use_srtp" extension)
>2. renegotiation required to add "use_srtp" extension would add an extra round trip
>I would suggest "use_srtp" extension must always be enabled for DTLS session used in bundle.

Assuming SRTP is supported, I assume. If a node doesn't support SRTP to begin with, or if an application is never going to offer (or accept if offered) SRTP, I guess there is no reason to mandate "use_srtp".

Now, there are statements in RFC 5764 saying e.g.:

	"This extension MUST only be used when the data being transported is RTP or RTCP [RFC3550]."

That of course makes sense for a non-BUNDLE DTLS connection, but I wonder whether we somehow explicitly need to say that it doesn't apply for BUNDLE?

Regards,

Christer

On Thu, May 28, 2015 at 7:31 AM, GUBALLA, JENS (JENS) <[email-masked]> wrote:
Hi Christer,

Best regards,
Jens

---

From: Roman Shpount <[email-masked]>
Date: Sat, 30 May 2015 20:09:46 -0400

On Fri, May 29, 2015 at 1:24 AM, Christer Holmberg <
[email-masked]> wrote:

> Assuming SRTP is supported, I assume. If a node doesn't support SRTP to
> begin with, or if an application is never going to offer (or accept if
> offered) SRTP, I guess there is no reason to mandate "use_srtp".
>
> That of course makes sense for a non-BUNDLE DTLS connection, but I wonder
> whether we somehow explicitly need to say that it doesn't apply for BUNDLE?
>
>
Another big question how would current browser implementations handle a
DTLS connection without "use_srtp" extension. I have a strong suspicion
that DTLS session setup will fail without this extension present. I think,
WebRTC enabled browsers currently export SRTP key material during session
setup even if no SRTP traffic is ever sent or received by this connection
and fail the entire connection if key export fails. This, most likely, can
be modified to only export SRTP key material when SRTP session is actually
created and defining some sort of fall back procedure when a media track is
actually added to a connection without "use_srtp" (either failure or
require renegotiation with new transport).

To conclude, the group can either decide that all DTLS sessions in bundle
should be setup with "use_srtp" extension and keep the current
implementations working as they are currently coded, or allow not to
include this extension and fix the implementations.
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 31 May 2015 07:02:39 +0000

Hi,

>> begin with, or if an application is never going to offer (or accept if offered) 
>> SRTP, I guess there is no reason to mandate "use_srtp".
>>
> Another big question how would current browser implementations handle a DTLS 
> connection without "use_srtp" extension. I have a strong suspicion that DTLS session 
> setup will fail without this extension present.
>
> I think, WebRTC enabled browsers currently export SRTP key material during 
> session setup even if no SRTP traffic is ever sent or received by this connection 
> and fail the entire connection if key export fails. This, most likely, can be modified 
> to only export SRTP key material when SRTP session is actually created and 
> defining some sort of fall back procedure when a media track is actually 
> added to a connection without "use_srtp" (either failure or require renegotiation with new transport).

Anyone from the browser community that can comment on this?

> To conclude, the group can either decide that all DTLS sessions in bundle should be setup 
> with "use_srtp" extension and keep the current implementations working as they are 
> currently coded, or allow not to include this extension and fix the implementations.

Currently, I am not aware of any scenarios where people would use BUNDLE without SRTP - or at least using clients that wouldn't support SRTP.

But, as the current trend seems to be to put more and more protocols on DTLS, I think one can assume that there will also be use-cases without SRTP in future.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 31 May 2015 13:28:07 -0400

> But, as the current trend seems to be to put more and more protocols on DTLS, I think one can assume that there will also be use-cases without SRTP in future.

As things stand, if you use data channels and don't use/support RTP, 
then there is no reason to use BUNDLE - you don't have anything, even 
potentially, to bundle with the data channel.

So, until and unless there is something else that can be bundled with 
data channel over DTLS then this is a moot issue.

	Thanks,
	Paul