Giacomo Vacca

It goes without saying that SIP solutions are impacted by NAT. So much that some scenarios required integration to RFC 3261 , e.g. with RFC 3581 , which defined the ' rport ' attribute to be added in the Via header (integrating the ' received ' attribute): with that information, responses could be routed to the source port of the related request, and not on the advertised port in the original Via. That was called Symmetric Response , and applied to connection-less transports (UDP), while, as mentioned in RFC 6314 , it's not necessary when using reliable transports (TCP in most cases): SIP responses can be sent back on the same connection on which the request arrived. Also from RFC 3261, chapter 18, Transport layer, client behaviour: "For reliable transports, the response is normally sent on the connection on which the request was received." But the client needs to be prepared to receive the response on a new connection: "[...] the transport layer MUST...

There are various levels of testing, from unit to component, from integration to end-to-end, not to mention performance testing and fuzzing. When developing or maintaining Real Time Communications (RTC or VoIP) systems,  all these levels (with the exclusion maybe of unit testing) are made easier by applications explicitly designed for this, like sipp . sipp has a deep focus on performance testing, or using a simpler term, load testing. Some of its features allow to fine tune properties like call rate, call duration, simulate packet loss, ramp up traffic, etc. In practical terms though once you have the flexibility to generate SIP signalling to negotiate sessions and RTP streams, you can use sipp for functional testing too. sipp can act as an entity generating a call, or receiving a call, which makes it suitable to surround the system under test and simulate its interactions with the real world. What sipp does can be generalised: we want to be able to simulate the real world tha...

The Kamailio Developers Meeting is a two-day event held in Dusseldorf, currently at the second edition.  As described in https://www.kamailio.org/w/developers-meeting/,  "The purpose of the event is to support the interaction between developers and to offer a great environment to work together on relevant topics related to the Kamailio project. It is intended for participants that want to write code for Kamailio and its tools or improve the documentation. There will be no formal presentations, only open discussions, coding or documentation writing sessions." The sipgate offices offered a very welcoming environment. Noticeable to have a kitchen with chefs for breakfast and lunch, and a private pub, where the social event was held. I noticed the presence of art works and learned that those offices are also part of an art itinerary in Dusseldorf. We started listing the topics that we wanted to tackle during the event, then discussed a plan to go through them. ...

This was my fifth time in a row attending Kamailio World in Berlin. The weather was warmer and sunnier than usual. Apart from the obvious focus on Kamailio , as usual the RTC ecosystem was well represented (with Janus, Asterisk, FreeSWITCH, Homer, RTPEngine, and many others). Attendance from the other side of the Atlantic Ocean gave stronger emphasis to the "World" term in the title. My personal mission this year was to talk about a framework for testing Kamailio as a tool for developers and maintainers of the project: kamailio-tests . The main concept was that early tests that are not focused on a specific business logic (as we all have in our projects) and can be automated will be beneficial to Kamailio's reliability. We want to defer end-to-end testing to later stages, because they are expensive. To provide a uniform infrastructure where to run the tests, without requiring permanent test environments, we use Docker for this. This is, of course, not th...

If you've ever worked with SIP, you must have stumbled upon a trace with 200 OK to INVITE being retransmitted for about 30" and then the call just being set up fail. The ACK was never received. Then comes the interesting part: discovering why. Here are some notes about what should happen, in particular when there are multiple proxies along the path, and with a little additional complexity of one of the proxies with two network interfaces. All this assuming loose routing everywhere. The main reference here of course is RFC 3261 . Isn't an image worth a thousand words? Then here's a sequence diagram: All Record-Route headers are assumed to carry loose routing URIs (they have the ;lr attribute). B, C and D, working as proxies that want to stay in the path, record route themselves. For this reason E, the UAS and "callee", receives an INVITE with a list of Record-Route headers with B, C and D. In particular for B there will be two Record-Route head...

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...

I hope this can save the reader some time. If you need to read the entire content of the P-Asserted-Identity header of an incoming INVITE, be aware that you should change the sofia profile by adding a param like: param name="p-asserted-id-parse" value="verbatim" FreeSWITCH will populate the variable accordingly and make it available with commands like (e.g. with lua): PAID = session:getVariable("sip_P-Asserted-Identity") If you don't add this parameter, you'll get the default behaviour, which is just filling the variable with the P-Asserted-Identity URI username part. Possible value are: "default", "user-only", "user-domain", "verbatim" , which I think are self-explanatory. A recent reference here .

As simple as this: sipsak -s sip: sipsak  will send an OPTIONS request to , defaulting to UDP port 5060.

SIP is a relatively simple, text-based, human readable protocol that is now the standard de facto for VoIP signalling. The protocol though (in my opinion!) is a little tricky, where typically the tricks are: details . In this first post of a series of "Trip-wires for the SIP fans", I'll talk about CANCEL. The main concept is easy: a caller may decide to cancel a call before this is answered. To do this, it sends a CANCEL request to the called party. What's important to know is that: A CANCEL request relates to an INVITE request, and does not relate to the SIP dialog the request may have created (or will create). For this reason the To header tag must be the same as the INVITE request, even if meanwhile there's been a provisional response to the INVITE creating a dialog (e.g. a 180 with a tag in the To header). From RFC 3261, 9.1 : The following procedures are used to construct a CANCEL request.  The    Request-URI, Call-ID, To, the numeric part of ...