- Subscrever fonte RSS
- Marcar como novo
- Marcar como lido
- Marcador
- Subscrever
- Página amigável para impressora
- Denunciar conteúdo inapropriado
em 03-23-2015 12:39 PM
Com a especialista Bianca Meslin
P: Para analisar o problema, precisaria coletar traces detalhados do CUCM e debugs no Cube para analisar o que o CUCM esta enviando e o que o CUBE esta respondendo?
Normalmente sim, se você tem um ambiente onde você tem um call manager e o cube, e o cube então fala com a sua provedora, seja qual for o protocolo, inicialmente você não sabe onde esta o problema então o ideal é fazer isso, coletar traces do CUCM e debugs no CUBE, porque ai você pode ver toda negociação. No cube você vai ver o que você recebe e envia para o call manager, mas pode ser que algum detalhe que esteja nos traces do call manager você não visualiza nos debugs do CUBE.
P: Há alguma limitação de versão no caso CUCM 7.1.5 / RTMT na coleta de trace para uma chamada SIP ?
Não. Eu desconheço. A diferença dos traces que a gente ve, como eu mencionei na apresentação, antes do 9 elas eram feitas, salvas nos arquivos CCM SDI e hoje no SDL. Algumas coisas que modificam de uma versão para a outra é na página de configuração dos traces, na parte de baixo, você tem paramentros onde você define o tamanho de cada arquivo e o número de arquivos gerados e isso pode variar de uma versão para a outra. Você pode ter uma limitação diferente de tamanho e de número de arquivos que você gera nos traces de um Call Manager.As vezes em algumas situações você precisa aumentar esses parametros porque você tem um volume de chamadas muito grandes e você precisa coletar um periodo muito grande para tentar achar o problema, e para não subescrever você aumenta esses números, mas não sei dizer uma limitação que tenha no 7 para coleta de traces não, você vai coletar via RTMT normalmente.
P: É possível configurar um tronco SIP de um call manager cisco para uma central Phone2b?
Se o outro dispositivo suportar a sinalização SIP é possivel configurar o tronco SIP.
P: Tenho um SIP Trunk com um parceiro, onde no meu ambiente é um CUCM 7.1.5 e o parceiro é CUCM 8.6. Ocorre normalmente chamadas de áudio, mas não conseguimos a chamada com vídeo. No parceiro tem um CUBE.
Precisa verificar se a opção “Video Capabilities” está habilitada na configuração do device, se estiver, precisa coletar trace detalhado do cucm para verificar a negociação entre CUCM e CUBE.
Segue abaixo link que mostra como coletar traces do cucm:
https://supportforums.cisco.com/document/126666/collecting-cucm-traces-cucm-862-tac-sr
P: Quais os fatores que podem estar impactando. Segundo o parceiro ele informa que não visualiza a informação de vídeo no trace.
Precisa verificar se a opção “Video Capabilities” está habilitada na configuração do device e verificar a troca de mensagens sip nos traces do cucm para confirmar quem não está mandando.
P: É a partir desse erro 4xx que definimos qual lado apresentou erro, no caso 4xx é o lado do client e 5xx do lado do servidor certo?
Correto. Segue abaixo um link com um resumo das mensagens sip de erro.
P: Na linha do SDP é que podemos definir que se trata de uma sessão de video ou audio?
Correto. Verifique as tabelas 6-3, 6-4 e 6-5 do link abaixo, estas tabelas possui uma explicação de cada linha do campo sdp.
P: Justamente a linha m=vídeo que não está sendo informada no trace gerado pelo parceiro, onde ele diz que não estou enviando.
Precisa verificar o dispositivo que não está informando pois este campo indica “Media description – UDP port and RTP payload type for offered video codecs (in preference order)” .
Pode confirmar esta informação na tabela 6-5 do documento abaixo:
P: O mais normal é Early offer?
Ambos são utilizados. Normalmente a provedora pede que a chamada seja enviada em early offer. Segue abaixo dois links, o primeiro com um exemplo de troca de mensagens utilizando Delayed Offer e o segundo utilizando Early Offer.
P: A opção de verificar pacotes VoIP também funciona para SCCP?
Sim, se você acessar a funçao Telephony à VoIP Calls do wireshark, você poderá ver toda troca mensagens sccp.
P: Existe algum impacto em ativar o Early Offer no CUCM? Utilização de MTP por exemplo. E o IOS, por padrão utiliza o que?
Depende da versão, se a versão do cucm for 8.0 para baixo ele irá alocar mtp para todas as chamadas, já nas versões 8.5 em diante, o mtp será alocado somente se necessário utilizando a opção “Early Offer support for voice and video calls (insert MTP if needed)”. Segue abaixo um link com mais informações:
http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/srnd/8x/uc8x/media.html#wp1055839
O IOS irá depender de como ele receber a chamada, caso receba uma chamada em early offer o mesmo a encaminhará como early offer e se receber a chamada em delayed offer encaminhará a chamada em delayed offer. Você pode forçar o cube a enviar early offer mesmo quando recebe delayed offer configurando o comando “early-offer forced”.
P: Ele nao configurou o ip trust list?
A partir do IOS 15.1(2)T, o IOS irá rejeitar chamadas de fontes desconhecidas por padrão se o comando “ip address trusted list” não estiver configurado.
P: Qual versão de RTMT possui a opção Session Trace?
Foi adicionado na versão 8.5(1).
P: No caso na versão 7.1.5 não tem o Trace Session SIP?
Respondido na pergunta anterior.
P: Ola, sabe me dizer se o VLT ainda esta disponivel no RTMT para versões do do CUCM 10.x?
Pela documentação suporta até a versão 10.0(1) do cucm. Segue abaixo a documentaçao do CUCM e do VLT. (está pergunta foge do tema da apresentação)
P: O Sip permite a mudança de codec após a conversação estabelecida atraves do reinvite ?
Sim, permite. De acordo com a RFC6141 isto pode ser realizado. Segue abaixo link da rfc com mais informações:
https://tools.ietf.org/html/rfc6141#page-12


