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
Подход, конечно, интересный, но не логичнее было бы сначала использовать встроенный в 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 без дополнительных вариантов, то не так уж и всегда.
Проводя автомобильные аналогии, Вы заказали разработку абстрактной машины с четырьмя колесами, крышей и рулем, на выходе получили два сваренных друг с другом велосипеда с запряженной костылями лошадью и прикрученным синей изолентой пляжным зонтиком (или Лада Калину). После чего удивляетесь, что у нее нет адаптивных систем безопасности, круиз-контроля, разгона до 100 за 3 секунды и шильдика S63 AMG — 21й век на дворе ведь, это само собой разумеющиеся вещи.
Зависит от конкретного случая, оборудования и настроек. RFC2833 описывает возможность как оставлять оригинальный тон в аудио-потоке, наряду с генерацией NTE-пайлода, так и удалять его (в Cisco реализовано оба варианта: dtmf-relay rtp-nte [digit-strip]). Из RFC:
Так что тон мог быть в записанном голосе (или даже только в нем как in-band DTMF, без relay вовсе), и подобная проблема сменой DTMF-relay механизма уже не решалась бы.
В Wireshark они были бы видны как пакеты с полной структурой сообщения внутри.
Декодированный RTP-NTE, к примеру (нажата цифра 8):
Очевидно, анализ имеет смысл производить только на вызове с воспроизведенной проблемой и уточненными данными со стороны абонентов (в какое время тестового звонка возник тон, не нажимались ли клавиши и т.д.).
Ничуть не умаляю проделанной работы, за анализ и статью спасибо, было интересно почитать. :)
Вопрос только зачем было это делать в контексте возникшей проблемы?
В схеме [Абонент1]---[АТС]--E1--[Cisco GW]--SIP--(Провайдер)--(ТфОП)--[Абонент2] начинать сбор основной информации на участке АТС-Cisco, как мне показалось, немного нелогично. Дебаги и стандартные средства показали бы, что в тестовом вызове DTMF приходил на call-leg'е провайдера, и дальнейший источник проблемы, и ее фикс стоит искать в той стороне. К чему Вы, собственно, и пришли:
На выходе получили бы pcap файс с дампом трафика, Wireshark отлично декодит RTP из него во всех основных кодеках.
Да и само появление DTMF-тонов можно было бы отследить через debug voice rtp session named-event и debug voice ccapi inout, не прибегая сразу к такому глубокому анализу.
Если на dial-peer статически задать dtmf-relay rtp-nte без дополнительных вариантов, то не так уж и всегда.