Уже много лет пользуюсь SIP, звоню с телефона под Android через SipDroid и CSipSimple. Раньше, пока везде были тоновые меню, DTMF нормально работал. Последний год пользоваться DTMF не приходилось, а несколько дней назад приспичило, и такое ощущение, что оно не работает — роботы не реагируют на посылки, продолжая талдычить дальше по порядку.
В CSipSimple есть выбор способа отправки событий DTMF — RTP, SIP, in-band. Перепробовал все — без толку.
Есть ли какие-нибудь способы проверить, как эти посылки воспринимаются на той стороне?
Если звонить на обычный телефон, то абонент слышит тональные посылки, но непонятно, в каком месте они преобразуются в звук.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Уже много лет пользуюсь SIP, звоню с телефона под Android через SipDroid и CSipSimple. Раньше, пока везде были тоновые меню, DTMF нормально работал. Последний год пользоваться DTMF не приходилось, а несколько дней назад приспичило, и такое ощущение, что оно не работает — роботы не реагируют на посылки, продолжая талдычить дальше по порядку.
ЕМ>В CSipSimple есть выбор способа отправки событий DTMF — RTP, SIP, in-band. Перепробовал все — без толку.
ЕМ>Есть ли какие-нибудь способы проверить, как эти посылки воспринимаются на той стороне?
ЕМ>Если звонить на обычный телефон, то абонент слышит тональные посылки, но непонятно, в каком месте они преобразуются в звук.
RTP(rfc2833) и SIP шлются в виде метаданных до коммутатора/PBX, и передаст ли он DTMF дальше зависит от настроек коммутатора/PBX.
in-band генерирует тон на клиенте и шлет его как голос (как если бы вы воспользовались blue box аппаратным тон генератором и попищали в микрофон трубки).
Может "не проходить", из-за сжатия в используемых кодеках и перекодировании по пути из одного в другой.
Здравствуйте, Stanislaw K, Вы писали:
SK>RTP(rfc2833) и SIP шлются в виде метаданных до коммутатора/PBX, и передаст ли он DTMF дальше зависит от настроек коммутатора/PBX.
А в каком виде шлются эти посылки при звонке с мобильника? Коммутатор или PBX может быть настроен так, чтобы вести себя по-разному при звонках по GSM и SIP?
SK>in-band генерирует тон на клиенте и шлет его как голос (как если бы вы воспользовались blue box аппаратным тон генератором и попищали в микрофон трубки).
Это я в курсе.
SK>Может "не проходить", из-за сжатия в используемых кодеках и перекодировании по пути из одного в другой.
Настолько, что речь не искажена, но тоновые посылки искажаются?
SK>по возможности перейти на G.711 (a-law)
Ни один из моих клиентов его не поддерживает. Есть только PCMA, PCMU, speex, G.722, BV16, GSM, SILK, AMR, AMR-WB, ISAC, ISBC.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Есть ли какие-нибудь способы проверить, как эти посылки воспринимаются на той стороне?
ЕМ>Если звонить на обычный телефон, то абонент слышит тональные посылки, но непонятно, в каком месте они преобразуются в звук.
А при звонке с обычного мобильника тоновые сигналы на том же роботе работают?
Здравствуйте, Евгений Музыченко, Вы писали:
SK>>RTP(rfc2833) и SIP шлются в виде метаданных до коммутатора/PBX, и передаст ли он DTMF дальше зависит от настроек коммутатора/PBX.
ЕМ>А в каком виде шлются эти посылки при звонке с мобильника?
С мобильника dtmf дублируется in-band и RTP. На мобильник in-band.
ЕМ>Коммутатор или PBX может быть настроен так, чтобы вести себя по-разному при звонках по GSM и SIP?
С большой вероятностью оно так и настроено — по SIP один набор кодеков, в GSM другой.
SK>>in-band генерирует тон на клиенте и шлет его как голос (как если бы вы воспользовались blue box аппаратным тон генератором и попищали в микрофон трубки). ЕМ>Это я в курсе.
Этот вариант можно проверить. (попищать в трубку программным тон генератором).
SK>>Может "не проходить", из-за сжатия в используемых кодеках и перекодировании по пути из одного в другой. ЕМ>Настолько, что речь не искажена, но тоновые посылки искажаются?
Да.
SK>>по возможности перейти на G.711 (a-law) ЕМ>Ни один из моих клиентов его не поддерживает. Есть только PCMA, PCMU, speex, G.722, BV16, GSM, SILK, AMR, AMR-WB, ISAC, ISBC.
PCMА название одного из варианта реализации.
Больше нужно смотреть не потенциальные возможности клиента, а что поддерживается со стороны PBX, и что (из совпавшего) они решили использовать в этот раз.
По простому — на клиенте отключить заведомо не нужные кодеки и перезапустить его.
Здравствуйте, Stanislaw K, Вы писали:
SK>С большой вероятностью оно так и настроено — по SIP один набор кодеков, в GSM другой.
Кодеки могут влиять на DTMF именно в плане обработки посылок в цифровом (кодированном в протоколе) формате? Я очень сильно сомневаюсь, что существуют кодеки, пропускающие мало-мальски разборчивую речь, но необратимо портящие DTMF.
SK>попищать в трубку программным тон генератором
Попищал — не срабатывает.
ЕМ>>Настолько, что речь не искажена, но тоновые посылки искажаются?
SK>Да.
Как это может получаться технически? Вы это наблюдали непосредственно, сравнивая волны/спектры, или просто предполагаете?
SK>PCMА название одного из варианта реализации.
Здравствуйте, Евгений Музыченко, Вы писали:
SK>>С большой вероятностью оно так и настроено — по SIP один набор кодеков, в GSM другой.
ЕМ>Кодеки могут влиять на DTMF именно в плане обработки посылок в цифровом (кодированном в протоколе) формате? Я очень сильно сомневаюсь, что существуют кодеки, пропускающие мало-мальски разборчивую речь, но необратимо портящие DTMF.
Большинство кодеков портят DTMF. на стороне слушающей даже костыль придумали опцию "relax dtmf" расширяющую критерии детекции тонов (частоту/длительность).
SK>>попищать в трубку программным тон генератором ЕМ>Попищал — не срабатывает.
Но сомнения остались?
ЕМ>>>Настолько, что речь не искажена, но тоновые посылки искажаются? SK>>Да. ЕМ>Как это может получаться технически? Вы это наблюдали непосредственно, сравнивая волны/спектры, или просто предполагаете?
До такой глубины анализа не доходил, ибо бессмысленно. портится оно на стороне мне не подконтрольной.
SK>>PCMА название одного из варианта реализации. ЕМ>Попробовал его — ничто не меняется.
При этом другие кодеки нужно запретить.
А что в дебаг логах sip клиента? Если в клиенте нет логов то wireshark поанализировать сессию. он автоматически разложит на sip диалог и медиатрафик (если не шифрован) можно послушать.
Здравствуйте, Stanislaw K, Вы писали:
SK>Большинство кодеков портят DTMF.
Как именно портят? Я работаю со звуком не один десяток лет, и не представляю, как можно испортить тоновые посылки с частотами до 2 кГц, не испортив при этом речь.
Ну, или алгоритм распознавания посылок должен быть предельно дубовый, вроде поиска чистых фрагментов волны на фоне полной тишины, вместо анализа спектра.
SK>на стороне слушающей даже костыль придумали опцию "relax dtmf" расширяющую критерии детекции тонов (частоту/длительность).
Подозреваю, что ее придумали как раз для крайне дубовых алгоритмов, чтоб не переделывать их.
ЕМ>>Попищал — не срабатывает.
SK>Но сомнения остались?
А куда им деваться? Я ж пока не понял, в каком виде оно попадает (если вообще попадает) к тому роботу, что отвечает на том конце.
SK>До такой глубины анализа не доходил, ибо бессмысленно. портится оно на стороне мне не подконтрольной.
Стоило бы посмотреть, что именно приходит на Вашу сторону, хотя бы ради интереса. А на слух это как звучало?
ЕМ>>Попробовал его — ничто не меняется.
SK>При этом другие кодеки нужно запретить.
Зачем? Клиент отображает использование именно PCMA, на другие кодеки не переходит.
SK>А что в дебаг логах sip клиента?
Если DTMF настроен на "протокольный" режим — пишет, что отправляет соответствующие цифры. Если in-band — ничего не пишет.
В аудиозаписях звонков тонов DTMF нет даже в режиме in-band. То есть, код клиентов ленится их туда замешивать.
Сейчас попробовал в последнем MicroSIP под виндой — такая же хрень, в том числе с единственным кодеком G.711 a-law.
Какой-то весь этот клиентский софт явно кривой.
>wireshark поанализировать сессию. он автоматически разложит на sip диалог и медиатрафик (если не шифрован) можно послушать.
Здравствуйте, Евгений Музыченко, Вы писали:
SK>>Большинство кодеков портят DTMF.
ЕМ>Как именно портят? Я работаю со звуком не один десяток лет, и не представляю, как можно испортить тоновые посылки с частотами до 2 кГц, не испортив при этом речь.
Причины те же, по которым VoIP не работали голосовые модемы и факсы. Детали можно почитать на форумах телефонистов, за период широкого начала распространения IP телефонии 2000-2010 года.
ЕМ>Ну, или алгоритм распознавания посылок должен быть предельно дубовый, вроде поиска чистых фрагментов волны на фоне полной тишины, вместо анализа спектра.
Сдвиг частот +-5% человеческим ухом воспринимается нормально, а детектор двухтональной мультчастотной модуляции детектит запрещенные некоректные сочетания. Например ждет "*472#58", получает "52A10D5" и конечно такая посылка молча отбрасывается.
ЕМ>>>Попищал — не срабатывает. SK>>Но сомнения остались? ЕМ>А куда им деваться? Я ж пока не понял, в каком виде оно попадает (если вообще попадает) к тому роботу, что отвечает на том конце.
SK>>До такой глубины анализа не доходил, ибо бессмысленно. портится оно на стороне мне не подконтрольной. ЕМ>Стоило бы посмотреть, что именно приходит на Вашу сторону, хотя бы ради интереса. А на слух это как звучало?
Звучало не нормально, но у меня не музыкальный слух.
ЕМ>>>Попробовал его — ничто не меняется. SK>>При этом другие кодеки нужно запретить. ЕМ>Зачем? Клиент отображает использование именно PCMA, на другие кодеки не переходит.
У меня нет веры в честность sip клиентов.
SK>>А что в дебаг логах sip клиента? ЕМ>Если DTMF настроен на "протокольный" режим — пишет, что отправляет соответствующие цифры. Если in-band — ничего не пишет.
ЕМ>В аудиозаписях звонков тонов DTMF нет даже в режиме in-band. То есть, код клиентов ленится их туда замешивать.
Клиент может не писать часть потока.
ЕМ>Сейчас попробовал в последнем MicroSIP под виндой — такая же хрень, в том числе с единственным кодеком G.711 a-law. ЕМ>Какой-то весь этот клиентский софт явно кривой.
Весь SIP кривой, особенно кривой когда один из концов не под твоим контролем.
>>wireshark поанализировать сессию. он автоматически разложит на sip диалог и медиатрафик (если не шифрован) можно послушать. ЕМ>Руки дойдут — попробую.
Здравствуйте, Stanislaw K, Вы писали:
SK>Причины те же, по которым VoIP не работали голосовые модемы и факсы.
Причины не могут быть теми же. Модемы/факсы используют всю доступную в телефонии полосу, и намного более чувствительны к фазовым искажениям. DTMF использует полосу в несколько раз уже голосовой.
SK>Сдвиг частот +-5% человеческим ухом воспринимается нормально, а детектор двухтональной мультчастотной модуляции детектит запрещенные некоректные сочетания.
Для чего кодеку сдвигать частоты на 5%?
SK>Звучало не нормально, но у меня не музыкальный слух.
Для такого достаточно и технического.
SK>У меня нет веры в честность sip клиентов.
Если клиент обманывает, отображая текущий кодек, то что ему помешает обманывать, используя запрещенный?
ЕМ>>В аудиозаписях звонков тонов DTMF нет даже в режиме in-band. То есть, код клиентов ленится их туда замешивать.
SK>Клиент может не писать часть потока.
Ну да — он, судя по всему, смешивает то, что идет с микрофона, с тем, что идет на динамик, а добавлять туда посылки, генерируемые для линии, то ли забывает, то ли не считает нужным.
Здравствуйте, Евгений Музыченко, Вы писали:
SK>>Причины те же, по которым VoIP не работали голосовые модемы и факсы.
ЕМ>Причины не могут быть теми же. Модемы/факсы используют всю доступную в телефонии полосу, и намного более чувствительны к фазовым искажениям. DTMF использует полосу в несколько раз уже голосовой.
Модемы и факсы не могли связаться даже понизив протокол до v.22 1200 mnp4/mnp6. (пакеты 32 бит, адаптивная скорость 300-9600)
SK>>Сдвиг частот +-5% человеческим ухом воспринимается нормально, а детектор двухтональной мультчастотной модуляции детектит запрещенные некоректные сочетания. ЕМ>Для чего кодеку сдвигать частоты на 5%?
не думаю что это делается специально.
SK>>У меня нет веры в честность sip клиентов. ЕМ>Если клиент обманывает, отображая текущий кодек, то что ему помешает обманывать, используя запрещенный?
Если кодек запрещен, в процессе рукопожатия он не анонсируется на другую сторону, она не жмет в него и не принимает (отбрасывает) такие пакеты.
и на него не перейдут, если клиент\сервер умеют адаптивно менять кодеки в течении сессии.
ЕМ>>>В аудиозаписях звонков тонов DTMF нет даже в режиме in-band. То есть, код клиентов ленится их туда замешивать. SK>>Клиент может не писать часть потока. ЕМ>Ну да — он, судя по всему, смешивает то, что идет с микрофона, с тем, что идет на динамик, а добавлять туда посылки, генерируемые для линии, то ли забывает, то ли не считает нужным.
Здравствуйте, Stanislaw K, Вы писали:
SK>Модемы и факсы не могли связаться даже понизив протокол до v.22 1200
Да хоть до 300 — в v.22 тоже фазовая модуляция. Именно фаза в первую очередь страдает при сжатии.
SK>>>Сдвиг частот +-5% человеческим ухом воспринимается нормально, а детектор двухтональной мультчастотной модуляции детектит запрещенные некоректные сочетания. ЕМ>>Для чего кодеку сдвигать частоты на 5%?
SK>Если кодек запрещен, в процессе рукопожатия он не анонсируется на другую сторону
Здравствуйте, Евгений Музыченко, Вы писали:
SK>>Модемы и факсы не могли связаться даже понизив протокол до v.22 1200
ЕМ>Да хоть до 300 — в v.22 тоже фазовая модуляция. Именно фаза в первую очередь страдает при сжатии.
Да. Но после роста производительности CPU и перехода на G.711 alaw аналоговые модемы начали соединятся over VoIP на 14400.
SK>>>>Сдвиг частот +-5% человеческим ухом воспринимается нормально, а детектор двухтональной мультчастотной модуляции детектит запрещенные некоректные сочетания. ЕМ>>>Для чего кодеку сдвигать частоты на 5%? SK>>Если кодек запрещен, в процессе рукопожатия он не анонсируется на другую сторону
ЕМ>Я уже и запрещать пробовал, без толку.
С нашей стороны мы проверили всё. Теперь дело за техподдержкой оператора связи SIP аккаунта.
Есть только PCMA, PCMU, speex, G.722, BV16, GSM, SILK, AMR, AMR-WB, ISAC, ISBC.
Я ж пока не понял, в каком виде оно попадает (если вообще попадает) к тому роботу, что отвечает на том конце.
не думаю что это делается специально.