Re: [Wish] Prototype client/server WHIP implementations

Awesome work Lorenzo!

As you have anticipated, I feel that the current draft is quite mature in
terms of functionalities, so I plan to request a session at the next IETF
hackathon for doing interoperability tests between client and server
implementations and incorporate the feedback we gather into the protocol.

I also plan to implement it into Millicast and do a small javascript based
client for testing. Would be great to have much more diverse
clients/servers for testing!

Best regards
Sergio

El jue, 9 sept 2021 a las 11:59, Lorenzo Miniero (<lorenzo@meetecho.com>)
escribió:

> Hi all,
>
> FYI, I just created a couple of repositories that host a prototype
> implementation of both the server and client side of WHIP. They're
> quite barebone and nothing to write home about, but hopefully they
> should be helpful to perform some interoperability tests, and more
> importantly check whether the specification works as it is.
>
> The server side is a simple node.js frontend to the open source Janus
> WebRTC server, meaning it implements the WHIP API on one end, and
> translates those interactions to the Janus API on the other end, in
> order to eventually create a PeerConnection to the VideoRoom (SFU):
>
>         https://github.com/lminiero/simple-whip-server
>
> The client side, instead, is a basic command-line application that
> takes advantage of GStreamer's webrtcbin stack, implementing what I
> figured out a WHIP client was supposed to talk like:
>
>         https://github.com/lminiero/simple-whip-client
>
> While I've been testing them against each other, the idea of course is
> that they should also be able to talk to any other WHIP client/server
> implementation, which is the main purpose of the interoperability tests
> I'd like to happen sooner or later. I know Sergio was interested in
> doing something in that direction at the next IETF hackathon, but of
> course if anything else happens earlier than that as well I'd be glad
> to hear how that goes!
>
> About the implementation choices, I did make some assumptions on the
> specification in the prototypes (e.g., see discussion on tokens from
> the latest post by Sergio), but in general it should be a reasonably
> faithful implementation of the current specification. The client
> doesn't seem to be able to detect when a PeerConnection goes down
> (e.g., when someone else sends a DELETE on its its behalf), but that
> seems to be a limitation in the current implementation of GStreamer's
> webrtcbin (apparently changes in the DTLS state don't update the
> overall state of the webrtcbin element); I'll try to find a workaround
> for that.
>
> Hope this helps,
> Lorenzo
>
> --
> I'm getting older but, unlike whisky, I'm not getting any better
> https://twitter.com/elminiero
>
> --
> Wish mailing list
> Wish@ietf.org
> https://www.ietf.org/mailman/listinfo/wish
>