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

 

16 thoughts on “Third Party Registration

  1. Pingback: Sh Interface – What Is It Good for? | RCS, IMS, SIP, WebRTC and all the stuff around

  2. Pingback: Much Ado about Registration | Real Time Communication

  3. Pingback: VoLTE in IMS | Real Time Communication

  4. Pingback: VoLTE flows – close encounters | Real Time Communication

  5. Pingback: Is the Presence Social? | Real Time Communication

  6. Pingback: Summer & IMS | Real Time Communication

  7. Pingback: How to read tcpdump – Registration | Real Time Communication

  8. Pingback: IP-SM-GW Transport Level Interworking | Real Time Communication

  9. Pingback: Sh Interface – What Is It Good for? | Real Time Communication

  10. Pingback: Presence – from the other site | Real Time Communication

  11. Pingback: How to read Initial Filter Criteria | Real Time Communication

  12. Pingback: Rainy-day Scenarios – S-CSCF Restoration | Real Time Communication

  13. Pingback: SIP Illustrated 4: SIP Session | Real Time Communication

  14. Pingback: SIP Illustrated 5: SIP Session Routing | Real Time Communication

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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