- From: Lorenzo Miniero via GitHub <sysbot+gh@w3.org>
- Date: Fri, 01 Mar 2019 10:18:13 +0000
- To: public-webrtc-logs@w3.org
@fippo that's true in a generic SFU that has control over all the aspects of the media routing, which unfortunately is not my case. The SFU part in my case is a module, so the media routing and the WebRTC termination part are separated, and the server won't know where media will go to or come from. As such, there could be sendrecv connections, where accepting the extensions means accepting them in all directions: since the source of the media may be a different PeerConnection with completely different MID mappings, I might end up sending the user an RTP packet with mid=x where it's expecting mid=y. For this reason, at the moment I'm rejecting it on the way in too, and just rely on SSRC. I know this isn't really a spec issue, or an issue any of you should be really be bothered about, but it was just to clarify that saying "that's what SFUs should do" may not be practical in some cases. I guess eventually I'll have to bite the bullet and just always accept the mid extension, and generate my own extension on the way out (which I'd rather not do for performance reason but whatever). -- GitHub Notification of comment by lminiero Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/1174#issuecomment-468616065 using your GitHub account
Received on Friday, 1 March 2019 10:18:14 UTC