Pull to refresh

Comments 6

Подход, конечно, интересный, но не логичнее было бы сначала использовать встроенный в ISR еще с IOS 12.X monitor capture на SIP call-leg'е?
На выходе получили бы pcap файс с дампом трафика, Wireshark отлично декодит RTP из него во всех основных кодеках.
Да и само появление DTMF-тонов можно было бы отследить через debug voice rtp session named-event и debug voice ccapi inout, не прибегая сразу к такому глубокому анализу.

переключение шлюза в режим SIP INFO (на маршрутизаторах Cisco ISR данный режим всегда включен)
Если на dial-peer статически задать dtmf-relay rtp-nte без дополнительных вариантов, то не так уж и всегда.
Здравствуйте! Хочу поблагодарить за высказанное мнение. Перечисленные вами инструменты мне известны и в ходе работ по данному инциденту применялись. Wireshark действительно может извлечь звук из дампа, вот только тон мы там не услышим. По крайней мере лично я до сих пор так и не научился отличать RTP-NTE и SIP INFO на слух.

появление DTMF-тонов можно было бы отследить через debug voice rtp session named-event и debug voice ccapi inout

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

Если на dial-peer статически задать dtmf-relay rtp-nte без дополнительных вариантов, то не так уж и всегда.

Здесь я лишь озвучил точку зрения производителя:

The sip-info method is available only on SIP dial peers. This is an out-of-band DTMF relay mechanism that registers the DTMF signals using SIP-Subscribe messages and transports the DTMF signals using SIP-Info messages. The body of the SIP message consists of signaling information and uses the content-type application/dtmf-relay. The method is always enabled for SIP dial peers, and is invoked when a SIP INFO message is received with DTMF relay content.
Вам также спасибо за развернутый ответ.
Wireshark действительно может извлечь звук из дампа, вот только тон мы там не услышим
Зависит от конкретного случая, оборудования и настроек. RFC2833 описывает возможность как оставлять оригинальный тон в аудио-потоке, наряду с генерацией NTE-пайлода, так и удалять его (в Cisco реализовано оба варианта: dtmf-relay rtp-nte [digit-strip]). Из RFC:
A source MAY send events and coded audio packets for the same time
instants, using events as the redundant encoding for the audio
stream, or it MAY block outgoing audio while event tones are active
and only send named events as both the primary and redundant
encodings.

Так что тон мог быть в записанном голосе (или даже только в нем как in-band DTMF, без relay вовсе), и подобная проблема сменой DTMF-relay механизма уже не решалась бы.
По крайней мере лично я до сих пор так и не научился отличать RTP-NTE и SIP INFO на слух.
В Wireshark они были бы видны как пакеты с полной структурой сообщения внутри.
Декодированный RTP-NTE, к примеру (нажата цифра 8):image
Да, появление тонов так можно отследить. Но в отрыве от контекста разговора мы не сможем сказать, правомерно ли появился данный тон
Очевидно, анализ имеет смысл производить только на вызове с воспроизведенной проблемой и уточненными данными со стороны абонентов (в какое время тестового звонка возник тон, не нажимались ли клавиши и т.д.).
О них и так в доступе масса информации, чего не скажешь об экстракции звука из дампов PCM.
Ничуть не умаляю проделанной работы, за анализ и статью спасибо, было интересно почитать. :)
Вопрос только зачем было это делать в контексте возникшей проблемы?

В схеме [Абонент1]---[АТС]--E1--[Cisco GW]--SIP--(Провайдер)--(ТфОП)--[Абонент2] начинать сбор основной информации на участке АТС-Cisco, как мне показалось, немного нелогично. Дебаги и стандартные средства показали бы, что в тестовом вызове DTMF приходил на call-leg'е провайдера, и дальнейший источник проблемы, и ее фикс стоит искать в той стороне. К чему Вы, собственно, и пришли:
Удалось выявить, что шлюз, на котором включен RFC2833, передает странные (не вполне понятно, откуда они берутся — то ли генерируются самим шлюзом, то ли приходят из сети оператора, но точно не от удаленного абонента) пакеты, которые маршрутизатор (на котором, в свою очередь, тоже включен RFC2833) воспринимает как RTP NTE
Вопрос только зачем было это делать в контексте возникшей проблемы?

Проверялись все участки прохождения вызова, в том числе и поток. Натолкнувшись в процессе на дамп PCM, самостоятельный анализ которого заявлялся категорически невозможным, я просто не смог пройти мимо. Первоначальную проблему можно было решить и без этого, согласен, но тогда одним нераскрытым секретом было бы больше. ;) Видимо, мне следовало иначе скомпоновать текст, оторвать предмет описания от контекста, в котором я начал разбирать формат дампа. Тогда бы у Вас не возник вопрос, который таки возник.
В голове не укладывается, как же получилось распознать структуру и выдернуть звук… Это очень круто, по-моему!)
На самом деле, публикуя заметку, опасался получить комментарий вроде: «уже давно существуют инструменты, позволяющие распознать внутреннюю структуру произвольного файла, зачем было изобретать велосипед?»

Мне о таких инструментах ничего не известно, но кто знает, что там уже успели изобрести? ;)
Sign up to leave a comment.

Articles