When sending SIP requests to Office Communications Server, a series of routing decisions are made by the server in order to route the requests to the right person or the right location. How the server decides this depends on the types of requests and the given topology. The server uses the information in the headers in each of the requests to know how to route the request through the network.
Office Communications Server uses the header information found in the packets to know how to route packets through the network to the right user or the right location. The headers that are primarily used for routing in SIP are record-route headers, route headers, via headers, and contact headers. Routing signatures are placed in the headers to guarantee integrity of the messages. The following sections describe each of these headers and routing signatures in more detail.
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 2007 Access Edge Server inserts its FQDN into all requests that establish a session originating from a corporate branch office; it does this to ensure that all subsequent messages in the established session have to go back through it before crossing the branch office firewall.
Route headers consist of a list of FQDNs or IP addresses of all entities in the path of a request. 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 Uniform Resource Identifier (URI) in the list.
The via header or 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.
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.
Office Communications Server uses route signatures to guarantee integrity of the messages flowing through the network. Without route signatures, the server would have no way to verify that the route the packets took through the network was not compromised by an attacker. 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 header and the via headers. The signing is performed on the edges of the server network trusted for supplying routing information on connections that are not trusted for routing and on Access Edge Servers on connections to federated domains. When signing the Record-Route+Contact header, 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.
Direct from the Source: Routing Logic
Figure 18-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 servers.
In the diagram, we have a sample topology with a federated user (FUser) and some extranet users (such as ED-P1-FE1) and intranet users (such as IA-P1-FE1). Federated users typically belong to another organization that is a peer of the enterprise. It can also be a user from the public cloud, such as Yahoo!, MSN, or AOL. These users do not belong to the enterprise but are able to get presence information and start communications with users within that enterprise. Their requests come in through an Access Edge Server. The extranet users are remote enterprise users that connect through an Access Edge Server. The intranet users are users located within the enterprise. Each of the extra-net users and intranet users belongs to different pools in the enterprise. You can see which pools each user belongs to in the diagram in Figure 18-5. For example, ED-P1-FE1 is an extranet user, User D, who belongs to Pool 1. FE stands for "Front End" and refers to the server that each of these users is logged on to. For instance, ED-P1-FE1 is logged on to Front-End Server 1.
An overview of the routing logic for enterprise and federated users is provided in the "Detailed Routing Logic in the Enterprise" and "Detailed Federation Logic" sections that follow. First, we introduce a few SIP routing concepts.
Detailed Routing Logic in the Enterprise
We will use the sample topology provided in Figure 18-5 (shown earlier) for the purposes of this discussion. This discussion includes any user in that topology except for FUser (federated user). Routing can vary depending on the request that comes in, who it is from, and who it is intended for. The following sections explain in more detail the routing logic for the different requests. All requests are first redirected to the home server of the user specified in the From header for logging and registration purposes, and then the destination logic applies.
REGISTER Requests from Extranet Users
When a REGISTER request comes in from an extranet user such as user ED, it arrives at the Access Edge Server. The REGISTER request is deterministically forwarded to one of the front-end servers, called a director. The request is then authenticated on that server, and a security association (SA) is established. At this point, one of two things can happen:
If the REGISTER request comes from a user that belongs to the same (director) pool, a registration record is created in the pool. In this case, the route would have been ED-P1-FE1 to Access Edge Server to P1-FE1.
If the REGISTER request comes from a user that belongs to a different internal pool, the REGISTER request is again deterministically forwarded to a front-end server in that pool. So, in this case, the routing logic would have been EC-P2-FE3 to Access Edge Server to P1-FE2 to P2-FE3. In this case, the SA was established in P1-FE2.
REGISTER Requests from Intranet Users
If the REGISTER request comes from an intranet user such as IA, one of the following two things can happen:
If the REGISTER request comes from a user that belongs to the same pool, a registration record is created in the pool. In this case, the route would have been IA-P1-FE1 to P1-FE1.
If the REGISTER request comes from a user that belongs to a different pool, the REGISTER request is redirected to a different pool via a "301" response. So, in this case, the routing logic is IA-P1-FE1 to P2-FE3 to "301" response to P1-FE1.
SUBSCRIBE Requests from Extranet Users
When a SUBSCRIBE request comes in from an extranet user such as user ED, it arrives at the Access Edge Server. The SUBSCRIBE request is deterministically forwarded to one of the front-end servers (director). Most likely, the SA would have been established by a prior REGISTER request. At this point, one of the following two things can happen:
If the SUBSCRIBE request is destined for a user in the director pool, a subscription dialog is created in the pool. In the case that ED-P1-FE1 is subscribing to User B, the route is ED-P1-FE1 to Access Edge Server to P1-FE1.
If the SUBSCRIBE request is for a user in an internal pool, the SUBSCRIBE request is again deterministically forwarded to a front-end server in that pool. In the case that ED-P1-FE1 is subscribing to User C, the routing logic would have been ED-P1-FE1 to Access Edge Server to P1-FE1 to P2-FE3. The SUBSCRIBE request was routed to one of the front-end servers in Pool2, where User C is homed.
SUBSCRIBE Requests from Intranet Users
If the SUBSCRIBE request comes from an intranet user such as IA, it comes in at the front-end server where the client is logged in. One of the following two things can happen:
If the SUBSCRIBE request is destined for a user in the same pool, the subscribe operation is done on that server. In the case that IA-P1-FE1 subscribes to its roaming contacts, the routing logic is IA-P1-FE1 to P1-FE1.
If the SUBSCRIBE request is destined for a user in a different pool, the SUBSCRIBE request is deterministically forwarded to a front-end server in that pool. In the case that IA-P1-FE1 subscribes to user C, the routing logic would have been IA-P1-FE1 to P1-FE1 to P2-FE4.
SERVICE Requests from Extranet Users
When a SERVICE request comes in from an extranet user such as user EC, it arrives at the Access Edge Server. The SERVICE request is deterministically forwarded to one of the front-end servers. Most likely, the SA would have been established by a prior REGISTER request. At this point, one of the following two things can happen:
If the SERVICE request is destined for a user in the director pool, the service operation is done on that pool. In the case that EC-P2-FE3 adds a new contact, the routing logic is EC-P2-FE3 to Access Edge Server to P1-FE2 to P2-FE3.
If the SERVICE request is for a user in an internal pool, the SERVICE request is again deterministically forwarded to a front-end server in that pool. In the case that EC-P2-FE3 issues a get presence request for User A, the routing logic is ED-P1-FE1 to Access Edge Server to P1-FE1 to P2-FE3 to P1-FE1.
SERVICE Requests from Intranet Users
If the SERVICE request comes from an intranet user such as IA, it comes in at the front-end server where the client is logged in. One of the following two things can happen:
If the SERVICE request is destined for a user in the same pool, the request is processed on the same server. In the case that IB-P1-FE2 deletes an existing contact, the routing logic is IB-P1-FE2 to P1-FE2.
If the SERVICE request is for a user in a different pool, the SERVICE request is deterministically forwarded to a front-end server in that pool. In the case that IBP1-FE2 issues a get presence request for EC-P2-FE3, the routing logic would have been IB-P1-FE2 to P1-FE2 to P2-FE3.
INVITE Requests from Extranet Users
When an INVITE request comes in from an extranet user, it arrives at the Access Edge Server. The INVITE request is deterministically forwarded to one of the front-end servers. Most likely, the SA would have been established by a prior REGISTER request. At this point, one of the following three things can happen:
If the INVITE request is destined for a user in the director pool, the INVITE request is routed to a particular endpoint by using the Multiple Point of Presence (MPOP) routing logic. In the case that ED-P1-FE1 sends an INVITE to User B (user B has only 1 endpoint, IB-P1-FE2, which is logged in to P1-FE2), the routing logic is ED-P1-FE1 to Access Edge Server to P1-FE1 to IB-P1-FE2.
If the INVITE request is for a user in an internal pool, the INVITE request is deterministically forwarded to a front-end server in that pool. In the case that ED-P1-FE1 sends an INVITE to User C (User C has three endpoints—IC-P2-FE4, IC-P2-FE5, and EC-P2-FE3—and assumes that EC-P2-FE3 wins MPOP logic), the routing logic is ED-P1-FE1 to Access Edge Server to P1-FE1 to P2-FE5 to P2-FE3 to Access Edge Server to EC-P2-FE3.
If the INVITE request is for a user in a federated domain, it is routed back to the Access Edge Server via static routes. In this case, if EC-P2-FE3 sends an INVITE to FUser, the routing logic is EC-P2-FE3 to Access Edge Server to P1-FE2 to P2-FE3 to P1-FE2 to Access Edge Server…to FUser.
INVITE Requests from Intranet Users
If the INVITE request comes from an intranet user such as IA, it comes in at the front-end server where the client is logged in. One of the following two things can happen:
If the INVITE request is destined for a user in the same pool, the request is routed to a particular endpoint by using the MPOP routing logic. In the case that IA-P1-FE1 invites User B, the routing logic is IA-P1-FE1 to P1-FE1 to P1-FE2 to IB-P1-FE2.
If the INVITE request is for a user in a different pool, the INVITE request is deterministically forwarded to a front-end server in that pool. In the case that IA-P1-FE1 invites user C, the routing logic is IA-P1-FE1 to P1-FE1 to P2-FE5 to P2-FE3 to Access Edge Server to EC-P2-FE3.
If a user changes presence, a NOTIFY request needs to be sent to a watcher who might be an extranet user. For example, if IC-P2-FE5 changes its presence and EC-P2-FE3 is one of its watchers, the routing logic is P2-FE5 to P2-FE3 to P1-FE2 to Access Edge Server to EC-P2-FE3.
NOTIFY Sent to Intranet User
If a user adds a new contact from one of its endpoints, a roaming delta NOTIFY request is sent to all of its other endpoints. In the case that IC-P2-FE4 and IC-P2-FE5 are the endpoints of the same user C and both of them have roaming subscriptions, and IC-P2-FE4 adds a new contact and a roaming delta NOTIFY request is sent to IC-P2-FE5, the routing logic is P2-FE4 to P2-FE5 to IC-P2-FE5.
Again, we will use the sample topology provided in Figure 18-5 for the purposes of this discussion. This discussion includes all requests coming into the enterprise from a federated user. Routing can vary depending on the type of request. The following sections explain in more detail the routing logic for the different requests.
When a REGISTER request comes into the Access Edge Server, all requests are blocked. The Access Edge Server returns a "403 Forbidden" response. This is because Office Communications Server 2007 does not allow federated users to register with its server.
When a SUBSCRIBE request comes in from a federated user, it arrives at the Access Edge Server. The SUBSCRIBE request is deterministically forwarded to one of the front-end servers. At that point, one of the following two things can happen:
If the SUBSCRIBE request is destined for a user in the director pool, a subscription record is created in that pool. In the case that FUser is subscribing to User A, the routing logic is FUser to Access Edge Server to P1-FE2.
If the SUBSCRIBE request is for a user in an internal pool, the SUBSCRIBE request is deterministically forwarded to a front-end server in that pool. In the case that the FUser subscribes to user C, SUBSCRIBE is routed to one of the front-end servers in Pool2, where user C is homed. The routing logic is FUser to Access Edge Server to P1-FE2 to P2-FE4.
When a SERVICE request comes in from an FUser to the Access Edge Server, the Access Edge Server blocks the request. The reason for this is that Office Communications Server 2007 does not support SERVICE requests from federated networks.
When an INVITE request comes in from a federated user, it arrives at the Access Edge Server. The invite request is deterministically forwarded to one of the front-end servers. At that point, one of the following two things can happen:
If the INVITE request is destined for a user in the director pool, the INVITE request is routed to a particular endpoint using MPOP routing logic. In the case that FUser sends an INVITE to User A and User A has only one endpoint, IA-P1-FE1, the routing logic is FUser to Access Edge Server to P1-FE2 to P1-FE1 to IA-P1-FE1.
If the INVITE request is for a user in an internal pool, the SUBSCRIBE request is deterministically forwarded to a front-end server in that pool. In the case that the FUser sends an INVITE to User C (User C has three endpoints—IC-P2-FE4, IC-P2-FE5, and EC-P2-FE3—and assumes that EC-P2-FE3 wins the MPOP logic), the routing logic is FUser to Access Edge Server to P1-FE2 to P2-FE5 to P2-FE3 to Access Edge Server to EC-P2-FE3.
NOTIFY Sent to a Federated User
If a user changes its presence, a NOTIFY request is sent to the watcher, FUser. In the case that IB-P2-FE2 changes its presence and FUser is one of its watchers, the routing logic is P1-FE2 to Access Edge Server to…to FUser.
Senior Software Developer Lead