You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This would be a good scenario to return a promise that resolves once all the changes have been applied. Then it is possible to do this:
awaittransceiver.transport.iceTransport.setSelectedCandidatePair(foo);constbar=transceiver.transport.iceTransport.getSelectedCandidatePair();// foo and bar now match
The text was updated successfully, but these errors were encountered:
I'm supportive of a promise. Even though the following might seem to suffice:
transceiver.transport.iceTransport.setSelectedCandidatePair(foo);awaitnewPromise(r=>transceiver.transport.iceTransport.selectedcandidatepairchange=r);constbar=transceiver.transport.iceTransport.getSelectedCandidatePair();// foo and bar now match
...it risks a race with the ICE agent once in a while if the method is called when a task is already queued to fire the event.
This would be a good scenario to return a promise that resolves once all the changes have been applied
UNLESS we elide firing selectedcandidatepairchange from the method — WebRTC has some precedent of not firing events on JS from JS's own actions, whether that was a good decision or not has been questioned — then we need to nail down the order: whether the event fires before or after the promise resolves.
The setSelectedCandidatePair method in § 9. RTCIceTransport extensions causes the selected candidate pair to change asynchronously.
This has several side-effects:
This would be a good scenario to return a promise that resolves once all the changes have been applied. Then it is possible to do this:
The text was updated successfully, but these errors were encountered: