One of the most complex issues within IMS is the routing of requests, especially the routing of initial requests. In our example, Tobias is sending the initial INVITE request to Theresa. Consequently, a SIP dialog is created within which several subsequent requests – such as ACK, PRACK, UPDATE and BYE – are sent.
Tobias's UE is unaware at the time of sending the INVITE request how Theresa's UE can be reached. All it can provide is:
The final destination of the INVITE request – which is the SIP URI of Theresa (one of her public user identities) that Tobias had to indicate (e.g., by selecting it from his phone book).
The address of the P-CSCF – which is the outbound proxy of Tobias's UE and will be the first hop to route to. This address is obtained before SIP registration during the P-CSCF discovery procedures (see Section 10.3).
The address of the S-CSCF – which was discovered during registration procedures by means of the Service-Route header (see Section 10.5.8).
Armed with this partial route information the INVITE request is sent on its way. It first traverses the P-CSCF and then the S-CSCF that have been selected for Tobias.
Tobias's S-CSCF now has no further routing information available for the request other than the final destination (i.e., the public user identity of Theresa, sip:theresa@ home2.hu). As Tobias's S-CSCF does not act as a registrar for Theresa, it can only resolve the host part of the address: home2.hu. This domain name is sent ...