8000 WebRTC updated with Extend and Capabilities by helu-milestone · Pull Request #572 · onvif/specs · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

WebRTC updated with Extend and Capabilities #572

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 5 commits into
base: development
Choose a base branch
from
Open

WebRTC updated with Extend and Capabilities #572

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
56508c9
Updated WebRTC with extend text and updated diagram
helu-milestone May 27, 2025
e694f6b
Updated WebRTC with explanation about when to use extend
helu-milestone May 27, 2025
698c5cb
Updated webRTC text based on review
helu-milestone May 28, 2025
da0d2c2
Updated register command with capabilities
helu-milestone May 28, 2025
653be7d
Update doc/WebRTC.xml
helu-milestone May 29, 2025
File filter

Filter by extension

8000 Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
83 changes: 80 additions & 3 deletions doc/WebRTC.xml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -283,9 +283,10 @@
<emphasis role="italic">client</emphasis> and a <emphasis role="italic">device</emphasis>
with the intention of establishing a WebRTC peer-to-peer connection between the
client and a device. The messages are always sent via the <emphasis>signaling
server</emphasis> called <emphasis>server</emphasis> from now on. Once a peer-to-peer
server</emphasis>, called <emphasis>server</emphasis> from now on. Once a peer-to-peer
connection has been established the connection with the server can be dropped without
affecting the peer-to-peer connection.</para>
<para>A WebRTC signaling server may enforce expiration on active sessions by using the ExpiryTime property of the connect command. In such scenarios, the client shall maintain the connection with the signaling <emphasis>server</emphasis> and send extend command periodically before the session expires.</para>
<figure xml:id="_Ref493258797">
<title>Signaling flow sequence diagram</title>
<mediaobject>
Expand Down Expand Up @@ -347,7 +348,37 @@
</tgroup>
</table>
</para>
<para>The following sections specify the parameters of the individual commands.</para>
<section xml:id="section_capabilities">
<title>Session Capabilities</title>
<para>When calling connect command, an optional parameter called capabilities may be returned. The capabilities parameter will inform the client of the functionality available in the session. Below we list the possible capabilities</para>
<table frame="all">
<title>Capabilities</title>
<tgroup cols="2">
<colspec colname="c1" colnum="1" colwidth="2.0*"/>
<colspec colname="c2" colnum="2" colwidth="8.0*"/>
<thead>
<row>
<entry><para>Capability</para></entry>
<entry><para>Functionality</para></entry>
</row>
</thead>
<tbody>
<row>
<entry><para>subProtocols</para></entry>
<entry><para>SubProtocols are supported, read section section <xref linkend="section_data_channels"/>. As
SubProtocols was added before capabilities, some implementation may support this
without it being in capabilities. Support for this can be seen by the invite
command received.</para></entry>
</row>
<row>
<entry><para>extend</para></entry>
<entry><para>Connect command will return an expiry time parameter. It is possible to call extend command
before the expiry time ends to extend the session. </para></entry>
</row>
</tbody>
</tgroup>
</table>
</section>
<section xml:id="section_register">
<title>register</title>
<para> A signaling server shall expect this command to be sent once before any other command
Expand All @@ -363,6 +394,10 @@
<para role="text">The unique ID of the device or client.</para>
<para role="param">name optional [string]</para>
<para role="text">The human readable name of the device or client.</para>
<para role="param">capabilities optional [string]</para>
<para role="text">Capabilities of the device. This should only be used by the device and
the possible values can be found in the section <xref linkend="section_capabilities"
/>.</para>
</listitem>
</varlistentry>
<varlistentry>
Expand Down Expand Up @@ -408,6 +443,11 @@
<para role="text">The ID assigned by the signaling server to the session. </para>
<para role="param">iceServers optional unbounded [RTCIceServer]</para>
<para role="text">List of STUN and TURN servers to be used. </para>
<para role="param">expiryTimeSeconds optional [integer]</para>
<para role="text">Time in seconds before the session ends. If this is returned, the
extend command is also supported.</para>
<para role="param">capabilities optional [string[]]</para>
<para role="text">List of capabilities supported for this session.</para>
</listitem>
</varlistentry>
<varlistentry>
Expand Down Expand Up @@ -510,8 +550,45 @@
<para>If everything works as it should, a peer-to-peer WebRTC session can be set up between
client and device. After the session has been established the client can terminate the
WebSocket session to the signaling server and the peer-to-peer connection will not be
affected.</para>
affected. The only reason to keep the connection to the server is if the client needs to extend the session.</para>
</section>
<section xml:id="section_extend">
<title>extend</title>
<para>This command updates a session if more time is required. If an expiryTime is given
during the connect command response, the session will timeout. It is possible to request
an extension by sending a new authorization token and an expiryTime to the signaling
server.</para>
<variablelist role="op">
<varlistentry>
<term>request</term>
<listitem>
<para role="param">session [string]</para>
<para role="text">The ID assigned by the signaling server to the session. </para>
<para role="param">authorization optional [string]</para>
<para role="text">Access token that authorizes the client.</para>
<para role="param">expiryTimeSeconds optional [integer]</para>
<para role="text">Requested time in seconds to extend the session. If not filled, the
signaling server will extend with its default value.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>response</term>
<listitem>
<para role="param">expiryTimeSeconds [integer]</para>
<para role="text">The time in seconds the session has been extended.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>faults</term>
<listitem>
<para role="param">401 Authorization failed</para>
<para role="text">The authorization token cannot be verified, does not include the required claims, or has expired.</para>
<para role="param">403 Forbidden</para>
<para role="text">The client is not authorized to connect to the provided peer.</para>
</listitem>
</varlistentry>
</variablelist>
</section>
<section xml:id="section_error_notification">
<title>error</title>
<para>An ONVIF compliant signaling server, device and client shall support sending or receiving notifications signaling that an error has occurred.</para>
Expand Down
Loading
0