Re: [Wish] WG Last Call for draft-ietf-wish-whip

[Bernard Aboba <[e-mail]>]

Here is my (belated) review. 

Section 1

“ While WebRTC has been very successful in a wide range of scenarios,

   its adoption in the broadcasting/streaming industry is lagging 

   behind.”

[BA] I recently saw a survey indicating that WHIP is now the second most implemented ingestion protocol, second only to RTMP.  So while this sentence may have been correct at one time, it seems out of date now.  Can we delete this sentence? 

Also, overall Section 1 seems like it could be shortened considerably by highlighting the major points. Here is my suggestion: 

“ The IETF RTCWEB working group standardized JSEP ([RFC8829]), a

   mechanism used to control the setup, management, and teardown of a
   multimedia session.  JSEP also describes how to negotiate media flows
   using the Offer/Answer Model with the Session Description Protocol
   (SDP) [RFC3264] as well as the formats for data sent over the wire
   (e.g., media types, codec parameters, and encryption).  WebRTC
   intentionally does not specify a signaling transport protocol at 

   application level. 

Unfortunately, the lack of a standardized signaling mechanism in WebRTC has been an obstacle to adoption as an ingestion protocol within the broadcast/streaming industry, where a streamlined production pipeline is taken for granted: plug in cables carrying raw media to hardware encoders, then push the encoded media to any streaming service or Content Delivery Network (CDN) ingest using an ingestion protocol.

While WebRTC can be integrated with standard signaling protocols like SIP [RFC3261] or XMPP [RFC6120], they are not designed to be used in broadcasting/streaming services and there is no sign of adoption in that industry.  RTSP [RFC7826], which is based on RTP, is not compatible with the SDP offer/answer model [RFC3264].

This document therefore proposes a simple protocol for supporting WebRTC as a media ingestion method which:

   *  Is easy to implement,

   *  Is as easy to use as popular IP-based broadcast protocols

   *  Is fully compliant with WebRTC and RTCWEB specs

   *  Allows for ingest both in traditional media platforms and in
      WebRTC end-to-end platforms with the lowest possible latency.

   *  Lowers the requirements on both hardware encoders and broadcasting
      services to support WebRTC.

   *  Is usable both in web browsers and in native encoders.”

Section 2

I do not see a definition of “track”.  I think this is important to clarify. 

Section 4.2

“  While this version of the specification only supports a single audio

   and video track, in order to ensure forward compatibility, if the
   number of audio and or video tracks or number streams is not
   supported by the WHIP Endpoint, it MUST reject the HTTP POST request
   with a "406 Not Acceptable" error response.”

[BA] Support for stereo and surround-sound is becoming increasingly popular.  Can you clarify whether this is supported in this version of the specification?  I assume it can be (e.g. it is possible to have multiple channels per track) but the lack of a definition for “track” creates some uncertainty. 

4.6.  Simulcast and scalable video coding

   Both Simulcast [RFC8853] and Scalable Video Coding (SVC), including
   K-SVC (also known as "S modes", in which multiple encodings are sent
   on the same SSRC), MAY be supported by both the Media Servers and
   WHIP clients through negotiation in the SDP offer/answer.

[BA] K-SVC and “S” modes are different.  K-SVC denotes the KEY and KEY_SHIFT modes, whereas “S” modes denote the encapsulation of multiple encodings within a single SSRC, as is supported in VP9 and AV1.   Diagrams of the various modes are included in the WebRTC-SVC specification: https://w3c.github.io/webrtc-svc/" rel="nofollow">https://w3c.github.io/webrtc-svc/

Also, SVC is *not* negotiated within Offer/Answer in WebRTC.  It is something that the encoder can just turn on.  At least for temporal modes (L1T2, L1T3) ingester support can often be taken for granted.  While the VP9 and AV1 specifications require a compliant decoder to be able to decode any mode than an encoder can encode, in practice there are VP9 and AV1 hardware decoders that cannot decode spatial scalability because they do not support spatial references (e.g. a P-frame at a higher resolution than the P or I frame that it references).

This nasty little “wrinkle” required us to define the “spatialScalability” attribute in Media Capabilities, to allow applications to discover whether a (hardware) decoder supports spatial scalability or not: 
https://www.w3.org/TR/media-capabilities/#dom-videoconfiguration-spatialscalability" dir="ltr" width="300">
https://www.w3.org/TR/media-capabilities/#dom-videoconfiguration-spatialscalability">Media Capabilities
https://www.w3.org/TR/media-capabilities/#dom-videoconfiguration-spatialscalability">w3.org
https://www.w3.org/TR/media-capabilities/#dom-videoconfiguration-spatialscalability">

Not sure if you want to get into this in the specification.  Issues are most likely to be encountered where hardware-based transcoders are used (but in that scenario, spatial scalability probably wouldn’t be relevant anyway),