When sending SIP requests to Office Communications Server, the server makes a series of routing decisions based on predefined rules to route the requests to the right person or location depending on the types of requests and the given topology. The server uses the information in the headers in each of the requests to determine how to route the request through the network.
Office Communications Server uses the header information found in the SIP messages to know how to route messages through the network to the right user or location. The headers that are primarily used for routing in SIP are Record-Route, Route, Via, and Contact headers. Routing signatures are placed in the headers to guarantee the integrity of the messages.
Following is a series of requests between two clients, caller and callee, to illustrate the routing headers that are described later in this section. In the following example, the caller sends an initial INVITE request to the callee to establish a session, which the callee accepts by responding with 200 OK. The session is eventually terminated by the caller with a BYE request.
INVITE request:
INVITE sip:[email protected] SIP/2.0 Via: SIP/2.0/TLS 192.168.0.1:49171 From: <sip:[email protected]>;tag=8ca09007a0;epid=999d248d94 To: <sip:[email protected]> Call-ID: 886d6ef69a55472aa89cc34a69f23edc CSeq: 1 INVITE Contact: <sip:[email protected];opaque=user:epid:caller1111;gruu> ...
200 OK response:
SIP/2.0 200 OK Via: SIP/2.0/TLS 192.168.0.1:49171 FROM: [email protected];tag=8ca09007a0;epid=999d248d94 TO: <sip:[email protected]>;epid=5869277E95;tag=3a5f6462bb CSEQ: 1 INVITE CALL-ID: 886d6ef69a55472aa89cc34a69f23edc Contact: <sip:[email protected];opaque=user:epid:callee1111;gruu> Record-Route: <sip:srv3.example.com:5061;transport=tls> Record-Route: <sip:srv2.example.com:5061;transport=tls> Record-Route: <sip:srv1.example.com:443;transport=tls;ms-route- sig=aafynjdGOoa08ORug09qSeJ6_gK5X8RZbwFpMfiAAA> ...
BYE sip:[email protected] SIP/2.0 Via: SIP/2.0/TLS 192.168.0.1:49171 From: <sip:[email protected]>;tag=8ca09007a0;epid=999d248d94 To: <sip:[email protected]>;epid=5869277E95;tag=3a5f6462bb Call-ID: 886d6ef69a55472aa89cc34a69f23edc CSeq: 3 BYE Route: <sip:srv1.example.com:443;transport=tls;ms-route-sig=aafynjdGOoa08ORug09qSeJ6_ gK5X8RZbwFpMfiAAA> Route: <sip:srv2.example.com:5061;transport=tls> Route: <sip:srv3.example.com:5061;transport=tls> ...
The preceding three SIP messages are used as examples in the following sections to demonstrate the four common routing headers. The following sections describe each of these headers and routing signatures in more detail.
Proxy servers use Record-Route headers. A server that proxies a message can add its own fully qualified domain name (FQDN) or IP address to the Record-Route header to indicate that it wants to remain in the signaling path for all subsequent SIP traffic in the current session. For example, for security reasons, an Office Communications Server Access Edge Server inserts its FQDN into all requests. It does this to ensure that all subsequent messages in the established session have to go back through the Access Edge Server before crossing the firewall.
In the previous 200 OK response example, the message has three Record-Route headers, so these three servers—srv1.example.com, srv2.example.com, and srv3.example.com—have requested to be included in the path of all future requests in this session.
Route headers consist of a list of FQDNs or IP addresses of all entities in the path of a request. The client copies the Record-Route headers from the server response and uses those headers to create the Route headers for all new requests within a dialog. Upon receiving a message, each Office Communications Server removes its own FQDN or IP address from the list and forwards the message to the next URI in the Route header list.
In the preceding example, the Route headers in the BYE request demonstrate that the request follows a specific route to the recipient, which in this case is the same path defined by the Record-Route headers in the 200 OK response.
Via headers contain FQDNs or IP addresses of the client and all Office Communications Servers that have handled a request. Via headers are used to direct responses back to a client by using the same path by which it was sent, but in the opposite direction. A server can also inspect the Via header to determine whether it has previously handled a request.
In the preceding example, the Via header is shown in all of the requests and responses. In this snapshot where the SIP messages have been capture on the client, these messages contain only a single Via header because by the time the message reaches the client, all the additional Via headers have already been consumed and stripped off by each of the servers along the route path.
A user’s address, as opposed to the address of the SIP server on which the user is hosted, is stored in the Contact header. A server redirecting a message can write the address of the intended recipient in a Contact header returned in a response to the client. Subsequently, the client can contact the recipient directly without having to go through the server.
The Contact header appears in the first two messages in the preceding example. In the case of the INVITE request, the caller identifies its address. In the case of the 200 OK response, the callee identifies its address.
Office Communications Server uses route signatures to guarantee the integrity of the messages flowing through the network. Without route signatures, the server would not be able to verify that the routing headers were not compromised by an attacker while traversing the network. Office Communications Server uses a cryptographic signature to verify that the packets did actually come through every hop that was expected.
Office Communications Server signs routing information in the Record-Route, Contact, and Via headers. Access Edge Servers perform the signing on connections to federated domains and untrusted connections. When signing the Record-Route and Contact headers, the signature is placed in the route URI so that it is retained in the dialog state by the clients and echoed back in Route headers in each request in the dialog. When a request is received from an untrusted network boundary (such as client or federated), Office Communications Server uses the route signature contained in the route URI to verify that the route path has not been tampered with.
In the preceding example, the route signature is shown in the ms-route-sig parameter of both the 200 OK response’s Record-Route header and the BYE request’s Route header. The routing signature appears only in the routing header belonging to the server that is directly connected to the client.
To demonstrate how Office Communications Server uses SIP routing, Figure 22-5 shows an example topology with a mixture of federated users, extranet clients, and intranet clients, as well as multiple pools and multiple front-end (FE) servers.
Figure 22-5 shows a sample topology with intranet users (users A, B, and C), extranet users (users C and D), and a federated user (FUser). Note that user C is both an intranet and an extranet user because the user is logged in from an internal endpoint, such as an Office Communicator Phone Edition device, and an external endpoint, such as Office Communicator running on his laptop. Federated users belong to another organization; however, they can also be users from the public cloud, such as Yahoo!, MSN, or AOL. Federated users do not belong to the enterprise but are able to get presence information and start communications with users within that enterprise. The following list identifies each type of user and how each user accesses the enterprise:
Intranet users. Enterprise users connected from within the enterprise
Extranet users. Remote enterprise users connected to the enterprise through an Access Edge Server
Federated users. Nonenterprise users connected to the enterprise through an Access Edge Server
Each intranet and extranet user belongs to a pool in the enterprise. Users A, B, and D belong to pool 1, and user C belongs to pool 2. In this topology, pool 1 is configured as the Director pool, and pool 2 is an internal pool. For each endpoint, a user is connected to a single FE server within their pool. For instance, user A is connected to FE server 1 in pool 1 in this figure.
The full name of each user in the diagram encapsulates whether the user is internal or external, the user’s ID, the pool that the user belongs to, and the FE server that the endpoint is connected to. For example, IC-P2-FE5 indicates that user C ("C") is an internal (I) user belonging to pool 2 (P2) and connected to FE server 5 (FE5).
Routing varies depending on the type of request that comes in, who originated the request, and for whom the request is intended. All requests are first redirected (for internal users) or proxied (for external users) to the home server of the user specified in the From header for logging and registration purposes, and then the routing logic applies according to the destination in the To header. Table 22-1 describes the routing logic in the context of the example topology shown in Figure 22-5.
Table 22-1. Routing Logic Example