Haven’t found the answer? Let us know!

Name: Steve F


Comment: Hi RTC! I have another question for you fine folks!

For the RCS protocol (Rich communication services), Do I have it correct in that it uses multiple other supporting protocols, for example it uses,
MSRP for the file transfer/video/and audio transfer of text messages? Is it using RTP to send the packets, or is MSRP itself the protocol that is used for transport through the media/data? I know it uses SIP for signaling I believe.

2. When a MSRP INVITE is sent, this seems to mirror what happens during a regular SIP INVITE…and normally the signaling connection is kept open during the duration of the call… But how is this with a text message? Is the SIP connection literally opened just for the duration of a few seconds to send the message then immediately removed? It seems like these SIP signaling connections would be opened and closed almost instantly? it says that the RCS implementation of MSRP uses TCP (hence SIP) instead of the WebRTC’s use of UDP…but is it me or does this seem a bit…wasteful for such quick connections?

3. Do you guys have any call flows in regards to a RCS communication setup regarding a Text message with some sort of media involving the SIP and data paths?

4. What’s the difference when the device sends the message literally inside the SIP messages, and when it sends it through the Data portion using the media gateway? Does RCS use both methods? or does newer RCS implementations only use the media gateway to send the data of the text message? Is sending the text through the SIP messages still used?

Thanks and hope to hear back soon!



Hi Steve,

to answer your questions we would need firstly to explain all the RCS/RCSe/RCS UP history. In a great shortcut – originally the plan was to use MSRP for all the media (voice/video/files/messaging).  However it was kind of difficult to implement this omnipotent service, so some compromises were done – e.g. for file sharing some operators used http, for messaging so-called pager mode.

Currently the latest version called RCS Universal Profile aka Advanced Messaging does use MSRP only for instant messaging in Session Mode Messaging. To establish an MSRP session you need to send SIP INVITE, where SDP contains MSRP media description.

Otherwise for file transfer RCP UP doesn’t use MSRP anymore, http has been chosen as the final solution. And finally for video/voice we use RTP protocol – as a matter of the fact, voice and video is now supported by VoLTE part of the network (VoLTE and RCS are merged now).

And last but not least we can still send an SMS within SIP – that’s what we remain at least for 5G – that is supported by IPSMGW.

The details and call flows are explained in the referenced articles. Would there be any questions, let me know.

Kind Regards,



Name: Steve F.
Comment: Hello there! Love the blog and appreciate the hard work you put in! Working in the industry I can use your blog as a reference. My question to you is for SIP, we use port 5060 for normal unencrypted signaling. And we use 5061, but besides setting up the TLS connection, what else is 5061 used for? In our wireshark traces there’s communication back and forth between the UE device and our PCSCF SBC, that is using 5061. BUt there’s also a bunch of other traffic between the Device and the SBC that is using 5061, what type of other SIP traffic needs to be encrypted? As far as I know there’s no voice data correct? So what SIP signaling messages would need to be encrypted? I’m attaching two images just as a reference for you as to what I see… I’m just a bit confused as to why certain SIP messages are encrypted adn which one’s aren’t.. Thanks and hope to hear back from you!

“I have not failed, I have found 10,000 ways that will not work.”

Hello Steve,

Ports 5060 and 5061 are kind of default ports. 5060 is used for SIP and 5061 for SIPS (SIP over TLS). In more detail we discussed in SIP Illustrated 3: Routing and IMS Registration or DNS article. The relevant RFC is 3263 – Locating SIP Servers.

In the traces you shared I can see a TLS setup. In general the decision whether on not to encrypt the communication is up to the operator. Some do it, some not (as the VoLTE traffic goes through the internal traffic anyways). So typically if you use TLS, all the SIP communication between UE and P-CSCF – except the initial SIP REGISTER – goes over SIPS. The signalling inside the IMS goes over SIP only.

And correct, SIP is used just for signalling (unless we talk about DTFM). Voice data is sent out-of-band using RTP protocol. This can be encrypted as well, e.g. using SRTP.


Kind Regards,



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


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.