Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
A voz da Rede Telefónica Pública Comutado (RTPC) é considerada uma aplicação crítica para a empresa com elevadas expectativas de qualidade de voz. O Encaminhamento Direto para Telefonia do Microsoft Teams permite-lhe controlar fluxos de tráfego de multimédia para acomodar inúmeras topologias de rede e configurações de telefonia local para várias empresas em todo o mundo.
A Otimização de Multimédia Local para Encaminhamento Direto permite-lhe gerir a qualidade da voz ao:
Controlar a forma como o tráfego de multimédia flui entre os clientes do Teams e os Controladores de Limite de Sessão (SBCs) do cliente.
Manter os suportes de dados locais dentro dos limites das sub-redes da rede empresarial.
Permitir fluxos de multimédia entre os clientes do Teams e os SBCs, mesmo que os SBCs estejam protegidos por firewalls empresariais com IPs privados e não estejam visíveis diretamente para a Microsoft.
A Otimização de Multimédia Local suporta dois cenários:
Centralização de todos os ramais locais através de um SBC centralizado ligado ao ramal SIP (Session Initiation Protocol) main. Este cenário fornece serviços de telefonia a todas as sucursais locais da empresa.
Uma topologia de rede virtual de SBCs. Neste cenário, os SBCs nas sucursais locais estão ligados a um SBC de proxy centralizado que está visível e a comunicar com Telefonia do Teams através do respetivo endereço IP externo. Numa topologia de rede virtual, os SBCs a jusante estão a comunicar através de IPs internos e não estão diretamente visíveis para Telefonia do Teams.
Este artigo descreve funcionalidades de funcionalidades, cenários de clientes e soluções. Para obter detalhes sobre a configuração, veja Configurar a Otimização de Multimédia Local.
Nota
Se quiser manter os suportes de dados locais dentro dos limites da intranet, recomenda-se a Otimização de Multimédia Local. No entanto, se já tiver o Media Bypass e utilizar apenas os endereços IP públicos dos seus SBCs, não precisa de mudar para a Otimização de Multimédia Local. Pode continuar a utilizar o Media Bypass. Para obter mais informações, veja Planear Ignorar Multimédia.
Para obter informações sobre quais os fornecedores de SBC que suportam a Otimização de Multimédia Local, veja Controladores de Limite de Sessão Certificados para Encaminhamento Direto.
Cenários de cliente suportados
Para este debate, suponha que a Contoso gere várias empresas em todo o mundo da seguinte forma. (As regiões Europa e APAC são utilizadas apenas como exemplos. Uma empresa pode ter várias regiões diferentes com requisitos semelhantes.)
Na Europa, a Contoso tem escritórios em aproximadamente 30 países/regiões. Cada escritório tem o seu próprio Private Branch Exchange (PBX).
Foi oferecida à Contoso uma opção para centralizar os porta-malas numa localização – Amesterdão – para todos os 30 escritórios europeus. A Contoso implementou o SBC em Amesterdão, forneceu largura de banda suficiente para executar chamadas através da localização centralizada, ligou um porta-malas SIP centralizado à localização centralizada e começou a servir todas as localizações europeias a partir de Amesterdão.
Na região APAC, a Contoso tem vários escritórios em diferentes países/regiões.
Em muitos países/regiões, a empresa ainda tem ramais de multiplexing de divisão de tempo (TDM) em sucursais locais. A centralização dos ramais TDM não é uma opção na região APAC, pelo que não é possível mudar para o SIP. Imagine que existem mais de 50 sucursais da Contoso na região APAC com centenas de gateways (SBCs). Neste cenário, não é possível emparelhar todos os gateways para a interface de Encaminhamento Direto devido à falta de endereços IP públicos e/ou simultâneas na Internet local. Além disso, alguns países/regiões impõem requisitos regulamentares que não podem ser cumpridos sem ter conectividade de rede RTPC local.
Com base nos respetivos requisitos comerciais, a Contoso implementou duas soluções com a Otimização de Multimédia Local para o Encaminhamento Direto:
Na Europa, todos os ramais são centralizados e os fluxos multimédia entre o SBC central e os utilizadores, com base na localização do utilizador.
Se um utilizador estiver ligado à sub-rede local de uma rede empresarial (ou seja, o utilizador é interno), os fluxos de multimédia entre o IP interno do SBC central e o cliente teams do utilizador.
Se um utilizador estiver fora dos limites da rede empresarial, por exemplo, se o utilizador estiver a utilizar uma ligação à Internet sem fios pública, o utilizador será considerado externo. Neste caso, o suporte de dados flui entre o IP externo do SBC central e o cliente do Teams.
Na região APAC, um SBC de proxy centralizado é emparelhado com o Encaminhamento Direto da Microsoft, que direciona o suporte de dados entre a interface de Encaminhamento Direto e os SBCs a jusante nas sucursais locais.
Os SBCs a jusante nas sucursais locais não são diretamente visíveis para o Encaminhamento Direto no APAC, mas são emparelhados com o cmdlet Set-CSOnlinePSTNGateway para criar uma topologia de rede virtual no Telefonia do Teams. Os meios de comunicação permanecem sempre locais sempre que possível. Os utilizadores externos têm multimédia a fluir entre o cliente do Teams e o IP público do SBC do proxy.
SBC Central com ramais centralizados
Para criar uma solução em que os serviços RTPC são fornecidos a todas as sucursais locais através de um único SBC central com um ramal SIP centralizado ligado, o administrador inquilino da Contoso emparelha um SBC (centralsbc.contoso.com) com o serviço. O SBC tem um ramal SIP centralizado ligado ao mesmo.
Quando um utilizador está na rede interna da empresa, o SBC fornece o IP interno do SBC para suportes de dados.
Quando um utilizador está fora da rede empresarial, o SBC fornece o IP externo (público) do SBC.
Nota
Todos os valores dentro de exemplos, tabelas ou diagramas são apresentados apenas para fins ilustrativos.
Tabela 1. Parâmetros de rede de exemplo para SBCs
| Localização | SBC FQDN | Sub-rede interna | NAT Externo (IP Fidedigno) | Endereço IP externo SBC | Endereço IP interno SBC |
|---|---|---|---|---|---|
| Amsterdã | centralsbc.contoso.com | 192.168.5.0/24 | 172.16.76.73 | 172.16.76.71 | 192.168.5.5 |
| Alemanha | Não implementado | 192.168.6.0/24 | 172.16.76.74 | Não implementado | Não implementado |
| França | Não implementado | 192.168.7.0/24 | 172.16.76.75 | Não implementado | Não implementado |
Utilizador interno
O diagrama seguinte mostra o fluxo de tráfego quando um utilizador está ligado à rede empresarial na sucursal ou site do utilizador.
No local, o utilizador é atribuído à sucursal local na Alemanha. O utilizador faz uma chamada telefónica de Encaminhamento Direto através do Teams.
O cliente teams do utilizador comunica com Telefonia do Teams diretamente através da API REST, mas o suporte de dados gerado durante a chamada flui para o endereço IP interno do SBC central.
O SBC redireciona o fluxo para Telefonia do Teams e para a rede RTPC ligada.
O SBC central é visível para Telefonia do Teams apenas através do endereço IP externo.
Diagrama 1. Fluxo de tráfego quando o utilizador está no site "home" com um SBC centralizado e com um Ramal SIP centralizado ligado
Utilizador externo
O diagrama seguinte mostra o fluxo de tráfego quando um utilizador não está no local e não está ligado à rede empresarial (ou seja, o dispositivo do utilizador está ligado à Internet através de um dispositivo móvel ou Wi-Fi público). O utilizador faz uma chamada telefónica de Encaminhamento Direto através do Teams:
O cliente teams do utilizador comunica com Telefonia do Teams diretamente através da API REST, mas, neste caso, o suporte de dados gerado durante a chamada flui para o endereço IP externo do SBC central.
O SBC redireciona o fluxo para Telefonia do Teams e para a rede RTPC ligada.
O SBC central é visível para Telefonia do Teams apenas através do endereço IP externo.
Neste caso, o comportamento é semelhante quer o utilizador seja local para a sucursal na Alemanha ou para qualquer outra sucursal. O utilizador é considerado externo porque o utilizador está fora dos limites da rede empresarial.
Diagrama 2. Fluxo de tráfego quando o utilizador é externo com um SBC centralizado e com um Ramal SIP centralizado ligado
Proxy SBC com SBCs a jusante ligados
Para criar uma solução em que os serviços RTPC são fornecidos em todas as sucursais locais na região APAC onde a centralização dos ramais TDM não é uma opção, o administrador da Contoso emparelha um SBC (proxysbc.contoso.com), também denominado SBC de proxy, para o serviço de Encaminhamento Direto.
Posteriormente, o administrador da Contoso adiciona alguns SBCs a jusante que indicam que podem ser acedidos através do SBC do proxy proxysbc.contoso.com. Os SBCs a jusante não têm IPs públicos; no entanto, podem ser atribuídas a rotas de voz. A tabela seguinte mostra exemplos de parâmetros de rede e configuração.
Quando um utilizador está na sucursal local onde está localizado o SBC a jusante, o tráfego de multimédia flui diretamente entre o utilizador e o SBC a jusante local. Se um utilizador estiver fora do escritório (numa Internet pública), o suporte de dados flui do utilizador para o IP público do SBC do Proxy, que o proxie para os SBC(s) a jusante relevantes.
Tabela 2. Informações de rede SBC de exemplo
| Localização | SBC FQDN | Sub-rede interna | NAT Externo (IP Fidedigno) | Endereço IP externo SBC | Endereço IP interno SBC |
|---|---|---|---|---|---|
| Vietnã | VNsbc.contoso.com | 192.168.1.0/24 | 172.16.240.110 | Nenhum | 192.168.1.5 |
| Indonésia | IDsbc.contoso.com | 192.168.2.0/24 | 172.16.240.120 | Nenhum | 192.168.2.5 |
| Singapura | proxysbc.contoso.com | 192.168.3.0/24 | 172.16.240.130 | 172.16.240.133 | 192.168.3.5 |
Utilizador interno
O diagrama seguinte mostra o fluxo de tráfego de alto nível para o cenário em que um utilizador está dentro do escritório na região APAC. O utilizador, que está atribuído a uma sucursal local no Vietname e está no local, faz uma chamada telefónica de Encaminhamento Direto através do Teams.
O cliente teams do utilizador comunica com Telefonia do Teams diretamente através da API REST, mas os suportes de dados gerados durante a chamada fluem para o endereço IP interno do SBC local.
O SBC local redireciona o fluxo para o proxy SBC em Singapura e para a rede RTPC local ligada.
O SBC do proxy é visível para Telefonia do Teams apenas através do endereço IP externo e encaminha o fluxo do SBC a jusante (neste caso, o SBC local no Vietname) para Telefonia do Teams.
O SBC a jusante na sucursal local não está visível para Telefonia do Teams diretamente, mas é mapeado na topologia de rede virtual definida pelo administrador da Contoso ao configurar a Otimização de Multimédia Local.
Nota
O comportamento pode ser diferente para utilizadores locais e utilizadores não locais, consoante o modo de Otimização de Multimédia Local configurado.
Para obter mais informações sobre os modos possíveis e o comportamento relevante, veja Configurar a Otimização de Multimédia Local.
Diagrama 3. Fluxo de tráfego quando o utilizador está na rede "home" com um SBC de proxy e com SBCs a jusante ligados
Utilizador externo
O diagrama seguinte mostra o fluxo de tráfego quando um utilizador está fora dos limites da rede empresarial. O utilizador não está no local (não está dentro dos limites da rede empresarial). O utilizador faz uma chamada telefónica de Encaminhamento Direto através do Teams para um número de telefone no Vietname.
O cliente teams do utilizador comunica com Telefonia do Teams diretamente através da API REST, mas o suporte de dados gerado durante a chamada flui primeiro para o endereço IP externo do SBC do proxy em Singapura.
Com base nas políticas de configuração e voz (veja Configurar a Otimização de Multimédia Local), o SBC de proxy redireciona o fluxo para o SBC a jusante no Vietname.
O SBC a jusante no Vietname redireciona o fluxo para a rede RTPC local ligada.
O SBC do proxy é visível para Telefonia do Teams apenas através do endereço IP externo.
O SBC a jusante na sucursal local não está visível para Telefonia do Teams diretamente, mas é mapeado na topologia de rede virtual que é definida pelo administrador da Contoso ao configurar a Otimização de Multimédia Local. No exemplo, o utilizador é considerado externo porque o utilizador está fora dos limites da rede empresarial.
Diagrama 4. Fluxo de tráfego quando o utilizador é externo com um SBC de proxy e com SBCs a jusante ligados
Modos de Otimização de Multimédia Local
A Otimização de Multimédia Local suporta dois modos:
Modo 1: ignorar sempre. Neste caso, se o utilizador for interno, o suporte de dados flui através do endereço IP interno do SBC a jusante local, independentemente da localização real do utilizador interno, por exemplo, na mesma sucursal onde o SBC a jusante está localizado ou noutra sucursal.
Modo 2: apenas para utilizadores locais. Neste modo, o suporte de dados flui diretamente para o endereço IP interno do SBC a jusante local apenas quando gerado pelo utilizador interno localizado na mesma sucursal que o SBC a jusante.
Para distinguir entre os modos de Otimização de Multimédia Local, o administrador inquilino tem de definir o parâmetro -BypassMode como "Always" ou "OnlyForLocalUsers" para cada SBC através do cmdlet Set-CSonlinePSTNGateway. Para obter mais informações, veja Configurar a Otimização de Multimédia Local.
Nota
Quando os utilizadores são internos, é necessária conectividade multimédia entre o utilizador e o SBC através do endereço IP interno. Neste caso, não há qualquer contingência nos reencaminhamentos de transportes públicos para os suportes de dados, uma vez que o SBC fornece um IP interno para a conectividade multimédia.
Modo 1: ignorar sempre
Se tiver uma boa ligação entre sucursais, o modo recomendado é Ignorar sempre.
Por exemplo, suponha que uma empresa tem um porta-malas SIP centralizado em Amesterdão, que serve 30 países/regiões e tem uma boa conectividade entre todos os 30 sites e utilizadores locais. Também existe uma sucursal na Alemanha onde é implementado um SBC local.
O SBC na Alemanha pode ser configurado no modo "Ignorar sempre". Os utilizadores, independentemente da sua localização, ligam-se diretamente ao SBC através do endereço IP interno do SBC, por exemplo, da França para a Alemanha. Veja o seguinte diagrama para referência.
O seguinte descreve dois cenários:
Cenário 1. O utilizador está na mesma localização que o SBC definido na Política de Encaminhamento de Voz Online.
Cenário 2. O utilizador e os gateways estão em sites diferentes.
Cenário 1. O utilizador está na mesma localização que o SBC definido na Política de Encaminhamento de Voz Online
O SBC em Amesterdão está configurado para ser um SBC de proxy para um SBC a jusante local na Alemanha. O utilizador está na Alemanha dentro da mesma sub-rede que a rede empresarial do SBC local. Ambos os SBCs (proxy e a jusante) estão configurados para o modo Always Bypass. As políticas de encaminhamento de voz online especificam que as chamadas na Alemanha (com o código de área +49) devem ser encaminhadas para o SBC local na Alemanha. Todas as outras chamadas devem ser encaminhadas para o proxy SBC em Amesterdão. No entanto, se o SBC na Alemanha falhar, as chamadas na Alemanha também deverão ser encaminhadas para o proxy SBC em Amesterdão. A tabela seguinte resume a configuração de exemplo.
Tabela 3. Configuração de exemplo para o Cenário 1
| Localização física do utilizador | O utilizador faz uma chamada para um número | Política de Encaminhamento de Voz Online | Modo configurado para SBC | Fluxo de Multimédia |
|---|---|---|---|---|
| Alemanha | +49 1 437 2800 | Prioridade 1: ^+49(\d{8})$ -DEsbc.contoso.com Prioridade 2: .* - proxysbc.contoso.com |
DEsbc.contoso.com – Ignorar Sempre proxysbc.contoso.com – Ignorar Sempre |
Utilizador do <Teams –> DEsbc.contoso.com |
O diagrama abaixo mostra o fluxo de tráfego de alto nível para o utilizador interno na Alemanha a fazer uma chamada telefónica de Encaminhamento Direto através do Teams para o número na Alemanha.
O cliente teams do utilizador comunica com Telefonia do Teams diretamente através da API REST.
O suporte de dados gerado durante a chamada flui para o endereço IP interno do SBC local.
O SBC local redireciona o fluxo para o proxy SBC em Amesterdão e para a rede RTPC local ligada.
O SBC do proxy é visível para Telefonia do Teams apenas através do endereço IP externo e encaminha o fluxo do SBC a jusante (neste caso, o SBC local na Alemanha) para Telefonia do Teams.
O SBC a jusante na sucursal local não está visível para Telefonia do Teams diretamente, mas é mapeado na topologia de rede virtual que é definida pelo administrador da Contoso ao configurar a Otimização de Multimédia Local.
Diagrama 5. Fluxo de tráfego com o modo "Ignorar Sempre" e o utilizador está no site "home"
Cenário 2: O utilizador e os gateways estão em sites diferentes
O SBC em Amesterdão está configurado para ser um SBC de proxy para um SBC a jusante local na Alemanha. Ambos os SBCs (proxy e a jusante) estão configurados para o modo Always Bypass. O utilizador interno em França, localizado na sucursal local, está a fazer uma chamada de Encaminhamento Direto para a Alemanha. As políticas de encaminhamento de voz online especificam que as chamadas para a Alemanha (com o código de área +49) devem ser encaminhadas para o SBC local na Alemanha. Todas as outras chamadas devem ser encaminhadas para o proxy SBC em Amesterdão. No entanto, se o SBC na Alemanha falhar, todas as chamadas na Alemanha deverão ser encaminhadas para o proxy SBC em Amesterdão. A tabela seguinte resume a configuração de exemplo.
Tabela 4. Configuração de exemplo para o Cenário 2
| Localização física do utilizador | O utilizador faz uma chamada para um número | Política de Encaminhamento de Voz Online | Modo configurado para SBC | Fluxo de Multimédia |
|---|---|---|---|---|
| França | +49 1 437 2800 | Prioridade 1: ^+49(\d{8})$ -DEsbc.contoso.com Prioridade 2: .* - proxysbc.contoso.com |
DEsbc.contoso.com – Ignorar Sempre proxysbc.contoso.com – Ignorar Sempre | Utilizador do <Teams – > DEsbc.contoso.com |
O diagrama seguinte mostra o fluxo de tráfego de alto nível quando o utilizador alemão interno localizado em França faz uma chamada telefónica de Encaminhamento Direto através do Teams para o número na Alemanha.
O cliente teams do utilizador comunica com Telefonia do Teams diretamente através da API REST.
O suporte de dados gerado durante a chamada flui diretamente para o SBC no endereço IP interno da Alemanha.
O SBC na Alemanha redireciona o fluxo para o proxy SBC em Amesterdão e para a rede RTPC local ligada.
Diagrama 6. Fluxo de tráfego com o modo "Ignorar Sempre" e o utilizador não está no site "home", mas sim na rede interna
Modo 2: apenas para utilizadores locais
Se existirem ligações incorretas entre sucursais locais, mas boas ligações entre cada sucursal local e a sede regional, o modo recomendado é "Apenas para Utilizadores Locais".
Por exemplo, na região APAC, suponha que a Contoso tem vários escritórios em diferentes países/regiões. Para muitos países/regiões, não é possível mudar para o SIP porque a empresa ainda tem porta-malas TDM em muitas sucursais locais. A centralização dos ramais TDM não é uma opção na região APAC. Além disso, existem mais de 50 sucursais da Contoso na região APAC com centenas de gateways (SBCs).
Para criar uma solução em que os serviços RTPC são fornecidos em todas as sucursais locais na região APAC onde a centralização dos ramais TDM não é uma opção, o administrador da Contoso emparelha um SBC regional em Singapura como o SBC de proxy para o serviço de Encaminhamento Direto. A ligação direta entre as sucursais locais não é boa, mas há uma boa ligação entre cada sucursal local e o SBC regional em Singapura. Para o SBC regional, o administrador escolhe o modo "Ignorar Sempre". Para os SBCs a jusante locais, o administrador escolhe o modo "Apenas para Utilizadores Locais".
O seguinte descreve dois cenários:
Cenário 1. O utilizador está na mesma localização que o SBC definido na Política de Encaminhamento de Voz Online
Cenário 2. O utilizador e os gateways estão em sites diferentes
Cenário 1. O utilizador está na mesma localização que o SBC definido na Política de Encaminhamento de Voz Online
Suponha que o SBC em Singapura está configurado para ser um SBC de proxy para os SBCs a jusante locais no Vietname e na Indonésia. O utilizador está no Vietname na mesma localização que o SBC local. As políticas de encaminhamento de voz online especificam que as chamadas no Vietname (com o código de área +84) devem ser encaminhadas para o SBC local no Vietname. Todas as outras chamadas devem ser encaminhadas para o proxy SBC em Singapura. No entanto, se o SBC no Vietname falhar, as chamadas no Vietname devem ser encaminhadas para o SBC de procuração em Singapura. A tabela seguinte resume a configuração de exemplo.
Tabela 5. Configuração de exemplo para o modo "Apenas Para Utilizadores Locais" Cenário 1
| Localização física do utilizador | O utilizador faz uma chamada para um número | Política de Encaminhamento de Voz Online | Modo configurado para SBC | Fluxo de Multimédia |
|---|---|---|---|---|
| Vietnã | +84 4 3926 3000 | Prioridade 1: ^+84(\d{9})$ -VNsbc.contoso.com Prioridade 2: .* - proxysbc.contoso.com |
VNsbc.contoso.com – Apenas para Utilizadores Locais proxysbc.contoso.com – Ignorar Sempre |
Utilizador do <Teams –> VNsbc.contoso.com |
No diagrama seguinte, um utilizador atribuído à sucursal local no Vietname, enquanto está no local, faz uma chamada telefónica de Encaminhamento Direto através do Teams.
O cliente teams do utilizador comunica com Telefonia do Teams diretamente através da API REST.
Suporte de dados gerado durante a chamada flui para o endereço IP interno do SBC local.
O SBC local redireciona o fluxo para o proxy SBC em Singapura e para a rede RTPC local ligada.
O SBC do proxy é visível para Telefonia do Teams apenas através do endereço IP externo e encaminha o fluxo do SBC a jusante (neste caso, o SBC local no Vietname) para Telefonia do Teams.
O SBC a jusante na sucursal local não está visível para Telefonia do Teams diretamente, mas está mapeado na topologia de rede virtual.
Diagrama 7. Fluxo de tráfego com o modo "Apenas para Utilizadores Locais" e o utilizador está no site "home"
Cenário 2. O utilizador e os gateways estão em sites diferentes
Suponha que o SBC em Singapura está configurado para ser um SBC de proxy para os SBCs a jusante locais no Vietname e na Indonésia. O utilizador interno na Indonésia, localizado na sucursal local, está a fazer uma chamada de Encaminhamento Direto para o Vietname. As políticas de encaminhamento de voz online especificam que as chamadas para o Vietname (com o código de área +84) devem ser encaminhadas para o SBC local no Vietname. Todas as outras chamadas devem ser encaminhadas para o proxy SBC em Singapura. No entanto, se o SBC no Vietname falhar, as chamadas para o Vietname devem ser encaminhadas para o SBC de procuração em Singapura. O SBC de proxy em Singapura está definido como modo "Always Bypass" e o SBC local no Vietname está definido como modo "Apenas Para Utilizadores Locais". A tabela seguinte resume a configuração de exemplo.
Tabela 6. Configuração do usuário
| Localização física do utilizador | O utilizador faz uma chamada para um número | Política de Encaminhamento de Voz Online | Modo configurado para SBC | Fluxo de Multimédia |
|---|---|---|---|---|
| Indonésia | +84 4 3926 3000 | Prioridade 1: ^+84(\d{9})$ -VNsbc.contoso.com Prioridade 2: .* - proxysbc.contoso.com |
VNsbc.contoso.com – Apenas para Utilizadores Locais proxysbc.contoso.com – Ignorar Sempre |
Utilizador do <Teams –> proxysbc.contoso.com <–> VNsbc.contoso.com |
No diagrama seguinte, o utilizador interno, enquanto estiver no local na sucursal indonésia, faz uma chamada telefónica de Encaminhamento Direto através do Teams para um número no Vietname.
O cliente teams do utilizador comunica com Telefonia do Teams diretamente através da API REST.
Suporte de dados gerado durante os fluxos de chamada para o endereço IP interno do SBC do proxy primeiro.
O SBC de proxy em Singapura redireciona o fluxo para o endereço IP interno do SBC a jusante no Vietname e para Telefonia do Teams.
O SBC a Jusante no Vietname encaminha o fluxo para a rede RTPC local ligada.
O SBC do proxy é visível para Telefonia do Teams apenas através do endereço IP externo.
Os SBCs a jusante nas sucursais locais não são visíveis para Telefonia do Teams diretamente, mas são mapeados na topologia de rede virtual.
Diagrama 8. Fluxo de tráfego com o modo "Apenas para Utilizadores Locais" e o utilizador não está no site "home", mas na rede interna
Comportamentos conhecidos
A seguinte lista de comportamentos pode ser observada ao utilizar a Otimização de Multimédia Local:
| Comportamentos dos produtos | Observações |
|---|---|
| O cliente do Teams não é identificado como interno quando o IP público do cliente do Teams corresponde à lista de IP fidedignos do cliente, mas não corresponde ao site de rede. | A Otimização de Multimédia Local requer um site de rede correspondente para cada ligação efetuada a partir de um IP fidedigno listado. |
| O utilizador do Teams coloca a chamada em espera. A música é reproduzida na extremidade RTPC e a Otimização de Multimédia Local está a funcionar. O utilizador do Teams retoma a chamada. A chamada para a RTPC é retomada, mas a Otimização de Multimédia Local não está a funcionar e a chamada continua através do SBC Central (Proxy). | Quando um utilizador estaciona uma chamada para iniciar música em espera (MoH), a chamada é escalada de uma chamada 1:1 para uma chamada multipartidária pelo Controlador de Chamadas para invocar o Controlador de Multimédia e o Processador de Multimédia (que serve como misturador AVMCU) através do qual o MoH chega a um utilizador que foi suspenso. Desescalar para uma chamada 1:1 depois de a chamada retomar nunca acontece, de acordo com a estrutura. |
| Enquanto uma chamada está a ser estabelecida, o utilizador poderá ouvir o silêncio durante alguns segundos. | Este silêncio pode ocorrer em alguns casos devido à complexidade da arquitetura de Otimização de Multimédia Local. |
| Aplicações de voz (por exemplo, Atendedor Automático e Fila de Chamadas). | As aplicações de voz podem ser implementadas num ambiente com o LMO configurado. No entanto, as chamadas que envolvem aplicações de voz não são otimizadas para Otimização de Multimédia Local. Em vez disso, fluem através do SBC do proxy, com exceção das transferências do Atendedor Automático para os utilizadores da Otimização de Multimédia Local. Nestes casos, a chamada segue o caminho otimizado para Otimização de Multimédia Local, uma vez que é uma chamada direta 1:1. Para Location-Based cenários de Encaminhamento, veja Aplicações de voz (Atendedor Automático ou Fila de Chamadas). |
Artigos relacionados
Configurar a Otimização de Multimédia Local
Ignorar Suportes de Dados do Plano
Controladores de Limites de Sessão Certificados para Encaminhamento Direto