Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 6
Подход, конечно, интересный, но не логичнее было бы сначала использовать встроенный в ISR еще с IOS 12.X monitor capture на SIP call-leg'е?
На выходе получили бы pcap файс с дампом трафика, Wireshark отлично декодит RTP из него во всех основных кодеках.
Да и само появление DTMF-тонов можно было бы отследить через debug voice rtp session named-event и debug voice ccapi inout, не прибегая сразу к такому глубокому анализу.
На выходе получили бы 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.
появление 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.
Вам также спасибо за развернутый ответ.
Так что тон мог быть в записанном голосе (или даже только в нем как in-band DTMF, без relay вовсе), и подобная проблема сменой DTMF-relay механизма уже не решалась бы.
Декодированный RTP-NTE, к примеру (нажата цифра 8):
Вопрос только зачем было это делать в контексте возникшей проблемы?
В схеме [Абонент1]---[АТС]--E1--[Cisco GW]--SIP--(Провайдер)--(ТфОП)--[Абонент2] начинать сбор основной информации на участке АТС-Cisco, как мне показалось, немного нелогично. Дебаги и стандартные средства показали бы, что в тестовом вызове DTMF приходил на call-leg'е провайдера, и дальнейший источник проблемы, и ее фикс стоит искать в той стороне. К чему Вы, собственно, и пришли:
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):
Да, появление тонов так можно отследить. Но в отрыве от контекста разговора мы не сможем сказать, правомерно ли появился данный тонОчевидно, анализ имеет смысл производить только на вызове с воспроизведенной проблемой и уточненными данными со стороны абонентов (в какое время тестового звонка возник тон, не нажимались ли клавиши и т.д.).
О них и так в доступе масса информации, чего не скажешь об экстракции звука из дампов PCM.Ничуть не умаляю проделанной работы, за анализ и статью спасибо, было интересно почитать. :)
Вопрос только зачем было это делать в контексте возникшей проблемы?
В схеме [Абонент1]---[АТС]--E1--[Cisco GW]--SIP--(Провайдер)--(ТфОП)--[Абонент2] начинать сбор основной информации на участке АТС-Cisco, как мне показалось, немного нелогично. Дебаги и стандартные средства показали бы, что в тестовом вызове DTMF приходил на call-leg'е провайдера, и дальнейший источник проблемы, и ее фикс стоит искать в той стороне. К чему Вы, собственно, и пришли:
Удалось выявить, что шлюз, на котором включен RFC2833, передает странные (не вполне понятно, откуда они берутся — то ли генерируются самим шлюзом, то ли приходят из сети оператора, но точно не от удаленного абонента) пакеты, которые маршрутизатор (на котором, в свою очередь, тоже включен RFC2833) воспринимает как RTP NTE
Вопрос только зачем было это делать в контексте возникшей проблемы?
Проверялись все участки прохождения вызова, в том числе и поток. Натолкнувшись в процессе на дамп PCM, самостоятельный анализ которого заявлялся категорически невозможным, я просто не смог пройти мимо. Первоначальную проблему можно было решить и без этого, согласен, но тогда одним нераскрытым секретом было бы больше. ;) Видимо, мне следовало иначе скомпоновать текст, оторвать предмет описания от контекста, в котором я начал разбирать формат дампа. Тогда бы у Вас не возник вопрос, который таки возник.
Проверялись все участки прохождения вызова, в том числе и поток. Натолкнувшись в процессе на дамп PCM, самостоятельный анализ которого заявлялся категорически невозможным, я просто не смог пройти мимо. Первоначальную проблему можно было решить и без этого, согласен, но тогда одним нераскрытым секретом было бы больше. ;) Видимо, мне следовало иначе скомпоновать текст, оторвать предмет описания от контекста, в котором я начал разбирать формат дампа. Тогда бы у Вас не возник вопрос, который таки возник.
В голове не укладывается, как же получилось распознать структуру и выдернуть звук… Это очень круто, по-моему!)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Мифический PCM Capture Extraction Tool: извлекаем звук без обращения в TAC