Giacomo Vacca

Understanding WebRTC State Machines Specific transports, aggregate states, and the Chrome/libwebrtc mental model WebRTC is one of those technologies that appears deceptively simple on the surface. You call createOffer() , exchange some SDP, and suddenly two browsers are streaming video to each other. But beneath that simplicity lies a set of interlocking state machines that govern every aspect of the connection's lifecycle—from signaling and ICE candidate exchange to DTLS handshake completion. If you've ever stared at a WebRTC debugging log wondering why connectionState reads "connecting" while iceConnectionState says "connected" , this article is for you. The key insight, and the one the Chrome/libwebrtc codebase is built around, is that WebRTC state is organized into two distinct tiers: specific state machines that live on individual transports, and aggregate states on RTCPeerConnection that are derived—computed—from those transports. This art...

Before I forget again, a Wireshark setting that can help saving time by trying to interpret any UDP as RTP, if possible: Analyze --> Enabled Protocols... --> Search for RTP and enable at least 'rtp_udp' Without that change, when SIP signalling is not present (or it's encrypted) Wireshark would not understand automatically that UDP packets may be RTP. This is particularly true for example for WebRTC calls, where signalling happens elsewhere and is not available to Wireshark. This will also save the reader some time if you're used to right click and 'Decode As...' to achieve the same.

Disclaimer: I wrote this article on March 2022 while working with Subspace, and the original link is here:  https://subspace.com/resources/ice-negotiation . This post in my personal blog is a way to ensure it doesn't get lost. There is nothing service-specific in it, I've made only minor edits and I hope it can be a good technical reference on the topic. WebRTC is a set of protocols that allow applications, typically running on Web browsers, to exchange media (audio, video, data) with other entities. Before media can flow, however, the WebRTC entities need to discover what type of connection is possible, and among the possible connections, what’s the best to be used. This needs to happen as fast as possible, so that users can perceive the service as instantaneous as possible. WebRTC includes protocols like STUN and TURN that are designed to facilitate the establishment of connections when a direct connection is not possible. The typical case is a computer inside a home or o...

  WebRTC applications use the ICE negotiation to discovery the best way to communicate with a remote party. I t dynamically finds a pair of candidates (IP address, port and transport, also known as “transport address”) suitable for exchanging media and data. The most important aspect of this is “dynamically”: a local and a remote transport address are found based on the network conditions at the time of establishing a session. For example, a WebRTC client that normally uses a server reflexive transport address to communicate with an SFU. when running inside the home office, may use a relay transport address over TCP when running inside an office network which limits remote UDP targets. The same configuration (defined as “iceServers” when creating an RTCPeerConnection will work in both cases, producing different outcomes.

 Since I needed to see a few details in the handling of attributes in STUN responses, I thought of going through the whole STUN protocol RFC again and take notes on the most important parts. I put my notes in some slides, and I'm sharing then in Slideshare in case somebody else may find them useful too: STUN protocol from Giacomo Vacca

In the first part of my brain dump about this year's edition of Kamailio World I focused mainly on testing. Core developers and application designers want to be able to test the behaviour of Kamailio -based architectures with minimal effort and fast feedback. A different dimension to testing, that I haven't mentioned in my previous post, was related to Fuzz testing . There were two presentations focused on this: Sandro Gauci's (The easiest way to understand who Sandro is: listen on port 5060 on the public Internet and wait a couple of minutes. You'll see a SIP request from a tool called sipvicious (aka friendly-scanner), a penetration testing tool Sandro wrote (and others misuse)) and Henning Westerholt , historical member of the Kamailio community. Sandro's presentation focused around fuzzing approaches for RTC in general ( slides ), while Henning was more specifically focused on Kamailio. Fuzzing is a sophisticated technique to verify the robustness...

"I’ve been following  TADHack  and its related events for some time, and finally this month I got the opportunity to attend  TADHack-mini Paris . Participants can join from remote too, but the personal full immersion is something different (even, ironically, when the topic is Real Time Communications, and more in particular  WebRTC  and Telecom APIs. We met in central Paris [...] " This is the beginning of the behind-the-scenes story about my TADHack participation. You can read  my full article here .

On a previous post I shared my experiments with node.js as a WebSocket server. This is quite useful for people working on WebRTC prototypes and familiar with node.js. Some of the readers may have noticed that I was using plain WebSockets ('ws://' URLs). It's recommended to use Secure WebSockets instead ('wss://' URLs), so I thought of playing with the 'ws' node.js module and "add TLS". On github there's an example in this direction (see below), but I must admit I didn't understand some implications at first. I thought the instantiation of an HTTPS server was just coincidental and meant to provide the web pages and scripts in the example, and that the configuration of 'ws' with 'ssl: true' and certificates was independent. It turns out it's not. The best description of my understanding is that you need an HTTPS server to "decorate" the WebSocket module. The HTTPS server will take care of connectio...

In "FOSDEM 2015 - part I" I made an overview of this Conference and a few comments on the talk "Python, WebRTC and you", where the a peer-to-peer WebRTC service was also described. Fast forward to a Lightning talks on Day 1, afternoon: Emil Ivov about Jitsi VideoBridge . In this case we’re considering video-conference scenarios, possibly with many participants, and the ability to add some presentation features, like highlighting the current speaker. The architecture behind Jitsi VideoBridge aims to avoid a centralized mixer ( MCU ), but at the same time prevent the complexities of a Full Mesh approach. Enter the SFU (Selective Forwarding Unit) concept: the server component is “simply” a router of media streams among conference participants. A IETF Draft describes the behaviour expected for an SFU. Each participant receives one stream per each other user: it’s then up to the receiving client to take care of stream presentation. The...

I t's that time of the year when experts of Open Source software meet in frosty Brussels for two intense days of talks, conversations, and a good quantity of beer: FOSDEM . Being just 2 hours away from London with the Eurostar, the relevance/effort ratio is very high. Additionally, the event is free and held over the weekend, so it has a low impact on the normal job activity (although on the other hand it does have some on your family time, but you can't have everything, unless your kids are big enough to join you, which I'd recommend). Right after settling down in a lovely flat (AirBnB is a great choice) with three friends I started planning the sessions to follow. There are about twenty parallel sessions, so you must cherry pick. For day 1 I was oriented towards Configuration Management and Lightning Talks tracks. Day 2 had Virtualisation and Testing And Automation in my radar. As it turns out, FOSDEM is such a success that the rooms are filled incredibly fast a...

Docker is an incredibly useful tool to build prototypes of Linux hosts and applications. You can easily build a network of servers inside a single virtual machine, with each server represented by a docker container. Clients can access the services on the same IP address, but different ports. In this post I'd like to talk about a common prototype case in WebRTC  platforms: a WebSocket server. This will be a node.js server and will run inside a Docker container (hosted by an Ubuntu Trusty VM). The server logic can be as complex as you can imagine, but since it's not the point of this post I'll keep it as simple as the server example in the node.js websocket module : The WebSocket server will listen on port 8080, accept incoming connections, send back "something" upon client connection, and log the content of the messages from the clients. We can assume all the files in this article are in the same folder, and we're cd into it. The server logic is...

Verto is a newly designed signalling protocol for WebRTC clients interacting with FreeSWITCH . It has an intuitive, JSON-based RPC which allows clients to exchange SDP offers and answers with FreeSWITCH over a WebSocket (and Secure WebSockets are supported). It’s available right now with the 1.4 stable version (1.4.14 at the moment of writing). The feature I like the most is “ verto.attach ”: when a client has an active bridge on FreeSWITCH and, for any reason (e.g. a tab refresh) it disconnects, upon reconnection FreeSWITCH automatically re-offers the session SDP and allows the client to immediately reattach to the existing session. I have not seen this implemented in other places and find it extremely useful. I’ve noticed recently that this does not fully work yet when the media is bypassed (e.g. on a verto-verto call), but Anthony Minnesale, on the FreeSWITCH dev mailing list said this feature is still a work in progress, so I’m keeping an eye on it. Initially I was ex...

This year I was speaking at Astricon for Truphone Labs (you can see my slides here if you're interested). The week before Astricon I was invited try out respoke , a solution that allows you to build a WebRTC-based service . They provide you with a client JavaScript library, and you need a server account (with an app ID and secret key) to connect your application to the respoke server and allow clients to communicate with each other. This is an intuitive approach. As a service developer, you pay for the server usage, and you do so depending on how many concurrent clients you want. I got a testing account, and started trying out the JS library. The process of building a new application was very straightforward, and the docs guided me towards building a simple app to make audio calls, and then video calls as well. Soon I started thinking: respoke is from Digium , right, and Digium develops Asterisk . How is it possible that respoke and Asterisk cannot interconnect? W...

Back from ClueCon 2014, I've described the content of my presentation in this Truphone Labs Blog post . The slides are here . Any feedback is welcome, as usual.