jiebi/CodeConvo huggingface dataset:
Code change:
The text says: "The media codecs used in older protocols do not always match those being used in WebRTC, mandating transcoding on the ingest node," I don't understand this sentence. If I use an "older protocol", e.g, RTMP, why do I need to care about WebRTC codecs?
That refers if you use RTMP for ingest and WebRTC for viewing.
rewriten the editorial in
The text says: "These protocols are much older than webrtc and lack by default some important security and resilience features provided by webrtc with minimal delay." I assume you refer to RTMP, which is mentioned in the previous Section. Doesn't RTMPS solve some of the security issues? But in general, if you want to put up WHIP against RTMP, I think you need a little more text. Also, as WHIP is supposed to be an "easy to implement" protocol, I think it would be fair to also list some of the functions NOT supported compared to e.g., RTMP. As I have mentioned before, there is no command for start the ingestion - it is assumed to have begun when the connection has been established. Also, there is no PAUSE/RESUME.
It is more referring to RTSP which lacks DTLS support. no command for start the ingestion - it is assumed to have begun when the connection has been established. Also, there is no PAUSE/RESUME. RTMP protocol was intended as an RPC mechanism between the flash player and server. It allowed to create custom apps both on client and server side, which supported a wide range of methods using AMF. However, current "RTMP protocol" implemented for ingesting is a reversed engineered version of the implementation done by the FMS and it lacks support for PAUSE/RESUME and the publication is started from the start of the RTMP connection (same as whip).
rewriten the editorial in

Related discussion:
text: its adoption in the broadcasting/streaming industry is lagging behind. <del> Currently, there is no standard protocol designed for ingesting media into a streaming service using WebRTC and so content providers still rely heavily on protocols like RTMP for doing so. These protocols are much older than WebRTC and by default lack some important security and resilience features provided by WebRTC with minimal overhead and additional latency. The media codecs used for ingestion in older protocols tend to be limited and not negotiated.  WebRTC includes support for negotiation of codecs, potentially alleviating transcoding on the ingest node (which can introduce delay and degrade media quality).  Server side transcoding that has traditionally been done to present multiple renditions in Adaptive Bit Rate Streaming (ABR) implementations can be replaced with Simulcast RFC8853 and SVC codecs that are well supported by WebRTC clients.  In addition, WebRTC clients can adjust client-side encoding parameters based on RTCP feedback to maximize encoding quality. Encryption is mandatory in WebRTC, therefore secure transport of media is implicit. </del> The IETF RTCWEB working group standardized JSEP (RFC8829), a mechanism used to control the setup, management, and teardown of a multimedia session.  It also describes how to negotiate media flows
Code change:
The text says: "The media codecs used in older protocols do not always match those being used in WebRTC, mandating transcoding on the ingest node," I don't understand this sentence. If I use an "older protocol", e.g, RTMP, why do I need to care about WebRTC codecs?
That refers if you use RTMP for ingest and WebRTC for viewing.
rewriten the editorial in
The text says: "These protocols are much older than webrtc and lack by default some important security and resilience features provided by webrtc with minimal delay." I assume you refer to RTMP, which is mentioned in the previous Section. Doesn't RTMPS solve some of the security issues? But in general, if you want to put up WHIP against RTMP, I think you need a little more text. Also, as WHIP is supposed to be an "easy to implement" protocol, I think it would be fair to also list some of the functions NOT supported compared to e.g., RTMP. As I have mentioned before, there is no command for start the ingestion - it is assumed to have begun when the connection has been established. Also, there is no PAUSE/RESUME.
It is more referring to RTSP which lacks DTLS support. no command for start the ingestion - it is assumed to have begun when the connection has been established. Also, there is no PAUSE/RESUME. RTMP protocol was intended as an RPC mechanism between the flash player and server. It allowed to create custom apps both on client and server side, which supported a wide range of methods using AMF. However, current "RTMP protocol" implemented for ingesting is a reversed engineered version of the implementation done by the FMS and it lacks support for PAUSE/RESUME and the publication is started from the start of the RTMP connection (same as whip).
rewriten the editorial in

Related discussion:
text: 4.2. <ins> 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 draft-ietf-rtcweb-gateways. </ins> In order to reduce the complexity of implementing WHIP in both clients and media servers, WHIP imposes the following restrictions regarding WebRTC usage:
Code change:
NAME ping?
Section 4.1 “The WHIP client MAY perform trickle ICE or ICE restarts ] by sending an HTTP PATCH request…” Why is there a reference to RFC8863, which specifies ICE PAC, here? In general a reference to ICE PAC is useful, because this draft allows an offer without any candidates. So maybe that reference should go at the end of: “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 it MAY only contain local candidates (or even an empty list of candidates).”
I think it was a typo.
I created a PR to fix the tricke ice reference and add the pac one as suggested.

Related discussion:
text: 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 it MAY <del> only contain local candidates (or even an empty list of candidates). </del> <ins> only contain local candidates (or even an empty list of candidates) as per RFC8863. </ins> In order to simplify the protocol, there is no support for exchanging gathered trickle candidates from Media Server ICE candidates once the
Code change:
NAME ping?
Section 4.1 “The WHIP client MAY perform trickle ICE or ICE restarts ] by sending an HTTP PATCH request…” Why is there a reference to RFC8863, which specifies ICE PAC, here? In general a reference to ICE PAC is useful, because this draft allows an offer without any candidates. So maybe that reference should go at the end of: “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 it MAY only contain local candidates (or even an empty list of candidates).”
I think it was a typo.
I created a PR to fix the tricke ice reference and add the pac one as suggested.

Related discussion:
text: candidates of the Media Server.  The Media Server MAY use ICE lite, while the WHIP client MUST implement full ICE. <del> The WHIP client MAY perform trickle ICE or ICE restarts RFC8863 by sending an 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.  When used for trickle ICE, the body of this PATCH message will contain the new ICE candidate; when used for ICE restarts, it will contain a new ICE ufrag/pwd pair. </del> <ins> The WHIP client MAY perform trickle ICE or ICE restarts as per RFC8838 by sending an 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.  When used for trickle ICE, the body of this PATCH message will contain the new ICE candidate; when used for ICE restarts, it will contain a new ICE ufrag/pwd pair. </ins> Trickle ICE and ICE restart support is OPTIONAL for a WHIP resource. If the WHIP resource supports either Trickle ICE or ICE restarts, but