This is the third (but not last) post in a series that tries to describe the service-related and IMS-specific mechanisms used to route SIP requests in an IMS network.
As always, I recommend to read the specifications, while on my side I will try to provide a different description of the procedures, that can help the reader to more easily decrypt the occasionally obscure wording and the untold stories from the specifications.
This may lead to the so-called chaining of several application servers in the signalling path that originated from a SIP endpoint (client or application server) and will terminate at another one (client or application server). This chaining may take place on both sides of the end-to-end signalling path (i.e. phases 2 and 5).
This secret word, both created and consumed by the S-CSCF serves two purposes.
The procedure at the AS when it acts as a routeing B2BUA mandates it to copy the header in which the original dialogue identifier was placed (the Route header) in the request starting a new dialogue downstream (the second half of the B2BUA).
Similarly, if the AS uses a PSI as the originator identity for the SIP request, it may need to route it to an S-CSCF, so that originating procedures apply as well, this time for the PSI.
For accessing more information about the registration, the application server can subscribe to the registration event package (using SIP SUBSCRIBE). It will receive the registration information in the body of the NOTIFY(s) issued by the S-CSCF. The registration event package is also an alternative to 3rd party registration for the AS to be notified of de-registration and re-registration events.