Резервный SIP Trunk на Входящие и Исходящие звонки

[vladrnd]

Есть интересная тема. Имеется 2 SIP транка от одного провайдера, но с разными доменами типа sip1.au.main.net, sip2.uk.main.net . Задумка такая, если лежит один транк то все входящие и исходящие звонки должны маршрутизироваться на резервный канал, и обратно. С иходящими проблемы нет : настроены 2 ARS (Master/Slave внутр икоторых указан роутинг друг на друга). в SIP URI каждого транка прописаны идентичные входящие номера, но с разными Incoming/Outgoing Group). Они канал падал, исходящие маршрутизировались через второго. А вот со входящими звонками это нечто. Никакие входящие звонки не доступны на обоих транках (хотя они дублируют друг друга набором SIP URI номеров). ICR все настроено. Есть решение как эту схему корректно настроить и Incoming метрики чо б были.

[Pterodahtil]

Никакие входящие звонки не доступны на обоих транках (хотя они дублируют друг друга набором SIP URI номеров). ICR все настроено. Есть решение как эту схему корректно настроить и Incoming метрики чо б были.

где конкретика?
Два разных транка, один упал - второй работает. Где данные System Status и Monitor?
Сдаётся мне, при падении одного транка провайдер банально лочит вашу учётку.

[vladrnd]

Никакие входящие звонки не доступны на обоих транках (хотя они дублируют друг друга набором SIP URI номеров). ICR все настроено. Есть решение как эту схему корректно настроить и Incoming метрики чо б были.

где конкретика?
Два разных транка, один упал - второй работает. Где данные Sustem Status и Monitor?
Сдаётся мне, при падении одного транка провайдер банально лочит вашу учётку.

какие данные если входящих звонков нет. саму желаемую схему построения я описал (вообще можно такое сделать), реализация хромает.
оба SIP канала должны быть активные. в момент одновременной их активности ломаются входящие звонки (транки с разными локациями, но одного провайдера). ломfем один транк (не важно какой) - входящие нормализуются. непонятно как роутятся звонки по транкам у провайдера. провайдер DIDLogic.

[Pterodahtil]

Никакие входящие звонки не доступны на обоих транках (хотя они дублируют друг друга набором SIP URI номеров). ICR все настроено. Есть решение как эту схему корректно настроить и Incoming метрики чо б были.

где конкретика?
Два разных транка, один упал - второй работает. Где данные System Status и Monitor?
Сдаётся мне, при падении одного транка провайдер банально лочит вашу учётку.

какие данные если входящих звонков нет. саму желаемую схему построения я описал (вообще можно такое сделать), реализация хромает.
оба SIP канала должны быть активные. в момент одновременной их активности ломаются входящие звонки (транки с разными локациями, но одного провайдера). ломfем один транк (не важно какой) - входящие нормализуются. непонятно как роутятся звонки по транкам у провайдера. провайдер DIDLogic.

бред какой-то из разряда "у меня не работает - почините"
у провайдера проблемы - но виновата avaya.

[dsh]

Тут вопрос скорее гипотетически типа, а я вот хочу так настроить Вам провайдер как номера подает в каждый транк свои номера? Если у вас упал один транк так и входящих не будет по номерам этого транка, можете конечно пнуть провайдера, что бы у себя настроил, но думаю будете им посланы Провайдер направляет номера в те транки которые договоритесь и не обязан думать о резервировании, ну это их мнение

[vladrnd]

у меня этих транков от 1 до 7. все разные локаций. На АТС настроил пока 2 транка разных локаций. Прописал на каждом идентичные номера SIP URI. Работает все в норме. Настроил 2 ARS на разные транки (типо primary/slave, гоняю таким образом исходящие). Но темная сторона осталась со входящими.
Узнать бы как провайдер маршрутизирует звонки в эти транки, по каким приоритетам, и т.п. так как работает немного все странно. Какой добавил последний транк на АТС тот и является активным на данный момент. Но вот почему так происходит. Моя перепись с провайдером ничем не закончилась положительно. Никакого ответа я не получил. Тем не менее вопрос остается открытым.

При падении одного из транков : резервный работает. Но не сразу.