WebRTC data channels proposal #480

tomasz-zajac · 2024-10-10T12:31:02Z

Adds WebRTC data channel usage specification and defines subprotocol for streaming XML metadata.

doc/WebRTC.xml

kieran242 · 2024-10-23T12:02:27Z

doc/WebRTC.xml

+          <personname>Tomasz Zajac</personname>
+        </author>
+        <revremark>Added data channels.</revremark>
+      </revision>


Hi Tomasz,
just want to highlight these lines as they specify at the start of this document that the use of Data Channels are is outside of the scope of this version of the specification.

Can I please ask you update the same also. I have reviewed the content and was going to approve the same but for these sentences.

specs/doc/WebRTC.xml

Lines 66 to 68 in 94b5e2c

<para> Sending event and analytics metadata as well as PTZ and other commands via WebRTC

datachannels is outside of the scope of this version of the specifcation. Similar future

versions of the specification may address a directory protocol to query organizations,

Thank you Kieran, I have updated this paragraph and also removed mentions of directory protocol, which I believe is no longer valid.

bsriramprasad · 2024-10-23T12:33:29Z

doc/WebRTC.xml

-Server -> Client: { "method": "invite", "params": {"session": "s1", "offer": "SDP..."}, "id":3}
-Client -> Server: { "result": {"answer": "SDP..."}, "id": 3}
-  Server -> Device: { "result": {"answer": "SDP..."}, "id": 3}
+Device -> Server: { "method": "invite", "params": {"session": "s1", "offer": "SDP...", 


As per the example flow, it seems dataChannelSubprotocols offer/response is outside of SDP but as part of INVITE transaction.

But the specification text in Section Enabling data channels has the text as quoted

"it shall signal this in the SDP offer of the invite method. If the client supports data channels and intends to use them during the WebRTC session, it shall signal this in the SDP answer."

May I suggest text should say

it shall signal this as part of the invite method. If the client supports data channels and intends to use them during the WebRTC session, it shall signal this in the invite response along with SDP.

There are two levels of negotiation:

First is standard WebRTC datachannel negotiation, which is part of the SDP offer/answer. This is required for WebRTC clients to enable data channels in the session.

Second is our ONVIF protocols negotiation, which is required to enable specific ONVIF subprotocols and they are not part of the SDP, but instead INVITE request-answer.

Specification is not very clear about this 2-level negotiation, from my understanding the current example flow seems to cover/represent level-2 of negotiation process in INVITE, Would it be possible to add some example for the level-1 negotiation in SDP offer/answer? Or is that kind of covered in WebRTC RFC?

This is a standard way of enabling data channels covered by WebRTC W3C specs/RFCs and it usually involves calling createDataChannel() on PeerConnection object before SDP is exchanged. In my opinion the first paragraph is sufficient, it avoids referring to specific WebRTC APIs on how this can be achieved, which may be implementation specific.

bsriramprasad · 2024-10-23T12:44:32Z

doc/WebRTC.xml

+            <para>If the device supports WebRTC data channels, it shall signal this in the SDP offer 
+              of the invite method. If the client supports data channels and intends to use them during 
+              the WebRTC session, it shall signal this in the SDP answer.</para>
+            <para>ONVIF defines data channel subprotocol names starting with the “vnd.onvif” prefix. 


ONVIF defined data channel subprotocol names shall have “vnd.onvif” prefix. (start and prefix words add redundancy)

Rephrased as suggested

bsriramprasad · 2024-10-23T12:48:01Z

doc/WebRTC.xml

+              the WebRTC session, it shall signal this in the SDP answer.</para>
+            <para>ONVIF defines data channel subprotocol names starting with the “vnd.onvif” prefix. 
+              Usage of this prefix is restricted to ONVIF-defined subprotocols only.</para>
+            <para>Before creating and using any data channel subprotocol, the device and client need 


Suggested Text

Before creation and usage of any data channel subprotocol, the device and client shall exchange a list of allowed data channel subprotocols in the invite method.

Rephrased as suggested

bsriramprasad · 2024-10-23T13:42:18Z

doc/WebRTC.xml

+            <para>At any time after obtaining a WebRTC connection, a client may request enabling a 
+              pre-negotiated data channel subprotocol by creating a new data channel with the specified 
+              subprotocol identifier. This triggers a new data channel event on the device, which shall 
+              enable the requested data channel subprotocol only after ensuring it was negotiated during 


This triggers a new data channel event on the device, which shall enable the requested data channel subprotocol only after ensuring it was negotiated during the SDP exchange.

For me this whole text seems to be an implementation (may be part of a library) detail and we should discuss if this has to be in the specification?

Agree this sentence reflects a behavior of most WebRTC stacks implementation, however I added it with an intention to help understanding the flow of events between client requesting a data channel and device reacting to it. We can discuss if we want to keep it or not.

I would recommend to remove the same to avoid ambiguity of specification vs additional implementation related information, let's hear from WG too for their feedback.

kieran242

Just a single question. Not a blocker at the moment so approving.

kieran242 · 2024-11-04T10:02:09Z

doc/WebRTC.xml

-      datachannels is outside of the scope of this version of the specifcation. Similar future
-      versions of the specification may address a directory protocol to query organizations,
-      devices and profiles. </para>
+    <para>Sending PTZ and other commands via WebRTC datachannels is outside of the scope of this 


I know that there was discussion on the Uplink allowing PTZ communication via SOAP requests across the HTTP/2 Backchannel or WebSocket. In this context a Client and Device are making a Peer To Peer connection via WebRTC and that device may be a PTZ Camera and should this spec not allow the client to perform PTZ over the WebRTC backchannel.

Is there reasons why this is not updated as part of the Spec or are you only focusing on Metadata?

My initial intention was to include SOAP commands over data channel as well, however during last F2F meeting there was no interest from the client side to standardize it. We can revisit this again and if there is any vendor wishing to prototype this on the client side, I will add it.

HansBusch · 2024-11-11T15:41:48Z

doc/WebRTC.xml

+          <para><emphasis role="bold">Subprotocol identifier</emphasis>: vnd.onvif.metadata+gzip</para>
+            <para>The Metadata data channel subprotocol enables streaming XML Metadata over WebRTC data 
+              channels. Only GZIP compression is supported; uncompressed XML Metadata is not supported.</para>
+            <para>A device shall use the MetadataConfiguration from the media streaming profile selected 


Suggest to rephrase to positive requirement statement:

An ONVIF compliant device supporting streaming of metadata shall support gzip compressed metadata as signaled via the subprotocol vnd.onvif.metadata+gzip.

This automatically implies that there is no guarantee for devices supporting uncompressed transmission.

Rephrased as suggested

kieran242 · 2024-12-03T12:49:55Z

Re-reviewed the latest updates. Already Approved and happy with latest changes.

jcadev · 2024-12-05T13:00:29Z

doc/WebRTC.xml

+            <para>At any time after obtaining a WebRTC connection, a client may start using a data 
+              channel subprotocol by creating a new data channel with the specified subprotocol 
+              identifier. When a new data channel event is triggered on a device, the device should 
+              enable the relevant data channel subprotocol.


If a subprotocol is attempted to be used by a client, but is not allowed (as per the initial handshakes), what should the device do? And how to verify in a test tool that the refusal works as expected? If the data channel remains open, but no data is sent by the device, should the verification step involve some kind of timeout limit before the test passes? It would be cleaner and more direct if the device instead actively closes the data channel? Or simply closes the whole peer-to-peer session?

I think closing the data channel explicitly by the device makes most sense, as the client will also get the feedback. I will add such requirement if that's OK for everyone.

fine with me. And again it's no big deal, just thought it could simplify verification

@tomasz-zajac I am also happy with the update you proposed to @jcadev

@jcadev Updated now

tomasz-zajac added enhancement New feature or request Prototyping 25.06 labels Oct 10, 2024

jflevesque-genetec reviewed Oct 10, 2024

View reviewed changes

doc/WebRTC.xml Outdated Show resolved Hide resolved

doc/WebRTC.xml Outdated Show resolved Hide resolved

jflevesque-genetec approved these changes Oct 22, 2024

View reviewed changes

kieran242 reviewed Oct 23, 2024

View reviewed changes

bsriramprasad reviewed Oct 23, 2024

View reviewed changes

tomasz-zajac force-pushed the datachannels branch from d550557 to 92ef0f6 Compare October 31, 2024 12:14

kieran242 approved these changes Nov 4, 2024

View reviewed changes

HansBusch reviewed Nov 11, 2024

View reviewed changes

jcadev reviewed Dec 5, 2024

View reviewed changes

Tomasz Zajac added 6 commits January 7, 2025 14:32

Initial proposal for WebRTC data channels

e7a8cdc

Address review suggestions

d0d81c0

Address more PR issues

c15886c

Address latest issues

eda16cc

Renamed json field

8319fb8

Explicit close of non-negotiated subprotocols

e0f5b25

tomasz-zajac force-pushed the datachannels branch from 2580c97 to e0f5b25 Compare January 7, 2025 13:34

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

WebRTC data channels proposal #480

WebRTC data channels proposal #480

tomasz-zajac commented Oct 10, 2024

kieran242 Oct 23, 2024

tomasz-zajac Oct 31, 2024

bsriramprasad Oct 23, 2024

tomasz-zajac Oct 31, 2024

bsriramprasad Nov 4, 2024

tomasz-zajac Nov 4, 2024

bsriramprasad Oct 23, 2024

tomasz-zajac Oct 31, 2024

bsriramprasad Oct 23, 2024 •

edited

Loading

tomasz-zajac Oct 31, 2024

bsriramprasad Oct 23, 2024

tomasz-zajac Oct 31, 2024

bsriramprasad Nov 4, 2024 •

edited

Loading

tomasz-zajac Nov 12, 2024

kieran242 left a comment

kieran242 Nov 4, 2024

tomasz-zajac Nov 6, 2024

HansBusch Nov 11, 2024 •

edited

Loading

tomasz-zajac Nov 12, 2024

kieran242 commented Dec 3, 2024

jcadev Dec 5, 2024

tomasz-zajac Dec 5, 2024

jcadev Dec 5, 2024

kieran242 Dec 16, 2024

tomasz-zajac Jan 7, 2025

	<para> Sending event and analytics metadata as well as PTZ and other commands via WebRTC
	datachannels is outside of the scope of this version of the specifcation. Similar future
	versions of the specification may address a directory protocol to query organizations,

WebRTC data channels proposal #480

Are you sure you want to change the base?

WebRTC data channels proposal #480

Conversation

tomasz-zajac commented Oct 10, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bsriramprasad Oct 23, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bsriramprasad Nov 4, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kieran242 left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

HansBusch Nov 11, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kieran242 commented Dec 3, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bsriramprasad Oct 23, 2024 •

edited

Loading

bsriramprasad Nov 4, 2024 •

edited

Loading

HansBusch Nov 11, 2024 •

edited

Loading