A look at how PyHSS handles fixed line subscribers attaching to an IMS Network
Tag Archives: SIP
IMS iFC – SPT Session Cases
Valid Session Cases for use in an IMS iFC
HOMER API in Python
Interacting with Homer SIP capture vai the API
Failures in cobbling together a USSD Gateway
Adventures in setting up a non-working USSD Gateway for IMS
Kamailio Bytes: Adding Prometheus + Grafana to Kamailio
Adding Prometheus support to Kamailio and rendering stats in Grafana
SMS-over-IP Message Efficiency – K
How much overhead is used to send the message “K” back to an SMS?
Get all the FreeSWITCH Folder Paths
A simple trick to find all the system paths used in FreeSWITCH
CGrateS in Baby Steps – Part 4 – Rating Calls
In our last few posts we got CGrateS setup in order to have rates and tariffs in the system, so we can price a call. Where we ended we were able to use the APIerSv1.GetCost method to get the cost of a call, and today, we’re going to actually create some rated CDRs. So again … Continue reading CGrateS in Baby Steps – Part 4 – Rating Calls
Kamailio Bytes – Extracting SDP Parameters with Kamailio
Extracting SDP Parameters with Kamailio
FreeSWITCH – Incompatible Destination
A quick look at a possible cause for “INCOMPATIBLE DESTINATION” errors in FreeSWITCH.
FreeSWITCH, Kamailio & IMS Extensions
Recently I’ve been doing some work with FreeSWITCH as an IMS Conference Factory, I’ve written a bit about it before in this post on using FreeSWITCH with the AMR codec.
Pretty early on in my testing I faced a problem with subsequent in-dialog responses, like re-INVITEs used for holding the calls.
Every subsequent message, was getting a “420 Bad Extension” response from FreeSWITCH.


So what didn’t it like and why was FreeSWITCH generating 420 Bad Extension Responses to these subsequent messages?
Well, the “Extensions” FreeSWITCH is referring to are not extensions in the Telephony sense – as in related to the Dialplan, like an Extension Number to identify a user, but rather the Extensions (as in expansions) to the SIP Protocol introduced for IMS.
The re-INVITE contains a Require header with sec-agree which is a SIP Extension introduced for IMS, which FreeSWITCH does not have support for, and the re-INVITE says is required to support the call (Not true in this case).
Using a Kamailio based S-CSCF means it is easy to strip these Headers before forwarding the requests onto the Application Server, which is what I’ve done, and bingo, no more errors!
The Surprisingly Complicated World of SMS: Apple iPhone MT SMS
Quirks and gotchas of working with SMS on IMS on iPhones.
Handling multiple SIP headers with the same name in Kamailio
Some tricks to handle if you’ve got multiple headers all with the same name in Kamailio
Originating calls in FreeSWITCH
Starting calls from FreeSWITCH
VoIP is an only child – ‘Gotchas’ on running VoIP applications inside Containers
It’s 2021, and everyone loves Containers; Docker & Kubernetes are changing how software is developed, deployed and scaled. And yet so much of the Telco world still uses bare metal servers and dedicated hardware for processing. So why not use Containers or VMs more for VoIP applications? Disclaimer – When I’m talking VoIP about VoIP … Continue reading VoIP is an only child – ‘Gotchas’ on running VoIP applications inside Containers
Kamailio Bytes – OnReply Route
So far with most of our discussions about Kamailio we’ve talked about routing the initial SIP request (INVITE, REGISTER, SUBSCRIBE, etc), but SIP is not a one-message protocol, there’s a whole series of SIP messages that go into a SIP Dialog. Sure the call may start with an INVITE, but there’s the 180 RINGING, the … Continue reading Kamailio Bytes – OnReply Route
SIP Hold – With RFC6337
How SIP hold using RFC6336 is implemented and how it looks in production.
FreeSWITCH + ESL = Programmable Voice
An overview of FreeSWITCH’s ESL
Diameter and SIP: Registration-Termination-Request / Answer
These posts focus on the use of Diameter and SIP in an IMS / VoLTE context, however these practices can be equally applied to other networks. The Registration-Termination Request / Answer allow a Diameter Client (S-CSCF) to indicate to the HSS (Diameter Server) that it is no longer serving that user and the registration has … Continue reading Diameter and SIP: Registration-Termination-Request / Answer
Diameter and SIP: User-Authorization-Request/Answer
These posts focus on the use of Diameter and SIP in an IMS / VoLTE context, however these practices can be equally applied to other networks.
The Diameter User-Authorization-Request and User-Authorization-Answer commands are used as the first line of authorization of a user and to determine which Serving-CSCF to forward a request to.
Basics
When a SIP Proxy (I-CSCF) receives an incoming SIP REGISTER request, it sends a User-Authorization-Request to a Diameter server to confirm if the user exists on the network, and which S-CSCF to forward the request to.
When the Diameter server receives the User-Authorization-Request it looks at the User-Name (1) AVP to determine if the Domain / Realm is served by the Diameter server and the User specified exists.
Assuming the user & domain are valid, the Diameter server sends back a User-Authorization-Answer, containing a Server-Capabilities (603) AVP with the Server-Name of the S-CSCF the user will be served by.
I always find looking at the packets puts everything in context, so here’s a packet capture of both the User-Authorization-Request and the User-Authorization-Answer.
First Registration
If this is the first time this Username / Domain combination (Referred to in the RFC as an AOR – Address of Record) is seen by the Diameter server in the User-Authorization-Request it will allocate a S-CSCF address for the subscriber to use from it’s pool / internal logic.
The Diameter server will store the S-CSCF it allocated to that Username / Domain combination (AoR) for subsequent requests to ensure they’re routed to the same S-CSCF.
The Diameter server indicates this is the first time it’s seen it by adding the DIAMETER_FIRST_REGISTRATION (2001) AVP to the User-Authorization-Answer.

Subsequent Registration
If the Diameter server receives another User-Authorization-Request for the same Username / Domain (AoR) it has served before, the Diameter server returns the same S-CSCF address as it did in the first User-Authorization-Answer.
It indicates this is a subsequent registration in much the same way the first registration is indicated, by adding an DIAMETER_SUBSEQUENT_REGISTRATION (2002) AVP to the User-Authorization-Answer.
User-Authorization-Type (623) AVP
An optional User-Authorization-Type (623) AVP is available to indicate the reason for the User-Authorization-Request. The possible values / reasons are:
- Creating / Updating / Renewing a SIP Registration (REGISTRATION (0))
- Establishing Server Capabilities & Registering (CAPABILITIES (2))
- Terminating a SIP Registration (DEREGISTRATION (1))
If the User-Authorization-Type is set to DEREGISTRATION (1) then the Diameter server returns the S-CSCF address in the User-Authorization-Answer and then removes the S-SCSF address it had associated with the AoR from it’s own records.
Other Diameter Cx (IMS) Calls
User-Authorization-Request / User-Authorization-Answer
Server-Assignment-Request / Server-Assignment-Answer
Location-Info-Request / Location-Info-Answer
Multimedia-Auth-Request / Multimedia-Auth-Answer
Registration-Termination-Request / Registration-Termination-Answer
Push-Profile-Request / Push-Profile-Answer
References:
RFC 4740 – Diameter Session Initiation Protocol (SIP) Application