Following up on my previous post and very definitely staying in the realm of ‘rough notes’ I wanted to add a little more to the basic sample that I’d cooked up around UWP/webRTC.
In the previous sample, I’d gone to great lengths to make a UI that was almost impossible to use because I was putting the burden of signalling onto the user of the UI and so the user had to copy around long strings containing details of session descriptions and ICE servers and so on. The user was the ‘signalling server’ and it was a bit tedious to pretend to be a server but it did work.
This was useful to me as it let me try to understand what was going on, what a signalling server had to do for webRTC to work and also to reduce some of the code in the sample.
Ultimately, though if I’m going to make progress, I need a signalling server and I decided to simply re-use the console server which sits in this project within the UWP/webRTC PeerCC sample.
Which also meant that I could re-use the code which talks to that server which is contained in the PeerCC sample in a couple of places;
I mostly didn’t take code from the Conductor class, only the Signalling class which I moved lock stock and barrel into my project after creating a new branch (Signalling) and removing most of the existing ‘UI’ that I had as it was largely related to manually copying around SDP strings and so on.
I hosted the console signalling server on a VM in Azure.
My new ‘UI’ simply contains boxes where I can type in the details of my signalling server;
and the intention of this little UI is to be ‘simple’ as possible rather than ‘comprehensive’ in any way and so the intended flow is as below;
- Enter the IP address and port of the signalling service
- Click the ‘Connect to Signalling…’ button.
- The app will then connect to the signalling service and, if successful, it replaces the UI with 2 MediaElements, one for local video and one for remote.
- The app then goes through the process of creating a Media object and using GetUserMedia() and associating the first local video track that it gets with a MediaElement in the UI so that the user can see their local video.
- The app then waits for the signalling service to either
- Deliver an offer from some other peer
- In this case, the app creates the RTCPeerConnection, accepts the offer, creates its answer, sends it back via the signalling service and adds the first remote video track that comes in to a MediaElement on the UI so that the user can see the remote video.
- Deliver a message telling it that some other peer is connected to the signalling service
- If the ‘Is Initiator’ CheckBox is checked the app will then go and create the RTCPeerConnection, create an offer and send it over over the signalling service to the remote peer.
- Deliver an answer from some other peer
- This is assumed to be the response to the offer made above and so it is accepted.
And so the app is very simplistic in its approach and based on the ‘Is Initiator’ CheckBox will aggressively try and begin a session with the first peer that it sees connected to the signalling service which might not be a very realistic thing to do but it works for a basic sample.
With that in play, I can run two instances of this app on two machines, tell one to be the ‘Initiator’ and tell the other one not to be ‘Initiator’ and I get video and audio streams flowing between them.
Here’s a screenshot of my app doing this;
but because I re-used the signalling server that the original PeerCC sample used and because I didn’t do anything to the protocol that it uses on that server (other than add an extra piece of datta to it) I can use the original PeerCC sample to also communicate with my app and so here’s that sample sending/receiving video and audio to an instance of my app on another PC;
Now, it’s not exactly ‘an achievement’ to put someone else’s signalling server and their protocol code back into my sample here because my first sample was mostly about how to make webRTC work without that signalling server but, again, it’s a learning experience to take things apart and put them back together again.
I’d like to now refactor some code within that application as I’ve just let the code-behind file ‘mushroom’ a little and I think it I could make it better so I’ll perhaps revisit that ‘Signalling’ branch and improve things in the coming days.
Pingback: Rough Notes on UWP and webRTC (Part 3) – Mike Taulty