[Wish] WHIP enhancements

[Adam Roach <[e-mail]>]

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