Subject: [rtcweb] Offer/Answer and DTLS

From: Roman Shpount <[email-masked]>
Date: Sun, 22 Feb 2015 12:43:41 -0500

Let me try to explain what my issue is with offer/answer, DTLS and multiple
sessions over the same transport. First of all, as far as I understand,
based on the specifications, an end point is supposed to start a new DTLS
session (not re-key) if the setup role or fingerprint changes.

Imagine the following situation: An end point has no intent to create a new
DTLS session, it send an offer with the existing fingerprint and actpass
setup role. Since it does not intend to change anything DTLS related,
existing DTLS session continues to run. Remote party maintains the
transport parameters but changes either role or fingerprint. This implies
new DTLS session. So remote party closes the existing DTLS session (sends
an alert) and starts negotiating a new session (potentially sends Client
Hello). All of this happens at the same time as the answer is being
generated and sent out to the offering pary. Offering party might not get
this answer before new DTLS session handshake is received, so this
handshake is most likely to be ignored, potentially delaying the session
setup by DTLS timeout.

Another problem: Offering party desires to change the DTLS session settings
without changing the transport parameters and sends a new offer with new
fingerprint and/or setup role. It cannot simply close the existing DTLS
session, since offer might still fail for unrelated reason. If setup role
is passive or actpass, offering party can still get the Client Hello before
the successful answer was received, which means it should be able to
process DTLS client offers while still processing data for the existing
DTLS session.

based on this, it looks like anything that runs offer/answer in combination
with DTLS, should be able to handle a new DTLS session setup while an
existing session is still running. At the very least, it should queue the
Client Hello packets to be processed when signaling level decides to start
a new session. Alternative would be loss of data or media for the duration
of DTLS timeout.

Finally, data and alerts from the previous session can be received after
new session is setup. These two DTLS sessions can be demultiplexed based on
their signatures or packets from an old session can simply be ignored since
they failed the signature verification, which would be much less graceful.
I think the better solution would be for an end point to maintain the list
of recent DTLS sessions and try to dispatch a DTLS packet to the right
session based on the packet signature. Having some sort of session
indicator (similar to MKI) would make this process more transparent and
less resource intensive but I do not think this is available for DTLS.

So, my questions are:
1. Am I missing something in regard to DTLS session mulitplexing?
2. Is DTLS session multiplexing defined somewhere?
3. Have anybody implemented something similar to this?

I am primarily interested in this in regard to WebRTC implementations. In
particular I am interested in what is going to be supported or implemented
by web browsers. As far as I know, current browser implementations do not
support such renegotiation at all. If this is the intent for the
foreseeable future, then prohibiting changes (at least with a SHOULD) to
DTLS session without change to the underlying transport might not be a bad
option.
_____________
Roman Shpount

On Mon, Feb 16, 2015 at 3:01 PM, Makaraju, Maridi Raju (Raju) <
[email-masked]> wrote:

>
>
> On Mon, Feb 16, 2015 at 12:51 PM, Roman Shpount <[email-masked]> wrote:
>
> What is unclear to me is how DTLS is dealing with multiple DTLS sessions
> (i.e. DTLS data and alerts) on the same transport connection. I cannot find
> any documentation or implementations of such feature.
>
>
> *[Raju] **DTLS is a protocol which is typically runs in application-space. You typically run just one DTLS session on top of underlying transport layer (TCP or UDP). As explained by Simon, DTLS rekeying does not result in a new DTLS association, but rather new handshake sequence on top of existing association. *
>
> *However, during subsequent SDP O/A role change may trigger a new DTLS association to be setup. In such a case previous association should be gone and any transport layer packets (TCP or UDP) from the previous DTLS association may arrive on new DTLS association, but I think they will and should be discarded due to MAC failure (with bad_record_mac alert?).*
>
> *Please note that this is not unique to TCP; though unreliable, UDP transport could also receive delayed pkts from previous DTLS association. Or someone could simply inject UPD pkts into mix. So, re-establishing TCP connection is not a solution and won’t help when UDP is used.*
>
> *So, IMO a DTLS implementation should handle such out-of-band (OOB) pkts in a graceful way (i.e. without dropping the DTLS association).*
>
>
>
> *Hope this helps!*
>
> *Raju*
>
>
>
>

---

From: Martin Thomson <[email-masked]>
Date: Mon, 23 Feb 2015 07:39:59 +1300

> session (not re-key) if the setup role or fingerprint changes.

Or you could not do that.  The feature exists to support a change to a
new communication endpoint.  A new DTLS association should not be
needed if the two endpoints are the same.  A different endpoint will
have different a transport addresses and different ICE credentials,
meaning that the whole demux issue is addressed at lower layers of the
stack.

The only thing we would need to do in that case is say that you MUST
NOT change a=setup during renegotiation unless the endpoint (and
therefore the transport parameters) needs to change.

---

From: Roman Shpount <[email-masked]>
Date: Sun, 22 Feb 2015 13:52:37 -0500

> therefore the transport parameters) needs to change.

I actually agree. I would really like to see that specified somewhere that
*fingerprint* and *setup role* SHOULD NOT, or better yet, MUST NOT change
if end points and transport parameters did not change as well. This will
address all necessary use cases and simplify the implementations. In fact I
have suggested this on multiple occasions. Other people keep insisting that
these things can change independently.

Alternatively, which I do like a lot less, it is possible to define how
DTLS sessions can be setup and demultiplexed over the same connection.
Unless someone provides a good reason why this is needed and comes up with
a plausible implementation I would prefer not to have multiple DTLS
sessions over the same connection.
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 23 Feb 2015 05:06:34 +0000

Hi,

> I actually agree. I would really like to see that specified somewhere that fingerprint and 
> setup role SHOULD NOT, or better yet, MUST NOT change if end points and transport 
> parameters did not change as well. This will address all necessary use cases and simplify 
> the implementations. In fact I have suggested this on multiple occasions. Other people 
> keep insisting that these things can change independently.

The SCTP-SDP draft currently contains the following sentence:

	"Therefore, endpoints SHOULD NOT change the 'active/
   	passive' status during a session, unless they want to establish a new
   	DTLS connection."

And, even if a new DTLS connection is established, it of course doesn't mean that the active/passive status automatically will be changed - but the status will be re-negotiated.

	"If the transport parameters or the key fingerprints change, the
   	endpoints MUST establish a new DTLS connection.  In such case the
   	'active/passive' status of the endpoints will again be determined
   	following the procedures in [RFC4145], and the new status will be
   	used to determine the TLS roles of the endpoints associated with the
   	new DTLS connection."

> Alternatively, which I do like a lot less, it is possible to define how DTLS sessions can be setup and 
> demultiplexed over the same connection. Unless someone provides a good reason why this is 
> needed and comes up with a plausible implementation I would prefer not to have multiple 
> DTLS sessions over the same connection.

My understanding is that, when BUNDLE is used, a single DTLS connection will be used for all bundled media/data within that BUNDLE group.

I am not even sure it would be allowed to have multiple DTLS connections on a single 5-tuple, but I guess some DTLS expert can answer that.

Regards,

Christer

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 23 Feb 2015 08:54:07 -0800

Roman said:

"I actually agree. I would really like to see that specified somewhere that
*fingerprint* and *setup role* SHOULD NOT, or better yet, MUST NOT change
if end points and transport parameters did not change as well. This will
address all necessary use cases and simplify the implementations. In fact I
have suggested this on multiple occasions. Other people keep insisting that
these things can change independently."

[BA] I'm generally supportive of this direction.  Existing implementations
don't support re-negotiation, so in general it won't work anyway.

"Alternatively, which I do like a lot less, it is possible to define how
DTLS sessions can be setup and demultiplexed over the same connection."

[BA] This is much less desirable - and even if the standards work were
done, who would implement it?

On Sun, Feb 22, 2015 at 9:06 PM, Christer Holmberg <
[email-masked]> wrote:

> And, even if a new DTLS connection is established, it of course doesn't
> mean that the active/passive status automatically will be changed - but the
> status will be re-negotiated.
>
> DTLS sessions can be setup and
> My understanding is that, when BUNDLE is used, a single DTLS connection
> will be used for all bundled media/data within that BUNDLE group.
>
> I am not even sure it would be allowed to have multiple DTLS connections
> on a single 5-tuple, but I guess some DTLS expert can answer that.
>
> Regards,
>
> Christer
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: Roman Shpount <[email-masked]>
Date: Mon, 23 Feb 2015 12:12:10 -0500

>         used to determine the TLS roles of the endpoints associated with
My understand is that the current draft allows to establish new DTLS
connection over the same transport connection if an endpoint wants to do
this. I would like to make sure that the specification explicitly prohibits
this and states somewhere that fingerprint and setup role MUST NOT change
unless the transport parameters change as well.

Unless this is prohibited, some sort of specification language needs to be
provided stating how multiple DTLS connections can run over a single
5-tuple. This is not currently allowed or defined anywhere and it is
required for DTLS to operate with offer/answer end transport connection
reuse. As I have stated on several occasions, I do not like the option of
allowing multiple DTLS connections over the same transport since it
complicates implementations for no reason. Unless someone provides a
compelling use case why this is needed I strongly believe this should not
be allowed.
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 23 Feb 2015 20:37:59 +0000

Hi,

>And, even if a new DTLS connection is established, it of course doesn't mean that the active/passive status automatically will be >changed - but the status will be re-negotiated.
>
> My understand is that the current draft allows to establish new DTLS connection 
> over the same transport connection if an endpoint wants to do this.

Correct.

> I would like to make sure that the specification explicitly prohibits this and states 
> somewhere that fingerprint and setup role MUST NOT change unless the transport 
> parameters change as well.

As far as SCTP-SDP is concerned, personally I don't (at least not at this moment) have a problem with such restriction.

However, when BUNDLE is used, SRTP and SCTP may share a single DTLS connection. It could cause problems if SRTP and SCTP define different rules when a DTLS connection can be re-established. And, SRTP-DTLS does not forbid that fingerprint and setup role change, unless the transport parameters also change.

>Unless this is prohibited, some sort of specification language needs to be provided stating how 
>multiple DTLS connections can run over a single 5-tuple. This is not currently allowed or 
>defined anywhere and it is required for DTLS to operate with offer/answer end transport connection reuse.

Doesn't the DTLS spec say that, when a new DTLS connection has been established, you need to maintain the keys for the previous connection for a while, in order to handle late packets?

>As I have stated on several occasions, I do not like the option of allowing multiple DTLS connections 
>over the same transport since it complicates implementations for no reason. Unless someone provides 
>a compelling use case why this is needed I strongly believe this should not be allowed.

I don't have a use-case, but because of BUNDLE I'd like to have the same rules for SRTP and SCTP.

Of course, we could add your suggested restriction also to SRTP...

But, would we then need add the restriction also to other protocols using DTLS? E.g. BFCP.

The best thing would be to have generic Offer/Answer rules for DTLS, which all usages (SRTP, SCTP, BFCP etc) then reference, but it's too late for that...

Regards,

Christer

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 23 Feb 2015 23:38:04 +0100

> Doesn't the DTLS spec say that, when a new DTLS connection has been established, you need to maintain the keys for the previous connection for a while, in order to handle late packets?

AFAIK the spec states that just in the case of DTLS rekeying.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Roman Shpount <[email-masked]>
Date: Mon, 23 Feb 2015 18:22:20 -0500

On Mon, Feb 23, 2015 at 3:37 PM, Christer Holmberg <
[email-masked]> wrote:

> As far as SCTP-SDP is concerned, personally I don't (at least not at this
> moment) have a problem with such restriction.
>
> However, when BUNDLE is used, SRTP and SCTP may share a single DTLS
> connection. It could cause problems if SRTP and SCTP define different rules
> when a DTLS connection can be re-established. And, SRTP-DTLS does not
> forbid that fingerprint and setup role change, unless the transport
> parameters also change.
>
> Doesn't the DTLS spec say that, when a new DTLS connection has been
> established, you need to maintain the keys for the previous connection for
> a while, in order to handle late packets?
>

This is specific to DTLS re-key (not a complete new session establishment)
in combination with SRTP. In case of DTLS re-key with DTLS data frames the
epoch number can be used to reference the correct cipher settings. This
would be used for SCTP or BFCP which run on top of DTLS data.

Unlike re-key, creating a new session over the same transport at the same
time as the existing session continues to run is not defined for DTLS.

> I don't have a use-case, but because of BUNDLE I'd like to have the same

I agree that common rules for DTLS offer/answer would be beneficial for
everybody. It is currently either undefined or broken in a similar manner
for both DTLS-SRTP and SCTP draft. New BFCP drafts actually reference
DTLS-SRTP as far as DTLS session setup is concerned, so they will suffer
from the same problem. Furthermore,  I do not think anybody has any intent
to implement DTLS changes without transport changes for any protocol. I
think it would be better to define this correctly at some point vs to keep
repeating the same uncertainty.

> The best thing would be to have generic Offer/Answer rules for DTLS, which
> all usages (SRTP, SCTP, BFCP etc) then reference, but it's too late for
> that...
>

It might not be a bad idea to create such a document and use it to update
DTLS-SRTP and other protocols which use DTLS with offer/answer. I am
actually not sure what protocols are out there, since DTLS for BFCP is only
mentioned in the new RFC 4583 bis drafts. RFC 4583 bis draft would actually
benefit from a document that describes DTLS offer/answer setup, which it
can reference instead of DTLS-SRTP. All the new work, such as SCTP, can
reference this new document as well. I would guess this will need to go to
MMUSIC.

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 24 Feb 2015 15:12:53 +0000

Hi,

>> Doesn't the DTLS spec say that, when a new DTLS connection >> has been established, you need to maintain the keys for the >> previous connection for a while, in order to handle late 
>> packets?
>

Ok.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 24 Feb 2015 15:20:06 +0000

Hi,

>This is specific to DTLS re-key (not a complete new session establishment) in combination with SRTP. In case of >DTLS re-key with DTLS data frames the epoch number can be used to reference the correct cipher settings. This >would be used for SCTP or BFCP which run on top of DTLS data.
>
>Unlike re-key, creating a new session over the same transport at the same time as the existing session continues to run >is not defined for DTLS.

Ok. Would it be useful to mention that re-keying can be done without re-negotiation the underlying transport? Or, is it obvious?

Because, I assume we still want to allow re-keying, or?

>I agree that common rules for DTLS offer/answer would be beneficial for everybody. It is currently either undefined >or broken in a similar manner for both DTLS-SRTP and SCTP draft. New BFCP drafts actually reference DTLS-SRTP >as far as DTLS session setup is concerned, so they will suffer from the same problem. Furthermore,  I do not think >anybody has any intent to implement DTLS changes without transport changes for any protocol. I think it would be >better to define this correctly at some point vs to keep repeating the same uncertainty.

So, would anyone *object* to such restriction? I have seen no objections so far.

>It might not be a bad idea to create such a document and use it to update DTLS-SRTP and other protocols which use >DTLS with offer/answer. I am actually not sure what protocols are out there, since DTLS for BFCP is only mentioned >in the new RFC 4583 bis drafts. RFC 4583 bis draft would actually benefit from a document that describes DTLS >offer/answer setup, which it can reference instead of DTLS-SRTP. All the new work, such as SCTP, can reference this >new document as well. I would guess this will need to go to MMUSIC.

Yes. If we, within the RTCWEB community, agree that we want the restriction you’ve suggested, I will bring the discussion to MMUSIC.

Regards,

Christer

---

From: Roman Shpount <[email-masked]>
Date: Tue, 24 Feb 2015 10:30:52 -0500

On Tue, Feb 24, 2015 at 10:20 AM, Christer Holmberg <
[email-masked]> wrote:

>  >This is specific to DTLS re-key (not a complete new session
> establishment) in combination with SRTP. In case of >DTLS re-key with DTLS
> data frames the epoch number can be used to reference the correct cipher
> settings. This >would be used for SCTP or BFCP which run on top of DTLS
> data.
>
>   >
>
> time as the existing session continues to run >is not defined for DTLS.
>
>
>
> Ok. Would it be useful to mention that re-keying can be done without
> re-negotiation the underlying transport? Or, is it obvious?
>
>
>

I think re-key is something that has a real value for long duration
connections and should be allowed. Furthermore, DTLS re-key can be done at
any time at the DTLS session layer without the need for the offer/answer
exchange. Re-key is an integral part of DTLS protocol and it is well
defined for both DTLS data (used by SCTP and BFCP) and DTLS-SRTP. Since it
is an integral part of DTLS protocol, I would assume we do not need to
explicitly state that it is allowed.

_____________
Roman Shpount

---

From: Simon Perreault <[email-masked]>
Date: Tue, 24 Feb 2015 10:34:44 -0500

On Tue, Feb 24, 2015 at 10:20 AM, Christer Holmberg <
[email-masked]> wrote:

> everybody. It is currently either undefined >or broken in a similar manner
> DTLS-SRTP >as far as DTLS session setup is concerned, so they will suffer
> from the same problem. Furthermore,  I do not think >anybody has any intent
> think it would be >better to define this correctly at some point vs to keep
> So, would anyone **object** to such restriction? I have seen no
> objections so far.
>

Are you referring specifically to *simultaneous* DTLS connections over the
same transport? I wouldn't object to prohibiting those, but objecting would
be pointless anyway because it's just impossible to have multiple
simultaneous DTLS connections over the same transport. It's like saying
"packets MUST NOT travel faster than the speed of light."

If you're instead referring to multiple *non-simultaneous* DTLS connections
over the same transport, then yes I would object. There's no valid reason
to prohibit those.

Simon

---

From: Simon Perreault <[email-masked]>
Date: Tue, 24 Feb 2015 10:36:34 -0500

On Tue, Feb 24, 2015 at 10:34 AM, Simon Perreault <[email-masked]>
wrote:

> If you're instead referring to multiple *non-simultaneous* DTLS
> connections over the same transport, then yes I would object. There's no
> valid reason to prohibit those.
>

Oh, and by "transport" I'm assuming you mean "5-tuple". If that's not
correct then... I object, your honour! ;)

Simon

---

From: Roman Shpount <[email-masked]>
Date: Tue, 24 Feb 2015 10:44:42 -0500

> correct then... I object, your honour! ;)
So, do you want to allow setting up new DTLS session over the same
underlying transport ("5-tuple" or ICE connection)? If you do, can explain
how can you ensure that only one DTLS connection would be running over this
transport at any given time during the offer/answer re-negotiation? For the
description of the problems please see my original email that started this
thread. By very nature of offer/answer multiple simultaneous DTLS sessions
must be supported during the re-negotiation, and as you said yourself,
those are not possible.

Also, what is the use case for which you would need to setup new DTLS
session when underlying transport stays the same?
_____________
Roman Shpount

---

From: Simon Perreault <[email-masked]>
Date: Tue, 24 Feb 2015 10:57:40 -0500

On Tue, Feb 24, 2015 at 10:44 AM, Roman Shpount <[email-masked]> wrote:
> underlying transport ("5-tuple" or ICE connection)?
>

I don't, but that's besides the point. The point is that when there's no
reason to prohibit doing something, then we must not prohibit it.

> If you do, can explain how can you ensure that only one DTLS connection
> would be running over this transport at any given time during the
> offer/answer re-negotiation? For the description of the problems please see
> my original email that started this thread. By very nature of offer/answer
> multiple simultaneous DTLS sessions must be supported during the
> re-negotiation, and as you said yourself, those are not possible.
>

This is not specific to DTLS. All UDP-based protocols are affected by this.
When you want to set-up a new session over the same transport, either you
implement something like TCP's TIME_WAIT state, or you define a way to
unambiguously differentiate sessions. Various protocols do it in various
ways. For DTLS, packets from to the old session would be automatically
rejected. This can be acceptable depending on the use case.

Simon

---

From: Roman Shpount <[email-masked]>
Date: Tue, 24 Feb 2015 11:08:54 -0500

> reason to prohibit doing something, then we must not prohibit it.

At this point none of the webrtc implementations plan to support this. Why
specify something that no one will support?

> This is not specific to DTLS. All UDP-based protocols are affected by
> this. When you want to set-up a new session over the same transport, either
> you implement something like TCP's TIME_WAIT state, or you define a way to

Can you please read the problem description from my original email and
reply to it? I think you are missing the point that I am raising. This is
not about late packets, even though late packets are also somewhat of an
issue. This is about the fact that the new session would need to be
negotiated at the same time as the old session is running. Furthermore,
this can very often happen when an end point is not expecting it.

_____________
Roman Shpount

---

From: Simon Perreault <[email-masked]>
Date: Tue, 24 Feb 2015 11:17:21 -0500

> specify something that no one will support?

That's exactly what I'm saying! Let's not "specify" it. Let's just say
nothing at all about this topic.

> this can very often happen when an end point is not expecting it.

Look, I think we're agreeing on maybe 95% of the things. I think what we
need at this point is a verbatim text proposal. Then we can wordsmith it as
we like.

Simon

---

From: Roman Shpount <[email-masked]>
Date: Tue, 24 Feb 2015 11:22:13 -0500

> need at this point is a verbatim text proposal. Then we can wordsmith it as
My text proposal is: "DTLS fingerprint and setup role MUST NOT change
unless underlying transport did not change as well." You have just said
that you disagree with this.
_____________
Roman Shpount

---

From: Simon Perreault <[email-masked]>
Date: Tue, 24 Feb 2015 11:36:46 -0500

> that you disagree with this.

I don't disagree, as I said I think I agree with about 95% of it.

One negation needs to be reversed: "DTLS fingerprint and setup role MUST
NOT change unless underlying transport did change as well."

In what draft would this go? Which section? I'm sorry but after re-reading
the whole thread I still can't find this.

Simon

---

From: Roman Shpount <[email-masked]>
Date: Tue, 24 Feb 2015 11:55:06 -0500

> NOT change unless underlying transport did change as well."

This is not I do not write drafts -- I can be dyslexic at times.

> the whole thread I still can't find this.
I think this particular discussion started because of
draft-ietf-mmusic-sctp-sdp. The best alternative would be to have a
separate new draft in MMUSIC which will define common offer/answer rules
for DTLS. This draft can update RFC 5763 and it can be referenced by
draft-ietf-mmusic-sctp-sdp and RFC 4583 bis. Another alternative would be to
update DTLS-SRTP (update RFC 5763) and include this language in
draft-ietf-mmusic-sctp-sdp.
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 24 Feb 2015 17:36:05 +0000

Hi,

The actual documentation would be discussed in MMUSIC, and obviously they may have opinions on the suggested restriction too. Keep in mind that this is not an RTCWEB specific issue.

But, again, before I move the discussion to MMUSIC I’d like to verify whether we, from an RTCWEB perspective, are ok with the suggestion.

Regards,

Christer

From: Roman Shpount [mailto:[email-masked]]
Sent: 24 February 2015 18:55
To: Simon Perreault
Cc: Christer Holmberg; [email-masked]
Subject: Re: [rtcweb] Offer/Answer and DTLS

On Tue, Feb 24, 2015 at 11:36 AM, Simon Perreault <[email-masked]<mailto:[email-masked]>> wrote:

On Tue, Feb 24, 2015 at 11:22 AM, Roman Shpount <[email-masked]<mailto:[email-masked]>> wrote:
My text proposal is: "DTLS fingerprint and setup role MUST NOT change unless underlying transport did not change as well." You have just said that you disagree with this.

One negation needs to be reversed: "DTLS fingerprint and setup role MUST NOT change unless underlying transport did change as well."

In what draft would this go? Which section? I'm sorry but after re-reading the whole thread I still can't find this.

I think this particular discussion started because of draft-ietf-mmusic-sctp-sdp. The best alternative would be to have a separate new draft in MMUSIC which will define common offer/answer rules for DTLS. This draft can update RFC 5763 and it can be referenced by draft-ietf-mmusic-sctp-sdp and RFC 4583 bis. Another alternative would be to update DTLS-SRTP (update RFC 5763) and include this language in draft-ietf-mmusic-sctp-sdp.
_____________
Roman Shpount

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 24 Feb 2015 18:48:58 +0100

Den 24. feb. 2015 18:36, skrev Christer Holmberg:
> Hi,
> 
>  
> 
> The actual documentation would be discussed in MMUSIC, and obviously
> they may have opinions on the suggested restriction too. Keep in mind
> that this is not an RTCWEB specific issue.
> 
>  
> 
> But, again, before I move the discussion to MMUSIC I’d like to verify
> whether we, from an RTCWEB perspective, are ok with the suggestion.

Speaking as an RTCWEB participant, I'm happy with this resolution.
It says that I can't do something I don't want to do, and don't have to
write code for someone else doing it either.

> 
>  
> 
> Regards,
> 
>  
> 
> Christer
> 
>  
> 
> *From:*Roman Shpount [mailto:[email-masked]]
> *Sent:* 24 February 2015 18:55
> *To:* Simon Perreault
> *Cc:* Christer Holmberg; [email-masked]
> *Subject:* Re: [rtcweb] Offer/Answer and DTLS
> 
>  
> 
>         My text proposal is: "DTLS fingerprint and setup role MUST NOT
>         change unless underlying transport did not change as well." You
>         have just said that you disagree with this.
> 
>      
> 
>     One negation needs to be reversed: "DTLS fingerprint and setup role
>     MUST NOT change unless underlying transport did change as well."
> 
>  
> 
>     In what draft would this go? Which section? I'm sorry but after
>     re-reading the whole thread I still can't find this.
> 
>      
> 
>  
> 
> draft-ietf-mmusic-sctp-sdp and RFC 4583 bis. Another alternative would
> be to update DTLS-SRTP (update RFC 5763) and include this language in