Why is it possible to allow the answerer to force a new connection

[ekr]

The current structure of the draft seems to be:

• If ICE is in use, all new TLS connections require a restart
• The offerer can initiate a new connection by changing the tls-id
  but must do an ICE restart at the same time.
• On the answerer side (assuming ICE)
  • An offer with a new tls-id but without an ICE restart is an
    error.
  • An offer with a new tls-id with an ICE restart means a new
    connection and the answerer needs to supply a new tls-id.
  • An offer with the same tls-id but with an ICE restart allows
    the answerer to initiate a new connection by changing its
    own tls-id.

On the JSEP call today, we were concerned about this last point,
which doesn't seem very useful. It's also potentially a source
of confusion for the offerer if he offers an ICE restart about
how to interpret packets which come from the peer prior to
receiving the offer (for instance, an ICE-lite implementation
initiating a restart) as to whether they are DTLS handshake
packets or DTLS application/media packets.

I believe a simpler model would be to have tls-id's behavior match ICE
restart. I.e., the offerer decides and the answerer conforms. The
answerer's tls-id is still needed to indicate that (a) it knows about
the tls-id attribute and to do the new TLS connection and (b) address
Martin's UKS issues, but we should remove the answerer's ability to
force a new TLS connection.

[cdh4u]

Would the tls-id in the answer still have to be different from the one in the offer?

[ekr]

Yes, for @martinthomson's reasons

[cdh4u]

I personally don't have any strong feelings, if people think it's not needed, and/or that it can cause problems.

But, in any case it needs to be brought to the list, as we are talking about a relatively big change.

[rshpount]

What EKR proposes is a breaking change which will require major specification update.

The entire issue is centered around third party call control. Third party call control scenarios require either always start a new DTLS association when new offer is requested (INVTE with no SDP in SIP terms), which will match ICE behavior where ICE restart is required in such cases. This, however is inefficient since it forces a new DTLS association when it is not needed. What we proposed was that during 3pcc scenario where connection switches to a new end point and offer is requested, offer is generated with existing tls-id, and new DTLS association is created only if requested by tls-id change in the answer.

[ekr]

We seem to be simultaneously discussing this here and on the list, so I would suggest you discuss it there.