search

w3c / ortc

ORTC Community Group specification repository (see W3C WebRTC for official standards track)
http://www.w3.org/community/ortc/
122 stars 42 forks source link

RTP header extensions may conflict on transport receiver #803

Closed robin-raymond closed 6 years ago

robin-raymond commented 6 years ago

If there are multiple receivers with different header extensions mapped to the same ID this can cause issues in interpreting of the header extension. For example, RID might be mapped to an ID which conflicts in one sender with a different header extension.

This can cause receiver.receive(...) to fail. This can also cause changing transports on a receiver can fail due to attaching to a transport that already has header extensions assigned to different meanings for other receivers.

receiver.setTransport should be async to allow the receiver to interrogate the transport to ensure no conflicts occur with header extensions.

ibc commented 6 years ago

Yep. This is like "the egg or the chicken". The RID and MID header extensions are intended for demultiplexing RTP streams but they are set at RTCRtpParameters level within the corresponding RTCRtpSender.

receiver.setTransport should be async to allow the receiver to interrogate the transport to ensure no conflicts occur with header extensions.

How is that different from just throwing an exception? "Interrogating the transport" should be sync IMHO.

robin-raymond commented 6 years ago

Not always possible in all implementations to make this synchronous.

ibc commented 6 years ago

IMHO it makes sense that this is a synchronous operation. Implementations should honor the spec and not the other way around.

robin-raymond commented 6 years ago

@ibc This isn't so easy from experience in this case. The header extensions need to be registered as a transaction against the transport to ensure they take affect as multiple transports can conflict. This can cause contention if you attempt to do this synchronously. I would have a very difficult time making this synchronous in my own code for ortclib for example. There's a reason mechanisms that need to work across multiple objects become asynchronous vs objects than can act independently without interrogation / interaction / transacting with other active objects.

ibc commented 6 years ago

This is about iterating the RTCRtpParameters of all the RTCRtpSenders and RTCRtpReceivers managed by the given transport and checking whether MID and RID values do not conflict between them. Not sure why this cannot be synchronous. I've already done this in a synchronous way.

robin-raymond commented 6 years ago

It's not enough to check if they conflict, receivers have to be registered on construction and de-registered when they detach. This can and does cause contention issues across objects. When detachment happens this has to be done asynchronously for my implementation (for a long host of reasons as a whole set of pipelines need to be torn down across objects) and if I have certain things happen synchronously then it might be possible a detachment happens after a new attachment which can cause a false failure. Maybe your implementation doesn't have this issue but I can say for 100% certainty that it would be very difficult for me to handle this case synchronously.

ibc commented 6 years ago

Fair enough.