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).
The iFC is basically a list of conditions upon which an application server shall be contacted.
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:
Unfortunately the same applies also for the Contact header.
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:
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.
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@example.com" id="user1" state="init"> </registration> </reginfo>
The flow could then look like this:
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:
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.
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.