jiebi/CodeConvo huggingface dataset:
Change:
NAME could you take a look please?
The current text ignores the issue that (in the absence of OPTIONS) the offer must be sent before it is set as the local description, in order to avoid starting the ICE agent prematurely. I think we should consult an ICE specialist in order to understand what consequences that will have on connectivity.
There is already a note already covering that case. It is up to the WHIP client implementation to know which is its ICE implementation support regarding this case and choose to call setLocalDescription or not before updateConfiguration. The only case were a WHIP client is not tightly coupled with a ICE implementation is on browsers, and we already have checked that it works on all webrtc browsers.

Discussion:
specifications which may use this mechanism to configure the usage of STUN/TURN servers. <del> There are some WebRTC implementations that do not support updating the STUN/TURN server configuration after the local offer has been created as specified in RFC8829 section 4.1.18.  In order to support these clients, the WHIP endpoint MAY also include the STUN/TURN server configuration on the responses to OPTIONS request sent to the WHIP endpoint URL before the POST request is sent. </del> NOTE: Depending on the ICE Agent implementation, the WHIP client may need to call the setConfiguration method before calling the setLocalDespcription method with the local SDP offer in order to avoid having to perform an ICE restart for applying the updated STUN/ TURN server configuration on the next ICE gathering phase. <ins> There are some WebRTC implementations that do not support updating the STUN/TURN server configuration after the local offer has been created as specified in RFC8829 section 4.1.18.  In order to support these clients, the WHIP endpoint MAY also include the STUN/TURN server configuration on the responses to OPTIONS request sent to the WHIP endpoint URL before the POST request is sent.  However, this method is not NOT RECOMMENDED and if supported by the underlying WHIP Client's webrtc implementation, the WHIP Client SHOULD wait for the information to be returned by the WHIP Endpoint on the response of the HTTP POST request instead. </ins> The generation of the TURN server credentials may require performing a request to an external provider, which can both add latency to the OPTIONS request processing and increase the processing required to
Change:
NAME ping?
“The response may optionally contain the new set of ICE candidates for the Media Server and the new entity-tag correspond to the new ICE session in an ETag response header field.” Is this really meant to indicate that the new ICE candidates AND the new entity-tag are optional? I would have expected that after an ICE restart a new entity-tag is required.
The optionally only applies to the first part of, will reword it.

Discussion:
If the HTTP PATCH request results in an ICE restart, the WHIP resource SHALL return a "200 OK" with an "application/trickle-ice- sdpfrag" body containing the new ICE username fragment and password. <del> The response may optionally contain the new set of ICE candidates for the Media Server and the new entity-tag correspond to the new ICE session in an ETag response header field. </del> <ins> Also, the "200 OK" response for a sucesscull ICE restart MUST contain the new entity-tag corresponding to the new ICE session in an ETag response header field and MAY contain a new set of ICE candidates for the Media Server. </ins> If the ICE request cannot be satisfied by the WHIP resource, the resource MUST return an appropriate HTTP error code and MUST NOT
Change:
Looks good.
thank you Bernard!
from NAME 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.”
updated the PR to add MediaStream/MediaStreamTrack references

Discussion:
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 <del> 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. </del> <ins> complexity, no SDP renegotiation is supported, so no "m=" sections can be added once the initial SDP offer/answer over HTTP is completed. </ins> 4.

SHOULD include the "rtcp-mux-only" attribute in each bundled "m=" sections as per RFC8858. <del> While this version of the specification only supports, at most, a single audio and video track in a single media stream. (therefore, all "m=" sections MUST contain an "msid" attribute with the same value as per [[!RFC8830]]), 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. </del> <ins> This version of the specification only supports, at most, a single audio and video MediaStreamTrack in a single MediaStream as defined in [[!RFC8830]] and therefore, all "m=" sections MUST contain an "msid" attribute with the same value.  However, it would be possible for future revisions of this spec to allow more than a single MediaStream or MediaStreamTrack of each media kind, so 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. </ins> Furthermore, the WHIP Endpoint SHOULD NOT reject individual "m=" sections as per RFC8829 section 5.3.1 in case there is any error