New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

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

Comments

Projects
None yet
4 participants
@aboba
Copy link
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

This comment has been minimized.

Copy link

pthatcherg commented Aug 21, 2014

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

This comment has been minimized.

Copy link
Contributor

aboba commented Aug 21, 2014

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

@aboba

This comment has been minimized.

Copy link
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

This comment has been minimized.

Copy link
Member

martinthomson commented Sep 3, 2014

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

@aboba

This comment has been minimized.

Copy link
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 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 w…
…3c#146

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