2010-10-02 1 views
0

Я захватил tcpdump вызова SIP для отладки проблемы DTMF (повторные цифры), но у меня есть проблема с ее интерпретацией.Захват DTMF в Strange flow на tcpdump

Из того, что я понимаю, когда я анализирую захваченный трафик через "VOIP CALL" Wireshark, я должен увидеть что-то вроде этого (для цифр 123):

CAPTURE 1
RTP телефона событие DTMF Один 1
(конец события)
RTP-телефон событие DTMF Два 2
(конец события)
RTP-телефон событие DTMF Три 3
(конец события)

Но я вижу это вместо
CAPTURE 2
RTP телефона событие DTMF Один 1
RTP телефона событие DTMF Один 1
RTP телефона событие DTMF Один 1
(конец)
RTP телефона событие DTMF Два 2
RTP, телефон событие DTMF Два 2
RTP-телефон событие DTMF Два 2
(конец)
RTP-телефон событие DTMF Два 3
RTP-телефон событие DTMF Два 3
RTP-телефон события DTMF Два 3
(конец)

1 системы, захват 2 определяется как 123, но на другой системе, кажется, чтобы декодировать это как имеющий повторяющиеся цифры. В чем причина того, что wirehark не группирует их вместе как одно событие RTP?

Это поток RTP трафика:
ЗАХВАТ 1:

RTP СЛУЧАЙ DTMF-1
RTP СЛУЧАЙ DTMF-1
RTP СЛУЧАЙ DTMF-1 (конец)
RTP СЛУЧАЙ DTMF-1 (конец)
RTP-EVENT DTMF-1 (конец)
RTP СЛУЧАЙ DTMF-2
RTP СЛУЧАЙ DTMF-2
RTP СЛУЧАЙ DTMF-2 (конец)
RTP Е.В. ЛОР DTMF-2 (конец)
RTP СЛУЧАЙ DTMF-2 (конец)
RTP СЛУЧАЙ DTMF-3
RTP СЛУЧАЙ DTMF-3
RTP СЛУЧАЙ DTMF-3 (окончание)
RTP СЛУЧАЙ DTMF-3 (окончание)
RTP-EVENT DTMF 3 (окончание)
RTP ПОЛЕЗНОЙ
...
...
...
полезной нагрузки RTP

тогда ЗАХВАТ 2:
RTP СЛУЧАЙ DTMF 1
полезной нагрузки RTP
RTP СЛУЧАЙ DTMF 1
полезной нагрузки RTP
RTP СЛУЧАЙ DTMF-1 (конец)
полезной нагрузки RTP
RTP СОБЫТИЯ DTMF 1 (конец)
RTP PAYLOAD
RTP EVENT DTMF 1 (конец)
RTP PAYLOAD
полезной нагрузки RTP
полезной нагрузки RTP
полезной нагрузки RTP
полезной нагрузки RTP
RTP СЛУЧАЙ DTMF-2
полезной нагрузки RTP
RTP СЛУЧАЙ DTMF-2
полезной нагрузки RTP
RTP СЛУЧАЙ DTMF-2 (конец)
полезной нагрузки RTP
RTP EVENT DTMF 2 (конец)
RTP PAYLOAD
RTP EVENT DTMF 2 (конец)
полезной нагрузки RTP
полезной нагрузки RTP
полезной нагрузки RTP
полезной нагрузки RTP
RTP СЛУЧАЙ DTMF-3
полезной нагрузки RTP
RTP СЛУЧАЙ DTMF-3
полезной нагрузки RTP
RTP СЛУЧАЙ DTMF-3 (окончание)
полезной нагрузки RTP
RTP EVENT DTMF 3 (конец)
RTP PAYLOAD
RTP EVENT DTMF 3 (конец)
RTP ПОЛЕЗНОЙ
RTP ПОЛЕЗНОЙ
RTP ПОЛЕЗНОЙ
RTP ПОЛЕЗНОЙ
RTP ПОЛЕЗНОЙ
RTP ПОЛЕЗНОЙ

ли CAPTURE 2 следующие RFC2833?

ответ

2

Возможно, что событие «RFC 2833» может быть закодировано как несколько RTP-пакетов. Раздел 3.6 говорит нам, что

Если событие продолжается более один период, источник генерации события должен послать новый пакет событий со значением временной метки RTP , соответствующее началу события и длительность события соответственно увеличилась.

RFC определяет «один период» как 50 мс.

Так

RTP EVENT DTMF 1
RTP EVENT DTMF 1
RTP EVENT DTMF 1 (окончание)

означает, что у нас есть кто-то, нажав клавишу 1, около 150 мс.

+0

Спасибо, знаете ли вы, может ли другая система интерпретировать это как повторяющиеся цифры? – rtpquestion

+0

Они не должны: последний пакет должен иметь свой бит E бит, обозначающий конец события. –

+0

@FrankShearar хорошо сказано Фрэнк ... но у меня есть запрос для вас .... Я пытаюсь обнаружить шаблон DTMF для cisco ph из пакета RTP ... что я делаю, я проверяю тип полезной нагрузки ... тогда я проверяю, является ли dtmfeventend равным 1, если 1 затем добавить значение значения DTMF-события в мою локальную переменную с именем «tobematchpattern» .... и ждать следующего dtmfeventend, но это не удается, если шаблон, который должен быть сопоставлен, позволяет сказать 111 или 222 .... это работает, если шаблон, который должен быть сопоставлен, равен 123 или 456, то означают цифры. – Harry

3

На самом деле спецификация поощряет вас избыточно передавать пакеты событий RTP из-за возможной потери пакетов, и они предлагают отправлять по меньшей мере 3 раза. Проверьте время начала и окончания каждого дублированного события. Если вам нужно продлить событие (ключ все еще удерживается, дольше, чем вы хотите кодировать в одном событии и т. Д.), Вы можете продлить его, не заканчивая его.

Это также почему пакеты End отправляются 3 раза. (См. section 3.6 of RFC 2833).

Смежные вопросы