Инициализация переадресации вызова от имени прицепленной внешней учётки

Спасибо за отклик. С простыми переадресациями разобрался.
Допустим, переадресация/передача вызова поступившего звонка на неподцепленную к talk37 учётку адреса Sipnet. Поскольку поступил звонок не из Sipnet, то в половине случаев из-за внутренних проблем Sipnet получаем отлуп.
Если подцепляем в цепочку к talk37 транзитную внешнюю учётную запись Sipnet, чтобы сначала переадресовать на неё, а потом с неё на адрес конечного назначения Sipnet, то по идее сначала при первой переадресации звонка на транзитную учётку идёт обращения на Sipnet, чтобы как минимум узнать: есть ли и где прошедшая регистрацию активная учётная запись Sipnet онлайн – под одной учёткой же может быть несколько регистраций в разных местах, и в зависимости от программного обеспечения оператора при звонке на его учётку звонить будет последнее зарегистрированное устройство или все сразу. Поскольку к транзитной учётке Sipnet идёт обращение к Sipnet сначала, а не через внутреннюю маршрутизацию talk37, то по идее в порядка половины случаев получаем отлуп.
То есть при переадресации / передаче вызова нужна проверка: если переадресуется на внешнюю учётную запись Sipnet, подцепленную к talk37.ru, а от неё на другой внешний адрес (Sipnet), то нужна принудительная внутренняя маршрутизация без предварительного обращения к Sipnet: чтобы по пришедшей команде транзитная учётная запись Sipnet сама позвонила на конечную учётку Sipnet, и при успешном прохождении вызова и установлении конечного этапа соединения Sipnet-Sipnet чтобы произошло окончательное транзитное соединение через исключительно внутренний трафик talk37 без инициализирующих обращений к серверу Sipnet.

Часть решения вижу около опции Донабор: при входящем звонке нужно инициализировать Донабор от имени прицепленной к talk37 внешней учётной записи Sipnet, но обязательным условием нужно получение выхода на программирование юзерского DialPlan’a для Донабора (а выхода этого сейчас не вижу), чтобы автоматически при Донаборе “ничего” посредством DialPlan’а (какой-нибудь символ обозначения этого “ничего” нужно запрограммировать) срабатывало правило вызова на адрес Sipnet от имени прицепленной к talk37 внешней учётной записи Sipnet.

Ну и голосовое приветствие IVR как-то надо иметь возможность отключать.
Похоже, что лучше доп Опцию для всего этого, а не в рамках существующего Донабора.

Sipnet у меня близко получается за счёт пиринга, звонить с него легче мне лично напрямую, а не через посреднический сервер. Схема то есть стабильнее.
По железу у меня лимит по FXS-портам, поэтому для домашних предпочитаю использовать Ваш облачный сервис, дозваниваясь на него запрограммированной клавишей быстрого доступа, а с другой стороны получать адресованные мне на него входящие направленным мне звонком на Sipnet.
Ни в коем случае не уговариваю остальных так делать и не умАляю достоинств talk37.
Пользователи будут мне звонить в основном не юзеры Sipnet, но ценю в первую очередь необходимость стабильности моих исходящих Sipnet не через talk37. От себя напрямую это легче контролировать.

Спасибо. Идею понял.
Потестирую. Пока постоянного прохождения звонков внутри Сипнет через эту и другую облачную АТС так и не добился: как-то влияет почему-то, видимо, дневная нагрузка. Хотя при этом внутри Сипнет при вызове напрямую с необлачного устройства – проблем нет.

Экспериментирую/настраиваю параллельно 2 решения несвязанно друг с другом. Изучаю: где стабильнее получается консолидировать входящие и принимать на Sipnet. Второе решение = LV, там раньше начал. В логах talk37 пока всего поля экспериментов может не быть – часть наблюдений с LV.
Отключаю передачу АОН. Соответственно, номер на Сипнет приходит Сипнетовский. Но как-то Сипнет в часы дневных пиковых нагрузок просекает и учитывает приоритезацизцию (предположение): если вызов был непростой, а каким-то из способов инициирован посредством другого транзитного SIP-сервиса (хоть просто набор, хоть переадресация/передача вызова и тп) – днём периодически возвращается 486 или 408 код. Возможно, (предположение) что-то где-то кто-то с кем-то несовсем по SIP-стандартам в какие-то моменты начинает взаимодействовать в части телефонной сигнализации: количество ОК-ев и периодичность и тп.

А если простой вызов внутри Сипнет с устройства на устройство без дополнительных звеньев вызова (без облачных АТС), то проблем нет, как не замечено также проблем при звонках с Сипнет на ТфОП.
Эксперименты проводятся неспешно несколько дней и по мере наличия времени.

OffTop/ Мде. Ни слова по сути решения поставленной технической задачи, зато пост “дартаньяна” в заборных традициях.

Demon, Вам большое спасибо, к Вам и Вашему сервису в любом случае никаких претензий.
Пока эксперименты не все необходимые проведены – как выше написал: неспешно.
Учитывая, что разными способами через LV – периодически днём наблюдается та же проблемка, дело вероятно в Sipnet.
Также через Pbxes простой переадресацией (передачу вызова из одной сети с инициализацией транзитного вызова в другую там не придумал пока как сделать) проверял.