Haven’t found the answer? Let us know!

Name: Chris Ghost World
Comment: Hello! Greetings from Nokia of North America! I’m working in our IMS/VoLTE labs, and I’m still quite new, so I find your blog immensely impressive and a wealth of knowledge! Please don’t stop! I love your content. Anyway do you have any plans to do any articles on TLS / Authentication and how it works with OTT devices and other VoLTE devices? Right Now I’m a bit confused as to how OTT clients use TLS, do they do it for authetnicating the proxy pcscf? or do they use it just to create a secure channel when they register? In our setup, our OTT – PCSCF Register TLS is client only, mutual authentication isn’t required. Why is this? Why doesn’t the Pcscf authenticate the incoming device as well when it registers?

Thanks! Hope to hear back!

Time: January 27, 2018 at 17:20


Name: Chris Ghost World
Comment: Hello! Greetings from Nokia of North America! So, I come back to your site (wonderful site that is) with another question… Let’s say the UE has two OTT appls on his phone. For example purposes let’s say Skype and Message+. Both are on the same device so the share the same user number. Both clients are launched and attempt to register to the networks IMS Core, first hitting the P-CSCF. Can both clients be registered at the same time to the same PCSCF? From the PCSCF’s point of view, won’t it see two registration attempts from the same number? Or does the port it’s come differ, allowing it to have a distinct flow?

Time: June 6, 2021 at 20:27


Dear Chris,

Firstly, if we are talking about VoLTE/5G IMS, we don’t expect Skype to be registered with IMS 🙂 Anyways in general yes, we can get OTT to register with IMSCore – e.g. typically because the device doesn’t have a native support of VoLTE. Then we can have many registrations for the same public identity, even registered with the same IP (can be one device, but more often it’s because of NAT). And port number is sufficient to distinguish a unique point of contact. In fact we always work with a triple IP:Port:Protocol. Some more details in RFC 3263.

Kind Regards,


Dear Chris,

firstly thank you for reading and support 🙂

As for the question. I’m not sure I completely understand (any pcaps?). So let me describe the standard TLS. By OTT clients I understand apps accessing SBC directly from public Internet. (Not to be confused with VoWifi clients, which have IPSec tunnel with ePDG.)


The TLS support in IMS is described in 3GPP TS 33.203, Annex O, 24.229 and RFC 3329. The TLS encrypted communication is established during the first time Registration. For OTT we typically use SIP Digest authentication.

  • The P-CSCF receives only the initial REGISTER on the unprotected connection when TLS is employed. UE determines the usage of TLS in the Security-Client header in the initial REGISTER.
  • The 401 Challenge. To indicate to UE that P-CSCF supports TLS the P-CSCF adds Security-Server header with security-mechanism set to “tls”.
  • UE validates the TLS certificate of the network.
  • The subsequent REGISTER with credentials is received on the protected connection.
  • P-CSCF forwards the REGISTER request with credentials to S-CSCF with “integrity-protected” parameter as “tls-pending” in Authorization header.


  • In order for the UE to be able to trust the TLS session, the P-CSCF certificate has to be used during the authentication procedure.
  • In order for the P-CSCF to be able to trust that the UE, the P-CSCF has to use the mechanism for associating the TLS Session ID with registration parameters IP address, port, IMPI, IMPU(s).
  • The lifetime of a Session ID is subject to local policies of the UE and the P-CSCF. A recommended lifetime is one hour (or at least more than the re-REGISTRATION time out).

The TLS Call Flow can look like this:

SIP Registration with TLS

Any subsequent Re-Registrations are received over TLS and P-CSCF inserts “integrity-protected” parameter as “tls-yes” in Authorization header towards S-CSCF. All the other subsequent messages (e.g. SIP INVITE, SIP SUBSCRIBE, etc.) are received only on the protected connection. Unprotected messages are rejected by P-CSCF.

(Note, that when proxy is used, it can respond with 407 to new SIP messages. The logic is similar to 401 scenario. However haven’t seen this in T1 networks.)

I hope it answers some of your questions. Technically it is possible that authentication along with TLS/IPSec is provided by some additional Application Proxy (AP). But that is operator specific.

Kind Regards,


Name: John A
Comment: Hi,
could you write something about VoLTE codecs? What codecs are mandatory for VoLTE?

Time: November 22, 2017 at 07:56


Hi John,

thank you for the question. IR.92 has mandated AMR / AMR-WB codecs to be used for VoLTE. Other codecs may be also used in addition to the AMR codecs.

  • The UE must support the AMR, including all 8 modes and source rate controlled operations (3GPP TS 26.093). Moreover the UE has to be capable of operating with any subset of these eight codec modes.
  • The UE must support AMR-WB including all nine modes and source controlled rate operation (3GPP TS 26.193). Again the UE has to be capable of operating with any subset of these nine codec modes.
  • If the EVS codec is supported, then the EVS AMR-WB IO mode may be used as an alternative implementation of AMR-WB.
  • If super-wideband or fullband speech communication is offered, then the UE must support the EVS codec.

More info added into  VoLTE flows – close encounters.