Steve, Taylor: Is this correct that senders/receivers/transceivers must be destroyed on the webrtc signaling thread, or does it not matter what thread Stop() is run on when there are no other references to the object?

Modifying internal states wouldn't matter since there are no other references that could try to access them concurrently. My concern is if...
- Stopping a sender/receiver/transceiver invokes other objects methods expected to be run on the signaling thread, or
- A blocking invoke is called to another thread and while waiting the "current thread" executes tasks while waiting (this might be unexpected if enqueued main thread tasks occur during releasing a reference to a sender/recevier/transceiver).

Just want to check what the assumptions are about sender/receiver/transceiver destructors.

To clarify, the concern is if the RTCRtpSenderInternal/RTCRtpReceiverInternal's reference to the webrtc object was the last reference and thus the destructor of the webrtc object is performed on the main thread instead of the webrtc signaling thread, despite normally all operations for the object are performed on the webrtc signaling thread (either by explicitly doing PostTask or by invoking its methods on a PROXY that does the thread jump for you).

The destructors for API objects are proxied to the signaling thread just like all the other methods, so you shouldn't end up with any inconsistency on the WebRTC side. But you will end up with a blocking thread hop if destroying the object from a non-signaling thread, which may not be what you want.

See:
https://codesearch.chromium.org/chromium/src/third_party/webrtc/api/rtpsenderinterface.h?l=72
https://codesearch.chromium.org/chromium/src/third_party/webrtc/api/proxy.h?l=392

Oh cool, thanks! Closing this then :)

Making blocking calls main thread -> webrtc signaling thread is OK and happens by all the sync APIs already. Blocking in the other direction though would be deadlock prone.