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

[Adam Roach <[e-mail]>]

On 5/28/21 04:31, Sergio Garcia Murillo wrote:
>
> 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
>

Yep, we're absolutely going to want to restart when there are 
client-detectable network-layer changes. I'm more thinking of the cases 
around mid-session NAT binding changes, similar to the real-life 
problems that Juliusz described at the March meeting. Something 
client-initiated like consent checks seems like a good approach to me 
for such cases.

So perhaps we simply relax the 4-second minimum specified in RFC 7675 
(changing it to one second?) and suggesting some number of consecutive 
missed responses before a connection is considered failed (say, three 
consecutive STUN transactions). That would give stream recovery in 3 
seconds plus a couple RTT.


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


Ah, yes. I missed that. I'm okay with just the consent revocation 
message, as long as we make it a normative part of the protocol. If we 
leave consent revocation as optional, then I'd like RTCP BYE to be 
required. I'm completely open about which of these options we choose, as 
long as the normative behavior is to send some kind of explicit 
end-of-session message in the media channel.


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


Yeah, that occurred to me, but given that we're doing POST rather than 
PUT to send offers, I don't think it's really a concern. (I've also had 
a lot of discussions through the years about whether "GET(PUT(X)) == X" 
is in any way an architectural desire, and I don't think there's 
anything like a consensus on the topic among HTTP experts.)


That said...


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


...I think this is a cleaner approach anyway. So I'm more than happy to 
pursue that setup.

In any case though, I think we want to be explicit that WHIP servers 
MUST return HTTP 405 responses for GET, HEAD, and PUT operations on the 
links returned in the "Location" header fields, to make it cleaner to 
use those methods in the future if we identify corresponding use cases.

/a