Third Party Registration

The last time we went through the registration in the IMS. During the registration S-CSCF (the SIP Server handling a particular subscriber) authenticates the subscriber, learns her current point of presence, capabilities of her device, etc. But when it comes to multimedia sessions, S-CSCF can offer only some basic functions such as session routing or session management. For VoLTE or RCS service profiles we want to apply the service logic provided by Application Servers (TAS, RCS, IPSMGW..). The purpose of the Third party registration is to let the ASs know that the user is now connected and ready to communicate.

We ended up in the situation when a registrar (S-CSCF) authenticated the user. After the successful authentication S-CSCF downloads a user’s profile from the HSS. The profile contains information about what Application Servers (ASs) shall be triggered on behalf of the subscriber. The information is stored in a form of initial filter criteria (iFC).

Third Party Registration

Third Party Registration

The iFC is basically a list of conditions upon which an application server shall be contacted.

IFC - 3rd party reg

IFC – 3rd party reg

Once the S-CSCF knows which servers to contact it sends a third party registration. In this case the originator of the SIP REGISTER message is the S-CSCF. Hence (based on the 3GPP 24.229) we can see its address in the From header:

From: <>;tag=151

Unfortunately the same applies also for the Contact header.

Contact: <sip:>

Which means that we lost information about UE’s capabilities. This can be solved by putting the original SIP REGISTER message in the body of the 3rd party registration message.

The Request-URI is set to AS’s SIP URI:


The From and Request-URI help us to identify the 3rd party registration in a tcpdump.

The most important information – who is being registered – is present in the To header:


Based on the content of iFC the S-CSCF creates the message body.  The SIP REGISTER message body will either contain service information in XML document, or original SIP REGISTER message, or 200 OK response to the incoming REGISTER, or any combination of those. No authentication is now necessary as the AS’s IP address is trusted.

The application server responds with 200 OK.

After the response the Application server can subscribe with SIP SUBSCRIBE to Reg events.

Event: reg

Basically every time there will be an update of the registration status the AS will be notified via SIP NOTIFY. The information will be in XML:

<?xml version="1.0"?>
 <reginfo xmlns="urn:ietf:params:xml:ns:reginfo" version="1" state="full">
   <registration aor="" id="user1" state="init">

The flow could then look like this:

Third party registration

Third party registration


Note, that there can be some other messages triggered by an AS during the third party registration. For example the AS can request subscriber data using UDR message sent via Sh interface – for more details check the Sh Interface post. The AS can even perform another 3rd party registration (sometimes called 4th party registration :)) or can update data in GSM network using MAP or CAMEL interfaces.

The full Reg event would be:

Registration including 3rd party registration

Registration including 3rd party registration

The purpose of the third party registration is to let the application servers know that the user is available in the network (e.g. TAS will stop with Call Forwarding towards Voice Mail) and to create an AS Association. AS Association is a binding between the S-CSCF and (primary) Application Server. We said that the S-CSCF will select the AS based on iFCs. The thing is that the iFCs contain mostly generic FQDNs. S-CSCF will send DNS requests and based on the response it will send the SIP REGISTER message to the SRV record with the highest priority. The AS responds with 200 OK, which contains in the Contact header a site specific address. This address will be stored in the user context on the S-CSCF and since this time on the S-CSCF will always send the SIP messages (based on iFCs) to this particular server.

Third party registration - AS Association

Third party registration – AS Association

In our example DNS does loadsharing among the sites. So even when the both subscribers are registered on S-CSCF, site North, one of them (Bonie) use the TAS on the other site as her primary AS for VoLTE. S-CSCF has to remember this information as the other TAS doesn’t have information about Bonie’s services.

In case the third party registration would fail the DefaultHandling attribute in IFC indicates if the S-CSCF should continue with subscriber processing or if it should initiate the user deregistration procedure.



4 thoughts on “Third Party Registration

  1. To:

    he most important information – who is being registered – is present in the To header:

    these lines does not make sense to me as (To and requestor line is the AS how it can be a user no)


    • Hello Rashid,
      the Third-party Registration is provided by S-CSCF to AS on behalf of the user. The AS address is in the R-URI header, User IMPU (e.g. number) is in the To header.

      More precisely it is described in 24.229:

      third-party REGISTER request to each AS with the following information:
      a) the Request-URI, which shall contain the AS’s SIP URI;
      b) the From header field, which shall contain the S-CSCF’s SIP URI;
      c) the To header field, which shall contain a non-barred public user identity belonging to the service profile of the
      processed Filter Criteria. It may be either a public user identity as contained in the REGISTER request received
      from the UE or one of the implicitly registered public user identities in the service profile, as configured by the

      Hope it helps 🙂


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s