Posts Tagged ‘PRACK’

This is a summary of what I hope to be able to describe in the next several posts: the establishment of a basic SIP-IMS call flow, in a somewhat interesting scenario: when both Alice and Bob are in roaming.

Each of the participants talks to his/her own P, S and I servers. Here the presumption is that Alice is the one making the phone call.

sip-ims-call

Advertisements

“c1” because…mwell, because “a” was the register and 4G/IMS architecture, “b” was the OpenIMSCore and “c” should be an actual call flow.

Unfortunately, I cannot show you the actual 4G encapsulation, because I don’t have any tool to emulate that, but, as we’ve understood from the registration flow, each IMS message coming from or going to the IMS mobile device will be encapsulated in GTPv1-u header between the eNodeB, SGW, PGW and then forwarded, without the GTPv1-u encapsulation, to the P-CSCF. Juuust as for the Register flow…

4g-ims

Oook, now let’s take a look at the IMS-SIP call flow. Basically, what I’m going to show here is a Basic Call with Voice.

Now, the most basic SIP (Session Initiation Protocol) call flow has the following structure:

sip-basic

Basically, Alice sends an INVITE message to Bob (via a sip proxy server or directly), inviting Bob to a voip message exchange, and also sending in the SDP (Session Description Protocol) header (presented as a SIP message body), the RTP (Real-Time Protocol) codecs that Alice’s phone is supporting. 1xx is provisional messaging. 100 Trying and 180 Ringing is a good sign, they mean I am actually contacting Bob, I am just waiting for him to pick-up the phone. When he does that, his device signals a 200 OK (sending in this message also the RTP codecs known by Bob’s device), and Alice’s device Acknowledges. Now the RTP session can begin, with one of the matching codecs. Once the two guys finish talking, Alice’s phone (usually) is the one signaling the end of the conversation, by sending a BYE message to Bob, and this one acknowledges. Alice can also send her supported RTP codecs barely in her ACK message, procedure called late negotiation.

Now, this may rightfully seem simple enough, but wait! We haven’t yet got to the IMS part 🙂

The same “basic” SIP call flow in the IMS context would look like this (of course, excluding the 4G encapsulation which we’ve agreed we understand):

sip-basic-IMS

In the next chapter I’ll detail these messages.

For the moment, let’s just observe the presence of a weird new message called PRACK. The PRACK is defined in RFC3262: Reliability of Provisional Responses in the Session Initiation Protocol (SIP). The RFC 3262 states:

   The PRACK request plays the same role as ACK, but for
   provisional responses.  There is an important difference, however.
   PRACK is a normal SIP message, like BYE.  As such, its own
   reliability is ensured hop-by-hop through each stateful proxy.  Also
   like BYE, but unlike ACK, PRACK has its own response.  If this were
   not the case, the PRACK message could not traverse proxy servers
   compliant to RFC 2543 [4]."

I believe the IETF guys are pretty explanatory 🙂

See you in the next chapter.