Draft: draft-ietf-wish-whip

Commentary: I gave the spec a good read through and would like to propose some minor language edits as my first contribution . Most of these are straight forward such as : WebRTC not webrtc URI not uri signaling not signalling offer / answer not O / A some grammatical changes There is one somewhat significant correction here in that the header on the example WHIP endpoint reply pointed at the RFC for the extension . I believe this is incorrect and the intent is that this points at a WHIP resource . I have updated the example as such .
WebRTC intentionally does not specify a signaling transport protocol
at application level, while RTCWEB standardized the signalling
protocol itself (JSEP, SDP O/A) and everything that was going over
the wire (media, codec, encryption, ...).  This flexibility has
allowed for implementing a wide range of services.  However, those
services are typically standalone silos which don't require
interoperability with other services or leverage the existence of
tools that can communicate with them.
In the broadcasting/streaming world, the usage of hardware encoders
that would make it very simple to plug in (SDI) cables carrying raw
media, encoding it in place, and pushing it to any streaming service
or CDN ingest is ubiquitous.  Having to implement a custom signalling
transport protocol for each different webrtc services has hindered
adoption.
While some standard signalling protocols are available that can be
integrated with WebRTC, like SIP or XMPP, they are not designed to be
used in broadcasting/streaming services, and there also is no sign of
adoption in that industry.  RTSP, which is based on RTP and maybe the
closest in terms of features to webrtc, is not compatible with WebRTC
SDP offer/answer model.
In the specific case of ingest into a platform, some assumption can
be made about the server-side which simplifies the webrtc compliance
burden, as detailed in webrtc-gateway document I-D.draft-alvestrand-
rtcweb-gateways.
Allow for both ingest in traditional media platforms for extension
and ingest in webrtc end-to-end platform for lowest possible
latency.
WebRTC intentionally does not specify a signaling transport protocol
at application level, while RTCWEB standardized the signaling
protocol itself (JSEP, SDP O/A) and everything that was going over
the wire (media, codec, encryption, ...).  This flexibility has
allowed the implementation of a wide range of services.  However,
those services are typically standalone silos which don't require
interoperability with other services or leverage the existence of
tools that can communicate with them.
In the broadcasting/streaming world, the usage of hardware encoders
that make it very simple to plug in (SDI) cables carrying raw media,
encode it in place, and push it to any streaming service or CDN
ingest is already ubiquitous.  It is the adoption of a custom
signaling transport protocol for each WebRTC service has hindered
broader adoption as an ingestion protocol.
While some standard signaling protocols are available that can be
integrated with WebRTC, like SIP or XMPP, they are not designed to be
used in broadcasting/streaming services, and there also is no sign of
adoption in that industry.  RTSP, which is based on RTP and may be
the closest in terms of features to WebRTC, is not compatible with
the WebRTC SDP offer/answer model.
In the specific case of media ingestion into a streaming service,
some assumptions can be made about the server-side which simplifies
the WebRTC compliance burden, as detailed in webrtc-gateway document
I-D.draft-alvestrand-rtcweb-gateways.
Allows for both ingest in traditional media platforms and ingest
in WebRTC end-to-end platforms with the lowest possible latency.
WHIP client: WebRTC Media encoder or producer that acts as client
on the WHIP protocol and encodes and delivers the media to a
remote media server.
Media Server: WebRTC media server that establishes the media
session with the WHIP client and receives the media produced by
it.
WHIP resource: Allocated resource by the WHIP endpoint for an
ongoing ingest session that the WHIP client can send request for
altering the session (ICE operations or termination, for example).
WHIP resource URL: URL allocated to a specific media session by
the WHIP endpoint which can be used to perform operations such
terminating the session or ICE restarts.
The WebRTC-HTTP ingest protocol (WHIP) uses an HTTP POST request to
perform a single shot SDP offer/answer so an ICE/DTLS session can be
established between the encoder/media producer and the broadcasting
ingestion endpoint.
Once the ICE/DTLS session is set up, the media will flow
unidirectionally from the encoder/media producer to the broadcasting
ingestion endpoint.  In order to reduce complexity, no SDP
renegotiation is supported, so no tracks or streams can be added or
removed once the initial SDP O/A over HTTP is completed.
WHIP client: WebRTC media encoder or producer that acts as a
client of the WHIP protocol by encoding and delivering the media
to a remote media server.
WHIP endpoint URL: URL of the WHIP endpoint that will create the
WHIP resource.
Media Server: WebRTC media server or consumer that establishes the
media session with the WHIP client and receives the media produced
by it.
WHIP resource: Allocated resource by the WHIP endpoint for an
ongoing ingest session that the WHIP client can send requests for
altering the session (ICE operations or termination, for example).
WHIP resource URL: URL allocated to a specific media session by
the WHIP endpoint which can be used to perform operations such as
terminating the session or ICE restarts.
The WebRTC-HTTP ingest protocol (WHIP) uses an HTTP POST request to
perform a single shot SDP offer/answer so an ICE/DTLS session can be
established between the encoder/media producer (WHIP client) and the
broadcasting ingestion endpoint (media server).
Once the ICE/DTLS session is set up, the media will flow
unidirectionally from the encoder/media producer (WHIP client) to the
broadcasting ingestion endpoint (media server).  In order to reduce
complexity, no SDP renegotiation is supported, so no tracks or
streams can be added or removed once the initial SDP offer/answer
over HTTP is completed.
The HTTP POST request will have a content type of application/sdp and
contain the SDP offer as body.  The WHIP endpoint will generate an
SDP answer and return it on a 201 Accepted response with content type
of application/sdp and the SDP answer as body and a Location header
pointing to the newly created resource.
SDP offer SHOULD use the sendonly attribute and the SDP answer MUST
use the recvonly attribute.
Once a session is setup ICE consent freshness RFC7675 will be used to
detect abrupt disconnection and DTLS teardown for session termination
by either side.
To explicitly terminate the session, the WHIP client MUST perform an
HTTP DELETE request to the resource url returned on the Location
header of the initial HTTP POST.  Upon receiving the HTTP DELETE
request, the WHIP resource will be removed and the resources freed on
the media server, terminating the ICE and DTLS sessions.
The HTTP POST request will have a content type of application/sdp and
contain the SDP offer as the body.  The WHIP endpoint will generate
an SDP answer and return a 201 Accepted response with a content type
of application/sdp and the SDP answer as the body and a Location
header pointing to the newly created resource.
The SDP offer SHOULD use the sendonly attribute and the SDP answer
MUST use the recvonly attribute.
Once a session is setup, ICE consent freshness RFC7675 will be used
to detect abrupt disconnection and DTLS teardown for session
termination by either side.
To explicitly terminate the session, the WHIP client MUST perform an
HTTP DELETE request to the resource URL returned in the Location
header of the initial HTTP POST.  Upon receiving the HTTP DELETE
request, the WHIP resource will be removed and the resources freed on
the media server, terminating the ICE and DTLS sessions.
The initial offer by the WHIP client MAY be sent after the full ICE
gathering is complete containing the full list of ICE candidates, or
only contain local candidates or even an empty list of candidates.
The initial offer by the WHIP client MAY be sent after the full ICE
gathering is complete with the full list of ICE candidates, or only
contain local candidates or even an empty list of candidates.
The WHIP client MAY perform trickle ICE or an ICE restarts RFC8863 by
sending a HTTP PATCH request to the WHIP resource URL with a body
containing a SDP fragment with mime type "application/trickle-ice-
sdpfrag" as specified in RFC8840 with the new ice candidate or ice
ufrag/pwd for ice restarts.  A WHIP resource MAY not support either
trickle ICE (i.e.  ICE lite media servers) or ICE restart, and it
MUST return a 405 Method Not Allowed for any HTTP PATCH request.
A WHIP client receiving a 405 response for an HTTP PATCH request
SHALL not send further request for ICE trickle or restart.  If the
WHIP client gathers additional candidates (via STUN/TURN) after the
SDP offer is sent, it MUST send STUN request to the ICE candidates
received from the media server as per RFC8838 regardless if the HTTP
PATCH is supported by either the WHIP client or the WHIP resource.
The WHIP client MAY perform trickle ICE or an ICE restarts RFC8863 by
sending a HTTP PATCH request to the WHIP resource URL with a body
containing a SDP fragment with MIME type "application/trickle-ice-
sdpfrag" as specified in RFC8840 with the new ICE candidate or ICE
ufrag/pwd for ICE restarts.  A WHIP resource MAY not support trickle
ICE (i.e.  ICE lite media servers) nor ICE restart, and it MUST
return a 405 Method Not Allowed for any HTTP PATCH request.
A WHIP client receiving a 405 response for an HTTP PATCH request
SHALL not send further request for ICE trickle or restart.  If the
WHIP client gathers additional candidates (via STUN/TURN) after the
SDP offer is sent, it MUST send a STUN request to the ICE candidates
received from the media server as per RFC8838 regardless of the HTTP
PATCH supported by either the WHIP client or the WHIP resource.
WHIP endpoints and media servers MAY not be colocated on the same
server so it is possible to load balance incoming requests to
different media servers.  WHIP clients SHALL support HTTP redirection
via 307 Temporary Redirect response code.
WHIP endpoints and media servers MAY not be colocated on the same
server so it is possible to load balance incoming requests to
different media servers.  WHIP clients SHALL support HTTP redirection
via the 307 Temporary Redirect response code.
It is RECOMMENDED that broadcasting server provides an HTTP interface
for provisioning the TUNR/STUN servers url and short term credentiasl
as in I-D.draft-uberti-behave-turn-rest-00.  Note that the
authentication information or the url of this API are not related to
the WHIP enpoint URLs or authentication.
It could also be possilble to configure the STUN/TURN server URLS and
long term credentials provided by the either broadcasting service or
an external TURN provider.
Authentication and authorization is supported by the Authorization
HTTP header with a bearer token as per RFC6750.
Both simulcast and scalable video coding (including K-SVC modes) MAY
be supported by both media servers and WHIP clients and negotiated in
the SDP O/A.
It is RECOMMENDED that the broadcasting server provides an HTTP
interface for provisioning the STUN/TURN servers' URLs and short term
credentials as in I-D.draft-uberti-behave-turn-rest-00.  Note that
neither the authentication information nor the URLs of the STUN/TURN
servers are related to the WHIP endpoint.
It is also possible to configure the STUN/TURN server URLs with long
term credentials provided by either the broadcasting service or an
external TURN provider.
Authentication and authorization MAY be supported on the WHIP
endpoint and the WHIP resource by providing the Authorization HTTP
header with a bearer token as per RFC6750.
Both simulcast and scalable video coding (including K-SVC modes) MAY
be supported by both the media servers and WHIP clients through
negotiation in the SDP offer/answer.
Protocol extensions supported by the WHIP server MUST be advertised
to the WHIP client on the 201 created response to initial HTTP POST
request to the WHIP enpoint by inserting one Link header for each
extension with the extension "rel" type attribute and the uri for the
HTTP resource that will be available for receiving request related to
that extension.
Protocol extensions are optionasl for bot WHIP clients and servers.
WHIP clients MUST ignore any Link attribute with an unknown "rel"
attribute value and WHIP servers MUST not require the usage of any of
the extensions.
Protocol extensions supported by the WHIP server MUST be advertised
to the WHIP client on the 201 Created response to the initial HTTP
POST request sent to the WHIP endpoint.  The WHIP endpoint MUST
return one Link header for each extension with the extension "rel"
type attribute and the URI for the HTTP resource that will be
available for receiving requests related to that extension.
Protocol extensions are optional for both WHIP clients and servers.
WHIP clients MUST ignore any Link attribute with an unknown "rel"
attribute value and WHIP servers MUST not require the usage of any of
the extensions.
For example, taking a potential extension of server to client
communication using server sent events as specified in
https://html.spec.whatwg.org/multipage/server-sent-
events.html#server-sent-events, the url for connecting to the server
side event resource for the published stream will be returned in the
initial HTTP "201 Created" response with a "Link" header an a "rel"
attribute of "urn:ietf:params:whip:server-sent-events".
For example, taking a potential extension of server to client
communication using server sent events as specified in
https://html.spec.whatwg.org/multipage/server-sent-
events.html#server-sent-events, the URL for connecting to the server
side event resource for the published stream will be returned in the
initial HTTP "201 Created" response with a "Link" header and a "rel"
attribute of "urn:ietf:params:whip:server-sent-events".