Re: [Wish] WHIP enhancements

[Adam Roach <[e-mail]>]

Thanks for the review! Comments inline.

On 2/24/21 02:42, Lorenzo Miniero wrote:
> I was one of the proponents for the "terminate the session" option
> Sergio mentioned, so I'm definitely up for that. I'm not against Adam's
> proposal with respect to the JSON usage and the different URLs, as it
> seems quite flexible to me: whether it's different addresses, or HTTP
> headers, seems mostly semantics to me, so I'm fine either way (even
> though a JSON syntax would definitely allow for easier extensibility in
> the future). I'm fine with trickling as well, personally, and so see
> some value in allowing ICE restarts to happen too.


One of the things that I didn't point out (although the example does 
show it) is that the scheme I describe lets you easily split up the 
machines responsible for handling different operations. For example, 
under certain decomposition models, it makes sense to perform ICE 
operations directly towards a media node, while other session operations 
go towards a controller node. An operation-to-URL mapping makes this 
trivial and transparent to the broadcast client.


> What I'm not sure about are Adam's suggestion to use heartbeats for
> two-way communications. Adam, what kind of commands are you envisaging
> in the server-to-client direction here? Are you mostly thinking about
> asynchronous events of some nature, or something else too?


Mostly session termination and ICE restarts. But I also want to make 
sure it's extensible.


> With respect
> to the approach, I understand the desire to avoid long polls, but
> having some commands/events returned only in response to heartbeats
> here may lead to implementations that will poll often and aggressively
> to be sure they have timely information, and "forcing" implementations
> to only send heartbears at less frequent intervals may on the other end
> lead to suboptimal user experience (depending, again, on the nature of
> the commands/events the server would mean to send back).


Given a free hand, I actually prefer the long poll option. I included 
the description of both to demonstrate that, even if we don't want a 
long poll mechanism, we could still implement *something* that gives the 
server a means of telling the client to do things (like end a session).

/a