In the last post I promised that this time we will take a closer look on SIP headers which are related to routing. SIP routing is very flexible and most of the SIP textbooks are explaining it in a very general way. Here we focus only on routing in IMS context. We should also point out that there are two methods how to route SIP messages – so called strict routing and loose routing. As the strict rooting is obsolete since 2002 and 3GPP mandates only the loose routing for IMS, we will talk just about the loose routing.
The first and the most important header is the Request-Line, which contains the Request-URI. It allows us to route a SIP request directly to a Server. The response then follows the Via header. SIP Client and each proxy which wants to intercept the response adds itself into Via headers of the SIP request. During the processing of the response then each proxy removes its own Via record from the message. The Via header is also used to detect possible loops in signalling.
SIP Request – Response
In practice the UAs can’t see directly one each other and we have to use the IMS network to provide the routing. The first scenario we should go through is the IMS Registration. A VoLTE UE initiates a SIP REGISTER to the P-CSCF, using the P-CSCF IP that was made available during the LTE Attach. The Request-URI is set to the SIP-URI of the domain name of the home network.
SIP REGISTER towards IMS
SIP Loose Routing
We want to send the message through the P-CSCF. For that we use the Route header. The Route header contains a set of proxies which need to be visited along the way towards the final recipient. In case of loose routing (to indicate, we add the lr tag in the Route header), the message is sent firstly to the top-most Route header URI. Proxy then removes its own – the top-most Route header record. Only if there is no Route header present in the message, the request is forwarded based on the R-URI.
SIP Loose Routing
Let’s go back to our SIP Registration scenario. Now we have the message on P-CSCF and we have to decide where to route the message next. As we don’t have any Route header, we have to do the routing based on the R-URI. In case of Registration, the R-URI contains the domain of Registrar (S-CSCF).
So far so good – but where exactly, what SIP proxy/server we should send the message to? That is being defined in RFC 3263 and RFC 7984. In a shortcut – unless there is local policy specifying otherwise, the destination is determined by DNS. The DNS procedures allow a proxy to resolve a SIP URI into the IP address, port, and transport protocol of the next hop to contact. Note, that the DNS is not there just to translate the domain names, but we use it in a more general way for service discovery, loadsharing and failover scenarios.
The P-CSCF can be located in a visited network (see IMS Roaming). Therefore the discovery of I-CSCF has to be general enough. Using the NAPTR, SRV and A/AAA requests we can gain the IP address of the next hop for the SIP REGISTER message.
Domain Name System (query) Flags: 0x0100 Standard query Queries _sip._udp.operator.com: type SRV, class IN Name: _sip._udp.operator.com Type: SRV (Service location) Class: IN (0x0001)
With a great simplification, the P-CSCF sends a DNS request – “Please, provide me with the address of a server, which is in your domain responsible for SIP over UDP (or TCP)”.
Answers _sip._udp.operator.com: type SRV, class IN, priority 10, weight 100, port 5060, target i-cscf_01.operator.com _sip._udp.operator.com: type SRV, class IN, priority 20, weight 100, port 5060, target i-cscf_02.operator.com Authoritative nameservers operator.com: type NS, class IN, ns dns_01.operator.com Name: operator.com Type: NS (Authoritative name server) Class: IN (0x0001) Time to live: 8 hours Data length: 11 Name Server: dns_01.operator.com Additional records i-cscf_01.operator.com: type A, class IN, addr 10.0.1.2 Name: i-cscf_01.operator.com i-cscf_02.operator.com: type A, class IN, addr 10.0.2.2 Name: i-cscf_02.operator.com
And that is in the home network the I-CSCF.
SIP + DNS
I-CSCF is a simple proxy which main job is to locate the right S-CSCF. Once we know what S-CSCF is responsible for a particular subscriber, we don’t need the I-CSCF anymore. So after the IMS Registration we want to route the messages (e.g. SIP INVITE) directly between P-CSCF and S-CSCF. This is possible thanks to next SIP headers – the Path and Service-Route.
The P-CSCF receives the SIP REGISTER request from the UE and inserts the Path header with a SIP-URI identifying the P-CSCF for routing. The S-CSCF binds the P-CSCF address to the user’s contact, which are to be used to route future requests to the user. Then it returns a 200 OK response with a Service-Route header, that contains a SIP URI identifying the S-CSCF. The S-CSCF does use a different SIP-URI for each registration and this header field is only applicable to the 200 OK response of REGISTER request.
The subsequent requests can be then routed directly (S-CSCF->P-CSCF or P-CSCF->S-CSCF) using the Route header.
SIP Path, Service-Route
What remains during the IMS Registration is the routing on I-CSCF. I-CSCF is a SIP proxy which does the routing based on the Diameter triggering over Cx interfaces (UAR/UAA). I-CSCF either receives S-CSCF name or S-CSCF capabilities. Then the I-CSCF replaces the R-URI of the received REGISTER request with the URI of the S-CSCF. Anyway this is hardly to see, as the I-CSCF and S-CSCF are usually collocated in one server and this last SIP request is sent typically only internally.
The next time we can analyze a simple voice-call signalling path.
Related posts:
Real Time Communication 