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

[Sergio Garcia Murillo <[e-mail]>]

Hi Adam, welcome back!

Answers inline below:

El jue, 27 may 2021 a las 23:37, Adam Roach (<[e-mail]>) escribió:

> ----
>
> 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.
>
My intention was that the protocol must support the negotiation of both svc
and simulcast, and both clients and publishers may support them, so I agree
with your suggestion. Opened an issue for clarifying it:

https://github.com/murillo128/webrtc-http-ingest-protocol/issues/9


> ----
>
> 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).
>


I am fine with recommending having  RTCP SR/RR reports sent more often, but
I don't think it is something we can mandate. Also, the client can use the
STUN consent fresnesh to detect the network interruption. However, reducing
the timeouts to be able to react faster will likely cause a lot of false
positives (even if we do c), so I think we should not do it and for being
able to detect network changes, like wifi to 4g, it is best that the
clients rely on the OS provided APIs rather than on any media timeout:

https://developer.android.com/training/monitoring-device-state/connectivity-status-type
https://wicg.github.io/netinfo/
https://developer.apple.com/library/archive/samplecode/Reachability/Introduction/Intro.html

----
>
> 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).
>

I am fine with the RTCP BYE approach, the draft also includes using the
revocation of consent as per RFC7675

The media server may terminate the session by using the Immediate
Revocation of Consent as defined in {{!RFC7675}} section 5.2.


>
> ----
>
> 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.
>

I like the idea.


> ----
>
> 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.
>

I am not sure if using GET on the resource URI to return something
different than the SDP representation is covered under the HTTP best
practices, we should double check that.

For extensibility I was thinking that each extension we could introduce a
Link header with the extension rel type and the uri for the HTTP resource
of the extension on the 201 created, similar to what web push is doing:

https://datatracker.ietf.org/doc/html/rfc8030#section-9.2

So for example, taking a potential extension of server to client
communication using server sent events as specified in
https://html.spec.whatwg.org/multipage/server-sent-events.html#server-sent-events

The url for connecting to the server side event resource for the published
stream will be returned in the initial HTTP "201 Created" response with a
"Link" header an a "rel" attribute of
 "urn:ietf:params:whip:server-side-events",  the http 201 response to the
creation POST would look like

HTTP/1.1 201 Created
Content-Type: application/sdp
Location: https://watever.com/publications/213786HF
Link: <https://watever.com/publications/213786HF/sse>;rel="urn:ietf:params:whip:server-side-events
"

Other extensions could be added by registering new "rel" values on IANA.


Best regards
Sergio