To describe a single SIP Session in IMS is not that easy as it maybe sounds and in the beginning it requires a lot of simplification. The purpose of the signaling over SIP is to establish a multimedia session over RTP (or MSRP). That means that SIP helps to locate the recipient and to negotiate the parameters of the RTP session. To do that we need one more protocol, called Session Description Protocol (SDP) which SIP carries in its body. The procedures for IMS describing this mechanism can be found in 3GPP 24.229.
SIP 3 Way Handshake
To set up a session the SIP protocol mandates the SIP INVITE request. It has to be answered by some final response – ideally with 200 OK. To confirm, that the client received the 200 OK message, it sends a special request SIP ACK. The SIP ACK is the only SIP request which doesn’t trigger any response on the server side. The procedure is also known as SIP 3-way handshake.
In this post we will go through a basic VoLTE flow from the SIP and SDP point of view.
SIP INVITE routing in VoLTE
Before we will jump in the SIP Signalling, let’s take a look on SIP INVITE routing within IMS.
From the last time we know that a UE is connected over SIP to P-CSCF. UE inserts the P-Preferred-Identity header in the message. The P-CSCF verifies the value based on the P-Associated-URI list it got during the registration and inserts the P-Asserted-Identity, which then identifies the originator in IMS network.
The P-CSCF has an information about what S-CSCF the UE belongs to. The S-CSCF after a successful registration provides a Third Party Registration (TPR) to Application Servers. That means that the S-CSCF knows that all the SIP INVITE messages coming from or going to a particular UE should be firstly forwarded to a Telephony Application Server (TAS) to apply Origination or Terminating Services. In more detail we will discuss the S-CSCF – AS communication in some other post.
The routing in SIP is done based on the Route headers and Request-URI. In case of VoLTE flow the R-URI contains sip or tel URI of the recipient. Once the TAS is finished with the Originating services for UAC, it sends the SIP INVITE to S-CSCF. S-CSCF is trying to find the routing based on the R-URI within the IMS network. There are more ways how to do it (e.g. to get the routing information from ENUM, via CAMEL, use MSC to route the message etc.). In the most basic scenario S-CSCF takes the R-URI and use the DNS to analyze the recipient’s domain in a similar way the P-CSCF does it during registration.
In a nutshell the S-CSCF ask’s the DNS, what is the server which is handling the SIP traffic for a given domain? The answer is obviously the I-CSCF of the recipient’s network. That applies even in the case that terminating I-CSCF belongs to the same network as the originating S-CSCF. The main functionality is to – based on a Diameter triggering – to find out what (terminating) S-CSCF is handling the recipient. Then it is easy, S-CSCF forwards the message to TAS to apply the terminating services, once we’re finished the S-CSCF has a linkage – again thanks to registration – to the right terminating P-CSCF and it also knows the current point of presence of the user so it can modify the R-URI. The P-CSCF is maintaining the path towards the UAS. So at least there are 9 elements involved in the signalling.
SDP Offer/Answer
If everything went fine, now the UAS has got the SDP Offer. The SDP Answer is usually sent – instead of a final SIP response – in a provisional response 183 Session in Progress message. Provisional responses are used to exchange information and to update the UAC about the progress of the session setup.
183 with SDP
The SDP contains parameters of the media session. The Originator and Recipient exchange the IP addresses (10.0.0.111 and 145.154.23150), ports (1111, 10005) and codecs (AMR-WB, AMR, telephone-events), parameters related to QoS and bandwidth, etc.
SDP updates by B2BUAs
Just remember that the media path is in fact split into several segments by Session Border Controllers (SBCs). For that reason B2BUAs have to modify the SDP offers/answers accordingly.
SIP INVITE in pcap on TAS
The first SDP answer is sent in a provisional 183 response. For the UAS it is important to know whether or not this response has been delivered. In SIP a server can request confirmations for provisional responses using a header Require with a value 100rel.
Require: precondition,100rel
Based on this header the client sends SIP PRACK – provisional acknowledgement, defined in RFC 3262. It is a request as any other and should be responded with 200 OK. In VoLTE it is given by the standard.
SIP PRACK is a request sent within a dialog. For routing such requests we use a Record-Route header and Contact header of the original INVITE/183. The URI from the contact header is set as the R-URI of new requests (within the dialog). In more detail we will discuss in a next post.
The second value of the Require header indicates that for VoLTE we shall use so-called preconditions. That means that the P-CSCF should reserve sufficient resources using Rx interface. The state of reservation is written in SDP (more information here). To let the both parties know that the resources have been reserved we have to exchange one more SDP offer/answer. They are sent within SIP UPDATE/200 OK messages.
PRACK/UPDATE on TAS
SIP UPDATE message is defined in RFC 3311 and can is used to update a session, but has no impact on the state of a dialog. It is similar to a re-INVITE, but it can be sent before the initial INVITE has been completed (200 OK).
SIP Session signalling flow
Only after the SDP is acknowledged, the UAS can start to ring. The ringing tone is typically generated locally by UAC. After the call is accepted by the B-party, the 200 OK response is sent. To finish the 3-way handshake, the UAC responds with SIP ACK and starts to communicate over RTP. As mentioned the parameters of the session can be later changed (e.g. put user on hold) by sending re-INVITE – an INVITE with a new SDP.
To close the session any of users can send SIP BYE and the other responds with 200 OK.
In more detail the SIP VoLTE registration and call setup are described in this post. But that is not the only way how to establish an RTP session. Technically it is also possible to play some announcements before or after the main session is started/finished. We talk about “early-media sessions”.
Related posts:
Real Time Communication 