Always negotiate datachannels #242
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -1494,6 +1494,74 @@ <h3>Modifications to existing procedures</h3> | |
| </p> | ||
| </section> | ||
| </section> | ||
| <section id="always-negotiating-datachannels"> | ||
| <h2>Always negotiating data channels</h2> | ||
| <section id="always-negotiating-datachannels-configuration"> | ||
| <h3> | ||
| {{RTCConfiguration}} extensions | ||
| </h3> | ||
| <p> | ||
| {{RTCConfiguration/alwaysNegotiateDataChannels}} defines a way for the application | ||
| to negotiate data channels in the SDP offer before creating a datachannel. | ||
| This also negotiates the data m= section before any audio or video m sections and | ||
| uses it as the "offerer-tagged m= section" for [[BUNDLE]]. | ||
| </p> | ||
| <pre class="idl">partial dictionary RTCConfiguration { | ||
| boolean alwaysNegotiateDataChannels = false; | ||
| };</pre> | ||
| <section> | ||
| <h2> | ||
| Dictionary {{RTCConfiguration}} Members | ||
| </h2> | ||
| <dl data-link-for="RTCConfiguration" data-dfn-for="RTCConfiguration" class="dictionary-members"> | ||
| <dt> | ||
| <dfn data-idl="">alwaysNegotiateDataChannels</dfn> of type <span class="idlMemberType">boolean</span> | ||
| </dt> | ||
| <dd> | ||
| <p> | ||
| Specifies whether the application prefers to always negotiate data channels in the initial SDP offer. | ||
| </p> | ||
| </dd> | ||
| </dl> | ||
| </section> | ||
| </section> | ||
| <section id="always-negotiating-datachannels-negotiationneeded-extensions"> | ||
| <h3> | ||
| Modifications to existing procedures | ||
| </h3> | ||
| <p> | ||
| In the steps to call the {{RTCPeerConnection/createDataChannel()}} method replace | ||
| "If channel is the first RTCDataChannel created on connection | ||
| update the negotiation-needed flag for connection" | ||
| with | ||
| "If channel is the first RTCDataChannel created on connection | ||
| and {{RTCPeerConnection/[[SctpTransport]]}} is null | ||
| update the negotiation-needed flag for connection". | ||
| </p> | ||
| </section> | ||
| <section id="always-negotiating-datachannels-interface-extensions"> | ||
| <h3> | ||
| JSEP modifications | ||
| </h3> | ||
| <p> | ||
| In the PeerConnection's Constructor in [[RTCWEB-JSEP]] section 4.1.1, add | ||
| "The application can specify whether it prefers to always negotiate data channels"</li> | ||
| </p> | ||
| <p> | ||
| In the algorithms for generating initial offers in [[RTCWEB-JSEP]] section 5.2.1, insert | ||
| "If the application prefers to always negotiate data channels, a m=section MUST be generated for data with fields set as described below." | ||
| before | ||
| "An m= section is generated for each RtpTransceiver that has been added to the PeerConnection, [...]". | ||
| </p> | ||
| <p> | ||
| In the algorithms for generating initial offers in [[RTCWEB-JSEP]] section 5.2.1, | ||
| replace | ||
| "Lastly, if a data channel has been created, a m= section MUST be generated for data" | ||
| with | ||
| "Lastly, if a data channel has been created and no m=section has been generated for data, a m= section MUST be generated for data". | ||
| </p> | ||
|
Comment on lines
+1556
to
+1562
Member
There was a problem hiding this comment. Can we add a note somewhere to clarify this changes the m-line order? As presented, this effect and its benefit wrt BUNDLE seems important to include as a reason why someone may want to use this API
Contributor
Author
There was a problem hiding this comment. Added, don't forget to squash (or I can squash) There was a problem hiding this comment. If we're going to note the "bundle-tag rejection trap avoidance" benefit, we might also want to mention that this benefit only applies with bundlePolicy=="max-bundle" (for "max-compat" the problem does not exist in the first place, and for "balanced" it won't help).
Contributor
Author
There was a problem hiding this comment. for balanced it would help since (surprise!) if you reject the bundle-tagged m-line you can still not move to the next per https://datatracker.ietf.org/doc/html/rfc8843#section-7.3.3 ?
There was a problem hiding this comment. I'm not sure I understand. If it is in a group all by itself, (which is what "balanced" says to do, sort of, it's worded poorly), rejecting it destroys that transport, but since nothing else is in there it's fine. On the other side, if you have multiple m=audio, those will share a transport, but rejecting that bundle tag still messes things up; it's not the first m-section overall, but it still can destroy a transport and bring down everything bundled with it.
Contributor
Author
There was a problem hiding this comment. https://jsfiddle.net/fippo/5y6ag2Lw/1/-- I don't see separate bundle groups with balanced? (nor do I see the second audio m-line marked as bundle-only) Either way, do we agree this is cheap and solves a (max-bundle) headache without overpromising? |
||
| </section> | ||
| </section> | ||
| <section class="informative"> | ||
| <h2>Event summary</h2> | ||
| <p> | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@docfaraday what can we expect wrt rtcweb-wg/jsep#1039 here? What's next steps?