Странный захват потока DTMF на tcpdump

Я перехватил tcpdump SIP-вызова для отладки проблемы с DTMF (повторяющиеся цифры), но у меня возникли проблемы с его интерпретацией.

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

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

Но вместо этого я вижу это
CAPTURE 2
Событие телефона RTP DTMF One 1
Событие телефона RTP DTMF One 1
Событие телефона RTP DTMF One 1
(конец)
Телефон RTP событие DTMF Two 2
Телефонное событие RTP DTMF Two 2
Телефонное событие RTP DTMF Two 2
(конец)
Телефонное событие RTP DTMF Two 3
Телефонное событие RTP DTMF Two 3
RTP телефонное событие DTMF Two 3
(окончание)

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

Это поток трафика rtp:
CAPTURE 1:

СОБЫТИЕ RTP DTMF 1
СОБЫТИЕ RTP DTMF 1
СОБЫТИЕ RTP DTMF 1 (конец)
СОБЫТИЕ RTP DTMF 1 (конец)
СОБЫТИЕ RTP DTMF 1 (конец)
СОБЫТИЕ RTP DTMF 2
> СОБЫТИЕ RTP DTMF 2
СОБЫТИЕ RTP DTMF 2 (конец)
СОБЫТИЕ RTP DTMF 2 (конец)
СОБЫТИЕ RTP DTMF 2 (конец)
СОБЫТИЕ RTP DTMF 3
СОБЫТИЕ RTP DTMF 3< br> СОБЫТИЕ RTP DTMF 3 (конец)
СОБЫТИЕ RTP DTMF 3 (конец)
СОБЫТИЕ RTP DTMF 3 (конец)
ПОЛЕЗНАЯ НАГРУЗКА RTP
...
...
. ..
ПОЛЕЗНАЯ НАГРУЗКА RTP

тогда как CAPTURE 2:
СОБЫТИЕ RTP DTMF 1
ПОЛЕЗНАЯ НАГРУЗКА RTP
СОБЫТИЕ RTP DTMF 1
ПОЛЕЗНАЯ НАГРУЗКА RTP
СОБЫТИЕ RTP DTMF 1 (конец)
ПОЛЕЗНАЯ НАГРУЗКА RTP
СОБЫТИЕ RTP DTMF 1 (конец)
ПОЛЕЗНАЯ НАГРУЗКА RTP
СОБЫТИЕ RTP DTMF 1 (конец)
ПОЛЕЗНАЯ НАГРУЗКА RTP
ПОЛЕЗНАЯ НАГРУЗКА RTP
ПОЛЕЗНАЯ НАГРУЗКА RTP
ПОЛЕЗНАЯ НАГРУЗКА RTP
ПОЛЕЗНАЯ НАГРУЗКА RTP
СОБЫТИЕ RTP DTMF 2
ПОЛЕЗНАЯ НАГРУЗКА RTP
СОБЫТИЕ RTP DTMF 2
ПОЛЕЗНАЯ НАГРУЗКА RTP
СОБЫТИЕ RTP DTMF 2 (окончание)
ПОЛЕЗНАЯ НАГРУЗКА RTP
СОБЫТИЕ RTP DTMF 2 (окончание)
ПОЛЕЗНАЯ НАГРУЗКА RTP
> СОБЫТИЕ RTP DTMF 2 (конец)
ПОЛЕЗНАЯ НАГРУЗКА RTP
ПОЛЕЗНАЯ НАГРУЗКА RTP
ПОЛЕЗНАЯ НАГРУЗКА RTP
ПОЛЕЗНАЯ НАГРУЗКА RTP
СОБЫТИЕ RTP DTMF 3
ПОЛЕЗНАЯ НАГРУЗКА RTP
СОБЫТИЕ RTP DTMF 3
ПОЛЕЗНАЯ НАГРУЗКА RTP
СОБЫТИЕ RTP DTMF 3 (конец)
ПОЛЕЗНАЯ НАГРУЗКА RTP
СОБЫТИЕ RTP DTMF 3 (конец)
ПОЛЕЗНАЯ НАГРУЗКА RTP
СОБЫТИЕ RTP DTMF 3 (конец)
ПОЛЕЗНАЯ НАГРУЗКА RTP
ПОЛЕЗНАЯ НАГРУЗКА RTP
ПОЛЕЗНАЯ НАГРУЗКА RTP
ПОЛЕЗНАЯ НАГРУЗКА RTP
ПОЛЕЗНАЯ НАГРУЗКА RTP
ПОЛЕЗНАЯ НАГРУЗКА RTP

Соответствует ли CAPTURE 2 RFC2833?


sip rtp dtmf
person rtpquestion    schedule 02.10.2010    source источник

Ответы (2)


arrow_upward
2
arrow_downward

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

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

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

So

СОБЫТИЕ RTP DTMF 1
СОБЫТИЕ RTP DTMF 1
СОБЫТИЕ RTP DTMF 1 (конец)

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

person Frank Shearar    schedule 02.10.2010
comment
Спасибо, вы знаете, может ли это привести к тому, что другая система интерпретирует это как повторяющиеся цифры? - person rtpquestion; 03.10.2010
comment
Они не должны: в последнем пакете должен быть установлен бит E, указывающий на конец события. - person Frank Shearar; 03.10.2010
comment
@FrankShearar хорошо сказал, Фрэнк ... но у меня есть к вам вопрос .... я пытаюсь определить шаблон DTMF для cisco ph из пакета RTP ... что я делаю, так это проверяю тип полезной нагрузки .... тогда я проверьте, равен ли dtmfeventend 1, если 1, то добавьте значение значения события DTMF в мою локальную переменную с именем tobematchpattern.... и дождитесь следующего dtmfeventend, но это не удается, если шаблон, который нужно сопоставить, скажем, 111 или 222... , это работает, если шаблон для сопоставления равен 123 или 456, я имею в виду, что цифры различаются - person Harry; 20.11.2017
comment
Допустим, кто-то удерживал клавишу 1 в течение ~ 100 мс на 2-й цифре в 111, но только 50 мс на 1-й и 3-й. Я ожидал бы увидеть пакеты что-то вроде СОБЫТИЯ RTP DTMF 1 (конец) СОБЫТИЕ RTP DTMF 1 СОБЫТИЕ RTP DTMF 1 (конец) СОБЫТИЕ RTP DTMF 1 (конец). Но чтобы быть уверенным, я бы использовал инспектор пакетов, чтобы увидеть, что именно отправляет устройство, прежде чем писать код для обнаружения того же. - person Frank Shearar; 20.11.2017
comment
Вы видите то, что jesup описывает в своем ответе - отправка избыточного пакета. Посмотрите время начала/окончания пакетов. (Боюсь, у меня не будет времени помочь вам дальше, я боюсь.) - person Frank Shearar; 21.11.2017

arrow_upward
3
arrow_downward

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

По этой же причине пакеты End отправляются 3 раза. (См. раздел 3.6 RFC 2833).

person jesup    schedule 22.10.2010