An IMS Analysis Challenge – Find the answers to the questions through analysis of PCAPs.
Tag Archives: VoLTE
Improving WiFi Calling quality for WiFi Operators
Profiling ePDG addresses to provide a better experience for Voice over WiFi users on your WiFi network.
Verify Android Signing Certificate for ARA-M Carrier Privileges in App
Calculating SHA-1 Digest of an Android App to be used on the SIM to grant Carrier Privileges
Authenticating Fixed Line Subscribers into IMS
A look at how PyHSS handles fixed line subscribers attaching to an IMS Network
IMS iFC – SPT Session Cases
Valid Session Cases for use in an IMS iFC
SQN Sync in IMS Auth
A look at how the SQN resync procedure is performed in the IMS Authentication flows
SMS-over-IP Message Efficiency – K
How much overhead is used to send the message “K” back to an SMS?
Kamailio I-CSCF – SRV Lookup Behaviour
Recently I had a strange issue I thought I’d share. Using Kamailio as an Interrogating-CSCF, Kamailio was getting the S-CSCF details from the User-Authorization-Answer’s “Server-Name” (602) AVP. The value was set to: sip:scscf.mnc001.mcc001.3gppnetwork.org:5060 But the I-CSCF was only looking up A-Records for scscf.mnc001.mcc001.3gppnetwork.org, not using DNS-SRV. The problem? The Server-Name I had configured as a … Continue reading Kamailio I-CSCF – SRV Lookup Behaviour
Sending SMS with an alphanumeric String as the Source
If you’ve ever received an SMS from your operator, and the sender was the Operator name for example, you may be left wondering how it’s done. In IMS you’d think this could be quite simple – You’d set the From header to be the name rather than the MSISDN, but for most SMSoIP deployments, the … Continue reading Sending SMS with an alphanumeric String as the Source
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.
FreeSWITCH as an IMS Application Server
Using FreeSWITCH as an IMS Application Server
Lifecycle of a Dedicated Bearer – From Flow-Description AVP to Traffic Flow Templates
A look at how Dedicated Bearers get established for VoLTE.
Basics of EPC/LTE Online Charging (OCS)
A glimpse into the complexities of prepaid billing (Online Charging) Diameter based networks.
Docker & BIND as an ENUM Playground
A Bind environment in a Docker container for experimenting and learning ENUM for DNS based Call Routing.
IMS Routing with iFCs
Peer behind the magic curtain at how IMS networks route your VoLTE and VoNR calls, and how iFC (Initial Filter Criteria) achieve this.
Adding support for AMR Codec in FreeSWITCH
Adding support for AMR Codec in FreeSWITCH
The Surprisingly Complicated world of MO SMS in IMS/VoLTE
Short messaging can be anything but simple…
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