Subject: [Wish] Prototype client/server WHIP implementations

From: Lorenzo Miniero <[email-masked]>
Date: Thu, 9 Sep 2021 11:59:27 +0200

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

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Thu, 9 Sep 2021 12:23:50 +0200

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 (<[email-masked]>)
escribió:

> Wish mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/wish
>

---

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 09 Sep 2021 13:24:24 +0200

> 	https://github.com/lminiero/simple-whip-client

Thanks a lot, Lorenzo!

In order to get it to compile under Debian, I did the following:

    apt install libgstreamer1.0-dev libgstreamer-plugins-bad1.0-dev libjson-glib-dev libsoup2.4-dev

-- Juliusz