Re: [Wish] WHIP enhancements

[Adam Roach <[e-mail]>]

On 2/25/21 02:52, Sergio Garcia Murillo wrote:
> Hi Adam,
>
> Comments inline
>
> El jue, 25 feb 2021 a las 0:25, Adam Roach (<[e-mail] 
> <mailto:[e-mail]>>) escribió:
>
>     Thanks for the quick review of my proposal! Comments inline below.
>
>
>     On 2/24/21 02:14, Sergio Garcia Murillo wrote:
>     > 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.
>
>
>     The scheme I'm looking for here is one of a very small set of core
>     functions, plus optional fields that are ignored if an implementation
>     doesn't understand them. To test interop, all that would be
>     necessary is
>     to check the proper functioning of the core functions (along with, I
>     suppose, cursory checks that unknown fields are correctly ignored).
>
>
> My main concern about this is that most people will only implement the 
> core package and don't do the optional part.
> So I would prefer to have as less optionality as possible, especially 
> if the optional functionality is something that may be required by 
> some people in order to make it work.


To be clear, what I'm looking for here primarily is well-defined 
extension points. I'm happy leaving the actual optional extensions for 
later. The principle I'd follow here is that whatever is part of the 
core functionality should always be sufficient to connect to an ingress 
gateway and begin a broadcast.

Anything optional would necessarily be additional functionality that 
would possibly enhance the experience, but which would not be required 
for interop of core functionality. You mention SIP in your message, and 
I think there's a good example to use as a mental model: while a device 
that implements just basic, core SIP for voice calls can dial into a 
conference bridge and send/receive media, RFC 4575 defined a way that 
devices can learn and present additional information about the 
conference state. It's not necessary to implement; it just makes things 
nicer.


>
>     > 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.
>
>
>     I'm definitely okay leaving both trickle ice and ice restart
>     functions
>     off for now, as long as we have some kind of extensibility mechanism.
>     What I'm trying to avoid is some kind of future situation where
>     RT-CDNs
>     are hosted behind application load balancers, and the processing
>     nodes
>     themselves lack v4 unique addresses (and are therefore natted). I
>     don't
>     see it being an issue right now, but depending on how quickly we can
>     rely on 100% IPv6 deployment to end users, it may become an issue
>     in the
>     future. I don't want to be painted into a corner when/if this happens.
>
>
> That may be an interesting use case to support in order to be future 
> proof and would be easy to implement server side (just ignore the 
> client updated candidates). So my proposal would be either to not 
> support it, or include it on the core package.


I'm just as happy including it as part of core functionality. Given that 
it's part of the core JSEP model, I would expect any WebRTC stack to 
include it, so it's unlikely to make things particularly complicated for 
implementations.

[snip]


>     UPDATE is even more problematic, as HTTP doesn't have an UPDATE
>     method,
>     and the process of adding new methods to HTTP is politically
>     difficult
>     in the best circumstances (e.g., creating a method that has broad
>     applicability to all resource types -- see the difficulty and
>     insanely
>     long timeline getting PATCH defined for an example).
>
> My bad, too much time working on SIP. Obviously defining any new http 
> methods or headers is something we should not do.


With that in mind, I think there are really only two ways that we can 
indicate operations:

 1. Have an in-band indication of the operation type in the body of the
    HTTP request, or
 2. Use unique endpoints for each request type.

I think either one works, although I think the second one is a bit 
cleaner, as it allows for separation of interests (e.g., routing 
requests to the node that can most efficiently handle them); and, as a 
nice side effect, it makes it clear which operations the server 
supports. If we choose option 1, then we'll need some additional 
mechanism for the client to learn which operations the server supports.

/a