Re: [Wish] WHIP enhancements

[Lorenzo Miniero <[e-mail]>]

Hi all,

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.

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

In general, though, I think the proposal looks interesting, and I'm
looking forward to the session in a couple of weeks.

Lorenzo



On Wed, 24 Feb 2021 09:14:27 +0100
Sergio Garcia Murillo <[e-mail]> wrote:

> Hi Adam,
> 
> The need for a way to explicitly terminate the session was already by
> several people, so I think we should definitely include it.
> 
> https://github.com/murillo128/webrtc-http-ingest-protocol/issues/2
> 
> However, I would be against optionalities, as it makes the testing and
> interoperability much more difficult.
> 
> In that regard, I am against including the trickle option as the
> server should be accessible to the publisher, and the only case where
> it could make sense is if the WHIP server is on a public server but
> the media servers are behind NATed network without port forwarding.
> 
> Also, I am not sure what would be the benefits of the ice restart
> (especially if it is optional) compared to just restarting the whole
> publishing session again, which is something that the service has to
> implementa anyway.
> 
> On a last note, I would prefer to make the process less json-like and
> more http-like, reusing HTTP headers and methods as much as possible.
> 
> My initial thoughts about how to implement it were that the POST
> request to start the publication returned a 201 created response with
> a Location header indicating the URI to the entity representing the
> publication. And then allow the following methods on the request
> 
> - GET for retrieving information about the state of the publication
> (TBD).
> - OPTIONS for keep alive
> - UPDATE for updating the session (we would need to specify what
> would we actually allow to be updated)
> - DELETE for terminating the session
> 
> Best regards
> Sergio
> 
> 
> El mié, 24 feb 2021 a las 3:09, Adam Roach (<[e-mail]>)
> escribió:
> 
> > Hey, folks! Now that we have an approved working group, it’s time to
> > get this party started. IETF 110 is just around the corner, and it
> > would be great to have things to talk about during our meeting slot.
> >
> > I've gone over the current proposal and compared it against some of
> > the things that were brought up at the DISPATCH discussion, as well
> > as some of the things that I know our own network either needs or
> > will need in the near future. I'm going to lay this out by first
> > describing requirements, and then sketch out a proposal that
> > attempts to address these requirements.
> >
> > -----------------------------------------------------------------
> >
> > Requirements
> >
> > One of the things that came up in DISPATCH, which is definitely
> > something that we need, is session management -- or at least session
> > termination. This means that we’ll need some way to correlate a
> > session termination request with a session origination request.
> > Beyond this, we've found the ability to have signaling-level
> > heartbeats to be important for service separation, as well as a
> > small handful of other operations, like ICE restarts and trickling
> > of ICE candidates.
> >
> > Although not strictly necessary, there is a strong desire to be able
> > to perform *some* of these operations (e.g., session termination,
> > ICE restart) from the ingest node towards the broadcasting tool.
> >
> > The current document leaves open whether an ingest connection
> > supports different ordinalities of audio and video streams; and, if
> > they do, how they might be distinguished. We should be clear about
> > what is expected in an SDP offer regarding the number of each, and
> > perhaps add some signaling so that the tool and ingest node can
> > negotiate or signal what combinations of media are supported.
> >
> > Finally, for future extensibility and feature experimentation, there
> > is a desire to be able to expand the protocol with new operations
> > and new protocol fields in a backwards-compatible way.
> >
> > Those are the requirements I'm aware of that we’ll want to consider
> > in updating the current protocol proposal. I'm going to sketch out
> > how we might achieve them below. One focus of this proposal is
> > ensuring that the implementation complexity on the client can be
> > kept as low as possible, so as to encourage the widest range of
> > broadcasting tools possible to adopt this solution.
> >
> > -----------------------------------------------------------------
> >
> > Implementation Sketch
> >
> > First, we would update the POST/200 transaction so that it carries
> > more information than a simple offer/answer. This could be a MIME
> > multipart body, but that seems probably more trouble than
> > representing the SDP alongside the other information we want to
> > send.
> >
> > So for example, one way of doing this is having the POST operation
> > contain a JSON object indicating which server-oriented operations it
> > supports (if any), along with the SDP offer; something like:
> >
> > POST /ingest/username HTTP/1.1
> > Content-Type: application/json
> > ...
> >
> > {
> >    'offer': 'v=0\r\n0=- 20150 0 IN IP6...',
> >    'operations': ['update', 'end', 'ice-restart']
> > }
> >
> > The POST response from the server then contains an answer, along
> > with a list of operations that it can accept, plus the endpoints
> > that the client would use to perform those operations. Something
> > like:
> >
> > HTTP/1.1 200 OK
> > Content-Type: application/json
> > ...
> >
> >
> > {
> >    'answer': 'v=0\r\n0=- 20150 0 IN IP6...',
> >    'heartbeat': 'https://example.com/stage/adam/ea48c65c/heartbeat',
> >    'update': 'https://example.com/stage/adam/ea48c65c/update',
> >    'end': 'https://example.com/stage/adam/ea48c65c/terminate',
> >    'trickle':
> > 'https://mg.example.com/stage/adam/ea48c65c/ice-candidate',
> > 'ice-restart':
> > 'https://mg.example.com/stage/adam/ea48c65c/ice-restart' }
> >
> > You'll notice that the endpoints are (or at least can be) customized
> > for the session by including a unique identifier (ea48c65c in the
> > example above). The broadcast client doesn't have to worry about
> > this; all it needs to do is use the endpoints that it gets in
> > response to a session creation post to enact the corresponding
> > operations.
> >
> > We can have a discussion about which of these operations
> > implementations are expected to support, and which are supplemental,
> > but I think we definitely need at least heartbeat and session
> > termination (which I call "end" above).
> >
> > For each of these operations, we would define how the client
> > interacts with them to enact the operation, but the general pattern
> > would be as above: a POST message sent to the corresponding
> > endpoint, containing a JSON body with operation parameters; and the
> > HTTP response will contain a JSON body with response parameters.
> >
> > So that gets us an extensible list of operations, and allows the
> > ingest node to embed a session identifier into the endpoints as
> > necessary.
> >
> > On top of this we can add something kind of clever to the
> > "heartbeat" operation that allows two-way communication without
> > requiring broadcast tools to do anything (relatively) complex like
> > implementing web sockets, by sending such operations in the response
> > to heartbeats.  One approach would be to limit egress nodes to
> > sending commands towards the client once per heartbeat period (e.g.,
> > if the clients sent a heartbeat once every 15 seconds, then the
> > server might have to wait as long as 15 seconds to send a command).
> > Another approach would be to have the server wait for the heartbeat
> > interval before responding, thereby leaving the heartbeat
> > transaction open for the entire time. If we decided to go with this
> > latter behavior, the server could send a command to the client at
> > any time by responding to the pending heartbeat operation.
> >
> > Finally, I think the extensibility story here naturally falls out of
> > the techniques described above: new transactions can be defined by
> > adding them to the initial message exchange; and new parameter can
> > be added to existing operations by adding them to the JSON objects
> > that are part of those operation's POST/200 transactions.
> >
> > -----------------------------------------------------------------
> >
> > I'd like to close on the rough shape of these issues, and then get
> > a draft pulled together in time for the WISH meeting at IETF 110.
> > Input on how we might want to do things differently than I propose
> > above would be very welcome.  Thanks!
> >
> > /a
> >
> > --
> > Wish mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/wish
> >  



-- 
I'm getting older but, unlike whisky, I'm not getting any better
https://twitter.com/elminiero