Third Party Registration

Posted on by

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: <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:[email protected]

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:[email protected]" 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.

 

21 thoughts on “Third Party Registration”

  2. To: sip:[email protected]

    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)

    Like

    Reply

    • 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.

      Like

      Reply

    • 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.

      Like

      Reply

  4. 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)?

    Like

    Reply

    • 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.

      Like

      Reply

  5. What is the scscf capabilities. Why it is required for every user. Does every user have different capabilities to support different scscf.

    Like

    Reply

    • There was an idea that there can be more types of s-cscf in the network. But in practice we treat all the s-cscf the same way. You can see the caps as a generic FQDN.

      Like

      Reply

    • Yes, of course 🙂 Devices are distinguished by +sip.instance in the Contact header. It’s typically AS which is making the forking decision based on precedence and supported Caps. Please not we typically do sequential forking rather then parallel forking.

      Like

      Reply

      • Yes, technically you can call without any TAS/MMTel server involved (that’s what we call ‘VoIP’). However, that is not what we refer to as ‘VoLTE’. VoLTE service is defined by GSMA in IR.92. This document clearly states, that TAS appling Suplementary Services is a must for any VoLTE network. TAS is typically responsible for many more functions and services in the network (e.g. collocation with SCC AS, MRF triggering, ENUM triggering, SCP, … ) In my practice with more than 30 T1 mobile operatorsI have never seen a ‘volte’ voice call without TAS – sure your experience may be different – what operator doesn’t use TAS?

        Like

  9. Hello.. Could you please help me to answer on below queries:

    – What are P-Associated URI, P-Preferred URI ,P-Asserted URI, P- Inserted URIs and what are the importance of these
    – Where it uses basically, Share info with examples for each.

    Please add other P-xxx URI if i missed and that play important role

    Like

    Reply

Leave a Reply