Passagem do tráfego da webconferência

Tópico modificado em: 2009-03-10

Para habilitar a Webconferência com usuários externos, é preciso que um serviço de Borda A/V manipule a sinalização SIP necessária para configurar e derrubar uma conferência. Também é necessário que um serviço de Borda de Webconferência atue como proxy da transferência do conteúdo da reunião, como slides, quadro de comunicações e perguntas e respostas entre usuários internos e externos. Além disso, um proxy reverso http é necessário para habilitar o download e a criptografia do slide. A sequência de chamadas, ilustrada na Figura 1, é a seguinte:

Figura 1. Sequência de chamadas para habilitar a Webconferência com usuários externos

1. Um usuário externo recebe um email convidando-o para ingressar em uma Webconferência. O email contém uma chave de conferência e um URI que leva à conferência. A chave e o URI são exclusivos de cada reunião.
   A URL da reunião não é um URI baseado em HTTP. Portanto, um usuário final não pode ingressar em uma conferência copiando o URI e colando-o em um navegador. O formato do URI é meet:sip:Organizer@domain;ms-app=conf;ms-conf-id=1234. Quando o usuário convidado clica no URI da reunião, o console do Live Meeting é iniciado e tenta se conectar ao servidor de acordo com a configuração do console (manual ou automática).
2. O usuário externo inicia o procedimento de ingresso clicando no URI da reunião no email. O console do Live Meeting é iniciado e envia um SIP INVITE contendo as credenciais do usuário. Um usuário federado ou remoto ingressa em uma conferência usando as credenciais da sua empresa. No caso de um usuário federado, o SIP INVITE primeiro é enviado ao servidor primário, que autentica o usuário e encaminha a solicitação INVITE à empresa que está hospedando a conferência. É necessário que um usuário anônimo passe na autenticação digest. Para obter informações detalhadas sobre a autenticação digest, consulte Autenticação no Office Communications Server 2007 R2.
3. Um Diretor ou Servidor Front-End autentica o usuário remoto ou anônimo e notifica o cliente. (Conforme mencionado na etapa 2, os usuários federados que ingressam em uma conferência são autenticados pela empresa.)
4. O cliente envia uma solicitação INFO para adicionar o usuário à Webconferência.
5. A Webconferência envia uma resposta referente à adição de usuário que contém o token a ser apresentado ao serviço de Borda de Webconferência, entre outras informações.
   Observe que todo o tráfego SIP anterior passou pelo serviço de Borda de Acesso.
6. O cliente se conecta ao Servidor de Webconferência, que valida o token e envia a solicitação (que contém outro token de autorização) por proxy ao Servidor de Webconferência. O Servidor de Webconferência valida o token de autorização, que é originalmente emitido pelo canal SIP, para assegurar que um usuário válido está ingressando na conferência.
7. O Servidor de Webconferência envia ao usuário externo a URL do slide da reunião, juntamente com uma chave para a descriptografia do slide.
   A URL do conteúdo do slide é gerada aleatoriamente e não pode ser vista pelo usuário. Ela não é incluída no email inicial e não pode ser descoberta no cliente. A navegação pelos diretórios é proibida no Servidor de Webcomponents também. A chave para os slides é separada da chave da conferência e destina-se exclusivamente a esse recurso de conferência e a essa reunião. O usuário recebe essa chave somente após ser autenticado no canal SIP.
8. O usuário externo baixa os slides e os criptografa usando a chave de slide exclusiva.
   Os slides e outros recursos de conferência são criptografados usando o AES de 128 bits. Com a criptografia AES, a única forma de descriptografar o conteúdo é pela força bruta, e o número de chaves possíveis é tão grande que é eletronicamente inviável preparar um ataque de força bruta bem-sucedido no curto período de tempo disponível. Observe que o conteúdo da reunião e a chave ficam armazenados apenas enquanto dura o processo e não são fisicamente armazenados no disco rígido do usuário final.