Re: [MMUSIC] Draft new version: draft-holmberg-mmusic-sdp-dtls-01

[Roman Shpount <[e-mail]>]

On Mon, Jun 22, 2015 at 3:39 AM, Christer Holmberg <
[e-mail]> wrote:

> > One thing to keep in mind here, that unless ICE restart was initiated by
> the offering side (i.e. it had a different ufrag/pwd even if it specified
> > connection:exisiting), answering side cannot allocate a new transport.
> Answering side is simply not allowed to respond with a new ufrag/pwd
> > unless new ufrag/pwd was used in the offer. In cases where offer has the
> same ufrag/pwd, answering side must use connection:existing and issue > a
> new offer to setup new transport and new DTLS association.
>
> That's a good point. Is that a generic ICE rule, or something we need to
> define for DTLS in the draft?
>
>
This is a generic ICE rule defined in RFC 5245 9.2.2 (
https://tools.ietf.org/html/rfc5245#section-9.2.2):

Unless the agent has detected an ICE restart from the offer, the username
fragments, password, and implementation level MUST remain the same as used
previously.  If an agent needs to change one of these it MUST restart ICE
for that media stream by generating an offer; ICE cannot be restarted in an
answer.

I do not think we need to restate this, but we need to specify how this
will affect DTLS setup. Primarily there are two things we want to mention:

1. When ICE is used, new DTLS association can only be setup in an answer,
if it is an answer to ICE restart.

2. If an ICE offer is received, which requires a new DTLS association,
either due to fingerprint or setup role change, or due to "connectiion:new"
attribute, and this offer does not have new ufrag/pwd, then it cannot be
handled. This would indicate an error condition, and media line would need
to be refused with m-line port 0 or the whole offer would need to be
refused with an error response. After that connection would need to be torn
down or renegotiated with a new offer with new transport and DTLS
association.
_____________
Roman Shpount