Monitoring SIP traffic on Kamailio with an observability stack based on Vector, Loki and Grafana
Effective operation of a VoIP platform requires end-to-end visibility into signaling activity, traffic patterns, system load and failure conditions. Achieving this level of observability is essential for troubleshooting issues, understanding traffic behavior, and ensuring service reliability. In a Kamailio based SIP infrastructure, a monitoring stack composed of Vector, Loki and Grafana offers a scalable and efficient approach to collecting, enriching, storing and visualizing SIP signaling data, providing useful insights into real-time traffic and system performance.
Warpgate SSO integration
In the previous post on Warpgate, we saw how to configure two-factor authentication for SSH access to servers on private network. Here, instead, we are going to analyze the possibility of integrating Single Sign-On authentication into the system. One of the most interesting aspects of Warpgate is the possibility of integrating Single Sign-On authentication with enterprise providers such as Microsoft Entra ID (Azure AD). Thanks to support for standard protocols such as OpenID Connect (OIDC) and SAML 2.0, Warpgate can completely delegate the authentication process to the corporate identity management system, allowing users to access using the same Microsoft credentials already adopted for other corporate services.
Warpgate MFA via TOTP
Warpgate is an open-source secure access solution with bastion host capabilities for SSH servers, databases, Kubernetes, and web services, centralizing authentication, authorization, and auditing. It is not a jump host, but rather acts as an intermediate gateway between users and the internal infrastructure. Warpgate authenticates users via SSO/MFA, applies granular access policies, records sessions, and forwards connections to authorized resources without directly exposing the internal network or requiring VPN connections. In short, it is an excellent solution for granting access to resources that are not directly exposed to the Internet.
Kamailio and RTPEngine, an Open Source SBC
A SIP SBC (Session Border Controller) is designed to isolate external VoIP traffic from the traffic generated within the private subnet, ensuring the correct signaling and media flows between the external and internal networks, and vice versa. The term “Border” refers to a point of demarcation, as an SBC is located at the edge of the network and represents the boundary between the internal network and Internet. For example, suppose we have a VoIP phone (using the SIP protocol) inside a LAN, and this phone needs to receive calls from a public VoIP provider, which is necessarily located on the Internet. To communicate directly, the phone would need a public IP, which would represent a security risk for our network. The solution is called SBC, which, deployed between the LAN and the Internet, decouples the public call leg - from the provider to SBC public interface - from the private call leg between its private interface and the internal LAN elements.
Kamailio permission module
The permission module includes features and controls to create ACLs based on source IP, From, Request Uri. This allows to control who can do what, for example whether requests arriving from a certain source IP can be rotated to the destination, or whether a certain SIP Uri can be handled or must be rejected.
Kamailio SecureSIP gateway with rtpengine
In previous posts we have already discussed about rtpengine and how to use it with Kamailio to manage NAT or voice transcoding. In this article we’ll see how to use Kamailio with the TLS module and rtpengine to create a TLS/SRTP proxy, which on the first call leg uses secure SIP with TLS and SRTP and on the second leg uses UDP and RTP. In this way we will have the possibility to add Secure SIP support to existing media servers that only support UDP transport with RTP, adding security. The SRTP (Secure RTP) protocol is used with SIP over TLS and transmits voice in encrypted IP packets, avoiding the interception and decoding of audio packets.
Kamailio with TLS module
The “tls” module is specifically designed to add TLS (Transport Layer Security) support at the TCP transport level, and allows to manage traffic that uses SIPS (SIP Secure) for SIP encryption. All details are available on the official Kamailio documentation for the [tls] module (https://kamailio.org/docs/modules/stable/modules/tls.html). Here we will see how to activate it on our Kamailio installation.
Genesys Cloud Third Party ChatBot integration
With the introduction of the WebChat APIs in Genesys Cloud it is now possible to integrate your external ChatBot with the Genesys platform offering an interesting user experience for users. By taking advantage of the WebChat APIs you can, for example, develop your own ChatBot that welcomes users with the possibility of switching between ChatBot and real Agent on Genesys Cloud, also making the history of the conversation that the user had with the BOT available to the agent.
Genesys Cloud integration with SIP external IVR, transfer back to Genesys
In the previous post we configured a BYOC SIP Trunk on Genesys Cloud and transferred a call from a Genesys flow to an external IVR. Here we will see how to return the call back to the Genesys after connected it with the external IVR.
In summary, we have a user who is connected with an Architect voice flow in Genesys Cloud, the user is transferred via SIP to an external IVR and from there he is transferred back into Genesys Cloud, on the same flow or on any other flow.
Genesys Cloud integration with SIP external IVR
In the last days I have had the opportunity to experiment a bit with the Genesys Cloud platform and I decided to write a couple of articles on integration with external systems, in particular on the possibility of transferring call to an external IVR and then resuming it on the Genesys flow, but also on chat integration capabilities. The purpose of this first article is to describe how to handle the first case, transferring a call from a Genesys flow to an external IVR.