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, VoWifi 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: <sip:scscf-test.ims.net>;tag=151

Unfortunately the same applies also for the Contact header.

Contact: <sip:10.29.40.140:5061>

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:

REGISTER sip:ipsmgw-test.ims.net SIP/2.0

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:

To: sip:+123456789012@ims.mnc987.mcc654.3gppnetwork.org

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="sip:user1@ims.net" id="user1" state="init">
   </registration>
 </reginfo>

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.

 

Related articles:

 

Print Friendly, PDF & Email

Realtimecommunication.info

4G/5G, VoLTE, RCS, IMS, SIP, WebRTC, IoT/M2M Descrition, CallFlows, Illustrated Guides, Tests and other stuff for telco egineers

8 thoughts to “Third Party Registration”

  1. To: sip:+123456789012@ims.mnc987.mcc654.3gppnetwork.org

    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)

    1. 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
      operator;

      Hope it helps 🙂
      Karel.

    1. Hi Abhishek,
      The TPR Contact header (as in any other SIP message) indicates what address (including the user part, port and protocol) should be used for subsequent communication. So in case of TPR it tells to AS what S-CSCF should be used for new SIP Requests. For example, if IPSMGW receives a new SMS from SMSC, it generates a SIP MESSAGE. That one is sent to the address retrieved from TPR Contact header.
      Technically AS can also retrieve the information about primary S-CSCF via Sh interface, but TRP Contact is usually the preferred method.

      The detail information can be found in 3GPP TS 24.229.
      Hope it helps, Karel.

  2. In the case of 3rd-party Registration must/should an Application Server always respond to NOTIFY with a SUBSCRIBE request?

    Say there is patchy coverage in the LTE network and a UE that registered only minutes before sends another REGISTER to the IMS Core. (This is not a re-registration based on timeout and there hasn’t been an explicit de-register request.)
    1. Should the S-CSCF treat this any differently from the initial REGISTER request (sending NOTIFY to all ASs in the iFC)?
    2. Should all the receiving ASs send SUBSCRIBE when hey receive the NOTIFY (even if they sent one for the same subscriber minute before)?

    1. Hi John,
      as the 3GPP 24.229 says:
      Upon receipt of a third-party REGISTER request, the AS may subscribe to the reg event package for the public user identity registered at the user’s registrar (S-CSCF).

      So it’s just optional. The subscription (SUBSCRIBE) is from AS to S-CSCF. In case the user registration status changes, the S-CSCF sends NOTIFY towards AS. NOTIFY is sent after SUBSCRIBE.

      In case of a low LTE coverage, UE should deregister. Even if for some reason the deregistration didn’t happen there will be a new LTE attach followed by a new initial registration followed by authentication… ?

      Karel.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.