Edge Placement

Edge Server placement is critical in a deployment to optimize media paths. The SIP signaling used for presence and IM is more tolerant of slight delays, but web conferencing and A/V traffic are sensitive to latency, so it is important to properly plan Edge Server placement.

For example, consider a small deployment for Company ABC, as shown in Figure 27.1 where a single Front-End Server in San Francisco exists. In this deployment, only a single Edge Server is necessary to support all the remote features. Media paths are all local to San Francisco.

Figure 27.1 Single Edge Server

Imagine Company ABC expands with a new office in London with a WAN link back to San Francisco and adds a new Front-End pool for the London users. The London users have been assigned policies that allow remote access, but no conferencing or A/V traffic. In this case, the single Edge Server in San Francisco can still support the London Front-End pool. The SIP signaling enters the San Francisco Edge Server, uses the San Francisco Front-End as next hop, and then communicates with the London Front-End Server. London users have full remote access presence and IM capabilities.

Now consider that Company ABC wants to allow London users to conduct conferences with A/V remotely. There is the potential for users in London who must use the San Francisco A/V Edge Server to relay media traffic. This is inefficient and can result in a poor experience for the remote London users because of the latency involved with each packet traversing to San Francisco and back. There can be a London user on the Internet trying to do an A/V call with another London user who is internal, but the media traffic flows all the way back to the San Francisco Edge Server just to reach the internal London user. Figure 27.2 shows how inefficient this media path can be.

Figure 27.2 Single Edge Server with Multiple Sites

The solution in this scenario is to also deploy an Edge Server in London so that users there have a local point to relay media when remote. The SIP signaling still travels through the San Francisco Access Edge Server, but media traffic is much improved. If Company ABC deploys an Edge Server in London, the traffic flow shown in Figure 27.2 changes to the traffic flow shown in Figure 27.3. In this case, the remote users can exchange media traffic with London users directly across the Internet.

Figure 27.3 Multiple Edge Servers