Re: [webrtc-pc] Investigate stopping SRD and createAnswer

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