SH Interface
SH Interface
There are main principles and there are small technical details. People mostly understand how
a petrol engine works. But that doesnt mean they are able to fix one or even make it. No, it is
a long way to understand how things really work. And it is a psychologically proven fact that
we cant really understand things until we will try to change them. Well, dont try it at home
with your petrol engine.
This time we will take a closer look on one of often omitted interfaces. You dont need it in
order to understand the general idea of IMS but when we go into a detail it can be very
important.
Sh Interface
Remember the third party registration? I admit I didt tell you the whole truth. Shame on me.
It can also look like this:
Sh interface in the third party registration
This operation is used to download data for particular subscriber from HSS.
Profile-Update-Request/Answer (AS->HSS)
In this operation AS stores/updates its data at HSS for a particular subscriber and/or
application.
AS takes a subscription that when ever there is change in particular data field for a given
subscriber.
Push-Notification-Request/Answer (HSS->AS)
HSS updates the AS for change in some particular subscriber profile if the AS has an active
subscription.
Why we need this when there is a SIP REGISTER/SUBSCRIBE/NOTIFY? The thing is the
SIP messages in the 3rd party registration are intended for the Event: Reg. Meaning that the
AS will not receive all information subscriber or non subscriber data it needs for the
application of service (e.g. There is no information in the SIP REGISTER or NOTIFY telling
the RCS whether a particular user has some active news feeds or a permission to moderate
video chats.) Sh operations are more sensitive and suitable for this purpose.
It can also happen that some request (e.g. coming from Authentication Proxy) will not arrive
on the right AS (AP can select a secondary AS for a particular subscriber). In that case the
AS will download the subscriber data from the HSS via the Sh interface. Another reason can
be geo-redundancy. We can have ASs which are handling only the users connected from
some geographical area. But in case of a failure they can act as a backup ASs too. That means
that the registration will be done by the primary server. After the failure the backup AS needs
to access the subscribers data in order to apply services correctly.
Sh for failover
Most probably there will be also two I/S-CSCF. But the flow is complex already enough:
Sh failover
For the VoLTE the ETSI TS 29.364 defines the XML format for service data descriptions for
AS interoperability.
Clear? The final question is what is the LDAP for? Well, LDAP interface can be used
instead of the Sh for the data handling procedures. Depends on the preferences and on what
vendors support. LDAP is usually being used along with SOAP protocol because not all the
needed operations are supported by the LDAP.