- From: Philipp Hancke via GitHub <sysbot+gh@w3.org>
- Date: Tue, 21 Nov 2023 14:42:51 +0000
- To: public-webrtc-logs@w3.org
This discussion of fundamentals is orthogonal to this PR and the API it describes, no? Can we move it elsewhere? > "Early 1.0" versions of the spec (and indeed early implementations of the API for many years) worked fine without transceivers. As I recall, we introduced transceivers chiefly two reasons: 1) direction changes, and 2) stop. No. Transceivers were introduced because it turned out that with unified plan and the many m-lines it was no longer possible to treat the SDP as an opaque blob. Transceivers are baking SDP semantics into the API (which means we can never get rid of SDP) and do a *very good* job at providing a model for the SDP (I am serious! I am not happy but they do what they were supposed to do). A side effect is that you need to understand SDP semantics in order to understand the API. The direction attribute including its values is literally taken from https://www.rfc-editor.org/rfc/rfc4566#page-26 stop describes the concept rejecting a m-line from https://www.rfc-editor.org/rfc/rfc3264#section-6 The header extensions API is on the transceiver as well but header extensions can actually negotiate a direction in the SDP (albeit not universally implemented). Harald: > it deals only with preferences for receiving Thank you for pointing that out, the difference is subtle but [the sample](https://github.com/webrtc/samples/pull/1640) is now fixed to show the right semantics! -- GitHub Notification of comment by fippo Please view or discuss this issue at https://github.com/w3c/webrtc-encoded-transform/pull/186#issuecomment-1821059248 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 21 November 2023 14:42:53 UTC