Media Bypass consideration

I just follow up with a discussion I had with a customer who operates a huge Enterprise Network and 30.000 Lync User. We had three distributed Lync Pools around our region and each of this Pool had a consolidated AV Server Setup and seperate Mediation Server.
We needed an integration with and behind the CCM 7.x.
Estimated for Enterprise Voice, 20% of the user should use Lync as their primary phone.

Audio Codec Bandwidth

Audio codec Scenarios Audio payload bitrate (KBPS) Bandwidth audio payload and IP header only (Kbps) Bandwidth audio payload, IP header, UDP, RTP and SRTP (Kbps) Bandwidth audio payload, IP header, UDP, RTP, SRTP and forward error correction (Kbps)
RTAudio WidebandPeer-to-peer29.
RTAudio NarrowbandPeer-to-peer, PSTN11.827.839.851.6
The bandwidth numbers in the previous table are based on 20ms packetization (50 packets per second) and for Siren and G.722 include the additional secure real-time transport protocol (SRTP) overhead from conferencing scenarios and assume the stream is 100% active. Forward Error Correction (FEC) is dynamically used when there is packet loss on the link to help maintain the quality of the audio stream.
For video, the codec is always RTVideo.The bandwidth required depends on the resolution, quality, and frame rate. For each resolution, there are two interesting bit rates:

How do we considered Media Bypass:
If we assume 20% EV user = 6,000 which make 10% concurrent call -> 600 throughout 3 Pool = 200 call concurrently.
So we need to consider the protocol used by Lync, the encryption and more. First with Cisco you cannot implement any encryption, so no TLS, which means you have medium security in this network. Cisco supports only codec g711ulaw.

Just compare the network call flow, if you have a mediation server in place, the client connect to the Mediation Server directly, which than trunk it and communicates with the Gateway, here CCM. If we have Media Bypass, the client directly connects to the CCM.

Lets do a very basic calculation:
200 call via RTAudio Narrowband (51.6kbps) to the consolidated Pool are:            10320kbps
200 call via g711ulaw (156kbps) with in the network to the CCM are:                      31200kbps 
If i would even calculate this with more concurrent calls, this more dramatically impacting the network.

Say we have 900 concurrent calls, which btw would require already 2 physical, or 5 virtual Mediation Server ;)
900 call via RTAudio to the consolidated Pool are:                46440kbps

900 call via g711ulaw with in the network to the CCM are:  140400kbps 
If you know check and see in an enterprise network, where you mainly have sites connected via WAN connection, you need carefully calculate and consider the those bandwidth impacts.
From my opinion and also having in mind you will need additional internal Firewall rules for those calls.
I clearly prefer the Mediation Server.
Here in Asia, where bandwidth is very costly, the price comparison between bandwidth and server, even if you have virtualized MS, will alway lead to non Media Bypass.

Media bypass refers to removing the Mediation Server from the media path whenever possible for calls whose signaling traverses the Mediation Server. This feature is new for Lync Server 2010.
Media bypass can improve voice quality by reducing latency, needless translation, possibility of packet loss, and the number of points of potential failure. Scalability can be improved, because elimination of media processing for bypassed calls reduces the load on the Mediation Server. This reduction in load complements the ability of the Mediation Server to control multiple gateways.

Where a branch site without a Mediation Server is connected to a central site by one or more WAN links with constrained bandwidth, media bypass lowers the bandwidth requirement by allowing media from a client at a branch site to flow directly to its local gateway without first having to flow across the WAN link to a Mediation Server at the central site and back.
By relieving the Mediation Server from media processing, media bypass may also reduce the number of Mediation Servers that an Enterprise Voice infrastructure requires.

The following figure shows basic media and signaling pathways in topologies with and without media bypass.
Ein paar der Gateway Anbieter die Media Bypass fähige und mit FXS Ports ausgestattete Gateways anbieten:
  • Audiocodes
  • Dialogic
  • Ferrari electronics AG
  • NET

Media and signaling pathways with and without media bypass

Requirements for Media Bypass

For each call to the PSTN, the Mediation Server determines whether media from the endpoint of origin can be sent directly to a Mediation Server peer without traversing the Mediation Server. The peer can be a PSTN gateway, IP-PBX, or Session Border Controller (SBC) at an Internet telephony service provider (ITSP). For details about defining Mediation Server peers, see Define a Peer of the Mediation Server for a Site in the Deployment documentation.
Media bypass can be employed when the following requirements are met:

A Mediation Server peer must support the necessary capabilities for media bypass, the most important being the ability to handle multiple forked responses (known as “early dialogs”). Contact the manufacturer of your gateway or PBX, or your ITSP, to obtain the value for the maximum number of early dialogs that the gateway, PBX, or SBC can accept.

The Mediation Server peer must accept media traffic directly from Lync Server 2010 endpoints. Many ITSPs allow their SBC to receive traffic only from the Mediation Server. Contact your ITSP to determine whether its SBC accepts media traffic directly from Lync Server 2010 endpoints.

Lync Server 2010 clients and a Mediation Server peer must be well connected, meaning that they are either located in the same network region or at network sites that connect to the region over WAN links that have no bandwidth constraints

Planning for Media Bypass

Media bypass is useful when you want to minimize the number of Mediation Servers deployed. Typically, a Mediation Server pool will be deployed at a central site, and it will control gateways at branch sites. Enabling media bypass allows media for PSTN calls from clients at branch sites to flow directly through the gateways at those sites. Lync Server 2010 outbound call routes and Enterprise Voice policies must be properly configured so that PSTN calls from clients at a branch site are routed to the appropriate gateway.

  • If you have a centralized topology without WAN links to branch sites, you can enable global media bypass, because fine-grained control is unnecessary.
  • If you have a distributed topology consisting of one or more network regions and their affiliated branch sites, determine the following:
- Whether your Mediation Server peers are able to support the capabilities required for media bypass.
- Which sites in each network region are well connected.
- Which combination of media bypass and call admission control is appropriate for your network.

Bypass IDs are computed, either directly or indirectly, depending on configuration by the administrator. In addition to enabling media bypass globally, you must enable media bypass individually on each PSTN trunk. If bypass is enabled globally but is not enabled for a particular PSTN trunk, media bypass will not be invoked for any calls involving that PSTN trunk. In addition, when media bypass is set to Use Site and Region Information, you must associate all routable subnets with the sites in which they are located. If there are routable subnets within a site for which bypass is not wanted, these subnets should be grouped within a new site before you enable media bypass. Doing so will assure that the unroutable subnets are assigned a different bypass ID.


Popular posts from this blog

Cannot join external Lync Meeting: Lync Edge Server Single IP Address (Lync Edge Server Single IP Web Conferenceing Problem)

How to hide users from GAL if they are AD Connect synchronized

MFA with Guest Access and different tenants settings