LIK50A подключена через LDK100 по VOIP. Выход в город с LDK100 по PRI.
При звонке с LIP-8002(других IP телефонов нет) на внешний номер вызываемый абонент слышит DTMF сигналы.
При звонке с SLT(2 встроенные в LIK50) трубок этого нет.
С LDK100 тоже нет проблем.

Прошивка LIK50A бетта для работы с LIP8002.

Из-за чего это происходит и в как устранить проблему?

Может 111-22 подергать?, но очень сомневаюсь, что поможет..

Кто слышит DTMF-тоны: вызываЕМЫЙ (внешний абонент, ГАТС) или все-таки вызываЮЩИЙ (LIP-8002)???

Именно вызываЕМЫЙ (внешний абонент, ГАТС)

Что то как то не понятно. А как вызываЕМЫЙ(внешний абонент, ГАТС) может слышать эти сигналы, если набирается его номер и, следовательно, его еще и не вызвали...

Т.е. вызываемый абонент отвечает и в этот момент слышит DTMF-тоны??
Может, LIP-8002 дублирует цифры набранного номера, и те из них, которые остались в буфере уже после получения Connect, уходят в линию тоном (inband)?? Вообще-то с дублированием цифр набора была проблема с SLTM +LGSM + Auto Record. Тут вроде другая ситуация. ХЗ. Надо бы как-то исследовать.

Да человек подмимает трубку и слышит DTMF-тоны.
Очень похоже что тонами дублируется номер который набрали, но точно проверить не могу.
Сегодня попробую через Phontage ошишу резльтат

А когда будет офицальная прошивка с подержкой LIP8002 ?
И есть ли свежая прошивка на телефоны ?
потому что в текущей что я работаю сильно заметно что бетта

Неизвестно... Ждем-с.
И в чем же проявляется бетта??

Вызываемый внешний абонент ГАТС "подмимает трубку и слышит DTMF-тоны"
Если бы сразу такую фразу сказали - было бы понятно с первого поста..

Проверил у себя на стенде, собрав аналогичную схему с транзитом.
Увы, все подтвердилось, проблема имеет место быть - при ответе вызываемого абонента у него действительно слышен DTMF набор. Придется делать запрос разработчикам на исправление этого бага.

Спасибо
Будем ждать. Когда появятся обновления отпишитесь здесь пожалуйста.

ОК. Я исследовал этот баг. Он проявляется в IPECS только при определенном условии: при посылке Overlap'ом по линии типа NET (ПГМ322: тип линий =NET, ПГМ324: PSTN Enblock = OFF ). При этом после получения сообщения Connect станция iPECS ошибочно повторяет набранные цифры как DTMF-тоны (Inband).
Запрос в Корею на исправление бага мы напишем, а пока могу предложить другой вариант решения.
Что у Вас назначено в iPECS50:
- в ПГМ322, какой тип линий указан для каналов VOIP: NET или PSTN??
- в ПГМ324, что прописано для транзитного (в сторону LDK) кода: PSTN Enbloc = On или Off??
Так вот, если включить PSTN Enbloc, то iPECS уже не будет дублировать набранные цифры. Эта проблема будет решена. Но... у Вас iPECS подключен к LDK, на котором выполняется транзит на линию ISDN.
Далее все будет определяться настройками LDK. Возможно, придется слегка подправить настройки транзита на станции LDK... У меня на стенде все заработало нормально, в том числе и транзит.

Была именно такая конфигруция.( NET + Overlap)
Так как сейчас не смог добраться до LDK.
Просто изменил тип линии в 332 программе на PSTN и DTMF-тоны пропали.
Странно что пришлось менять только на стороне iPECS

Ну, я бы лучше тип линий оставил NET (ПГМ322), а для транзитного кода в ПГМ324 вкключил бы опцию PSTN Enbloc = ON. И в том и в другом случае уйдет Enblock'ом.
Ничего странного нет. Зависит от версии прошивки LDK, от того какой АОН отправляется далльше в город и т.п. Поскольку тут есть нюансы, то я Вас просто на всякий случай предупреждал, что при переходе от Overlap к Enblock ваша проблема с тонами будет решена, но могут появиться другие, связанные с транзитом.
Если сейчас все работает, то и славно!!!

Да, интересные и несколько, на первый взгляд, нелогичные вещи подчас выясняются. Век живи - век учись!

Указанный баг (набор Overlap'ом на линии типа NET) исправлен на тестовой версии E[5].5Db.