Planejando o controle de admissão de chamadas

 

Tópico modificado em: 2011-08-18

O planejamento do CAC (serviço de controle de admissão de chamadas) requer informações detalhadas sobre a topologia da rede da empresa. Para ajudar a planejar suas políticas do serviço de controle de admissão de chamadas, execute as etapas a seguir.

1. Identifique os hubs/backbones (chamados de regiões de rede) dentro de sua rede corporativa.

2. Identifique os escritórios ou locais (chamados sites de rede) dentro de cada região de rede.

3. Determine a rota de rede entre cada par de regiões de rede.

4. Determine os limites de largura de banda para cada link WAN.

   Observação:
   Os limites de largura de banda indicam a quantidade de largura de banda em um link WAN que é alocado para o Lync Enterprise Voice e o tráfego de áudio e vídeo. Portanto, quando um link WAN é descrito como "largura de banda restrita", o link WAN tem um limite de largura de banda menor do que os picos de tráfego esperados pelo link.

5. Identifique as subredes de IP que são atribuídas a cada site de rede.

Para explicar esses conceitos, usaremos a topologia de rede de exemplo mostrada na figura a seguir.

Exemplo de topologia para o controle de admissão de chamada

Observação:

Todos os sites de rede estão associados a uma região de rede. Por exemplo, Portland, Reno e Albuquerque estão incluídos na região da América do Norte. Nessa figura, são mostrados apenas links WAN que têm políticas de CAC aplicadas, com limites de largura de banda. Os sites de rede, Chicago, Nova York e Detroit, são mostrados dentro da região oval da América do Norte, porque eles não estão com restrições largura de banda e não exigem políticas de CAC.

Os componentes da topologia neste exemplo são explicados nas subseções a seguir. Para obter detalhes sobre como essa topologia foi planejada, incluindo os limites de largura de banda, consulte Exemplo: Coletando informações necessárias para o controle de admissão de chamadas.

Identifique as regiões de rede

Uma região de rede representa um backbone de rede ou um hub da rede.

Um backbone ou hub de rede é uma parte da infraestrutura de rede do computador que interconecta diferentes partes da rede, fornecendo um caminho para a troca de informações entre diferentes LANs ou subredes. Um backbone pode interligar diversas redes de um pequeno local para uma área geográfica ampla. A capacidade do backbone é normalmente maior do que as redes que se conectam a ele.

Nossa topologia de exemplo tem três regiões de rede: América do Norte, EMEA e APAC. Uma região de rede contém um conjunto de sites de rede (consulte a definição de sites de rede neste tópico). Trabalhe com sua equipe de operações de rede para identificar as regiões de rede.

Associando um site central de cada região de rede

O CAC exige que um site central do Lync Server para cada região de rede. Um componente de software no Lync Server toma as decisões do CAC. A topologia de rede do exemplo anterior mostra três regiões de rede, cada uma com um site central que gerencia as decisões do CAC. Este site central é escolhido pela proximidade geográfica. Como o tráfego de mídia é mais pesado dentro das regiões de rede, atribuir a propriedade por vizinhança geográfica torna a região de rede independente; as comunicações dentro de uma região de rede continuarão mesmo se outros sites centrais ficarem indisponíveis. No exemplo anterior, a associação apropriada é mostrada na tabela a seguir.

Observação:

Os sites centrais não correspondem necessariamente aos sites de rede. No entanto, nos exemplos nesta documentação, os nomes de alguns sites centrais (Chicago, Londres e Pequim) são os mesmos que alguns sites de rede. Mesmo se um site central e um site de rede compartilharem o mesmo nome, o site central será um elemento da topologia do Lync Server. O site de rede faz parte de toda a rede na qual a topologia do Lync Server reside.

Regiões de rede, sites centrais e sites de rede

Região de rede	Site central	Sites de rede
América do Norte	Chicago	Chicago Nova York Detroit Portland Reno Albuquerque
EMEA	Londres	Londres Colônia
APAC	Pequim	Pequim Manila

Identifique os sites de rede

Um site de rede representa um local onde a sua organização tem escritórios, um conjunto de edifícios ou um campus. Inicie o levantamento de todos os escritórios da organização. Em nosso exemplo de topologia, a região de rede da América do Norte consiste nos seguintes sites de rede: Nova York, Chicago, Detroit, Portland, Reno e Albuquerque.

Você deve associar cada site de rede a uma região de rede. Dependendo se o site de rede tem um link WAN restrito, uma política de largura de banda é associada ao site de rede. Para obter detalhes sobre políticas de CAC e a largura de banda que você aloca ao usá-las, consulte "Defina as políticas de largura de banda" posteriormente neste tópico. Para configurar o CAC, você deve associar os sites de rede às regiões de rede e criar políticas de alocação de largura de banda para aplicar às conexões de largura de banda restrita entre um determinado site ou região e conexões WAN entre locais e regiões.

Identifique os links de rede

Os links de rede as representam conexões WAN físicas que vinculam sites e regiões diferentes. Em nosso exemplo de topologia, há dois links de rede regionais, cinco links de rede entre locais e regiões e um link de rede entre dois sites.

Os dois links regionais estão entre América do Norte e EMEA, representado como NA-EMEA-LINK, e entre APAC e EMEA, representado como EMEA-APAC-LINK.

Os links de site são indicados por linhas que conectam Portland, Reno e Albuquerque à região da América do Norte, Manila à região APAC e Colônia à região EMEA. A linha entre Reno e Albuquerque mostra um link de rede direta entre esses dois sites.

Defina as políticas de largura de banda

Trabalhe com sua equipe de operações de rede para determinar a quantidade de largura de banda WAN que está disponível para o tráfego de vídeo e áudio em tempo real entre os links WAN na organização. As políticas de largura de banda são geralmente aplicadas aos links WAN quando o uso de largura de banda é restrito, isso é, espera-se que ele seja maior do que a largura de banda que pode ser alocada para as modalidades de áudio e vídeo.

As políticas de largura de banda do CAC definem a quantidade de largura de banda reservada para as modalidades de vídeo e áudio em tempo real.

As políticas de largura de banda do CAC podem definir o seguinte:

• Largura de banda total máxima alocada para áudio

• Largura de banda total máxima alocada para vídeo

• Largura de banda máxima alocada para uma única chamada de áudio (sessão)

• Largura de banda máxima alocada para uma única chamada de vídeo (sessão)

Observação:
Todos os valores de largura de banda do CAC representam os limites máximos de largura de banda unidirecional.

Observação:

Os recursos de Política de Voz do Lync Server 2010 fornecem a capacidade de substituir as verificações de política de largura de banda nas chamadas de entrada para o usuário (não nas chamadas de saída que são inseridas pelo usuário). Depois da sessão ser estabelecida, o consumo de largura de banda será contabilizado com precisão. Essa configuração deve ser usada com moderação e deve ser evitada nas decisões de controle de admissão de chamada apropriadas. Para obter detalhes, consulte Criar uma política de voz e configurar registros de uso PSTN ou Modificar uma política de voz e configurar registros de uso PSTNna documentação de implantação.

Para otimizar a utilização de largura de banda com base por sessão, considere o tipo de codec de áudio e vídeo que será usado. Mais especificamente, evite alocar menos largura de banda para um codec que você espera que seja usado com frequência. Por outro lado, se você deseja impedir que a mídia use um codec que exija mais largura de banda, deverá definir a largura de banda máxima por sessão menor o suficiente para desencorajar tal uso. Para o áudio, nem todos os codecs estão disponíveis para cada cenário. Por exemplo:

• As chamadas de áudio ponto a ponto entre os pontos de extremidade do Lync 2010 usarão RTAudio (8 kHz) ou RTAudio (16 kHz) quando você usar o fator na largura de banda e na priorização de codecs.

• As chamadas de conferência entre os pontos de extremidade do Lync 2010 e o serviço de Conferência de Áudio e Vídeo usarão G.722 ou Siren.

• As chamadas para a PSTN para os pontos de extremidade do Lync 2010 ou deles usarão 711 ou RTAudio (8 kHz).

Use a tabela a seguir para ajudar a otimizar as configurações de largura de banda máxima por sessão.

Utilização de largura de banda por codecs

Codec	Requisito de largura de banda sem nenhuma FEC (correção de erro antecipada)	Requisito de largura de banda com FEC (correção de erro antecipada)
RTAudio (8 kHz)	49,8 kbps	61,6 kbps
RTAudio (16 kHz)	67 kbps	96 kbps
Siren	57,6 kbps	73,6 kbps
G.711	102 kbps	166 kbps
G.722	105,6 kbps	169,6 kbps
RTVideo (CIF 15 fps)	260 kbps	Não aplicável
RTVideo (VGA 30 fps)	610 kbps	Não aplicável

Observação:
Os requisitos de largura de banda consideram a sobrecarga de conta para o seguinte: Ethernet II, IP, UDP, RTP e SRTP. Eles também incluem 10 kbps para sobrecarga RTCP.

Os codecs G.722.1 e Siren são semelhantes, mas oferecem diferentes taxas de bits.

G.722, o codec padrão para conferência do Lync Server 2010, é completamente diferente dos codecs G.722.1 e Siren.

O codec Siren é usado no Lync Server 2010 nas seguintes situações:

• Quando a política de largura de banda está definida como muito baixa para permitir que o G.722 seja usado

• Quando um cliente do Communications Server 2007 ou do Communications Server 2007 R2 se conecta a um serviço de conferência do Lync Server 2010 (porque os clientes não suportam o codec G.722)

Utilização de largura de banda por cenário

Cenário	Requisito de largura de banda otimizado por quantidade (kbps)	Requisito de largura de banda para modo balanceado (kbps)	Requisito de largura de banda otimizado por qualidade (kbps)
Chamadas de áudio ponto a ponto	45 kbps	62 kbps	91 kbps
Chamadas em conferência	53 kbps	101 kbps	165 kbps
Chamadas PSTN (entre o Lync 2010 e o gateway PSTN, com ignorar mídia)	97 kbps	97 kbps	161 kbps
Chamadas PSTN (entre o Lync 2010 e o Servidor de Mediação, sem ignorar mídia)	45 kbps	97 kbps	161 kbps
Chamadas PSTN (entre o Servidor de Mediação e o gateway PSTN, sem ignorar mídia)	97 kbps	97 kbps	161 kbps

Identifique as subredes IP

Para cada site de rede, você precisará trabalhar com seu administrador de rede para determinar quais subredes IP são atribuídas para cada site de rede. Se seu administrador de rede já organizou as subredes IP em regiões de rede e sites de rede, seu trabalho é significantemente simplificado.

Em nosso exemplo, o site de Nova York na região da América do Norte é atribuído às seguintes subredes IP: 172.29.80.0/23, 157.57.216.0/25, 172.29.91.0/23, 172.29.81.0/24. Vamos supor que Bob, que geralmente trabalha em Detroit, viaja para o escritório de Nova York para treinamento. Quando ele liga o computador e se conecta à rede, o computador obterá um endereço IP em um dos quatro intervalos alocados para Nova York, por exemplo, 172.29.80.103.

Aviso:

As subredes IP especificadas durante a configuração de rede no servidor devem corresponder o formato oferecido por computadores clientes para poder ser usado adequadamente pelo bypass de mídia. Um cliente do Lync 2010 leva seu endereço IP local e mascara o endereço IP com a máscara de subrede associada. Ao determinar o ID de bypass associado com cada cliente, o Registrador irá comprar a lista de subredes IP associadas com cada local de rede na subrede oferecida pelo cliente para uma correspondência exata. Por este motivo, é importante que as subredes inseridas durante a configuração de rede no servidor sejam subredes reais ao invés de subredes virtuais. (Se você implantar o controle de admissão de chamada, mas não o bypass de mídia, o controle de admissão de chamada funcionará mesmo se você configurar as subredes virtuais.) Por exemplo, se um cliente faz logon em um computador com um endereço IP de 172.29.81.57, uma máscara de subrede IP de 255.255.255.0, o Lync 2010 irá solicitar o ID de bypass associado com a subrede 172.29.81.0. Se a subrede é definida como 172.29.0.0/16, embora o cliente pertença à subrede virtual, o Registrador não irá considerar uma correspondência porque ele está procurando especificamente pela subrede 172.29.81.0. Portanto, é importante que o administrador insira subredes exatamente conforme fornecidos pelos clientes (que são provisionados com subredes durante a configuração de rede estática ou por DCE.)