O Office Communications Server
Powers de controle de chamada remota como OCS 2007 R2
Rajesh Ramanathan
Visão geral:
- O que o controle de chamada remota pode fazer
- Como funciona o RCC
- Cenários de OCS comuns para implementar RCC
Conteúdo
O padrão CSTA
Carregando o canal RCC
O fluxo de MakeCall básica
O fluxo de chamada de resposta básico
RCC e integração de presença
RCC e conferência
RCC no Enterprise Voice com PBX
As limitações do RCC
Este artigo é uma continuação da série abrangendo como o Office Communications Server (OCS) 2007 fornece comunicação unificada, de voz sobre IP (VoIP) e conferência recursos. Aqui eu abordarei como o Office Communications Server fornece o recurso RCC (controle de chamada remota) com PBXs herdados e como vários cenários relacionados chamada podem ter suporte usando RCC. Eu também tocar rapidamente sobre a configuração de bifurcação dupla e como RCC pode ser usado em que configuração para fornecem uma opção flexível para que o usuário faça e receba chamadas de Office Communicator ou o telefone de PBX.
Em meu artigo" Como presença Powers OCS 2007" Forneceu uma visão geral sobre a solução de 2007 de OCS, explicando como diversas peças se encaixam. Eu também explicou como o presença desempenha um papel de chave na comunicação unificada e como ele é usado para o roteamento com eficiência chamadas de voz. Em" Como voz Powers OCS 2007" Discuti como OCS oferece recursos de VoIP. Eu também conheceu breve várias opções de configuração para um usuário, enfocando o Enterprise Voice configuração.
Outra configuração que rapidamente alterado após foi RCC, que acompanha o Live Communication Server 2005 e permite que o Office Communicator 2005 controlar as chamadas do telefone de PBX. Com o 2007 de OCS, esse recurso está ainda disponível como uma configuração alternativa quando há uma implantação de PBX existente. Há também uma opção para habilitar RCC com o Enterprise Voice, onde os usuários podem usar o PBX de telefone, bem como o Office Communicator para gerenciar suas chamadas.
RCC é a capacidade de enviar ou receber chamadas em um dispositivo diferente de seu computador. OCS, isso significa o seguinte:
- Quando os toques de telefone de PBX, um alerta aparece no Communicator que permite que você responder à chamada.
- Quando o número de telefone de alguém é clicado no Communicator, o telefone de PBX vai fora do gancho no modo de viva voz e disca o número.
- Encaminhamento de chamada pode ser definido no telefone PBX.
- Chamadas de entrada para o número podem ser deflected a outros números de telefone.
- Eventos de controle Mid-Call, como uma etapa transferência e transferência Consultative, podem ser executados em uma chamada no telefone PBX. Sinais DTMF podem ser enviados pelo telefone PBX usando a interface do usuário no Communicator.
Figura 1 configuração RCC A
Uma das grandes diferenças entre a configuração RCC e o Enterprise Voice é que na configuração RCC, os clientes do Office Communicator apenas tem controles configurado com o PBX de sinalização — não há nenhuma chamada VoIP enviada para os clientes do Office Communicator. Em outras palavras, o Office Communicator não está sendo usado como um softphone nessas configurações.
Na configuração mais simples, RCC pode ser implantado, configure um gateway SIP/CSTA entre o PBX e OCS. O gateway SIP/CSTA fornece uma interface de protocolo SIP (Session Initiation Protocol) para o lado de OCS e usa CSTA (Computer-Supported Telecommunications aplicativo) sinalizando mensagens empacotadas dentro de mensagens do SIP para se comunicar com clientes do Office Communicator.
Para o lado de PBX, o gateway SIP/CSTA usa PBX de proprietários específicos do fornecedor interfaces de sinalização. Como você pode ver na Figura 1 , implantações de RCC aproveitar a conectividade de rede (PSTN) telefônica pública comutada fornecida pelo PBX para fazer chamadas check-out para o mundo PSTN. Essas implantações também utilizam o sistema de correio de voz que o PBX está associado.
a Figura 2 mostra o diagrama lógico de como chamadas de voz se encaixam em um sistema RCC. Como você pode ver, o cliente do Office Communicator cria uma sessão de sinalização onde as mensagens de controle de chamada que se baseiam o protocolo CSTA fluir entre o cliente do Office Communicator e o gateway SIP/CSTA. A chamada real propriamente dito é entre o telefone de suporte técnico PBX e a empresa remota, que pode ser outro telefone de suporte técnico de PBX ou um ponto de extremidade PSTN — ou até mesmo outro usuário de Enterprise Voice-habilitado em um telefone de OCS.
A Figura 2 chama em uma configuração RCC
O padrão CSTA
Implementação de RCC no Office Communicator baseia-se no ECMA (European Computer Manufacturers associação) técnico relatório-87 (TR-87). Isso é uma implementação de SIP do modelo CSTA também proposto pelo ECMA. Outro padrão, 323 ECMA, fornece o esquema detalhado das mensagens XML que são enviadas no canal SIP para uma implementação do CSTA. O Office Communicator segue um subconjunto das capacidades e os métodos em TR-87. A documentação mais detalhada sobre o suporte para o padrão CSTA no Communicator está disponível por meio da Conectar-se o Microsoft programa. Observe que em todo este artigo, CSTA se refere ao protocolo genérico que é usado entre clientes Office Communicator e o PBX.
Carregando o canal RCC
No artigo "como presença Powers OCS", eu expliquei como o SIP URI Uniform Resource Identifier () é um importante parte do sistema de OCS e como cada usuário é atribuído um URI SIP, que permite chamadas para serem roteadas para o usuário. Quando os clientes do Office Communicator conversar com um gateway SIP/CSTA, eles precisam identificar qual telefone Office Communicator precisa controle. Este número de telefone é identificado como um URI de linha, que é basicamente um número de telefone em formato 3966 de RFC. Esta propriedade de linha URI é armazenada no Active Directory no registro do usuário e ficará disponível para o Office Communicator como parte do provisionamento inband.
Durante a inicialização, os clientes do Office Communicator também precisar se conectar ao gateway SIP/CSTA (que é abordado conforme definido pelo URI de servidor na configuração de usuário OCS) para configurar um canal de CONVITE persistente. O Communicator sabe sobre o recurso RCC e o URI de servidor usando o mecanismo de provisionamento inband (também explicado no artigo "como presença Powers OCS").
O sistema RCC segue um modelo de comando/Response. Cada mensagem que Office Communicator envia para o gateway SIP/CSTA contém um comando codificado como uma carga XML (ECMA 323). Cada resposta ou a notificação de que o gateway SIP/CSTA também contém uma carga XML (ECMA 323). O convidar SIP primeiro cria a sessão e contém uma mensagem de CSTA RequestSystemStatus. O gateway SIP/CSTA aceita a solicitação e responde com um RequestSystemStatusResponse na 200 OK (veja a Figura 3 ).
A Figura 3 Convidar modelo com o gateway SIP/CSTA
Observe que não há nenhum BYE correspondente o CONVITE. Isso ocorre porque o CONVITE é configurado como uma sessão de longa duração em quais comandos subseqüentes do Office Communicator podem ser enviados ou notificações recebidas do gateway SIP/CSTA.
Quando a seqüência de convite/200 OK for concluída, o Office Communicator consulta os recursos do gateway SIP/CSTA (que se relaciona com recursos de PBX) para descobrir o conjunto de recursos com suporte. E, em seguida, ele inicia monitoramento na linha telefônica.
Consultar os recursos de PBX é uma etapa importante na inicialização — dependendo de quais recursos são suportados no gateway de PBX/CSTA, vários elementos de interface do usuário no Office Communicator podem estar desativados ou não estar disponíveis em todos os. Por exemplo, se o recurso de uma transferência de etapa não tem suporte no gateway SIP/CSTA, Office Communicator não mostrará o botão de transferência para uma chamada nos controles de chamada.
Assim, uma configuração RCC requer dois parâmetros que são consumidos pelos clientes Office Communicator. Primeiro é URI do servidor, que é um URI SIP que contém o endereço do gateway SIP/CSTA e permite que os clientes Office Communicator se conectar ao servidor, emitindo um SIP convidar para o URI. (Esse URI é geralmente do gateway@contoso.com formulário.)
Segundo é o URI de linha, que é um URI TEL que identifica o número de telefone no sistema PBX. Esse URI segue o formato de RFC 3966 (por exemplo, TEL: +14255551212 ou TEL:4255551212; ext = 1212).
Quando a inicialização inicial for concluída, o Office Communicator recebe eventos o PBX quando ocorre uma alteração de status na linha telefônica monitorados conforme especificado por um número de telefone. Quando Office Communicator precisa se originam ou responder a uma chamada, ele envia uma mensagem INFO que contém mensagens CSTA XML para o gateway SIP/CSTA. Eventos recebidos do gateway SIP/CSTA também contêm mensagens XML do CSTA incorporadas mensagens SIP INFO (consulte a Figura 4 para obter um exemplo).
Figura 4 mensagem INFO e 200 resposta OK
INFO sip:gateway@contoso.com SIP/2.0
From: <sip:alice@ocs.contoso.com>;tag=31424bf782;epid=77e47b4782
To: <sip:gateway@ocs.contoso.com>;tag=1fbe74b0
Call-ID: 52c4a528322d4457a486283ccf78b696
User-Agent: UCCP/2.0.6362.0 OC/2.0.6362.0 (Microsoft Office Communicator)
Content-Disposition: signal;handling=required
Content-Type: application/csta+xml
Content-Length: 277
<?xml version="1.0"?>
<MakeCall xmlns="http://www.ecma-international.org/standards/ecma-323/csta/ed3">
<callingDevice>tel:+14255551212;ext=1212</callingDevice>
<calledDirectoryNumber>tel:+14258828080;ext=5555</calledDirectoryNumber>
<autoOriginate>doNotPrompt</autoOriginate>
</MakeCall>
SIP/2.0 200 OK
From: <sip:alice@ocs.contoso.com>;tag=31424bf782;epid=77e47b4782
To: <sip:gateway@ocs.contoso.com>;tag=1fbe74b0
Call-ID: 52c4a528322d4457a486283ccf78b696
Content-Disposition: signal;handling=required
Supported: 100rel,replaces,timer
User-Agent: Example Gateway Release 1.0 version 4.2.3
Contact: <sip:gateway@ocs.contoso.com>
Content-Type: application/csta+xml
Content-Length: 247
<?xml version="1.0" encoding="UTF-8"?>
<MakeCallResponse xmlns="http://www.ecma-international.org/standards/ecma-323/csta/ed3">
<callingDevice>
<callID>17772</callID>
<deviceID> tel:+14255551212;ext=1212</deviceID>
</callingDevice>
</MakeCallResponse>
Observe que OCS serve como um proxy SIP neste cenário. Quaisquer mensagens sinalização entre clientes Office Communicator e o gateway SIP/CSTA são passadas forma transparente pelo servidor OCS. Para garantir que o gateway SIP/CSTA está sendo executado e o link de sinalização está disponível, Office Communicator atualiza a caixa de diálogo do CONVITE cada 10 minutos enviando um Re-INVITE com o comando RequestSystemStatus.
O fluxo de MakeCall básica
A seqüência de fazer uma chamada é realçada na Figura 5 . O usuário pode fazer uma chamada para um número de digitando-se no número na caixa de busca Office Communicator ou selecionando o número do telefone um contato na lista clique para chamada. Quando o usuário seleciona para chamar um número, o Office Communicator emite um comando MakeCall para o gateway SIP/CSTA que contém o número de telefone que está selecionado para a chamada. A interface RCC só permite aos usuários fazer chamadas para os números de telefone. Quando o usuário seleciona a opção de chamada do Communicator para chamar alguém, o Office Communicator gerado uma chamada VoIP para URI do SIP do usuário remoto.
A Figura 5 fazer uma chamada
A seqüência de mensagem em A Figura 5 mostra como o gateway SIP/CSTA converte um comando MakeCall em mensagens de PBX proprietárias; o telefone de PBX ficar fora do gancho e faz uma chamada para o número de telefone selecionado.
Observe que a interface para o gateway SIP/CSTA fornece mecanismos elaborados para indicar vários estados do telefone. Neste exemplo, você pode ver que há vários eventos recebidos por Office Communicator que indicam a atividade no telefone PBX. Esses comece a OriginatedEvent (indicando que o telefone de PBX é origem uma chamada de saída) para o DeliveredEvent (indicando um estado Ringing). Quando que um DeliveredEvent é recebida, é possível que um caminho de mídia para reprodução de sons ringback já foi estabelecido entre o telefone e o usuário remoto.
Quando a chamada é respondida por fim, o PBX envia os sinais apropriados para o gateway SIP/CSTA e um EstablishedEvent é enviada ao Office Communicator indicando que a chamada tiver sido respondida (consulte A Figura 6 ).
A Figura 6 A chamada tiver sido respondida
O fluxo de chamada de resposta básico
Quando uma chamada para o sistema de PBX, o PBX informa o gateway SIP/CSTA, que por sua vez se origina uma notificação de CSTA DeliveredEvent enviada para o Office Communicator (veja a Figura 7 ). Depois que o Office Communicator recebe a notificação DeliveredEvent, a notificação de chamada de entrada é mostrada ao usuário.
A Figura 7 Atendimento uma chamada
Office Communicator também realiza pesquisa de nome inversa (RNL) contra os contatos de serviço de catálogo de endereços e o Microsoft Office Outlook do usuário para mostrar um nome de exibição para o chamador correspondente. O usuário pode agora responder à chamada de notificação, resultando em um comando de CSTA AnswerCall para o gateway SIP/CSTA. Neste ponto, o gateway SIP/CSTA converte o AnswerCall em uma mensagem de resposta específica de PBX apropriada e o canal de mídia bidirecional é configurado entre o chamador e o telefone de PBX.
RCC e integração de presença
Com a integração de RCC, o status de telefone de um usuário está agora integrado presença. Por exemplo, sempre que o usuário estiver em uma chamada no PBX, Office Communicator será alterar o status do usuário para em uma chamada. Este status podem ser exibido em clientes do Office Communicator de outros usuários. Além disso, os usuários podem publicar seus números de telefone pessoal por meio de presença para outras pessoas podem chamá-los em seus números de base ou móveis por meio do Office Communicator.
Mas observe que, quando a presença do Office Communicator 2007 é definida como Não Incomodar, não incomodar recurso do sistema PBX não é acionado. Um usuário manualmente deve gerenciar o estado de ' Não incomodar ' no sistema PBX.
RCC e conferência
Quando em uma chamada RCC, o Office Communicator 2007 não permite ao usuário adicionar outro usuário para a chamada usando o Office Communicator. No entanto, os usuários podem ainda criar uma conferência no telefone PBX usando o recurso de conferência o telefone de PBX. Quando isso ocorre, o Office Communicator continua a mostrar a chamada como uma chamada de peer-to-peer, em vez de uma chamada de conferência.
Semelhante ao escalonamento para o cenário de três empresas, chamadas de conferência de entrada no telefone PBX aparecem como peer-to-peer chamadas no Office Communicator e pode ser atendida como peer-to-peer chamadas no Office Communicator.
RCC no Enterprise Voice com PBX
RCC pode ser usado no cenário do Enterprise Voice com a integração de PBX (também conhecido como duplo divisão). Em o Enterprise Voice com cenário de integração de PBX, o PBX e OCS bifurcação de sistemas chama para si para permitir ao usuário usar o telefone de PBX ou o Office Communicator softphone para responder chamadas. Esta opção permite que os usuários aproveitar todos os benefícios de Enterprise Voice.
O Enterprise Voice com cenário de integração de PBX com RCC adicionado no fornece uma experiência exclusiva: os usuários sejam capazes de atender uma chamada em Telefone ou em Office Communicator de uma notificação de chamada de entrada único no Office Communicator (consulte a A Figura 8 ).
A Figura 8 escolhendo um ponto de extremidade para responder a uma chamada de entrada
Além disso, os usuários com computadores notebook podem usar Office Communicator como um softphone para fazer chamadas quando fora do local corporativa. Usuário tem ainda a capacidade de criar chamadas de conferência a partir de Office Communicator, aproveitando os recursos de conferência fornecidos pelo Office Communication Server A vários pontos de V controle MCUs (unidades /.
As limitações do RCC
RCC oferece uma maneira fácil para alcançar a integração com uma implantação de PBX existente. No entanto, os recursos de um usuário habilitado RCC são limitados pelo que pode fazer o telefone de PBX com fio. Por exemplo, um usuário o Enterprise Voice pode aproveitar o suporte de OCS nativo para recursos de voz externo e fazer e receber chamadas de VoIP interno e fora da organização.
O Enterprise Voice cenário também habilita vários recursos de presença que OCS oferece (como presença níveis de acesso à equipe, permitindo que as interrupções urgentes durante ' Não incomodar '). Um usuário RCC-somente não terá acesso a esses recursos. Além disso, outros recursos, tais como escalar duas empresas conferências para uma conferência com várias partes, há suporte para também apenas com o Enterprise Voice usuários.
Em um sistema RCC, o PBX é o mestre das regras de tratamento de chamada. Portanto, nenhuma configuração ou regras que desviar chamadas automaticamente ou enviá-los para uma linha compartilhada, na verdade, são controladas no PBX. Novos recursos disponíveis para um usuário, como tocar simultaneamente e o recurso de delegação introduzido com o OCS 2007 R2, Enterprise Voice não estão disponíveis para um usuário RCC-somente.
Configurações de RCC são projetadas para ser limitada a um PBX implantado em um único local. Esse é o motivo pelo qual várias regras de discagem específicas de localização não há suporte para RCC topologia. Por outro lado, uma configuração do Enterprise Voice permite vários locais seja especificado e os usuários em locais específicos receberão números regras da normalização que são específicas para seus locais.
No entanto, RCC oferece uma maneira útil para fornecer recursos de telefonia OCS em determinados cenários. Enquanto ele oferece um conjunto de recursos limitados em comparação com o Enterprise Voice, quando usado em uma configuração do Enterprise Voice (para divisão dupla), RCC pode dar aos usuários um conjunto sofisticado de recursos de OCS junto com a flexibilidade para fazer e receber chamadas de um telefone de suporte técnico ou Office Communicator.
Rajesh Ramanathan funciona como gerente de programas de cliente potencial com a equipe do Office Communicator. Ele trabalhou em comunicações há 15 anos e foi projetado protocolos de voz, experiências de usuário e voz e conferência experiências para o Office Communicator 2007 R2. Ele pode ser contatado em rajeshra@Microsoft.com.