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

I'm sure I belong to the large group of people who love to analyse network traces with tools like Wireshark. Being able to see the details of a packet or datagram down to the level of the bits is not only extremely useful, but also fascinating. Time ago I wrote a dissector for Wireshark, using the Lua interface, and that was fun (I see it's still available here ). The official recommendation  is to use Lua only for prototyping and testing, but when performances are not key and there isn't the intent to add the dissector to the official distribution, it's fast and effective. In order to parse network traces with audio and extract it into the payload first, and then decode it into a WAV file, C is a viable solution. I wrote about a program that does that here and since it attracted some attention and feedback I wrote an updated version later . More recently I wanted to identify programmatically the presence (and value) of DTMF tones - as RTP Events, RFC 2833 - in network ...

There are many scenarios where an application running inside a Kubernetes environment may need to interact with its API. For example, an application running inside a Pod may need to retrieve real time information about the availability of other applications' endpoints. This may be a form of service discovery that integrates or extend the native Kubernetes internal service discovery. In most cases, DNS records are associated to a Service and provide the list of active Endpoints for that Service, with a proper TTL. There are situations though where those DNS records are not available, an application is not able to use them directly, or what's needed is more than the private IP addresses associated with the Endpoints. If interacting with the Kubernetes API from inside an application is needed, then there are two main areas to consider: Authentication and Authorisation. Every Pod has a Service Account associated to it, and applications running inside that Pod can use that Service A...

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