Planeación del control de admisión de llamadas

Identificar regiones de red

Una región de red representa una red troncal de red o un concentrador de red.

Un concentrador de red o una red troncal es parte de la infraestructura de una red informática que interconecta las diferentes partes de la red, lo que proporciona una ruta de acceso para el intercambio de información entre las diferentes LAN o subredes. Una red troncal puede enlazar diversas redes, ya sea de una pequeña ubicación a una extensa área geográfica. Con frecuencia, la capacidad de la red troncal es mayor que la de las redes que se conectan a ella.

Nuestra topología de ejemplo tiene tres regiones de red: Norteamérica, EMEA y APAC. Una región de red contiene un grupo de sitios de red (consulte la definición de sitios de red que aparece en este tema). Trabaje con el equipo de operaciones de red para identificar sus regiones de red.

Asociación de un sitio central con cada región de red

CAC precisa que cada región de red tenga un sitio central de Lync Server. Un componente de software de Lync Server toma las decisiones de CAC. La topología de red del ejemplo anterior muestra tres regiones de red, cada una de ellas con un sitio central que se encarga de las decisiones de CAC. Este sitio central se selecciona por la proximidad geográfica. Como el tráfico de medios es más pesado en las regiones de red, la asignación de pertenencia por proximidad geográfica convierte la región de red en autocontenida; las comunicaciones dentro de una región de red continuarán aunque otros sitios centrales no estén disponibles. A partir del ejemplo anterior, en la siguiente tabla se muestra la asociación adecuada.

Regiones de red, sitios centrales y sitios de red

Identificar sitios de red

Un sitio de red representa una ubicación en la que la organización tiene oficinas, un conjunto de edificios o un campus. Comience por realizar un inventario de las oficinas de la organización. En nuestra topología de ejemplo, la región de red Norteamérica está formada por los siguientes sitios de red: Nueva York, Chicago, Detroit, Portland, Reno y Albuquerque.

Debe asociar todos los sitios de red con una región de red. En función de si el sitio de red tiene o no un vínculo WAN restringido, se asocia una directiva de ancho de banda con el sitio de red. Para obtener más información acerca de las directivas de CAC y el ancho de banda que asigna mediante ellas, consulte "Definir directivas de ancho de banda" posteriormente en este tema. Para configurar el CAC, asocie sitios de red con regiones de red y, a continuación, cree directivas de asignación de ancho de banda para aplicarlas a las conexiones con ancho de banda restringido entre un sitio o región determinada y las conexiones WAN entre los sitios y regiones.

Identificar vínculos de red

Los vínculos de red representan conexiones a la WAN física que vincula diferentes regiones y sitios. En nuestra topología de ejemplo, hay dos vínculos de red regional, cinco vínculos de red entre regiones y sitios y un vínculo de red entre dos sitios.

Los dos vínculos de red regional están entre Norteamérica y EMEA, representado como NA-EMEA-LINK y entre APAC y EMEA, representado como EMEA-APAC-LINK.

Los vínculos de sitios se indican mediante las líneas que conectan Portland, Reno y Albuquerque con la región Norteamérica, Manila con la región APAC y Colonia con la región EMEA. La línea entre Reno y Albuquerque muestra un vínculo de red directo entre estos dos sitios.

Definir directivas de ancho de banda

Colabore con el equipo de operaciones de red para determinar la cantidad de ancho de banda WAN disponible para tráfico de audio y vídeo en tiempo real a través de los vínculos WAN de la organización. Normalmente, las directivas de ancho de banda se aplican a vínculos WAN si el uso del ancho de banda está restringido, es decir, si se espera que sea mayor que el ancho de banda que se puede asignar para modalidades de audio y vídeo.

Las directivas de ancho de banda del CAC definen la cantidad de ancho de banda que se reserva para modalidades de audio y vídeo en tiempo real.

Las directivas de ancho de banda del CAC pueden definir cualquiera de las siguientes opciones o todas ellas:

• Ancho de banda total máximo asignado para audio

• Ancho de banda total máximo asignado para vídeo

• Ancho de banda máximo asignado para una única llamada de audio (sesión)

• Ancho de banda máximo asignado para una única videollamada (sesión)

Para optimizar la utilización del ancho de banda por sesión, tenga en cuenta el tipo de códecs de audio y vídeo que se van a usar. En concreto, evite una asignación insuficiente de ancho de banda a un códec que prevea que se va a usar con frecuencia. Por el contrario, si desea evitar que los medios usen un códec que precisa mayor ancho de banda, deberá establecer un ancho de banda máximo por sesión lo suficientemente bajo para disuadir de su utilización. En lo que respecta al audio, no todos los códecs están disponibles para todos los escenarios. Por ejemplo:

• Las llamadas de audio de punto a punto entre extremos de Lync 2010 usarán RTAudio (8 kHz) o RTAudio (16 kHz) cuando tenga en cuenta el ancho de banda y la prioridad de los códecs.

• Las llamadas de conferencia entre extremos de Lync 2010 y el servicio de conferencia A/V usarán G.722 o Siren.

• Las llamadas a la RTC que partan o se dirijan a extremos de Lync 2010 usarán G.711 o RTAudio (8 kHz).

Use la tabla que aparece a continuación para optimizar la configuración de ancho de banda máximo por sesión.

Utilización de ancho de banda por códecs

Los códecs G.722.1 y Siren son similares, pero ofrecen diferentes velocidades de bits.

G.722, el códec predeterminado para conferencia de Lync Server 2010, es completamente diferente de los códecs G.722.1 y Siren.

El códec Siren se usa en Lync Server 2010 en las siguientes situaciones:

• Si la directiva de ancho de banda tiene un valor demasiado bajo para permitir la utilización de G.722

• Si un cliente de Communications Server 2007 o Communications Server 2007 R2 se conecta a un servicio de conferencia de Lync Server 2010 (debido a que estos clientes no admiten el códec G.722)

Utilización de ancho de banda por escenario

Identificar subredes IP

Para cada sitio de red, tendrá que trabajar con el administrador de la red para determinar qué subredes IP están asignadas a cada sitio de red. Si el administrador de la red ya ha organizado las subredes IP en regiones de red y sitios de red, su trabajo se habrá simplificado en gran medida.

En nuestro ejemplo, el sitio Nueva York de la región Norteamérica tiene asignadas las siguientes subredes IP: 172.29.80.0/23, 157.57.216.0/25, 172.29.91.0/23, 172.29.81.0/24. Demos por supuesto que Bob, que normalmente trabaja en Detroit, viaja a la oficina de Nueva York para recibir formación. Cuando encienda su equipo y se conecte a la red, su equipo obtendrá una dirección IP de uno de los cuatro rangos asignados a Nueva York, por ejemplo, 172.29.80.103.

Advertencia:

Las subredes IP especificadas durante la configuración de red del servidor deben coincidir con el formato que proporcionan los equipos cliente para que se puedan usar adecuadamente para el desvío de medios. Un cliente de Lync 2010 toma su dirección IP local y enmascara la dirección IP con la máscara de subred asociada. Al determinar el identificador de desvío asociado a cada cliente, el registrador comparará la lista de subredes IP asociadas con cada sitio de red con la subred indicada por el cliente para comprobar que coincidan exactamente. Por este motivo, es importante que las subredes introducidas durante la configuración de la red del servidor sean subredes reales y no virtuales. (Si implementa el sistema de control de admisión de llamadas, pero no el desvío de medios, el sistema control de admisión de llamadas funcionará correctamente aunque configure subredes virtuales). Por ejemplo, si un cliente inicia sesión en un equipo con una dirección IP 172.29.81.57 con una máscara de subred IP 255.255.255.0, Lync 2010 solicitará el identificador de derivación asociado con la subred 172.29.81.0. Si la red se define como 172.29.0.0/16, aunque el cliente pertenezca a una subred virtual, el registrador no lo considerará una coincidencia debido a que el registrador está buscando específicamente la subred 172.29.81.0. Por lo tanto, es importante que el administrador introduzca las subredes exactamente tal y como las proporcionan los clientes (que se aprovisionan con subredes durante la configuración de red, ya sea de forma estática o mediante DHCP).