RTCDtlsTransport: Effect of calling start() after start()? #146

Closed
aboba opened this Issue Aug 21, 2014 · 5 comments

Projects

None yet

4 participants

@aboba
Contributor
aboba commented Aug 21, 2014

From Shijun Sun:
What is the behavior if calling RTCDtlsTransport.start(param_2) after a valid start(param_1) call?

I see two options:

  1. start new session
  2. throw exception
@pthatcherg

Calling IceTransport.start does a restart. We could do the same for
DtlsTransport. However, I don't see a use case, and it would be more work
for the implementation. So, can we do #2 until we think of a use case?

On Thu, Aug 21, 2014 at 10:03 AM, aboba notifications@github.com wrote:

From Shijun Sun:
What is the behavior if calling RTCDtlsTransport.start(param_2) after a
valid start(param_1) call?

I see two options:

  1. start new session
  2. throw exception


Reply to this email directly or view it on GitHub
#146.

@aboba
Contributor
aboba commented Aug 21, 2014

I also do not see a use case, so approach #2 (Exception) seems fine to me.

@aboba
Contributor
aboba commented Sep 3, 2014

Proposed resolution is to add the following sentence to the definition of start in Section 2.3.2:

"If start() is called after a previous start() call, throw an InvalidState exception."

@martinthomson
Member

Or you could just be idempotent. If already started, report success.

@aboba
Contributor
aboba commented Sep 5, 2014

The issue is with calling RTCDtlsTransport.start(newRemoteParameters).- a situation in which a new negotiation would be required (since the remote parameters have changed). For that case, returning without actually restarting negotiation with the requested remote parameters is probably not a good idea.

@robin-raymond robin-raymond added the 1.1 label Sep 25, 2014
@robin-raymond robin-raymond pushed a commit to robin-raymond/ortc that referenced this issue Oct 14, 2014
Robin Raymond Address questions about RTCDtlsTransport.start(), as noted in: Issue #…
…146

Address questions about RTCRtpCodecCapability.preferredPayloadType, as noted in: Issue #147
Address questions about RTCRtpSender.setTrack() error handling, as noted in: Issue #148
Partially address 'automatic' use of scalable video coding (in RTCRtpReceiver.receive()) as noted in: Issue #149
Renamed RTCIceListener to RTCIceGatherer as noted in: Issue #150
Added text on multiplexing of STUN, TURN, DTLS and RTP/RTCP, as noted in: Issue #151
Address issue with queueing of candidate events within the RTCIceGatherer, as noted in: Issue #152
Clarify behavior of RTCRtpReceiver.getCapabilities(kind), as noted in: Issue #153
7a48e0b
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment