Re: [Wish] New draft version draft-murillo-whip-01

[Adam Roach <[e-mail]>]

Thanks for the new version, Sergio!

I apologize for being somewhat absent since our March meeting. I had a 
partially-typed-up summary of issues and resolutions started, but had to 
work on some different priorities for a couple of months. I'll go over 
the items that I had notes for from our last set of conversations below, 
along with comments and proposals. In general, I really like all of the 
changes to the draft.

----

Item 1: SVC and Simulcast. There are basically three questions here: (1) 
does the protocol need to support SVC and simulcast; and (2) are clients 
required to support SVC and simulcast, and (3) are servers required to 
support SC and simulcast.

My suggestion for a path forward is:

- Yes, the protocol needs to support these features, and will 
informatively cite RFC 8853 and RFC 6190 as the means for doing so.

- No, clients are not required to support these mechanisms, and will use 
the procedures in RFC 8853 §5.3 and RFC 6190 §7.2.2 to negotiate whether 
they will do so.

- No, servers are not required to support these mechanisms, and will use 
the same procedures as clients to negotiate their support.

----

Item 2: Signaling within a session

The new proposal in the document sends the initial offer in a POST, and 
the server replies with a 201 that contains an answer in the body, and 
contains a link corresponding to the created session in a "Location" 
header field. I've poked around and convinced myself that this is a 
perfectly good use of 201, and that it gets the O/A exchange completed 
in a single transaction, and so I support the approach.

----

Item 3: ICE Trickle & Restart

The new proposal in the document specifies the use of PATCH with 
application/sdpfrag for both trickle and restart.

I really like the ability for the client to initiate restart, BTW, as it 
allows for transition between, e.g., mobile networks and WiFi for mobile 
clients, so this is a very important addition for me.

This proposed mechanism looks perfectly fine to me, although it comes 
with the caveat that this approach only allows the client to trickle 
candidates, and only allows the client to request an ICE restart.

For the trickle case, I think this is okay: in the vast majority of the 
cases, the server will not need to gather candidates and will simply be 
using host candidates. Even in the unlikely case that the server needs 
to gather candidates, this approach at least allows client and server 
collection to take place in parallel.

For the restart case, this requires the client to be completely 
responsible for detecting and repairing failed ICE connections. Since 
there is no media flowing from the server to the client, this means that 
the client will need to wait some multiple of the RTCP transmission 
interval before it can determine that the connection is no longer 
working -- in practice, this means it will take on the order of 5 to 20 
seconds to perform such detection and trigger a restart. This opens up a 
number of options:

(a) Live with this situation
(b) Specify something at the media level, such as a faster cadence for 
RTCP RR packet transmission from the network to the client so detection 
can take place faster
(c) Introduce a two-way channel for server-to-client communications

I gather that (c) remains unpopular due to its complexity. I'm okay with 
both (a) and (b), with a slight preference for something along the lines 
of (b) -- largely because users will consider the system to be 
completely failed long before client detection if we go with (a).

----

Item 4: Session Termination

The current draft supports this through the use of a DELETE message sent 
to the session endpoint. This approach seems quite sensible, and it 
allows the signaling layer to perform swift resource cleanup in the 
sunny-day case.

As with the ICE signaling above, this approach means that servers cannot 
initiate session termination on the signaling layer. I would propose 
that we add explicit text that specifies that network-initiated teardown 
can be performed by the network sending RTCP BYE packet(s) to the 
client. The client would be responsible for then initiating a DELETE 
operation on the signaling layer (which gives the network confirmation 
that the client is aware of the session termination, and has had the 
opportunity to notify the user).

----

Item 5: Heartbeating

This proposal does not include any means of signaling-level detection of 
client-side session failure (e.g., the client loses a network connection 
or crashes). Based on previous conversations about the intention of 
media channels potentially surviving a signaling-level failure, I gather 
that this is considered a feature rather than an omission.

After some internal discussion, I'm okay with this, even if it isn't my 
preferred approach. However, if the idea here is that media can survive 
independently of session state, then I'd like to also see a (required) 
client-to-network RTCP BYE packet sent whenever a session is terminated. 
I propose that this would happen in addition to the DELETE operation, 
not instead of it.

----

Item 6: Extensibility

This proposal does not have any defined extension points. The operations 
performed on the session resource are mapped onto HTTP methods, and the 
currently proposed methods have a good semantic match to the operations 
that they correspond to. What I would propose is:

(1) The base WHIP document does not address extensibility except for a 
statement that GET operations on the created resource URL (the one that 
we get in the "Location" header field) are reserved for future 
extensibility (this means that unextended servers will need to return a 
405 response to GET on the resource);

(2) Separate from the specification of the base WHIP document, we create 
a new document that discusses how to use GET to bootstrap protocol 
extensions. I have ideas about how to do this, but would like to make 
progress on the core protocol before we start those discussions.

/a

On 5/19/21 14:43, Sergio Garcia Murillo wrote:
> Hi all,
>
> I have just published a new version of the whip draft ( 
> https://datatracker.ietf.org/doc/html/draft-murillo-whip-01) with the 
> updated I outlined in a previous email a while back:
>
> - Return a resource URL in the response to the HTTP POST with the SDP O/A.
> - Allow trickle ICE and ICE restarts via HTTP PATCH with an 
> application/trickle-ice-sdpfrag 
> <https://www.iana.org/assignments/media-types/application/trickle-ice-sdpfrag> body 
> to the resource URL.
> - Allow to explicitly terminate the session by the WHIP client by 
> sending a HTTP DELETE to the resource URL.
>
> Best regards
> Sergio
>