Thoughts after Our Participation in OpenSIPIt’03

September 2023 marked the 3rd edition of OpenSIPIt — the online interoperability testing event for VoIP, SIP and related open-source technologies. This edition, the event featured a hackathon as well, where developers could either try to win some rewards (sponsored by Sippy Software) by completing a specific C/Python coding task or just spend the time performing more testing with other teams or simply work on internal/side projects.

The OpenSIPS project was represented by Răzvan Crainea and me, with each of us taking on the responsibility of hosting one of six tracks:

• SIPREC (guided by Răzvan Crainea)
• STIR & SHAKEN (guided by me)
• DTLS (guided by Maxim Sobolyev)
• Performance Testing (guided by Flavio Goncalves)
• Security / DoS (guided by Sandro Gauci)
• RFC 8760

In total, there were eight open-source projects who confirmed their participation at the event for at least one track. The “playground” was a private network of EC2 t3.medium instances, courtesy of Sippy Software, where each team had its own instance in order to install its own software and perform the testing against other teams.

Let’s take a look at how each track went!

STIR/SHAKEN Track

Two Years Later…

Unlike in the previous years, nowadays STIR & SHAKEN is a mandatory requirement for service providers across US & Canada, with adoption quickly growing in Europe as well, although we’ve yet to see a legal impetus for telcos to embrace it coming from the EU.

Zooming in on the technology itself, there have been little to no changes to the framework, except for perhaps some Rich Call Data additions to the PASSporT’s payload. Still, usage of the Caller ID signing framework in real life has prompted verifying Service Providers to provide the results of the verification to the end-user SIP device in a multitude of ways. Popular solutions include:

• a custom ;verstat= parameter for the P-Asserted-Identity SIP header
• a custom X-VerStat (or similar) SIP header
• a "[V] " Caller ID prepend, indicating that the caller is “verified”

Testing Results

An overwhelming majority of the projects showing up to the event took part in the STIR/SHAKEN track and performed interoperability tests using their own implementations. The overall consensus was that the track was a success, as we managed to:

• help fix/mitigate a configuration issue in FreeSWITCH, causing the STIR/SHAKEN verification service (VS) to accept self-signed certificates without explicit approval
• help fix a PASSporT signature packaging bug in Asterisk
• fix a bug in OpenSIPS, leading to bogus Date SIP header field values such as Tue, 22 Sep 2150 23:29:00 GMT passing through the VS without getting rejected (75a168a9)
• improve some stir_shaken OpenSIPS module SIP status code / status message replies on various PASSporT evaluation error cases (e2977a4f). To name some new SIP replies you will begin seeing soon:
  • 438 Invalid Identity Header (bad signature)
  • 438 Invalid Identity Header (cert validity)

SIPREC

The first edition of the SIPREC track was a bit modest, since only two projects participated: OpenSIPS and Sippy Software. Nevertheless, it was a successful one, since at the end of the session we ended up with a new state-of-the-art SIPREC Server based on the Sippy Software stack.

The first step was to setup a SIP proxy, which was ensuring calls can easily be established between two participants. This was done using an OpenSIPS proxy. Then, for call recording, enabling the SIPREC module allowed us to act as an SRC (SIP Recording Client) and start new SIPREC calls to an SRS (SIP Recording Server). But at this point we had no Recording Servers projects, as no projects attended. So we ended up building one ourselves.

To that goal, as a second step, we ended up setting a new OpenSIPS instance that was acting as an SDP de-multiplexer, using the B2B SDP Demux module. The idea was to essentially split the recording/SIPREC call in two different calls, that were being sent to a FreeSWITCH instance for recording the media. With this setup, we were able to both place calls, and record them using the SIPREC protocol.

This is the step where the Sippy Software team joined the track and wanted to setup a new SRS (SIP Recording Server) using Sippy Software. This would replace our custom SRS built on top of OpenSIPS and FreeSWITCH, with a new stack based on Sippy Software and RTPProxy, leading to the same target: recording calls using the SIPREC protocol. This new project is open-source as well and can be found on GitHub as Sippy Recorder.

by Răzvan Crainea

DTLS Interop Testing

Since OpenSIPS does not handle media by itself, we initially skipped the DTLS track. However, we quickly realized that OpenSIPS can make itself useful in this track as well by providing access to WebRTC endpoints, which require DTLS for media. Thus, we created a WebRTC to UDP gateway by enabling the WebSocket interface in OpenSIPS. This would allow the other projects’ participants to originate calls with DTLS media from the browser and send them to the projects (i.e. Asterisk, Sippy Software) they were interested to test DTLS for.

by Răzvan Crainea

Hackathon

The hackathon ran in the last couple of days, with the main targetted topics being:

• real-time Text-to-Speech (building on top of Microsoft’s SpeechT5 — a pre-trained model for Text-to-Speech)
• New python package for running rtpproxy in an embedded fashion

While there were some monetary rewards up for grabs for completing any of the tasks in each class, our team went for some old-fashioned “paying off your technical debt”.

So, we used the hackathon in order to write some extra SIPssert tests for the OpenSIPS stir_shaken module in sipssert-opensips-tests, cementing the fact that the issues during the event are fixed and will not return again.

Conclusions

All in all, taking part in the latest OpenSIPIt online was a valuable experience, as we not only tested our software and fixed bugs, but also got a better feel for how other people/projects view topics such as security, testing or fine-tuning a production-ready implementation of a given specification.

We would like to give a big “Thank you!” to Maxim Sobolyev (Sippy Software) for making the event happen and for your efforts on bringing the community together: from mailing lists to building the website to scheduling and running the event.

Cheers, all! Looking forward to the next edition!