Это префикс перехода в DTMF (вы позвонили с цифрового аппарата наружу, на автоответчик например и должны чего-то набрать в DTMF).
Это удобно и привычно (переход в DTMF по *).
Встречал места - где переход в DTMF - не *.

Для набора *104 и посылки *104 в TG100 - надо создать ячейку *104, где call number = prefix_TG100+*104

Естественно - создать ячейку *104 станция позволит, если в станции нет номеров *, *1, *10, *104хххх.

Что должен набрать человек и что должна набрать станция?
А по сути - если хотите создать (например) ячейку *104 - не должно быть ничего типа - *, *1, *10

IP DECT - не поддерживает сетевой роуминг. Т.е. Человек с другой станции, не может приехав в Вахтовый поселок работать в зоне IP DECT.
Зоны - не должны пересекаться. Переключение с одной на другую - по документации до 2 минут.

Оптический вынос по INTOF в здание ради пары базовых станций - слишком дорого.

А с переключением - интересен случай - когда все-таки одна база слабеет, а вторая становится сильнее. Понятно, что если вторая база рядом и уровень от нее -70 - то переключаться на соседнюю (хоть там и минус 33) может и не захотеть.

Приветствую всех, есть один вопрос, на который хотелось бы услышать практические рекомендации, если кто сталкивался.
Имеется - большой вахтовый поселок, много небольших зданий - офисы, общежития, столовые и т.п. Есть желание развернуть DECT, но есть проблема с кабелями - имеется оптика, меди между зданиями нет (и нет возможности ее доложить).
Есть возможность ставить в здания IP шлюзы (3-х слотовые) с IBS DECT. Но при этом возникает вопрос с синхронизацией, которая по IP не передается.

Собственно вопрос - пробовал ли кто-то ставить в рамках одной станции DECT, включенный в IP  выносы, когда зоны действия баз пересекаются. Насколько велики проблемы с хендовером. Выйдя из зоны действия одной базы и зайдя в зону действия другой - трубка все-таки переключится, или ее придется выключить/включить?

Сначала - system/dyn vg/assighment - пишете что сообщение (не путать с Voice Guide) например 900 находится на плате GD (например 1-0 - шелф-плата). ACT - это шелф/кристал, cpl/coupler - это плата.
Далее через префикс записи (естественно по phone feature COS абоненту этот префикс требуется разрешить, заходите в меню записи сообщений. Говорим пишем сообщение 900, пишем, сохраняем, присваиваем имя и какое-то memo (например имя 900, чтоб легче ориентироваться, memo - test, оно просто присутствует в теле файла).

Собственно после этого - вы можете пользоваться записанным сообщением:
- Берете какой-то VG (System/ VG), например 5-й. и меняете в нем - вместо submessage 5 рисуете 900. Теперь через префикс tone test - вы увидите, что играет, что вы наговорили вместо стандартного сообщения.
- вариант 2 - создаете (System/VG) VG например 900, указываете в нем submessage 900 (то что собственно наговорили). И пользуетесь им.

Самый простой способ проверить вариант 2 - услуга incoming call greeting guide:
- создаете префикс (например 1000) Incoming Call Greeting Guide id=1
- System/ Incoming call greeting guide  - создаете 1, VG=900, время=100 (10 сек), overflow number=(например 2000).
- заруливаете ВНЕШНИЙ входящий вызов на номер 1000. Что происходит - при звонке на 1000, слышим 900-ю подсказку 10 сек, а потом вызов уходит на 2000.

такое ощущение, что у вас проблемы с IP дорогой между VoIP платами.
По трассировке мы видим:
- процессора договорились между собой о VPN префиксах.
- с VoIP платы ушел звонок на адрес 172.16.65.244 (это я так понимаю GD на OXE2). Call proc  - это не ответ с той стороны, это ОХЕ1 сама себе дает.

А вот ответа с той стороны - нет. Я думаю, если бы вы с той стороны запустили трассировку - вы не увидели бы пришедший на GD Setup (второй, который звонок на номер 32699).

Так что смотрите, что у вас с IP - что прописано роутерами, куда деваются пакеты. Т.е. если из сети ОХЕ1 на GD на OXE2 добраться по IP не удается - так и будет.

Или у вас что-то затыкается - смотрите как быстро пинги ходят, смотрите нет ли инцидентов про дублирование адресов.

Можно уточнить, что означает "невозможно дозвониться"? Есть звонок, но нет голоса. Линк "out of services". Какие-то инциденты.

При невозможности дозвониться - запускаем сетевую трассировку.
По идее сначала станции обменяются ABC-F сообщениями, потом вызываемая станция сообщит свой VPN overflow префикс, потом с H323 TG пойдет звонок на адрес удаленной VoIP платы.

На каком этапе облом.

Самое правильное - сделать аудит.
Но если его не делать, можно рекомендовать следующее:
- system/ broadcast/ broadcast object - проверьте, что у вас одинаково указано на станциях, что рассылать и что принимать.
- рестартуйте броадкаст через cleanbroad (рестарт броадкаста, последовательности начнут нумероваться заново).

Проверка состояния броадкаста и пр. - prog_diff

Если что-то не создается (например префикс 7570) - проверьте, что этому ничего не мешает (например speed dial 7, 75, 757).

Решил немного написать, про роуты и time based-route lists (для обычного, типового случая).

В ARS листе вы создаете роуты (до 10 шт), порядок их создания, номера, номера TG внутри них - не имеют никакого отношения к порядку их использования.

Порядок их использования - задается в time based route lists.

Вам надо создать ОДИН !!! time based route list, в котором перечислить в каком порядке, какой роут вы хотите использовать (типа 1,-1-1; 2,-1,-1; 4,-1,-1 - т.е. сначала роут номер 1, потом номер 2, потом номер 4).
Типовая ошибка - вместо ОДНОГО листа с рутом 1 и 2, создают ДВА листа, один с рутом 1, второй с рутом 2. В этом случае ВСЕГДА будет использован рут номер 1.

И таки да - time based листы нужны всегда. Если у вас в ARS листе один рут - вы обязаны создать time based route list, в котором указать этот единственный роут.

а патч какой? Были такие исправления (вроде в 22-м патче) - TEMPORIS 500 PRO & TEMPORIS 42 connected to SLI16  rung back when using CLIP

Это касается ситуации - когда в старых релизах новые аппараты доходили до работоспособности (ло нескольких минут), а потом уходили в ресет. В более менее последних патчах всех релизов - устранено.

Зависит ли происходящее от того - кто второй абонент? Внутренний или внешний.

Попробуйте на аппарате выключить использование VLAN.

lanpbxbuild - ничего нет - для одного процессора и IP аппаратов в данной сети - это нормально.
По DHCP - в main subnetwork, если идти далее - IP диапазоны какие-то указаны?
Попробуйте - выключить/включить DHCP (выбрать OFF, потом обратно DHCP server).