At this point, users can log into the environment and check presence status of local users, send Instant Messages and place voice calls between users internally. External calls to the PSTN require two additional pieces: a Microsoft Mediation Server and a path to the PSTN such as SIP/PSTN gateway or IP-PBX.
The role of the Mediation Server is to convert Microsoft’s Real-Time Audio (RTA) codec to G.711 MuLaw or ALaw to communicate via SIP with third-party VOIP gateways. (Within the network, clients also support G.723, G.726, G.722.1, GSM, RTA Wide and Narrow codecs.) Mediation Servers can be paired one-to-one with gateways, or multiple Mediation Servers can point to a single gateway. Microsoft has a certification process for third-party gateways. The Mediation server can also be used to interface via SIP trunks to TDM Hybrid and IP-based PBX systems. Certification with specific vendors is in progress.
For our testing configuration, we used a moderate-size configuration, which would support approximately 15K users, consisting of two Mediation servers, two OCS servers in an Enterprise pool and a standard back-end configuration consisting of an Exchange 2007 server, SQL 2005 server and a domain controller. For PSTN connectivity, a pair of Quintum Tenor 8-span gateways was used to interface with the Mediation Servers. The dual Mediation Server configuration allowed us to test the failover abilities in the event of losing a gateway or Mediation Server.
One server was set up to handle inbound calls and the second to handle outbound. A call flow was established from the PSTN through the inbound gateway to the OCS server pool which routed the call back out to the test system through the outbound server. To test failover, the power was disconnected from the outbound server and the calls automatically flowed over to the other gateway and were completed successfully. With the factory default keep-alive timers, the failover process took 15 seconds until calls were again completing successfully. According to Microsoft, the timers could be adjusted for an even faster response, though there are tradeoffs to this: Shorter timers may cause issues in large, complex topologies.
A second test was conducted on the capacity of the Mediation Servers. We generated SIP phone calls using version 2.7 of WinSIP from Touchstone Technologies, Inc. We connected to the servers via a SIP trunk and delivered 30,000 BHCA (busy hour call attempts) with more than five 9s of success. Calls were being routed in the same manner as the redundancy test. The call rate was ramped up even further to 70,000 BHCA with the same result.
These were very simple calls—not much complex call handling or routing—but they did place stress on the call setup and teardown portions of the call path at a rate beyond what most organizations would expect to handle. The diverse topology, while encompassing several servers, shows the architecture to be highly scalable.
With the multiple servers in the pool, we also failed one of the OCS servers to determine the client reaction. Clients will log into a specific OCS server in the pool. If they are registered to a surviving server, there will be no impact. If they are registered to the failed server, the Office Communicator client will time-out and automatically restart, registering to an active server. Any RTP streams (voice, video) will remain active, with the client resetting once the call is finished. The entire process for a client to failover took 4.5 minutes. Again, this is with the factory defaults on the timers, which can be shortened for faster response, with tradeoffs as described above.
