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

[Christer Holmberg <[e-mail]>]

Hi,

>> 	The following issue has been discussed between myself and Sergio in:
>>
>> 	https://github.com/wish-wg/webrtc-http-ingest-protocol/issues/163
>> 
>> 	However, I bring it to the list because I think it would be useful to get 
>>          wider community input and guidance.
>> 
>> 	WHIP uses the SDP trickle-ice-sdpfrag content type for ICE restarts.
>>          However, RFC 8838 only defines usage of trickle-ice-sdpfrag for trickle ICE.
>>          With SIP, an ICE restart triggers a new SDP renegotiation.
>>  
>> 	Now, AFAIK the justification of WHIP using PATCH with trickle-ice-
>>          sdpfrag also for ICE restart (instead of POST with a new SDP offer),  is the
>>          statement in Section 3, saying that SDP renegotiations are not supported.
>>
>> 	“It is important to note that SDP renegotiations are not supported in WHIP, 
>>          meaning that no modifications to the "m=" sections can be made after the
>>          initial SDP offer/answer exchange via HTTP POST is completed and only
>>          ICE related information can be updated via HTTP PATCH requests as defined in
>>          Section 4.1.”
>> 
>>  
>> 	Q1: SDP renegotiation is more than the “m=” sections. There is also
>>          the session-level information, e.g., the “c=” section, the “o=” section etc. So,
>>          I think the text needs to talk about what INFORMATION can/cannot be
>>          updated.
> 
> Nothing can be changed except what we explicitly allowed in the 4.1. ICE
> support section.

Section 4.1 only talks about ICE support in general.

> I don't think we should make a list of what can and can't be
> changed here, especially given that some of that info has the spec in
> different RFCs which we may conflict with.

Section 3 explicitly forbids modifying "m=" sections, but does not e.g., talk about session-level information etc.

Could we simply say?

"Once the initial SDP offer/answer exchange via HTTP POST has been completed, only the ICE credentials and candidates
can be updated and renegotiated via HTTP PATCH, as defined in Section 4.1."

>> Q2: Related to Q1, the text says that ICE related information can be
>> updated. But, if the “m=” section cannot be updated, does that also mean
>> that the IP port in the host candidate cannot be updated, as that it typically
>> the port value also used in the “m=” section? Again, I think it is better to
>> explicitly describe what information can be updated.
>  
> I disagree, it would be easy to contradict what is specified on another rfcs.
> We could even be more precise and change the " and only ICE related
> information can be updated" by " and only certain ICE related information
> can be  updated"

See my reply to Q1.

>> Q3: Related to Q1 and Q2, it needs to be clear what information the
>> WHIP session can return in the PATCH response in case of an ICE restart. Can
>> the WHIP session change the port number of its host candidate? Etc.
>  
> As we are adding ICE restart in this draft, I agree that we should be more
> precise about the construction of the PATCH response. Do you have any
> suggestions? I will try to create a PR for that.

Since the WHIP client can only change certain ICE information, I guess the same could apply to the WHIP session?

Regards,

Christer