Section 2: DTLS Transport Issues

[aboba]

Section 2.2. Constructor of DtlsTransport. When a DtlsTransport is automatically constructed, the UA cannot create an internal IceTransport without a given IceOptions. So, we need RTCIceTransport on the Constructor. The RTCIceTransport should not be ‘optional’ on the constructor.

Section 2.3. DtlsTransport. When DtlsTransport is closed, calling start() will start a new session (with new key negotiations, etc.). This should be specified in the spec – for the start() method.

Section 2.3. DtlsTransport. When “error” should be fired? What we’d like to propose: If the transport is closed without either party calling stop(), the UA should fire an error event.

[aboba]

Issues above are from Shijun Sun. Another one:

When invalid remote-params as input to DtlsTransport.start(), UA should throw an “Invalid Access Exception”.

[aboba]

Section 2.2 should say: "A RTCDtlsTransport instance is optionally constructed with an RTCIceTransport object."

change: readonly attribute RTCIceTransport transport;
to: readonly attribute RTCIceTransport? transport; //defaulted to null if constructor doesn't have it.

change: void addTransport (RTCIceTransport transport, int index = null);
to: void addTransport (RTCIceTransport transport, unsigned long? index = null);
change: void setTransport (RTCIceTransport transport);
to: void setTransport (RTCIceTransport? transport = null);

[aboba]

If RTCDtlsTransport.setTransport is removed as was discussed at the June 24 ORTC CG meeting, then if RTCIceTransport is not provided within the constructor there would be no way to add it later. So it cannot be optional in the constructor. Also, the transport attribute cannot be nullable.

Should an invalid parameter to start() throw an InvalidParameter exception?

Other proposed changes seem reasonable.