Understanding SIP Routing

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.

SIP Routing Headers

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 request:

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.

Record-Route Headers

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

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

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.

Contact Headers

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.

Route Signatures

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.

How Office Communications Server Uses SIP Routing

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.

Sample topology

Figure 22-5. Sample topology

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

DESTINATION

ROUTE PATH

DESCRIPTION

REGISTER REQUEST

  

Extranet user: Request arrives at the Access Edge Server, where it is deterministically forwarded to one of the front-end servers in the Director pool. Then it is forwarded based on which pool the user belongs to.

Director pool

ED-P1-FE1 → Access Edge Server → P1-FE1

User ED registers itself. SA would be established on P1-FE1.

Internal pool

EC-P2-FE3 → Access Edge Server → P1-FE2 → P2-FE3

User EC registers itself. The SA would be established on P1-FE2.

Intranet user: Request arrives at a pool’s front-end server and is redirected based on which pool the user belongs to.

Same pool

IA-P1-FE1 → P1-FE1

User IA registers itself. The SA would be established on P1-FE1.

Different pool

IA-P1-FE1 → P2-FE3 → P1-FE1

User IA registers itself. The SA would be established on P2-FE3.

Federated user: Request arrives at the Access Edge Server, and all requests are blocked. The Access Edge Server returns a 403 Forbidden response because Office Communications Server does not enable federated users to register with its server.

SUBSCRIBE REQUEST

  

Extranet user: Request arrives at the Access Edge Server, where it is deterministically forwarded to one of the front-end servers in the Director pool. Then it is forwarded based on which pool the user belongs to. Most likely, the SA would have been established by a prior REGISTER request.

Director pool

ED-P1-FE1 → Access Edge Server → P1-FE1

User ED subscribes to user IB.

Internal pool

ED-P1-FE1 → Access Edge Server → P1-FE1 → P2-FE3

User ED subscribes to user IC.

Intranet user: Request arrives at the front-end server where the client is logged in and is redirected based on which pool the destination user belongs to.

Same pool

IA-P1-FE1 → Pl-FEl

User IA subscribes to its roaming contacts.

Different pool

IA-P1-FE1 → P1-FE1 → P2-FE4

User IA subscribes to user IC.

Federated user: Request arrives at the Access Edge Server, where it is deterministically forwarded to one of the front-end servers in the Director pool. Then it is forwarded based on which pool the destination user belongs to.

Director pool

FUser → Access Edge Server → +P1-FE2

FUser subscribes to user IA.

Internal pool

FUser → Access Edge Server → +P1-FE2 → P2-FE4

FUser subscribes to user IC.

SERVICE REQUEST

  

Extranet user: Request arrives at the Access Edge Server, where it is deterministically forwarded to one of the front-end servers in the Director pool. Then it is forwarded based on which pool the user belongs to. Most likely, the SA would have been established by a prior REGISTER request.

Director pool

EC-P2-FE3 → Access Edge Server → P1-FE2 → P2-FE3

User EC adds a new contact.

Internal pool

EC-P2-FE3 → Access Edge Server → P1-FE1 → P2-FE3 → P1-FE1

User EC issues a get presence request for user IA.

Intranet user: Request arrives at the front-end server where the client is logged in and is redirected based on which pool the destination user belongs to.

Same pool

IB-P1-FE2 → P1-FE2

User IB deletes an existing contact.

Different pool

IB-P1-FE2 → P1-FE2 → P2-FE3

User IB issues a get presence request for user EC.

Federated user: Request comes in from a FUser to the Access Edge Server, and the Access Edge Server blocks the request because Office Communications Server does not support SERVICE requests from federated networks.

INVITE REQUEST

  

Extranet user: Request arrives at the Access Edge Server, where it is deterministically forwarded to one of the front-end servers in the Director pool. Then it is forwarded based on which pool the user belongs to. Most likely, the SA would have been established by a prior REGISTER request. The INVITE request is routed to a destination user’s particular endpoint by using the Multiple Points of Presence (MPOP) routing logic.

Director pool

ED-P1-FE1 → Access Edge Server → P1-FE1 → IB-P1-FE2

User ED sends an INVITE to user IB (user IB has only 1 endpoint, IB-P1-FE2).

Internal pool

ED-P1-FE1 → Access Edge Server → P1-FE1 → P2-FE5 → P2-FE3 → Access Edge Server → EC-P2-FE3

User ED sends an INVITE to user C (user C has three endpoints: IC-P2-FE4, IC-P2-FE5, and EC-P2-FE3. This also assumes that EC-P2-FE3 wins MPOP logic).

Federated domain

EC-P2-FE3 → Access Edge Server → P1-FE2 → P2-FE3 → P1-FE2 → Access Edge Server → FUser’s federation server → Fuser

User EC sends an INVITE to FUser.

Intranet user: Request arrives at the front-end server where the client is logged in and is redirected based on which pool the destination user belongs to.

Same pool

IA-P1-FE1 → P1-FE1 → P1-FE2 → IB-P1-FE2

User IA invites user IB.

Different pool

IA-P1-FE1 → P1-FE1 → P2-FE3 → Access Edge Server → EC-P2-FE3

User IA invites user EC.

Federated user: Request comes in from a FUser to the Access Edge Server, where it is deterministically forwarded to one of the front-end servers in the Director pool. Then it is forwarded based on which pool destination the user belongs to.

Director pool

FUser → Access Edge Server → P1-FE2 → P1-FE1 → IA-P1-FE1

FUser sends an INVITE to user IA, and user IA has only one endpoint, IA-P1-FE1.

Internal pool

FUser → Access Edge Server → P1-FE2 → P2-FE3 → Access Edge Server → EC-P2-FE3

FUser sends an INVITE to user C (user C has three endpoints: IC-P2-FE4, IC-P2-FE5, and EC-P2-FE3. This also assumes that EC-P2-FE3 wins the MPOP logic).

NOTIFY REQUEST

  

Extranet user: Request is sent to a watcher, who is an extranet user.

N/A

P2-FE5 → P2-FE3 → P1-FE2 → Access Edge Server → EC-P2-FE3

User IC-P2-FE5 changes its presence and user EC-P2-FE3 is one of its watchers.

Intranet user: request is sent to a watcher, who is an intranet user.

N/A

P2-FE4 → P2-FE5 → IC-P2-FE5

User C has two endpoints with roaming subscriptions (IC-P2-FE4 and IC-P2-FE5). IC-P2-FE4 adds a new contact, and a roaming delta NOTIFY request is sent to IC-P2-FE5.

Federated user: Request is sent to a watcher, who is a federated user.

N/A

P1-FE2 → Access Edge Server → FUser’s federation server to FUser

User IB changes its presence and FUser is one of its watchers.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.147.238.1