Architecture for Voice, Video and Integrated Data

Cisco Unified Communications

Archive for the ‘Telepresence’ Category

Factory Reset em Endpoints de Vídeo

Posted by leonardotns em 27/05/2014

Olá,

Passei por um problema onde recebi um endpoint de video (SX20) com usuário e senha configurado, ninguém sabia me informar o mesmo, tive que realizar um factory reset no endpoint.

Existem 4 metódos:

  1. Via interface WEB mas se não possui o usuário e senha não adianta
  2. Via Touch Phone mas também é necessário o mesmo usuário e senha solicitado via WEB
  3. Via SSH, Telnet ou Serial, também é solicitado usuário e senha, não testei apenas com o cabo serial.
  4. E por ultimo é o reset fisíco usando o botão power da SX20

Esses procedimentos valem para as series C, MX, SX e EX.

Sem esse usuário e senha, não é possível emparelhar nenhum Touch Phone, atualizar o firmware, acesso via web.

Referência:

http://www.cisco.com/c/dam/en/us/td/docs/telepresence/endpoint/codec-c-series/tc6/troubleshooting_guide/tc_troubleshooting_guide_tc60.pdf

 

Posted in Endpoints, Telepresence, Video | Leave a Comment »

Reset de Senha – CTS

Posted by loliveira em 23/12/2013

Procedimento bacana para reset de senha da CTS.

http://www.cisco.com/en/US/docs/telepresence/cts_admin/1_9/admin/guide/ctsadmin_cfg.pdf

Quando executado o procedimento, é exibido um código na tela da CTS. Após inserir este código no prompt, a senha é reiniciada para o valor padrão:
User: admin
Pass: cisco

 

Posted in Telepresence | Leave a Comment »

CTS – Reset de Fábrica

Posted by loliveira em 29/09/2013

Procedimento em inglês para restaurar as configurações de fábrica de um CTS.

https://supportforums.cisco.com/docs/DOC-28241

Posted in Telepresence | Leave a Comment »

VCS – Exemplo de configuração de dial plan para evitar interworking

Posted by Paulo Souza em 26/09/2013

Pessoal,

Na minha experiência com projetos de vídeo envolvendo VCS Control e VCS Expressway, eu tive muitos problemas com conversão de protocolos no VCS, usando o recurso de interworking, como por exemplo em ligações de SIP para H323 e vice versa. Eu já vi alguns cenários em que a criptografia não era negociada direito, o DTMF não chegava do outro lado, ou acontecia algum erro de negociação bizarro e a chamada não funcionava. Isso quase sempre acontecia em ambientes com o VCS Expressway, onde o cliente fazia conferência com tudo o que é tipo de endpoint na internet, até aqueles bem antigos já aposentados que ninguém quer nem de graça. Inclusive, me lembro de ter pego uma situação onde um endpoint antigo da Polycom reiniciava (literalmente!!) sempre que o VCS convertia a chamada de SIP para H323 e o lado SIP era um endpoint interno tentanto negociar criptografia.

Mas claro, estes tipos de problemas não são comuns, existe a possibilidade de eles ocorrerem, principalmente quando há integração com a internet, mas não é algo que recorrentemente apresenta problema.

Bom, criei recentemente um documento mostrando um exemplo de configuração de dial plan do VCS no qual o VCS manipula as chamadas de forma a evitar conversão de protocolos (interworking) sempre que possível. Este documento contém todas as search rules e transforms que devem ser aplicadas nos VCSs para fazer a mágica acontecer. Publiquei o doc no CSC global de telepresença da Cisco, vale a pena conferir:

https://supportforums.cisco.com/docs/DOC-36695

Ate a próxima!

Paulo Souza

Posted in Telepresence | Etiquetado: , , , , | Leave a Comment »

VCS – Como evitar SIP UDP timeout sem desabilitar UDP

Posted by Paulo Souza em 26/09/2013

Pessoal,

Na minha experiência com projetos de telepreseça Cisco, eu já vi muitos cenários onde havia problemas delay em chamadas da rede local para internet usando a solução VCS Control e VCS Expressway da Cisco. Problemas geralmente relacionados a endpoints locais SIP chamando endpoints externos H323 não registrados no VCS Expressway, como endpoints stand alone, por exemplo. Neste cenário, muitas vezes as chamadas demoravam muitos segundos para conectar, a ponto de usuário simplesmente desistir da ligação achando que há algum problema com o sistema.

Estes questões em que leva um tempo muito grande para conectar as chamadas para a internet são normalmente relacionados ao protocol SIP usando transporte UDP. Então  maioria dos usuários desabilitam o protocol SIP UDP no VCS Expressway, o que definitivamente resolve o problema e é inclusive recomendado pela Cisco. Porém, em alguns casos, pode-se ter endpoints na internet antigos que apenas suportam SIP usando transporte UDP, neste caso, se o UDP for desabilitado globalmente nas configurações de SIP, tais endpoints não serão capazes de se comunicar com o seu ambiente usando SIP UDP. Isto não se relaciona a apenas endpoints legados que apenas suportam UDP, isto pode ser também aplicado para endpoints da internet que suportam SIP sobre TCP, UDP e TLS, mas que por algum motivo, apenas UDP foi habilitado.

Para contornar este problema sem desabilitar o SIP UDP globalmente, eu criei um workaround que pode ser aplicado em qualquer ambiente. Vale a pena conferir, segue link do documento que postei na CSC global de telepresence da Cisco:

https://supportforums.cisco.com/docs/DOC-36694

Até a próxima.

Paulo Souza

Posted in Telepresence | Etiquetado: , , | Leave a Comment »

Telepresence Touch 12 – Troubleshooting

Posted by loliveira em 18/09/2013

O processo de boot do Touch é composto por 7 passos, se travou em algum passo, visualize este documento e bom troubleshooting.

http://www.cisco.com/en/US/docs/telepresence/peripherals/cisco_touch/installation/cisco_touch_troubleshooting.html

Dica do Marcos Lopes.

Posted in Telepresence | Leave a Comment »

VCS – Entendendo licenciamento de chamadas

Posted by Paulo Souza em 13/09/2013

 

Olá pessoal,

Neste tópico vou compartilhar como funciona o licenciamento de chamadas no VCS (Video Communication Server), incluindo o que são e quais as diferenças entre Traversal License e Non-Traversall License. Continuem lendo.  =)

Sobre as licenças de chamada

Diferente do CallManager, o ponto chave de licenciamento no VCS não se baseia no número de devices cadastrados ou registrados, e sim no número chamadas simultâneas que se originam ou passam pelo VCS. O VCS já inclui, gratuitamente, licença para registrar 2500 devices, este número representa a capacidade máxima suporta por um VCS, portanto o licenciamento de devices no VCS não é algo a se preocupar quando adquirir licenças para o VCS.

O custo a se considerar está relacionado as licenças de chamadas, estas sim devem ser adquiridas para que os endpoints “gratuitamente” registrados no VCS consigam fazer e receber chamadas (Tandberg’s deal). Basicamente, dois tipos de licenças de chamadas podem ser compradas para o VCS:

Non-Traversal Call License:

Esta licença é utilizada pelo VCS sempre que uma chamada for considerada como “Non-Traversal Call”. Veja mais detalhes a seguir.

Esta licença pode ser adquirida em pacotes com 10, 20, 50, 200 ou 300. Os partnumbers para cada pacote estão listados abaixo:

  • LIC-VCS-10
  • LIC-VCS-20
  • LIC-VCS-50
  • LIC-VCS-200
  • LIC-VCS-300

O bundle padrão do VCS Control geralmente inclui 10 licenças Non-traversal. Já o bundle padrão do VCS Expressway não inclui nenhuma Non-traversall call license, uma vez que esta licença é normalmente utilizada no VCS Control, pois no VCS Expressway o que mais se aplica são as Traversal call licenses.

Traversal Call License:

Esta licença é utilizada pelo VCS sempre que uma chamada for considerada como “Traversal Call”. Veja mais detalhes a seguir.

Esta licença pode ser adquirida em pacotes com 10, 20 e 50. Os partnumbers para cada pacote estão listados abaixo:

  • LIC-VCSE-10
  • LIC-VCSE-20
  • LIC-VCSE-50

O bundle padrão do VCS Control geralmente inclui 100 licenças Traversal. Já o bundle padrão do VCS Expressway inclui 5 Traversall call license. Parece estranho o VCS Control já vir com tantas licenças Traversal, basta ler sobre o que é o uma licença traversal que você vai entender o motivo disto (Tandberg’s deal, again!).

O que é uma non-traversal call?

Uma non-traversall call é uma chamada onde apenas a sinalização passa pelo VCS, assim o RTP corre ponto a ponto de um device para o outro sem a intermediação do VCS. Em resumo, uma chamada será non-traversall sempre que o VCS não precisar fazer qualquer conversão de protocolos ou a chamada não for roteada para o VCS Expressway, como por exemplo:

  • Endpoint SIP para endpoint SIP
  • Endpoint H323 para H323

Mesmo que um dos pontos da chamada estiver registrado com um gatekeeper ou SIP server vizinho do VCS (exceto VCS Expressway), desde que a chamada não sofra conversão de protocolos, ela será considerada non-traversal, portanto consumirá uma licença Non-traversal Call License.

Cada VCS suporta um total 250 Non-traversal calls simultaneamente. Este número pode ser acrescido usando cluster de VCS.

O que é uma traversal call?

Uma traversal call é uma chamada onde o VCS roteia tanto a sinalização quanto a mídia/RTP (assim como o MTP do CallManager) para os endpoints, normalmente quando há conversão de protocolos ou quando a chamada é roteada para o VCS Expressway. Uma chamada será considerada traversal nos seguintes cenários:

  • Endpoint SIP para H323 (e vice versa)
  • Endpoint usando IPv6 para endpoint usando IPv4
  • Chamada roteada para uma traversal zone (trunk com VCS Expressway)
  • Quando o VCS tem duas interfaces (dual nic option), se a chamada entrar por uma porta e sair por outra
  • Endpoint SIP para endpoint SIP onde um deles está atrás de NAT
  • Chamadas que passam por uma zona com “media encryption policy” configurada
  • Chamadas criptografadas envolvendo OCS 2007 ou Lync 2010 onde o B2BUA não está sendo usado

Um detalhe importante é, no VCS Expressway, se você fizer uma chamada do tipo Non-Traversal (SIP to SIP ou H323 to H323), caso você não tenha nenhum licença Non-traversal no VCS Expressway, ele usará as licenças Traversal, mesmo que a chamada não seja traversal, e a mídia também não será roteada pelo VCS, apenas a sinalização. Obviamente, este comportamento só se aplica ao VCS Expressway.

Cada VCS suporta um total 100 Traversal calls simultaneamente. Este número pode ser acrescido usando cluster de VCS.

Espero que seja útil. Em um outro tópico vou descrever um método legal para aproveitar estas 100 Non-traversal call licenses gratuitas que vem inclusas no VCS Control e economizar na hora comprar as licenças. XD

Até a próxima!

Paulo Souza

Posted in Telepresence | Comentários desativados em VCS – Entendendo licenciamento de chamadas

Problema ao atualizar CallManager 8.5.1 para 8.6.2 – SIP Normalization script vcs-interop

Posted by Paulo Souza em 01/07/2013

Pessoal,

Recentemente tive um problema bastante bizarro quando estava atualizando um CallManager versão 8.5.1 para versão 8.6.2. Imagino que nenhum de vocês já tenham visto este problema, porque é uma restrição muito específica que não acontece quando atualizando um CallManager comum de telefonia, o problema é mais relacionado a atualização de CallManager de telepresença integrado com VCS (Video Communication Server). Continuem lendo.  =)

O problema

Eu peguei um CallManager versão 8.5.1 que era usado para telepresença e com integração com VCS via SIP Trunk. Provavelmente a maioria não saiba, mas para integrar o VCS com o CallManager é recomendado criar um SIP Trunk customizado cheio de frescuras e detalhes. Um dos pontos a se configurar, a partir da versão 8.5.1, é aplicar um SIP normalization script no trunk chamado vcs-interop. Este script não vem criado por padrão na versão 8.5.1 do CallManager, apenas na 8.6.2, então é necessário adicioná-lo manualmente. Pois bem, o CallManager possuía este SIP normalization script criado e aplicado no trunk (eu mesmo tinha feito isso). Pois bem, quando fui atualizar o callmanager da versão 8.5.1 para a versão 8.6.2, tudo parecia correr bem como das outras vezes que atualizei usando as mesmas versões (acho que foram 2 vezes), eu estava sentado em frente ao monitor hipnotizado por aquelas barrinhas lentas carregando, então de repente, durante a execução dos scripts de instalação… … … … … Bum!! Tela azul!! A instalação falhou e recebi uma mensagem de erro bastante inútil, algo do tipo “Falha inesperada na atualização. Tentando reverter sistema para versão anterior…” Então o CallManager reiniciou e voltou com a versão 8.5.1 (pelo menos voltou rsrs).

Depois de outras tentativas, obtive exatamente o mesmo erro bizarro! Antes que eu terminasse de arrancar os meus cabelos, notei que a única diferença deste CallManager para os outros que eu tinha atualizado usando as mesmas versões era o bendito SIP normalization script vcs-interop. Pois bem, abri o release notes da versão 8.6.1, apertei CTRL+F e digitei “vcs-interop”, me deparei com a seguinte observação:

“If you are upgrading to Cisco Unified Communications Manager 8.6.1 from an earlier release, and your previous network included a connection to a Cisco TelePresence Video Communications Server (VCS), the upgrade to 8.6.1 will fail if the name of the SIP normalization script used in your previous release was vcs-interop. In this case, you must rename the old script prior to completing the upgrade.”

Bom, acho que nem preciso dizer mais nada. Apaguei o SIP normalization script e atualização rodou bonito, deu até gosto de ver aquelas barrinhas carregando.  =P

Acontece que na versão 8.6.2 do CallManager este script já vem criado por padrão, então quando o setup de instalação tentar criar o script, ele falha porque o objeto já existe na base de dados, então a atualização é abortada (estilo tela azul do Windows) e o sistema faz roll back para a versão anterior, neste caso, 8.5.1. Comportamento meio estranho, não é? Se o objeto já existe, deveria subscrevê-lo ou ignorá-lo, mas abortar a instalação!? =O

Workaround

Chorar. Ou pesquisar uma solução no blog AVVID.  =)

Solução

Deletar ou renomear o SIP normalization script vcs-interop antes de prosseguir com a atualização.

Aposto que eu fui a única pessoa no mundo que pegou este problema, duvido que mais alguém tenha tanto azar. =/

 

Até a próxima!

 

Paulo Souza

Posted in Callmanager, Telepresence | Etiquetado: , , , | Leave a Comment »

CTS 1.8.0 – Problema com diretório corporativo – CUCM 8.6.2 – Bug CSCtu07566

Posted by Paulo Souza em 01/07/2013

Pessoal,

Neste post vou compartilhar com vocês um bug nas telepresenças Cisco que já me atrapalhou em 2 janelas de migração. Continuem lendo.

Após atualizar um CallManager da versão 8.5.1 para 8.6.2, notei que no telefone da telepresença não aparecia mais o diretório corportativo, quer seja usando o botão diretório ou a opção directory mostrada na tela do TSPM. Após alguns minutos reclamando e ouvindo o cliente reclamar, descobri que o problema refere-se a um bug na telepresença.  O problema acontece com qualquer telepresença CTS rodando firmware 1.8.0 ou inferior registrada no CallManager 8.6.2, trata-se do bug CSCtu07566.

Solução

Atualizar o firmware do codec para a versão 1.8.1 ou superior. Mas notem que atualizar o firmware do codec requer também instalar um novo phone service para aplicação TSPM. A versão do TSPM que deve ser usada depende da versão do firmware que for instalada na CTS. Vejam a tabela de mapeamento de arquivos de firmwares e versões de telepresença que eu postei recentemente, é uma boa referência para saber qual versão do TSPM utilizar de acordo com a versão de firmware instalada no codec.

Equipamentos afetados

Qualquer telepresença da série CTS rodando firmware 1.8.0 ou inferior registrada no CallManager 8.6.2. Note que a série TX não é afetada, uma vez que ela requer no mínimo firmware 1.9.

Até a próxima!

Paulo Souza

Posted in Telepresence | Etiquetado: , , | Leave a Comment »

Jabber for Telepresence – Problema de desconexão com cluster de VCS – CSCud17952

Posted by Paulo Souza em 23/06/2013

Olá pessoal,

Neste post vou compartilhar com vocês um problema que descobri recentemente com o Jabber for Telepresence. Trata-se de um bug que causa grande impacto e até o momento não foi resolvido. Continuem lendo. =)

O problema ocorre quando há Jabbers for Telepresence registrados em um cluster de VCS (Control ou Expressway) com autenticação de dispositivos habilitada. Neste cenário, o cliente Jabber pode experimentar desconexões de chamada e perdas de registro inesperadas, após um certo período de tempo que o cliente está registrado e/ou em ligação. Vejam como o problema acontece:

  • O Jabber se registra com o primeiro VCS do cluster que requer autenticação
  • Após alguns segundos, o registro SIP irá expirar, então o cliente terá que se registrar novamente, quando o re-registro é encaminhado para o segundo VCS do cluster, este VCS também solicitará autenticação, então o cliente Jabber desconectará a chamada atual para se autenticar com o segundo VCS

Em resumo, o cliente jabber desconectará as chamadas sempre que for se autenticar com outro peer do cluster.

Este problema acontece principalmente quando você tem um cluster de VCS Controls integrados com um VCS Expressway, e há clientes jabber da internet se registrando no cluster de VCS Control através do VCS Expressway usando proxied registration. Neste cenário, as desconexões acontecerão com mais frequência.

Workaround

Se o deployment em questão utiliza  proxied registration como citado anteriormente, não há workaround (se prepare para inventar uma boa desculpa). Se o deployment contempla clientes Jabber registrados diretamente em um cluster de VCSs Control ou Expressway, você pode abrir mão da sua redundância e configurar o seu ambiente de provisioning de forma que os jabbers se registrem com apenas um peer do cluster unicamente.

Importante: Este problema foi resolvido no Jabber for IPad, porém ainda está em aberto para o Jabber for Telepresence (Movi) cuja versão atual é 4.6.

Minha expectativa é que este bug seja solucionado na próxima versão do Jabber for Telepresence.

Abs!

Paulo Souza

 

 

 

Posted in Telepresence | Etiquetado: , , , | Leave a Comment »

TC Endpoints – Guia de troubleshooting TC6

Posted by Paulo Souza em 12/06/2013

Pessoal,

Estou compartilhando um novo documento da Cisco, trata-se de um guia de troubleshooting (até então inexistente) para endpoints Cisco que utilizam TC software versão 6 (Séries C, EX, MX e SX). Vejam:

http://www.cisco.com/en/US/docs/telepresence/endpoint/codec-c-series/tc6/troubleshooting_guide/tc_troubleshooting_guide_tc60.pdf

TC6 Troubleshooting Guide

Até a próxima…

Paulo Souza

Posted in Telepresence | Etiquetado: , , | Leave a Comment »

CTS/TX – Mapeamento de arquivos de firmware e versões

Posted by Paulo Souza em 12/06/2013

Pessoal,

Neste post estou compartilhando com vocês uma tabela muito importante que a Cisco publicou recentemente na comunidade de suporte global. Esta tabela serve como referência cruzada para identificar quais são os arquivos e firmwares necessários para aplicarmos no codec, touch screen e IP Phone, dependendo da versão de software que está sendo utilizada telepresença.

Note que, a partir da versão 1.8, basta instalar um arquivo COP no CallManager. Este arquivo já contém o firmware do codec, o midlet para o telefone e o firmware para o touch device. Portanto não é necessário instalar separadamente os arquivos listados na tabela. Se o sistema possui versão inferior a CTS 1.7.4, é recomendado atualizar para as versões mais novas seguindo o procedimento descrito neste link:

CTS_TX table for firmware files 1

CTS_TX table for firmware files 2

Referência – https://supportforums.cisco.com/docs/DOC-29789

Paulo Souza

Posted in Telepresence | Etiquetado: , , , , | 1 Comment »

Série TX agora suporta anotações na imagem de apresentação usando touch pad

Posted by Paulo Souza em 12/06/2013

Fala galera!

Estou escrevendo este tópico  para comunicar uma nova feature  que a Cisco introduziu na nova versão de firmware das telepresenças da série TX (CTS500-32, TX1300-47, TX1310-65, TX9000, TX9200). A partir da versão TX 6.0 é possível usar o touch pad da telepresença para fazer anotações na imagem de apresentação que está sendo compartilhada durante a conferência.

O funcionamento é bem simples, quando qualquer endpoint estiver compartilhando apresentação, o usuário pode usar uma opção de “anotação” no touch pad da telepresença, neste opção o usuário irá visualizar no touch a imagem de apresentação e poderá fazer anotações na imagem, estas anotações serão mostradas para todos os participantes da conferência.

Note que as anotações só podem ser feitas a partir dos endpoints CTS500-32, TX1300-47, TX1310-65, TX9000, TX9200, porém todos os demais participantes da conferência visualizam o que for anotado.

Seguem algumas telas de exemplo:

touch annotate 1

touch annotate 2

Referencia: Release Notes TX 6.0 – http://www.cisco.com/en/US/docs/telepresence/tx_sw/6_0/release/notes/tx_sw_6_0_release_notes.html

Paulo Souza

Posted in Telepresence | Etiquetado: , , , , , | Leave a Comment »

Otimizando consumo de banda em TC Endpoints

Posted by Paulo Souza em 12/06/2013

Galera,

Neste post vou compartilhar com vocês uma configuração legal que encontrei recentemente nas vídeo conferências Cisco que utilizam TC Software (C, SX, MX, EX e Profiles).

Segundo o datasheet dos TC endpoints, a banda mínima requerida para fazer uma chamada em HD (720P30) é 768Kbps. Vejam por exemplo o item Minimum bandwidth do datasheet do SX20:

http://www.cisco.com/en/US/partner/prod/collateral/ps7060/ps11304/ps11313/ps11424/ps12153/data_sheet_c78-688342.html

Quando eu li isso fiquei meio confuso, porque fazendo testes e mais testes, a chamada usando 768Kbps não fechava em HD de jeito nenhum, sempre fechava com resolução inferior. Então comecei a ler o admin guide (sempre leiam o guide!) do equipamento e descobri que o perfil de consumo de banda é configurável! Existe um parâmetro na configuração de vídeo da entrada da câmera que específica o nível de compactação e consequentemente o consumo de banda da chamada. Este parâmetro fica no menu de configuração Video > Input > Source [1..n] > OptimalDefinition > Profile. Nesta opção, pode-se definir o valor para normal, medium ou High. Dependendo do perfil definido, o consumo de banda será diferente. Vejam a tabela abaixo:

Optimal Definition Profile

Notem que os valores de banda descritos na tabela acima não consideram a banda para apresentação, apenas para áudio e vídeo básico.

Vejam que, de acordo com a tabela cima, se eu setar o perfil para medium, será possível fazer uma chamada a 720p a 30 frames por segundo. Eu fiz o teste e funcionou perfeitamente. De acordo com a documentação, o perfil normal oferece um nível comum de compactação do vídeo, o perfil médium reduz 25% do consumo de banda em comparação com o medium, enquanto que o perfil high reduz 50% do uso de banda em comparação com o perfil normal!   =O

Mas calma aí, se é tão simples, por que a Cisco não deixa por padrão configurado para usar um perfil que usa menos banda? Ou melhor, pra que definir o perfil através de um parâmetro? Não seria melhor o equipamento por padrão otimizar o máximo possível? Bem, a resposta para estas perguntas está abaixo:

Requisitos para otimizar o consumo de banda

De acordo com a documentação, para que o consumo de banda possa ser otimizado definindo um perfil com maior capacidade de compactação, é necessário que a sala possua iluminação em boas condições. Se a sala possui uma boa iluminação (eu recomendaria o mesmo padrão de iluminação usado em salas imersivas), então é possível sim otimizar o consumo de banda aumentando a compactação. Em geral, para utilizar cada perfil, siga esta recomendação relacionada a iluminação da sala:

Normal – Tipicamente usado em salas mal iluminadas

Medium – Tipicamente usado em salas com iluminação boa e estável e usando uma boa qualidade de input de vídeo (se você usa uma câmera Cisco Precision HD, a qualidade do input de vídeo não é problema)

High – Recomendado apenas em salas dedicadas para vídeo conferência, com iluminação muito boa, semelhante aquelas usadas em salas imersivas. Também é necessário uma boa qualidade de input de vídeo (se você usa uma câmera Cisco Precision HD, a qualidade do input de vídeo não é problema)

Espero que seja útil! Segue referência da Cisco:

SX20 Administrator Guide TC6 – Página 113 – http://www.cisco.com/en/US/docs/telepresence/endpoint/quick-set-sx20/tc6/administration_guide/sx20_quickset_administrator_guide_tc61.pdf

Paulo Souza

Posted in Telepresence | Etiquetado: , , , , , | Leave a Comment »

Falha ao compartilhar apresentação com MCU usando BFCP em chamadas criptografadas

Posted by Paulo Souza em 11/06/2013

Galera,

Hoje vim compartilhar com vocês um problema bastante comum relacionado às MCUs Cisco Codian (Série 4200, 4500, 5300 e 8500).

Descrição do problema

As MCUs Cisco suportam o compartilhamento de apresentação durante a conferência, utilizando os protocolos BFCP (quando o endpoint é SIP) e H239 (quando o endpoint é H323). Pois bem, a MCU possui uma limitação no suporte ao protocolo BFCP, ela não suporta a criptografia da apresentação quando usando BFCP. O endpoint será capaz de compartilhar apresentação usando BFCP apenas quando a chamada não for criptografada. Se a chamada for criptografada, o endpoint tentará negociar criptografia inclusive da apresentação, mas haverá falha na negociação, pois a MCU não suporta, então a apresentação não funcionará corretamente. O resultado neste cenário será, a MCU passará a enviar apresentação para o participante no canal principal de vídeo ao invés de usar um canal só para apresentação (é o que o BFCP possibilita), então se o endpoint em questão possui dois displays, ele não verá o vídeo principal em um display e a apresentação em outro, pois apenas um canal de vídeo estará aberto passando a apresentação e o vídeo principal, o endpoint verá então a apresentação apenas em um dos displays, além disso ele não será capaz de separar apresentação do vídeo principal, pois ambos serão recebidos no mesmo canal.

Workaround

Bem, eu consigo pensar em três possibilidades para contornar esta limitação da MCU:

1) Utilizar o protocolo H323 ao invés de SIP

Se o endpoint usar o protocolo H323, a apresentação será feita via H239, portanto não haverá limitação. Porém isso pode ser muito drástico quando se tem endpoints registrados no CallManager, pois as TPs e VCs se registram no CM usando SIP apenas, H323 não é suportado. E alguns endpoints, como o Jabber for Telepresence, por exemplo, apenas suporta SIP.  =O

2) Fazer interworking SIP to H323 no VCS

Neste cenário, o endpoint registraria no VCS usando SIP, com TLS e criptografia habilitados. Então o VCS sempre rotearia as chamadas dos endpoints SIP para a MCU usando H323, assim o VCS faria o interworking de SIP para H323, utilizando BFCP de um lado e H239 de outro. Mas fiquem atentos! O interworking do VCS tem algumass limitações, ele apresenta problemas dependendo do cenário e do endpoint que se está utilizando. Eu ainda não testei este cenário!

3) Forçar a MCU não usar criptografia para endpoints específicos

É possível pré-cadastrar os endpoints na MCU, neste pré-cadastro é possível forçar a MCU a não negociar criptografia com o endpoint. Então cadastrando endpoints na MCU permite que você desabilite a criptografia em alguns participantes específicos, evitando assim que a limitação do BFCP ocorra.

Estes são os workarounds que consigo imaginar. Eu particularmente ainda nem sei qual deles vou utilizar, isso vai me render algumas horas quebrando a cabeça. =(

Espero que a Cisco corrija está limitação em breve. Pois como estamos num processo de transição do VCS para o CUCM, o protocolo utilizado será sempre SIP. Precisamos do BFCP funcionando com criptografia!

Paulo Souza

Posted in Telepresence | Etiquetado: , , , , , | 3 Comments »

 
%d blogueiros gostam disto: