The transport-cc tests in the sdp_unittests can be re-enabled in this landing. I have been looking through the webrtc native library code. It looks like it is implemented there as Sergio has said (as far as I can see). Does anyone implement this differently? Each stream has a "Transport" object and we could potentially teach lib webrtc to key on some type of transport ID. Right now the AudioConduit and VideoConduit act as a webrtc::Transport and would need to be aware of their bundle or transport ID. These changes would be large enough I think that optimally we would want to implement them upstream and cherry pick them back. This would have the upshot of fixing for every one the case where everything isn't in a single bundle. :bwc signaling thoughts? :dminor uplift / merge thoughts?
Bug 1606823 Comment 5 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
The transport-cc tests in the sdp_unittests can be re-enabled in this landing. I can provide this patch. I have been looking through the webrtc native library code. It looks like it is implemented there as Sergio has said (as far as I can see). Does anyone implement this differently? Each stream has a "Transport" object and we could potentially teach lib webrtc to key on some type of transport ID. Right now the AudioConduit and VideoConduit act as a webrtc::Transport and would need to be aware of their bundle or transport ID. These changes would be large enough I think that optimally we would want to implement them upstream and cherry pick them back. This would have the upshot of fixing for every one the case where everything isn't in a single bundle. :bwc signaling thoughts? :dminor uplift / merge thoughts?
The transport-cc tests in the sdp_unittests can be re-enabled in this landing. I can provide this patch, though further work may be done to get them to pass as expected. I have been looking through the webrtc native library code. It looks like it is implemented there as Sergio has said (as far as I can see). Does anyone implement this differently? Each stream has a "Transport" object and we could potentially teach lib webrtc to key on some type of transport ID. Right now the AudioConduit and VideoConduit act as a webrtc::Transport and would need to be aware of their bundle or transport ID. These changes would be large enough I think that optimally we would want to implement them upstream and cherry pick them back. This would have the upshot of fixing for every one the case where everything isn't in a single bundle. :bwc signaling thoughts? :dminor uplift / merge thoughts?