Análise DTMF com Wireshark - SIP INFO | RFC2833 | INBAND

[@vandersonandrades]

Muito bom, e excelente didática.

[@gilsonjust]

@@vandersonandrades valeu Anderson !!!!

[@Juli4nn0]

Excelente explicação. Parabéns Gilson!

[@gilsonjust]

Obrigado Julianno :)

[@lukawelchen2537]

Esse entende muito. Grande vídeo Gilson, conteúdo de primeira.

[@VoipeasyBR]

Surreal sua explanação o tema

[@gilsonjust]

Valeu Guilherme :)

[@zoekr79]

Amazing my friend! Although i do not understand the language, i learnt a lot of helpful things only by watching the video! Thank you very much! Keep up the excellent work!

[@gilsonjust]

Thank you ver much for the feedback :)

[@rafaelmanieri]

Vídeo TOPPP

[@gilsonjust]

Valeu Rafael !! Obrigado :)

[@guigozerox]

Parabéns cara! Conteúdo excelente.

[@gilsonjust]

Obrigado Igor :)

[@anselmo.oliveira]

Parabéns pela aula, ótimo conteúdo!

[@gilsonjust]

Muito obrigado Anselmo :)

[@brendasantana7582]

Me salvou demais hoje! Parabéns pela explicação.

[@gilsonjust]

Obrigado Brenda 😀

[@ricardodilly3154]

Excelente! Muito obrigado!

[@wiltonctba]

Muito bom Gilson. Agradeço pelo video. Estou com uma situação em uma identificação de chamada em um ramal analógico (gateway Greandstream). Mudei o DTMF e não identifica o recebimento de jeito nenhum. Ou aparece número privado ou aparece apenas 2 zeros. Mudei os DTMF mas nada. Tenha ideia do que possa ser?

[@gilsonjust]

Fala Wilton, firme? a Análise DTMF deste vídeo não tem relação com identificação de chamadas. No seu caso, seria ideal verificar pelo trace Wireshark em qual campo do protocolo SIP (From header) está vindo o número de A, e se possível ajustar o endpoint para ler o número de A à partir do header identificado. Um abraço !

[@FMS-996]

Muito bom! Ótima didática

[@gilsonjust]

Obrigado pelo seu feedback Fellipy ! ;)

[@gabriellopeshespanhol9924]

Excelente vídeo e explicação.

[@gilsonjust]

Valeu Gabriel, obrigado ! :)

[@mauroroca6806]

Grato pela aula! Quais cénarios é preciso usar cada tipo de DTMF?

[@gilsonjust]

Depende de cada situação, RFC2833 transporta sobre os pacotes RTP, SIP INFO transporta os eventos DTMF sobre o próprio Body do método SIP, e INBAND, as frequências do DTMF são codificadas e decodificadas de acordo com cada CODEC (o que não é bom pois pode ocorrer perdas e falhas na detecção pelo recebedor). Grande abraço Mauro !

[@mauriciomotta3254]

Muito bom mesmo

[@gilsonjust]

Valeu Mauricio, :)

[@marcossimoes7658]

Consigo registro de DTMF recebido tb? Exemplo digitado pelo cliente

[@gilsonjust]

fala Marcos, firme? Consegue sim, o procedimento de análise é exatamente o mesmo !

[@marcossimoes7658]

@@gilsonjust muito obrigado! Ótima explicação , ótimo vídeo !

[@andersoncarlosbarbosadeoli9295]

Olá, eu estou tentando analisar um problema de eco com dfmf, ou seja, dtmf repetido em um ambiente, onde estou espelhando os pacotes da chamada de um SBC ÁudioCodes para um servidor externo coletando via wireshark. O transporte do DTMF esta ocorrendo em INBAND com negociação rfc2833. O problema é que quando eu exploro o flow sip ou voip, não aparece pra mim o rtp telefone-event do dtmf na chamada coletada, eu só consigo enxergar filtrando no wireshark como RTP com payload, ae aparece todos os eventos RTP, mas como é um ambiente com um volume muito alto de chamada, eu não consigo associar a minha chamada de amostra. Alguém sabe me dizer como eu consigo isolar a minha chamada?

[@gilsonjust]

fala Anderson, firme? O problema é que o seu SBC não tem buffer suficiente para armazenar todo o tráfego necessário para sua análise, nesses momentos um recurso que ajuda muito é realizar a captura externamente, via port-mirror diretamente para um PC armazenando o tráfego via Ring Buffer/File do Wireshark. Outro recurso útil é o merge do Wireshark que você pode juntar diversos arquivos num único, talvez te ajude na sua análise. Espero ter ajudado, grande abraço ! ;)

[@andersoncarlosbarbosadeoli9295]

@@gilsonjust Entendi, eu vou verificar junto a AudioCodes, sobre o port-mirror não será possível, pois a área de infra do cliente não permite. Sobre o merge de arquivo, não seria necessário, uma vez que coletamos tudo em único arquivo, o problema que eu consigo fazer leitura do DTMF apenas filtrando em rtp.p_type==101, porém eu estou com dificuldade em associar esta coleta a minha chamada.

[@gilsonjust]

​@@andersoncarlosbarbosadeoli9295você precisará de fato coletar a sinalização SIP/SDP para associar o streaming à sinalização através das portas negociadas (no SDP), não vejo outra forma de linkar uma coisa à outra, o Wireshark faz isso automaticamente em VoIP Calls, fora isso, não há como. Se o seu DTMF está sendo enviado via RFC2833, você consegue utilizar o filtro (rtpevent.event_id == 1) por exemplo para DTMF 1. Se for INBAND, o Audacity resolve isso para você através da análise em função da frequência como apresentado no vídeo.

[@andersoncarlosbarbosadeoli9295]

@@gilsonjust Eu consegui associar o RTP com minha chamada utilizando o session id gerado no campo DEBUG RECORDING da AudioCodes e aplicar como filtro. Uma pergunta, é normal a quantidade de eventos por digitos? Seria por causa do espelhamento do SBC? PRIMEIRA PERNA DE ENTRADA OPERADORA ========>> SBC SESSION ID DEBUG RECORDING: 22747451 Digito = 1 26 eventos 6 eventos de End Digito = 2 24 eventos 6 eventos de End Digito = 3 28 eventos 6 eventos de End Digito = 4 24 eventos 6 eventos de End Digito = 5 28 eventos 6 eventos de End Digito = 6 28 eventos 6 eventos de End SEGUNDA PERNA DE SAÍDAA SBC ========>> OPERADORA SESSION ID DEBUG RECORDING: 22747456 Digito = 1 26 eventos 6 eventos de End Digito = 2 24 eventos 6 eventos de End Digito = 3 28 eventos 6 eventos de End Digito = 4 24 eventos 6 eventos de End Digito = 5 28 eventos 6 eventos de End Não gerou o digito = 6

[@gilsonjust]

@@andersoncarlosbarbosadeoli9295 veja o payload/timestamp do próprio evento de DTMF se é incrementado à cada evento, se for repetido pode ser algo do espelhamento mesmo, se não, pode estar relacionado ao tempo de envio de DTMF