- From: henbos via GitHub <sysbot+gh@w3.org>
- Date: Thu, 05 Jul 2018 11:13:03 +0000
- To: public-webrtc-logs@w3.org
I need to discuss this further with you guys, there's things I don't understand yet. Me wrapping my head around bundling: Bundling is defined in [sdp-bundle-negotiation](https://tools.ietf.org/html/draft-ietf-mmusic-sdp-bundle-negotiation-52), JSEP uses a single bundle group/transport for bundled m= sections ([jsep#4.1.1](https://tools.ietf.org/html/draft-ietf-rtcweb-jsep-24#section-4.1.1)), but can have multiple transports for non-bundled m= sections. - `balanced`: the first transceiver (m= section) _of each type_ (audio/video/application) defines the transport parameters, all subsequent transceivers are bundle-only (bundled with the first one). Non-bundle-aware endpoints would still be able to send & receive 1 audio, 1 video and 1 application. - `max-compat`: all transceivers (m= sections) define their own transport parameters. So one transport per transceiver? - `max-bundle`: the first transceiver (m= section) is the only one that defines transport parameters, all subsequent transceivers regardless of type are bundle-only. Non-bundle-aware endpoints would only be able to send & receive 1 audio, 1 video OR 1 application: the first one. Then there is the "offerer tagged m= section", which is the m= section whose BUNDLE attributes apply to all other m= sections within that bundle group. **Questions due to my lack of understanding**: Q1. What are BUNDLE attributes? Q2. Is "offerer tagged" different from which transceiver defines transport parameters? Can a bundle-only m= section be the "offerer tagged" m= section? Rejecting the [offerer tagged m= section requires rejecting all m= section](https://tools.ietf.org/html/draft-ietf-mmusic-sdp-bundle-negotiation-52#section-7.3.3). This may imply: 1. The application is interested in knowing which transceiver (m= section) is "offerer tagged". 2. The application is interested in controlling which transceiver (m = section) is "offerer tagged". 3. The application is interested in knowing which transceivers are bundled. Today this can be controlled, and thus deduced from, the bundle-policy passed at construction. Exposing the bundle groups as a set of transceivers would make this a whole lot more clear though. And possibly, 4. Would it be worth considering being able to control bundling on a per transceiver basis? Including which one is "offerer tagged"? To me bundling seems roughly equivalent to "do the transceivers belong to the same transport?". Does RTCRtpTransceiver.getTransport()/setTransport() make sense? -- GitHub Notification of comment by henbos Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/1919#issuecomment-402689117 using your GitHub account
Received on Thursday, 5 July 2018 11:13:07 UTC