IMS
Registration

IMS Registration is the most important steps of all IMS process (except Emergency Call). The first step to learn IMS should be to understand every details related to IMS registration. In this page, I would describe the IMS Registration not only in terms of protocol sequence but also in terms of data flow in network architecture. This page would focus on overall data path and protocol sequence for IMS Registration, but would not look into the very details of each message. If you are intersted in the details of each message, refer to Message Example : REGISTER page. (If you are interested in other messages for various IMS/SIP protocol, refer to Message Example page)

Contents

TIPS : If you are working on UE verification / testing job, you SHOULD know all the details of two important SIP message which is REGISTER and INVITE. A lot of IMS testing issue comes just from the parameter mismatch between UE configuration and equipment setting. So it is VERY, VERY, VERY important to have all the informations about UE configuration or capabilities that are required to set the test equipment setting. At first, I wrote a long Check List and ask the customer to provide those information. This list is from my personal experience of many years of IMS testing and seems I could find the solution for most of the problem if I have the correct information for each items in the list. But almost nobody provided me with these informations.. I don't even know if they even read through the list :). So next thing I have been trying is to say 'Just capture SIP REGISTER message from Wireshark and send it to me please. No problem if call fails right after the REGISTER. I just need REGISTER message'. From this message, I can find out most of the information that I need for equipment setting at least for the IMS Registration step. (If UE does not even try REGISTER, then you need to go to CheckList page. There is no other short-cut solution for this case).  And then, if REGISTER process can be complete, I would say 'Just try to make a call capture SIP INVITE message from Wireshark and send it to me please. No problem if call fails right after the INVITE. I just need INVITE message'. From this message, I can find out most of the information that I need for equipment setting for the VoLTE setup procedure.

IMS Registration - Signal Flow in Network Architecture

Following illustration is based on the IMS registration sequence posted on EventHelix. I converted the sequence diagram into IMS architecture diagram so that you can get some better idea of interplay of each components.

Try to follow the big picture and understand overall logic. The very detailed sequence and parameters may vary depending on the network organization. So the log you collected from a specific network may be different from what you see here. If you have a log from a test equipment, it may be simpler than what you see here.

In Full IMS registration, it can be split into three major process as shown below.

  • Unauthenticated IMS Registration Attempt
  • IPSec Security Association Establishment
  • Authenticated IMS Registration

Simplified Registration Procedure

Even though the long procedure shown above is what's going on in live network, it would be a little bit overwhelming for many people (including me :). Also it would be very difficult for you to get the trace log showing all of these steps combined. In most case, you would relatively easily get the logs between UE and eNB (or Test Equipment).

Following is a kind of Simplified protocol sequence for Authenticated IMS Registration. You would see this kind of simplified process when you are testing IMS device with test equipment. (But basic idea is same as in real network). For the detailed contents of each steps and SIP messages, refer to Basic Procedure : Authenticated Registration

Unauthenticated IMS Registration Attempt

Following is the first main procedure - Unauthenticated IMS Registration Attempt.

This first REGISTER is not expected to complete the registration. Its main purpose is to let the UE reach the IMS core, let the network identify the subscriber, and trigger IMS AKA authentication. The result of this phase is normally a 401 Unauthorized response carrying the challenge information that the UE will use in the next REGISTER.

(1) : REGISTER  (Path : UA1 --> eNodeB --> S-GW --> P-GW --> P-CSCF)

SIP REGISTER message go through all the LTE radio access network and arrives at P-CSCF first (All the IMS/SIP message goes through P-CSCF). There can be wide differences in terms of the detailed parameters, but typical format of SIP REGISTER message would like as follows.

At this point the UE has IP connectivity and knows the P-CSCF address, but it has not yet proved its IMS identity. The REGISTER therefore carries basic identity, routing, contact, and security capability information rather than a valid authentication response.

    REGISTER sip:hims.net SIP/2.0,

    Via: SIP/2.0/UDP UE-IP;branch=0abab,

    Route: sip:[P-CSCF-IP], // Route specifies the IP of next node for this REGISTER to reach. In this case,

    This SIP message clip highlights the following parameters: Via, Route. Use these fields to correlate routing, dialog identity, transaction sequencing, registration/session state, security context, and media negotiation for this part of the procedure.

                                     //'Next Node' is P-CSCF

    Max-Forwards: 20,

    From: <sip:name@hims.net>;tag=abbb,

    To: <sip:name@hims.net>,

    Contact: <sip:[UE-IP]>;expires=90000,

    Call-ID: ababab,

    CSeq: 25 REGISTER,

    Security-Client: port-s, port-c,

    Authorization: Digest username = name.private@hims.net,

    Content-Length: 0

    This SIP message clip highlights the following parameters: Contact, Authorization, Security-Client, Expires, CSeq, Call-ID, From, To, Content-Length, Max-Forwards. Use these fields to correlate routing, dialog identity, transaction sequencing, registration/session state, security context, and media negotiation for this part of the procedure.

This REGISTER clip highlights the Request-URI, Via, Route, Max-Forwards, From, To, Contact, Call-ID, CSeq, Security-Client, Authorization, and Content-Length parameters. Pay special attention to Route, Contact, Security-Client, and Authorization because they decide the next hop, UE contact binding, IPSec capability, and private user identity used for registration.

Note : Since this step is 'REGISTER' process, 'Authentication' parameter does not carry any specific information for Authentication algorithm. Following is one example that I captured from test equipment.

    Authorization: Digest uri="sip:test.3gpp.com",

    This SIP message clip highlights the following parameters: Authorization. Use these fields to correlate routing, dialog identity, transaction sequencing, registration/session state, security context, and media negotiation for this part of the procedure.

          username="001010123456789@test.3gpp.com",

          response="",

          realm="test.3gpp.com",

          nonce=""

          This SIP message clip highlights the following parameters: nonce, response, realm. Use these fields to correlate routing, dialog identity, transaction sequencing, registration/session state, security context, and media negotiation for this part of the procedure.

This Authorization clip shows the uri, username, response, realm, and nonce parameters. In this unauthenticated REGISTER, response and nonce are empty, so the header mainly identifies the subscriber and the home realm before the network sends the real authentication challenge.

(2): DNS Query (Path : P-CSCF --> DNS Server)

Once P-CSCF get the SIP REGISTER, it has to find I-CSCF to pass the message to. To find the I-CSCF, P-CSCF to perform DNS query process (there can be other mechanism to find I-CSCF).

At first, P-CSCF send DNS Query to DNS server requesting IP address of I-CSCF.

This step is the IMS core routing decision from the visited/access side toward the home IMS domain. In a live network, DNS may return one or more candidate I-CSCF addresses and the P-CSCF selects where to forward the REGISTER.

    DNS Query for I-CSCF IP

(3): DNS Response (Path : DNS Server --> P-CSCF)

DNS server send response to P-CSCF with I-CSCF IP address.

After this response, the P-CSCF has enough routing information to send the REGISTER toward the home network entry point. No subscriber authentication has happened yet; this is still only routing preparation.

    DNS Response for I-CSCF IP

(4) : REGISTER (Path : P-CSCF --> I-CSCF)

Now P-CSCF forward the SIP REGISTER to I-CSCF.

The P-CSCF adds itself into the SIP path, usually by adding a Via header and preserving information needed for later routing back to the UE. From this point, the home network starts deciding which S-CSCF should handle this subscriber.

    REGISTER sip:hims.net SIP/2.0,

    Via: SIP/2.0/UDP pcscf1.vims.net;branch=0aab1,

    Via: SIP/2.0/UDP UE-IP;branch=0abab,

    Max-Forwards: 19,

    From: <sip:name@hims.net>;tag=abbb,

    To: <sip:name@hims.net>,

    Contact: <sip:[UE-IP]>;expires=90000,

    Call-ID: ababab,

    CSeq: 25 REGISTER,

    Content-Length: 0,

    Authorization: Digest username = name.private@hims.net integrity protection:no

    This SIP message clip highlights the following parameters: Via, Contact, Authorization, Expires, CSeq, Call-ID, From, To, Content-Length, Max-Forwards. Use these fields to correlate routing, dialog identity, transaction sequencing, registration/session state, security context, and media negotiation for this part of the procedure.

This forwarded REGISTER clip highlights the added Via parameter for the P-CSCF, the original Via parameter from the UE, Contact, CSeq, Content-Length, and Authorization. The integrity protection value in Authorization is important here because it indicates that this first REGISTER is not yet protected.

(5) : User Authorization Request (Path : I-CSCF --> HSS)

Once I-CSCF got the SIP REGISTER message, it talks talks to HSS to get the detailed subscriber information for the UA.

And with UAR (Diameter User Authentication Request), HSS retrieves authentication information and S-CSCF information. (This is very simplified description, in reality this process would be much more complicated).

The I-CSCF does not normally keep full subscriber profile information by itself. It asks the HSS whether this user is known, whether registration is allowed, and which S-CSCF name or capability set should be used for this registration attempt.

(6) : User Authorization Answer (Path : HSS --> I-CSCF)

With  UAA(Diameter User Authentication Answer), HSS send Authorized Answer and S-CSCF information to I-CSCF.

The answer gives the I-CSCF the information it needs to continue routing. Depending on operator configuration, it may contain a specific S-CSCF name or enough capability information for the I-CSCF to select an S-CSCF.

    S-CSCF Name,

    S-CSCF Capabilities

(7) : REGISTER (Path : I-CSCF --> S-CSCF)

Now I-CSCF forward the REGISTER message to S-CSCF.

The S-CSCF is the node that will own the registration state after authentication succeeds. This forwarded REGISTER therefore brings the subscriber identity, contact information, and route history to the server that will later validate the authentication response.

    REGISTER sip:hims.net SIP/2.0,

    Via: SIP/2.0/UDP icscf1.hims.net;branch=0aab2,

    Via: SIP/2.0/UDP pcscf1.vims.net;branch=0aab1,

    Via: SIP/2.0/UDP UE-IP;branch=0abab,

    Route: sip:scscf1.hims.net,Max-Forwards: 18,

    From: <sip:name@hims.net>;tag=abbb,

    To: <sip:name@hims.net>,

    Contact: <sip:[UE-IP]>;expires=90000,

    Call-ID: ababab,

    CSeq: 25 REGISTER,

    Content-Length: 0,

    Authorization: Digest username =name.private@hims.net integrity protection:no

    This SIP message clip highlights the following parameters: Via, Route, Contact, Authorization, Expires, CSeq, Call-ID, From, To, Content-Length, Max-Forwards. Use these fields to correlate routing, dialog identity, transaction sequencing, registration/session state, security context, and media negotiation for this part of the procedure.

This REGISTER clip shows how the I-CSCF forwards the request to the S-CSCF. The key parameters are the Via stack, Route, Max-Forwards, Contact, CSeq, Content-Length, and Authorization. The Route parameter points to the selected S-CSCF, while the Via stack preserves the reverse path for later responses.

(8) : Multimedia Authentication Request  (Path : S-CSCF --> HSS)

S-CSCF send MAR (Multimedia Authentication Request) to HSS.

At this stage the S-CSCF asks the HSS for IMS AKA authentication vectors. These vectors contain the challenge material and keys needed to authenticate the UE and to prepare integrity protection parameters.

(9) : Multimedia Authentication Response  (Path : HSS --> S-CSCF)

HSS sends MAA (Multimedia Authentication Answer) to S-CSCF with the following information.

The S-CSCF stores the selected vector so it can later compare the UE response in the authenticated REGISTER. This is the point where the network side has prepared the challenge but has not yet sent it to the UE.

    S-CSCF does followings at this point

    • Select Authentication vectors
    • Save the selected authentication vector

(10) : 401 UnAuthorized (Path : S-CSCF --> I-CSCF)

S-CSCF forward the Authentication information to I-CSCF. Followings are some of the important paramters.

The 401 response is not a registration failure in the normal IMS initial registration flow. It is the challenge message that tells the UE which authentication algorithm and challenge values should be used for the next REGISTER.

    WWW-Authenticate: nonce=RAND-AUTN, ck, ik,

    Via: icscf1, pcscf1, ue-ip

    This SIP message clip highlights the following parameters: Via, WWW-Authenticate, nonce. Use these fields to correlate routing, dialog identity, transaction sequencing, registration/session state, security context, and media negotiation for this part of the procedure.

This 401 Unauthorized clip focuses on the WWW-Authenticate and Via parameters. WWW-Authenticate carries nonce, CK, and IK related information for IMS AKA, while Via preserves the response path back through I-CSCF, P-CSCF, and the UE side address.

Note : This message will tell UE to initiate 'REGISTER' with authentication based on the information under 'WWW-Authenticate'. An example is as follows.

    WWW-Authenticate: Digest realm="test.3gpp.com",

    This SIP message clip highlights the following parameters: WWW-Authenticate, realm. Use these fields to correlate routing, dialog identity, transaction sequencing, registration/session state, security context, and media negotiation for this part of the procedure.

        nonce="qlWqVapVqlWqVapVqlWqVUUQA5HEt9VVZ3t1TM221cg=",

        qop="auth",

        opaque="MTcyMjU3ODA2NDo=SU1TLVNJUCBTZXJ2ZXI=",

        algorithm=AKAv1-MD5

        This SIP message clip highlights the following parameters: nonce, qop, algorithm, opaque. Use these fields to correlate routing, dialog identity, transaction sequencing, registration/session state, security context, and media negotiation for this part of the procedure.

This WWW-Authenticate example shows the realm, nonce, qop, opaque, and algorithm parameters. The UE uses realm and nonce as authentication inputs, qop to determine the protection mode, opaque as a server supplied value to return, and algorithm to select the AKA digest calculation.

(11) : 401 UnAuthorized (Path : I-CSCF --> P-CSCF)

I-CSCF forward the Authentication information to P-CSCF. Followings are some of the important paramters.

The I-CSCF mainly relays this response back along the SIP path. The important point is that the challenge and routing information must be preserved so that the response reaches the same access-side path used by the UE.

    WWW-Authenticate: nonce=RAND-AUTN, ck, ik,

    Via: pcscf1, ue-ip

    This SIP message clip highlights the following parameters: Via, WWW-Authenticate, nonce. Use these fields to correlate routing, dialog identity, transaction sequencing, registration/session state, security context, and media negotiation for this part of the procedure.

    P-CSCF does followings at this point

    • Save CK and IK
    • allocate P-CSCF side client and server ports

This forwarded 401 clip again centers on WWW-Authenticate and Via, with the P-CSCF also taking note of CK and IK. WWW-Authenticate keeps the authentication challenge intact, Via keeps the SIP response path intact, and CK/IK are used by the P-CSCF when IPSec security associations are prepared.

(12) : 401 UnAuthorized (Path : P-CSCF --> P-GW --> S-GW --> eNodeB --> UA1)

P-CSCF forward the Authentication information to UE through LTE Access network. Followings are some of the important paramters.

When the UE receives this 401 response, it derives the authentication response from the USIM and the challenge. If IPSec is used, the Security-Server information also tells the UE which P-CSCF ports and security parameters should be used to establish the security associations before sending the authenticated REGISTER.

    WWW-Authenticate: nonce=RAND-AUTN,

    Security-Server: port-s, port-c

    This SIP message clip highlights the following parameters: WWW-Authenticate, Security-Server, nonce. Use these fields to correlate routing, dialog identity, transaction sequencing, registration/session state, security context, and media negotiation for this part of the procedure.

This UE-facing 401 clip highlights WWW-Authenticate and Security-Server. WWW-Authenticate gives the UE the nonce challenge, and Security-Server provides the P-CSCF security parameters such as protected server and client ports for IPSec negotiation.

IPSec Security Association Establishment

After the 401 response, many IMS deployments require the UE and P-CSCF to protect subsequent SIP signaling with IPSec. This is why the registration flow has a separate security association phase before the authenticated REGISTER is sent.

There are four logical security associations because SIP traffic can be a UE initiated request, a response to the UE, a P-CSCF initiated request, or a response to the P-CSCF. The exact port numbers come from the Security-Client and Security-Server negotiation.

(1) : IPSec SA for UE Initiated Requests

This association protects SIP requests that originate from the UE and terminate at the P-CSCF server port. The authenticated REGISTER is the most important example in this procedure.

    UE-Client -> P-CSCF-Server

(2) : IPSec SA for Responses to UE

This association protects SIP responses that are sent from the P-CSCF client side back to the UE server side. It allows the response to the UE initiated request to follow the negotiated protected path.

    UE-Server <- P-CSCF-Client

(3) : IPSec SA for P-CSCF Initiated Requests

This association is used when the P-CSCF needs to initiate a SIP request toward the UE. It is separate from the UE initiated request direction because the local and remote ports are reversed.

    UE-Server <- P-CSCF-Client

(4) : IPSec SA for Responses to P-CSCF

This association protects responses from the UE back to the P-CSCF for requests that were initiated by the P-CSCF. Together, these four associations cover both SIP directions and both request/response roles.

    UE-Client -> P-CSCF-Server

Authenticated IMS Registration

Authenticated IMS Registration is the second REGISTER transaction. In this phase, the UE sends the calculated authentication response, uses the negotiated security path if required, and expects a final 200 OK if the S-CSCF accepts the registration.

Compared with the unauthenticated REGISTER, the message path is similar, but the meaning is different. The network is no longer only collecting routing and challenge information; it is validating the UE and binding the public identity to the contact address.

(1) REGISTER (Path : UA1 --> eNodeB --> S-GW --> P-GW --> P-CSCF)

The UE sends another REGISTER, this time including the response calculated from the challenge in the 401 Unauthorized message. If IPSec is used, this REGISTER is sent over the protected path negotiated in the previous phase.

    Via: UE-IP;UE-Server-Port,

    Route: pcscf1, pcscf-server-port,

    Contact: UE-IP ue-server-port,

    Authorization: Digest username = name.private@hims.net response=RES

    This SIP message clip highlights the following parameters: Via, Route, Contact, Authorization, response. Use these fields to correlate routing, dialog identity, transaction sequencing, registration/session state, security context, and media negotiation for this part of the procedure.

This authenticated REGISTER clip highlights Via, Route, Contact, and Authorization. Via and Contact now use the negotiated UE security ports, Route points to the protected P-CSCF path, and Authorization carries the response parameter calculated from the AKA challenge.

Note : Since this step is for Registration with Authentication, 'Authentication' parameter carries detailed information needed for the authentication algorith as shown below. This step is triggered by '401 UnAuthorized' in previous registration step.

    Authorization: Digest username="001010123456789@test.3gpp.com",

    This SIP message clip highlights the following parameters: Authorization. Use these fields to correlate routing, dialog identity, transaction sequencing, registration/session state, security context, and media negotiation for this part of the procedure.

          realm="test.3gpp.com",

          uri="sip:test.3gpp.com",

          qop=auth,

          nonce="qlWqVapVqlWqVapVqlWqVUUQA5HEt9VVZ3t1TM221cg=",

          nc=00000001,

          cnonce="11259375",

          algorithm=AKAv1-MD5,

          response="a3f549b13f477562f4445b7277cd83c1",

          opaque="MTcyMjU3ODA2NDo=SU1TLVNJUCBTZXJ2ZXI="

          This SIP message clip highlights the following parameters: nonce, response, realm, qop, algorithm, opaque. Use these fields to correlate routing, dialog identity, transaction sequencing, registration/session state, security context, and media negotiation for this part of the procedure.

This detailed Authorization clip shows username, realm, uri, qop, nonce, nc, cnonce, algorithm, response, and opaque. The most critical parameter is response because it proves the UE calculated the correct digest; nonce, nc, cnonce, qop, and algorithm define exactly how that response value is generated.

(2) REGISTER (Path : P-CSCF --> I-CSCF)

The P-CSCF validates that the request is using the expected protected association and then forwards the REGISTER toward the home network. It also keeps the route information needed for later SIP signaling to return to the UE.

    Via: pcscf1 UE-IP;UE-Server-Port,

    Contact: UE-IP ue-server-port,

    Authorization: Digest username = name.private@hims.net response=RES integrity protection: yes,RES

    This SIP message clip highlights the following parameters: Via, Contact, Authorization, response. Use these fields to correlate routing, dialog identity, transaction sequencing, registration/session state, security context, and media negotiation for this part of the procedure.

This protected forwarded REGISTER clip highlights Via, Contact, and Authorization. Via identifies the P-CSCF and UE protected path, Contact keeps the UE protected contact address, and Authorization now includes both response and integrity protection information.

(3) User Authorization Request (Path : I-CSCF --> HSS)

The I-CSCF again checks with the HSS so that the request can be routed to the correct S-CSCF. This repeated HSS query is common because the authenticated REGISTER is a new SIP transaction.

    name.private@hims.net

(4) User Authorization Response (Path : HSS --> I-CSCF)

The HSS returns the S-CSCF information for this subscriber. If an S-CSCF was already selected in the first transaction, the same server is normally used so the stored authentication vector can be matched.

    S-CSCF Name,

    S-CSCF Capabilities

(5) REGISTER (Path : I-CSCF --> S-CSCF)

The I-CSCF forwards the authenticated REGISTER to the selected S-CSCF. The S-CSCF now has both the stored challenge information and the UE supplied response, so it can complete the authentication decision.

    Via: icscf1 pcscf1 UE-IP;UE-Server-Port,

    Contact: UE-IP ue-server-port,

    Authorization: Digest username =name.private@hims.net response=RES integrityprotection: yes,RES

    This SIP message clip highlights the following parameters: Via, Contact, Authorization, response. Use these fields to correlate routing, dialog identity, transaction sequencing, registration/session state, security context, and media negotiation for this part of the procedure.

This REGISTER clip shows the final forwarding of the authenticated request to the S-CSCF. The important parameters are Via, Contact, and Authorization: Via records the I-CSCF/P-CSCF/UE path, Contact identifies the UE protected contact, and Authorization carries response plus integrityprotection confirmation.

(6) Server Assignment Request (Path : S-CSCF --> HSS)

After authentication succeeds, the S-CSCF informs the HSS that it is serving this user. This binds the subscriber registration state to the selected S-CSCF and allows later service control to use the right serving node.

    name.private@hims.net

(7) Server Assignment Request (Path : HSS --> S-CSCF)

The HSS confirms the assignment and may return service profile information used by the S-CSCF. This information can affect later originating and terminating service handling after registration is complete.

(8) 200 OK (Path : S-CSCF --> I-CSCF)

The S-CSCF sends 200 OK when the registration is accepted. This response confirms that the contact binding and registration state have been created successfully in the IMS core.

(9) 200 OK (Path : I-CSCF --> P-CSCF)

The I-CSCF relays the success response back toward the access side. It normally does not keep the final registration state; it simply follows the SIP response path.

(10) 200 OK (Path : P-CSCF --> P-GW --> S-GW --> eNodeB --> UA1)

When the UE receives this 200 OK, IMS registration is complete from the UE point of view. The UE can now use the registered public identity for IMS services such as voice, SMS over IMS, or other subscribed services.

Protocol Sequence of REGISTER

There are roughly three types of REGISTER process (This is not the official classification. This is just my personal classification). At the initial stage of IMS stack implementation, most of the device supported only Type 1 and then evolved to Type 2 and Type 3. For now (as of Mar 2017), I see most of the UE support all of these types, but it is highly likely that only Type 3 is allowed in live network.

These three examples are useful because they isolate the major implementation differences. When debugging registration, first identify which type the UE and network are attempting, and then check whether the REGISTER headers, authentication fields, and security negotiation match that type.

REGISTER message in various form

As there is different types of REGISTER procedure, there are many different variations of REGISTER message itself. The detailed contents of REGISTER message varies depending on UE capability, type of services that the UE subscribed and Authentication types etc. I would suggest you to get familiar with various REGISTER message and understand the meaning of each and every parameters in the message.

In practice, the REGISTER message is also a compact summary of the UE configuration. Public/private identity, contact address, security support, access network information, feature tags, and authentication values can all appear in one message, so small configuration errors often show up first in REGISTER.

SIP UnRegistration

There is no specific message for UnRegistration. SIP uses 'REGISTER' message for Unregistration as well. Just setting 'Expires' field to be 0 perform SIP Unregistration.

UnRegistration removes or shortens the contact binding that was created during registration. This can be triggered by UE power-off, IMS disablement, SIM change, airplane mode, or network-side policy, and the exact message content may vary by implementation.

    REGISTER sip:test.3gpp.com SIP/2.0

    f: <sip:+11234567890@test.3gpp.com>;tag=589636628

    t: <sip:+11234567890@test.3gpp.com>

    CSeq: 589636509 REGISTER

    i: 589636508_2363003488@10.133.202.46

    v: SIP/2.0/UDP 10.133.202.46:5060;branch=z9hG4bK428556305

    Max-Forwards: 70

    m: <sip:+11234567890@10.133.202.46:5060>

    P-Access-Network-Info: 3GPP-E-UTRAN-FDD; utran-cell-id-3gpp=3114800001FFFFFFF

    Expires: 0

    l: 0

    Authorization: Digest uri="sip:test.3gpp.com",username="001010123456789@test.3gpp.com",response="",realm="test.3gpp.com",nonce="",

    Digest uri="sip:test.3gpp.com",username="001010123456789@test.3gpp.com",response="",

    realm="test.3gpp.com",nonce=""

    This SIP message clip highlights the following parameters: Authorization, Expires, CSeq, P-Access-Network-Info, Max-Forwards, nonce, response, realm. Use these fields to correlate routing, dialog identity, transaction sequencing, registration/session state, security context, and media negotiation for this part of the procedure.

This unregistration REGISTER clip highlights Request-URI, From, To, CSeq, Call-ID, Via, Max-Forwards, Contact, P-Access-Network-Info, Expires, Content-Length, and Authorization. The key parameter is Expires: 0, which requests removal of the registration binding; Contact identifies the binding being removed, and Authorization identifies the subscriber context for the request.

IMS Registration based on 3GPP Specification

The most of the contents posted in this page is more like generic IMS/SIP procedure mostly based on RFC specification. When IMS/SIP is used under mobile network (especially LTE), some additional details on UE behabiour or SIP message are prescribed by 3GPP in addtion to RFC.

For conformance or interoperability testing, the 3GPP requirements are usually more important than the simplified ladder diagram. The same high level REGISTER flow can pass or fail depending on details such as URI format, contact header construction, expiration handling, and how the UE reacts to specific error responses.

Main 3GPP specification for IMS registration is 24.229 5.1.1.2 Initial Registration. Followings are some of details you have to pay attention in this specification are

  • Which URI format to be used in 'From', 'To' header field ?
  • What kind of UE id to be used ?
  • How to handle +sip.instance ?
  • Requirement for ICSI value (e.g, IMS Registration based on 3GPP Specification)
  • Requirement for Contact Field
  • Requirement for Via Field
  • Requirement for Expiration Interval
  • Reaction to Error Message
    • 305 Use Proxy
    • 408 Request Timeout
    • 423 Interval Too Brief
    • 500 Internal Server Error
    • 504 Server Timeout
      •