Comunicação e colaboração

como a voz reforça o OCS 2007

Rajesh Ramanathan

Visão geral:

• Fazendo chamadas no OCS 2007
• Como as chamadas são protegidas
• Conversas multimodais no OCS
• Integração com a UM do Exchange para serviços de caixa postal

Conteúdo

Chamadas básicas de voz
Usando números de telefone
Chamadas seguras
Atravessando NATs e firewalls
Roteamento de números de telefone
Roteamento de entrada
Relatórios de qualidade e solução de problemas
Unindo todos os elementos
Comportamento multimodal e conversas
Caixa postal
Conclusão

A primeira parte desta série sobre o Microsoft OCS (Office Communication Server) 2007 mostrava como o OCS foi criado com base nos pontos fortes do LCS (Live Communication Server) 2005 para fornecer

às empresas recursos aprimorados de mensagens instantâneas e presença, além de funções avançadas de mídia e telefonia (consulte a edição de fevereiro de 2008 da TechNet Magazine em technet.microsoft.com/magazine/cc194409). Este artigo dá continuidade à proposta, aprofundando-se nos aspectos de VoIP. Explicarei como as chamadas de voz são simples no sistema do OCS e abordarei a tecnologia camada por camada, acrescentando cada componente, junto com a funcionalidade correspondente.

Como foi mencionado no artigo anterior, o OCS pode ser configurado para fornecer telefonia aos usuários de várias formas diferentes:

Enterprise Voice. É a solução completa de comunicação unificada, que utiliza o OCS em conjunto com o Servidor de Mediação Microsoft®, sem a necessidade de um PBX. A UM (Unificação de Mensagens) do Exchange fornece os recursos de caixa postal do sistema. Vou me referir aos usuários deste serviço como "usuários UC" no restante do artigo. Também usarei o termo "ponto de extremidade UC" em referência a um cliente com essa configuração.

Enterprise Voice com integração ao PBX. Essa configuração permite que os usuários obtenham as vantagens da comunicação unificada e, ao mesmo tempo, mantenham os telefones PBX existentes em suas estações de trabalho. O OCS e o PBX podem ser configurados em paralelo, de forma que as chamadas recebidas gerem toques no Office Communicator e nos pontos de extremidade PBX ao mesmo tempo. O PBX continua a controlar o roteamento de chamadas e a fornecer os serviços de caixa postal.

Controle de chamada remota. Esse recurso usa o PBX como telefone principal, permitindo que seja controlado pelo cliente do Office Communicator.

Chamadas básicas de voz

Concentrarei minhas explicações no funcionamento do sistema para os usuários do Enterprise Voice. As chamadas simples de voz são configuradas no sistema do OCS usando o mecanismo SIP INVITE, conforme descrito na RFC 3261. O servidor do OCS desempenha a função de um proxy semelhante a um postmaster, que retransmite mensagens entre clientes (ou pontos de extremidade). Novos SIP INVITEs são originados pelos clientes sempre que uma sessão em tempo real, como uma chamada ou sessão de mensagens instantâneas, é criada. Se o INVITE é reconhecido com uma resposta (ou seja, o ponto de extremidade remoto envia uma resposta 200 OK), a chamada é estabelecida (veja a Figura 1).

Figura 1. Formato INVITE e 200 OK

INVITE sip:bob@example.com SIP/2.0
To: <sip:bob@example.com>
From: <sip:alice@example.com>;tag=5c5ffe5428;epid=d793aff63a
Call-ID: 3522acd5acd349b4855871e3100a5f4f
CSeq: 2 INVITE
Contact: sip:alice@xyz.example.com
Content-Type: application/sdp
Content-Length: 156

**Note: Alice Audio SDP payload not shown**

SIP/2.0 200 OK
To: <sip:bob@example.com>;tag=f5c728454a;epid=e73443245
From: <sip:alice@example.com>;tag=5c5ffe5428;epid=d793aff63a
Call-ID: 3522acd5acd349b4855871e3100a5f4f
CSeq: 2 INVITE
Contact: sip:bob@xyz.example.com
Content-Type: application/sdp
Content-Length: 160

**Note: Bob Audio SDP payload not shown**

Na Figura 2, Alice liga para Bob, escolhendo Chamada do Communicator no OC (Office Communicator) 2007, e o OC 2007 origina um INVITE para o URI (Uniform Resource Identifier) SIP de Bob (sip:bob@example.com). O INVITE transporta o descritor de chamada de áudio (denominado SDP, Session Description Protocol) dos pontos de extremidade de mídia onde Alice pode receber áudio. O OCS faz a bifurcação do INVITE para os pontos de extremidade SIP registrados de Bob (por exemplo, o Communicator Phone Edition e o Communicator desktop). O INVITE contém um cabeçalho From sip:alice@example.com, usado pelos pontos de extremidade clientes de Bob em uma RNL (pesquisa de nome inversa) para localizar o nome (Alice) a ser exibido na notificação de chamada recebida.

Figura 2. Roteamento de uma chamada para vários pontos de extremidade (clique na imagem para exibi-la em tamanho maior)

O GRUU (Globally Routable User Agent URI) de cada ponto de extremidade é exibido. O GRUU identifica de forma exclusiva um ponto de extremidade SIP e é obtido durante o processo de registro, emitido pelo servidor do OCS. O endereço GRUU ajuda a rotear mensagens SIP. Assim, depois que a chamada é atendida por um ponto de extremidade, o sinal SIP subseqüente para outras operações realizadas durante a chamada pode ser transportado entre os pontos de extremidade diretamente, com o uso do endereço GRUU.

A Figura 3 continua o processo, sendo que Bob atende no Communicator desktop. O OC de Bob envia uma mensagem 200 OK informando onde ele pode receber áudio. Assim que o proxy do OCS detecta o atendimento em um ponto de extremidade, cancela a chamada para os outros pontos de extremidade do Communicator Phone Edition. Quando a resposta 200 OK alcança o ponto de extremidade do Communicator de Alice, os dois pontos de extremidade do Communicator têm informações suficientes (portas IP, parâmetros de criptografia, e assim por diante) para iniciar a mídia.

Figura 3. Atendimento em um ponto de extremidade (clique na imagem para exibi-la em tamanho maior)

Usando números de telefone

Até agora, vimos o usuário clicar em Chamada do Communicator para criar o convite. O processo é um pouco diferente quando o usuário seleciona ou digita um número de telefone:

• Primeiro, o cliente normaliza o número de telefone e o representa como um URI TEL, que descreve recursos identificados por números de telefone, conforme indicado na RFC 3966.
• Como o servidor do OCS somente reconhece URIs SIP, os clientes convertem o URI TEL em um URI SIP correspondente, adicionando o sufixo do domínio e uma marca user=phone.
• Se o número corresponder a um usuário interno, o OCS roteará o convite diretamente. Se o número for externo, o convite será roteado para o gateway SIP-PSTN mais próximo.

Algumas chamadas para um número PSTN (Rede Telefônica Pública Comutada) exigem que o caminho de mídia seja configurado antes do atendimento da chamada, de forma que comunicados remotos possam ser reproduzidos ou dígitos adicionais coletados para completar a chamada. Em cenários assim, o gateway PSTN envia um indicador de Progresso da Sessão 183 com um SDP de áudio. O Communicator usa essa informação para configurar um caminho de mídia bidirecional com um ponto de extremidade de destino, antes que a chamada seja atendida pelo usuário remoto.

Quando o caminho de mídia preliminar está configurado, o Communicator habilita o teclado DTMF (Dual-Tone Multi-Frequency), ou seja, os toques de sinalização de discagem do telefone, para que o usuário possa inserir os dígitos adicionais requeridos pelo sistema remoto. Os dígitos DTMF inseridos são enviados pelo caminho de mídia como pacotes RFC 2833. O gateway PSTN se encarrega de gerar o sinais de toques DTMF adequados do lado do PSTN.

Observe que, se Bob tiver habilitado o Toque Simultâneo em seu celular, o proxy do OCS deverá rotear a chamada para o gateway e fazer com que os outros pontos de extremidade do Communicator de Bob toquem ao mesmo tempo. Em cenários assim, o proxy do OCS indica que a bifurcação está ativa na resposta de Progresso da Sessão 183. Isso faz com que o Communicator estabeleça um canal de mídia de somente recebimento com o gateway PSTN.

Chamadas seguras

Um dos principais recursos das chamadas de voz configuradas pelo OC é a criptografia de mídia por padrão, usando o protocolo SRTP, conforme definido na RFC 3711. O protocolo SRTP fornece ao tráfego RTP confidencialidade, autenticação de mensagens e proteção contra repetição. Durante a configuração da chamada, os clientes negociam os recursos de segurança e trocam chaves criptográficas, como parte do mecanismo INVITE.

A configuração padrão de criptografia para o OC é "opcional", permitindo que dois pontos de extremidade do OC configurem um canal de mídia criptografado. Essa configuração pode ser ajustada pelo administrador, de forma a adaptar-se às necessidades de conformidade da organização. Pode, por exemplo, tornar-se mais rígida para forçar a criptografia em todas as chamadas, ou então ser totalmente desativada.

Atravessando NATs e firewalls

Os clientes no sistema do OCS usam a tecnologia ICE (Estabelecimento de Conectividade Interativa) para fornecer conectividade de mídia aos usuários protegidos por dispositivos de NAT (conversão de endereço de rede) e firewalls, sem exigir alterações nos componentes de NAT existentes. A tecnologia ICE está sendo padronizada pela IETF (Internet Engineering Task Force). Cada cliente tem conhecimento do Servidor de Borda de A/V (áudio/vídeo) que atende a ele, por meio de um mecanismo de provisionamento inband, e mantém um link autenticado para o Servidor de Borda de A/V durante o logon.

Antes de fazer uma chamada, o cliente aloca recursos nos possíveis locais de conectividade (endereços e portas, também conhecidos como candidatos) no Servidor de Borda A/V (para a retransmissão de mídia), no NAT ou no cliente host propriamente dito. Quando o SIP INVITE é enviado, transporta as informações de conectividade como parte do INVITE. A resposta 200 OK transporta informações semelhantes sobre o ponto candidato. Quando cada ponto de extremidade já tem uma lista de pontos candidatos, um mecanismo elaborado de classificação e verificação seleciona o caminho ideal entre os dois pontos para garantir o sucesso da mídia.

Roteamento de números de telefone

O roteamento de números de telefone introduz uma certa complexidade no mecanismo básico de chamada, devido aos seguintes fatores:

• As organizações podem ter diferentes planos de discagem implantados internamente para chamadas de curta distância.
• Talvez os números estejam armazenados em formatos não padronizados (por exemplo, é possível que cadeias de caracteres de sete dígitos tenham sido salvas pelos usuários no Microsoft Office Outlook®).
• Pode ser que haja políticas diferentes mapeadas para números de saída diferentes. Por exemplo, a discagem internacional pode estar bloqueada para determinados usuários.

O sistema do OCS exige que os números de telefone estejam no formato RFC 3966 TEL URI para que possam ser roteados corretamente. Os números que não estiverem nesse formato serão convertidos antes que o cliente emita um INVITE. O diagrama na Figura 4 mostra como isso ocorre no sistema do OCS.

Figura 4. Roteando números de telefone (clique na imagem para exibi-la em tamanho maior)

Os números disponíveis para o cliente podem ter várias origens. Os números pré-normalizados vêm do ABS (Serviço de Catálogo de Endereços), que pode ter regras de normalização definidas pelo administrador para a conversão de números em um formato E.164 normalizado. Quando um cliente emite um SIP INVITE para o número normalizado, o OCS aplica um processo de conversão que mapeia o número para qualquer usuário interno.

• A Etapa 1 mostra que os números inseridos no sistema são exclusivos (normalizados, de acordo com o plano de numeração E.164) ou têm um contexto telefônico que identifica sua localização. Esses números são enviados para o servidor como parte do SIP INVITE. O OCS roteia o INVITE para um processo de conversão.
• O processo de conversão (Etapa 2) tenta mapear o número de telefone para um ponto de extremidade UC usando a RNL do lado do servidor. A conversão pode identificar uma rota para o número levando a um roteamento de saída ou a um usuário UC, ou então apresentar falha na chamada, com um código 4xx, se o número não puder ser convertido corretamente.
• Se o número for convertido em um número não-UC ou externo, será enviado para o componente de roteamento de saída, que redirecionará o INVITE para o gateway SIP-PSTN adequado para processamento adicional, depois de aplicar ao número as políticas relacionadas ao chamador (Etapa 3A). O roteamento de saída se encarrega de balancear a carga da chamada entre os gateways ou fazer failover para gateways alternativos, se necessário. O processo de roteamento de saída pode falhar ou recusar a chamada e retornar um código de resposta SIP 403, se o acesso a determinado número for proibido. Observe que o roteamento de saída se aplica apenas quando o chamador é um usuário UC. Quando não é esse o caso, o OCS tenta usar as rotas estáticas para gateways configurados para aquele URI.
• Se o número for convertido em um número de usuário UC, o INVITE será roteado para o URI SIP daquele usuário (Etapa 3B). O roteamento de entrada é uma função do OCS que se aplica somente a usuários UC e a todas as chamadas direcionadas ao URI SIP. Como você verá, o roteamento de entrada aplica regras para tempo limite de toques, encaminhamento de chamadas e encaminhamento de caixa postal para o usuário UC.

Observe que o número de resultados do processo de normalização pode variar, dependendo da localização do cliente. Os administradores podem configurar perfis de localização e atribuir regras de conversão numérica específicas para uma determinada localização (por exemplo, de que forma a discagem de quatro dígitos funcionará naquela localização). Um perfil de localização é atribuído a cada usuário UC, e todos os clientes no sistema baixam as regras específicas a seus perfis de localização usando o provisionamento inband. Em seguida, explicarei em mais detalhes o roteamento de entrada.

Roteamento de entrada

As regras de roteamento de entrada especificam como as chamadas para um usuário devem ser roteadas, na presença ou na ausência de clientes registrados no sistema. O componente de roteamento de entrada também se encarrega de aplicar regras baseadas em presença à chamada recebida; pode, por exemplo, enviar as chamadas recebidas para a caixa postal, se o usuário tiver definido o estado de presença como Não Incomodar. O roteamento de entrada tem conhecimento dos níveis dos contêineres de presença e recusa automaticamente as chamadas de usuários em contêineres bloqueados. A Figura 5 mostra um resumo das opções com suporte do componente de roteamento de entrada do OCS.

Figura 5. Recursos do roteamento de entrada

As regras de roteamento de entrada são carregadas no servidor como um esquema XML, como parte das informações de autoprovisionamento de um usuário. A Figura 6 mostra como funciona o roteamento de entrada. Uma chamada recebida para um usuário no sistema do OCS aciona por padrão o toque do usuário (mostrado como "Eu"). Se a chamada não for atendida no período de duração do toque, a chamada não atendida será enviada para a caixa postal por padrão. O usuário poderá optar por modificar a configuração padrão, escolhendo o encaminhamento imediato para um número, para outra pessoa ou diretamente para a caixa postal.

Figura 6. Roteando chamadas (durante o horário de trabalho) (clique na imagem para exibi-la em tamanho maior)

Todas as chamadas encaminhadas imediatamente para outra pessoa ou número farão com que as regras de roteamento de entrada para aquela pessoa ou número sejam aplicadas. O usuário também pode definir o encaminhamento das chamadas não atendidas para outro número ou pessoa.

Se o usuário marcar a opção Aplicar somente durante meu horário de trabalho do Outlook, nas regras de encaminhamento, as regras mostradas na Figura 6 serão aplicadas durante o horário de trabalho, e o comportamento padrão de toque dos pontos de extremidade registrados será aplicado fora desse horário. Para permitir esse comportamento, a organização precisa ter implantados os clientes do Microsoft Exchange Server 2007 e do Outlook 2007, pois o Communicator usa as informações de horário de trabalho do Web service de disponibilidade do Exchange 2007 e utiliza o suporte à detecção automática do Outlook 2007 para obter a localização do servidor.

Relatórios de qualidade e solução de problemas

Os clientes no sistema do OCS 2007 usam o RTAudio, um codec de áudio de última geração, capaz de tolerar condições imperfeitas da rede como tremulação, perda de pacotes, e assim por diante. Mesmo assim, o monitoramento é fundamental para que os administradores consigam localizar e corrigir possíveis pontos problemáticos. Ao final de todas as chamadas, os clientes no sistema do OCS 2007 enviam para um servidor central de QoE (Qualidade da Experiência) relatórios sobre a qualidade de cada chamada e fornecem estatísticas detalhadas, incluindo largura de banda, perda, tremulação, pontuação média de opiniões (uma medida da percepção do usuário), dispositivos utilizados e muito mais. Isso é feito com o envio da carga em uma solicitação SIP SERVICE para o servidor de QoE, que tem seu endereço programado com o uso do mecanismo de provisionamento inband.

Todos os pontos de extremidade clientes reportam a qualidade das chamadas para o servidor de QoE de forma independente. Caso uma chamada falhe devido a um erro na sinalização, os clientes enviarão o mesmo relatório também para o OCS, que conta com um repositório de todos os erros criados pelos clientes.

Unindo todos os elementos

Agora que já descrevemos vários aspectos da configuração de uma chamada, inclusive a inserção de números, o roteamento de entrada e de saída e as verificações de conectividade, vejamos o processo como um todo. A Figura 7 resume o que acontece a partir do momento em que um usuário faz uma chamada. Os clientes no sistema do OCS desempenham um papel fundamental na configuração de uma chamada, gerenciando todo o processo. O OCS está envolvido no roteamento inicial da chamada, e os servidores de borda ajudam os clientes a localizar a rota de mídia ideal. Vejamos agora o que acontece em seguida — a conversa.

Figura 7. Fluxo completo da chamada (clique na imagem para exibi-la em tamanho maior)

Comportamento multimodal e conversas

O conceito de conversas é essencial ao sistema do OCS. Uma conversa é uma sessão multimodal entre duas ou mais pessoas, podendo incluir voz, vídeo e MI ao mesmo tempo, além de artefatos como transferências de arquivos durante a sessão, emails do Outlook ou notas armazenadas no Microsoft Office OneNote®.

Vários aspectos das conversas podem exercer impacto sobre o design dos sistemas clientes do OCS:

• Todas as modalidades envolvidas em uma conversa usam a mesma janela. Se uma mensagem instantânea é adicionada a uma conversa de áudio, ela é associada à mesma janela.
• As conversas podem ocorrer entre dispositivos. Os usuários podem optar por ter áudio no Communicator Phone Edition, mas ter MIs no Communicator desktop.
• Todos os modos são escalonáveis para uma conferência conjunta: se isso ocorrer, todas as modalidades de uma conversa deverão ser escalonadas em conjunto, independentemente da modalidade de dispositivo ativada no momento. Por exemplo, se um modo de áudio estiver disponível no Communicator Phone Edition e um modo de MI para a mesma conversa estiver disponível no Communicator desktop, o escalonamento para a conferência garantirá que o áudio e a MI tenham o mesmo conjunto de participantes da conversa.
• As conversas, e não as sessões individuais, são registradas. Os registros de chamadas contêm informações completas sobre a conversa, inclusive detalhes sobre notas criadas durante a conversa, trocas de mensagens instantâneas, a duração do áudio, e assim por diante. Isso fornece aos usuários uma visão consolidada bastante útil da conversa como um todo, quando abrem o registro de chamadas do Outlook.
• É possível continuar conversas a partir dos registros de conversas.. Os clientes do OCS vinculam conversas usando um ID de conversa — um número que identifica com exclusividade a conversa entre dispositivos e aplicativos. Existe um mecanismo elaborado para computar deltas de conversas quando novas conversas são iniciadas a partir de um registro de histórico de uma conversa antiga. O mesmo ID de conversa é armazenado como ID do email no Outlook.

O ID da conversa viaja como parte do SIP INVITE, como uma propriedade personalizada, Ms-Conversation-Id. A Figura 8 mostra uma transação assim, na qual a voz é adicionada primeiro, e em seguida uma MI. Ao final da conversa multimodal, o registro de histórico armazenado no Outlook tem o mesmo ID da conversa.

Figura 8. Conversas multimodais e ID da conversa (clique na imagem para exibi-la em tamanho maior)

A UM do Exchange é o sistema de caixa postal do OCS 2007. O OCS somente faz o roteamento de chamadas para usuários com o UC habilitado para a UM do Exchange. O OCS fornece vários recursos de integração com a UM do Exchange:

• A opção Chamar Caixa Postal, na interface do usuário de telefone do Communicator (veja a Figura 9), permite que o usuário gerencie a caixa postal da UM, altere as saudações, e assim por diante, sem precisar digitar o PIN, pois já está autenticado.
• O indicador de chamada em espera, na interface do usuário do Communicator (veja a Figura 10), permite que o usuário abra a pasta da caixa postal no Outlook; já o indicador do Communicator Phone Edition permite que o usuário reproduza as mensagens de voz diretamente no telefone.
• As chamadas podem ser encaminhadas para a caixa postal a partir da interface do usuário do Communicator.
• As chamadas recusadas são roteadas automaticamente para a caixa postal.
• A opção Tocar no Telefone, no item de caixa postal do Outlook, aciona diretamente o toque dos clientes do Office Communicator.

Figura 9. Opção Chamar Caixa Postal no Communicator

Figura 10. Indicador de mensagem em espera no Communicator

O mecanismo pelo qual o OC recebe a notificação da caixa postal é diferente daquele do Communicator Phone Edition. O OC se registra para receber notificações de novos emails na pasta de pesquisa da caixa postal, no Outlook, e informa sobre as novas mensagens nessa pasta. O Communicator também usa Conversas Perdidas e Registros de Chamadas.

Conclusão

Mostrei aqui como funcionam as chamadas de voz no OCS 2007, um sistema baseado no protocolo SIP que utiliza várias RFCs. Os pontos de extremidade clientes desempenham um papel central no gerenciamento de chamadas no OCS. Todas as chamadas de voz são criptografadas com segurança por padrão. O OCS conta com componentes flexíveis, que permitem a manipulação de números e o gerenciamento de seu fluxo no sistema.

As conversas são um conceito central no OCS, envolvendo voz, MI e vídeo. O OCS se integra à UM do Exchange e permite que os pontos de extremidade do Communicator recebam notificações da caixa postal, além de acessar a caixa postal via Outlook ou diretamente no servidor.

Rajesh Ramanathan trabalha há 14 anos na área de comunicação. Projetou protocolos de voz, experiências do usuário, recursos de voz e de conferência para o Office Communicator 2007. Ele trabalha atualmente como gerente-chefe de programa na equipe do Office Communicator, na Microsoft. Entre em contato com Rajesh pelo email rajeshra@microsoft.com.

© 2008 Microsoft Corporation e CMP Media, LLC. Todos os direitos reservados. É proibida a reprodução total ou parcial sem autorização.