2 SIP провайдера, Звонки через 2 провайдеров Опции

[Sergo]

Добрый день. Как реализовать звонки сразу через 2 провайдера, не разделяя их на 2 группы. В одной СО 6 Voip линий, входящие с 2 провайдеров работают нормально. Есть возможность реализовать все через доп.префикс, нужно не на все внутренние номера, а на несколько (например факс).

[Sergo]

Если нет такого решения, вопрос тогда возникает такой. Для телефонов серии LIP (local и remote) по какому принципу выделяются каналы VOIP, сейчас из 8 каналов 2 выведены в 1 группу, получается выделяются только 6 каналов из 2 группы, если вывести из 6 еще несколько линий то для LIP остается мало линий. Как заставить работать на LIP все 8 каналов или все 6?

[harris]

Если нет такого решения, вопрос тогда возникает такой. Для телефонов серии LIP (local и remote) по какому принципу выделяются каналы VOIP, сейчас из 8 каналов 2 выведены в 1 группу, получается выделяются только 6 каналов из 2 группы, если вывести из 6 еще несколько линий то для LIP остается мало линий. Как заставить работать на LIP все 8 каналов или все 6?

1) Нет. Если 2 SIP провайдера, то требуется прописать 2 группы VOIP каналов (2 транка). К SIP провайдеру "привязываются" указанные в транке VOIP каналы.
2) Для поддержки IP-терминалов используются:
- VOIP-каналы той платы VOIB, которая указана для обслуживания Зоны Устройств (ПГМ395, VOIB Slot for RTP Relay)
- каждый канал указанной платы также может быть определен (или запрещен) для обслуживания IP-терминалов (ПГМ161, RTP Relay Use)
- каналы, разрешенные для обслуживания IP-терминалов, занимаются "по кругу", через 4 порта.

Т.е. если у Вас одна зона, то можно использовать все 8 каналов платы VOIB для поддержки терминалов (если канал не занят вызовом по SIP транку). Т.е. можно всем 8-ми каналом поставить разрешение RTP Relay Use =On.
Как то так.

[Alexey A. Astash...]

1) Нет. Если 2 SIP провайдера, то требуется прописать 2 группы VOIP каналов (2 транка). К SIP провайдеру "привязываются" указанные в транке VOIP каналы.

Очень плохо, что для каждого транка необходимо выделять определенное количество определенных каналов - эта идеология явно пришла с ipLDK.
не все ли равно какой канал платы обрабатывает RTP трафик и сигнализацию внутреннюю внешнюю? правильнее былобы: чтобы все прозрачно - вот 5 транков вот 24 канала, на 1й транк мы ставим 8 каналов, на 2й 20, а остальные 3 транка хоть по 24 канала.

существующая идеология мало того что создает сложности для производителя станции, это надо следить какой канал куда идет, под какой транк используется, может он для LIP телефонов заюзан итд. так еще и создает сложности для конечного потребителя...
Хотя конечно станция в целом не плохая.

[harris]

Очень плохо, что для каждого транка необходимо выделять определенное количество определенных каналов - эта идеология явно пришла с ipLDK.
не все ли равно какой канал платы обрабатывает RTP трафик и сигнализацию внутреннюю внешнюю? правильнее былобы: чтобы все прозрачно - вот 5 транков вот 24 канала, на 1й транк мы ставим 8 каналов, на 2й 20, а остальные 3 транка хоть по 24 канала.

существующая идеология мало того что создает сложности для производителя станции, это надо следить какой канал куда идет, под какой транк используется, может он для LIP телефонов заюзан итд. так еще и создает сложности для конечного потребителя...
Хотя конечно станция в целом не плохая.

Алексей! Ну мы уже говорили с Вами на эту тему. Сделано так, как сделано. И вряд-ли сейчас возможно поменять принятую идеалогию и структуру софта.
К SIP провайдеру привязываются VOIP каналы, т.е. ресурсы. Тот вариант, который предлагаете Вы, вероятно, тоже многих пользователей не устроил бы. Что толку, что в транк отписано 24 канала, а все ресурсы оказываются занятыми вызовами совсем с других направлений (другими транками).

[Alexey A. Astash...]

Алексей! Ну мы уже говорили с Вами на эту тему. Сделано так, как сделано. И вряд-ли сейчас возможно поменять принятую идеалогию и структуру софта.
К SIP провайдеру привязываются VOIP каналы, т.е. ресурсы. Тот вариант, который предлагаете Вы, вероятно, тоже многих пользователей не устроил бы. Что толку, что в транк отписано 24 канала, а все ресурсы оказываются занятыми вызовами совсем с других направлений (другими транками).

Толк какраз есть - рассмотреть вариант расширения этих самых VOIP каналов если их не хватает. За что я люблю свой iPECS - это за, то что я не парюсь с выбором сервера для большого количесва одновременных звонков. я знаю, что если я возьму плату на 24 канала - все 24 канала одновременно будут работать идеально, если я добавлю еще 48 каналов то все - 64 канала будут работать идеально.

Тем не менее тут возникает резонный вопрос, что мне толку от N каналов (где N например - 8) если я 5 отправил на сетевые звонки, а 3 отправли на междугородние и вот сейчас мне потребовалось 8 междугородних каналов, а завтра мне потребуется 8 сетевых звонков одновременно...
Это не удобно привязвать ресурсы (транки) к конретным каналам.
Но если вопрос касаемо ipLDK можно и не открывать потому, что станция в принципе имеет идеологию другую да и снимаются производства. А вот касательно iPECS-МG какраз еще все в переди. Тем более если я правильно понимаю такая идеология уже сделана в LIK, ну так к версии 2.5 осталось перенести ее в MG и все

[harris]

Толк какраз есть - рассмотреть вариант расширения этих самых VOIP каналов если их не хватает. За что я люблю свой iPECS - это за, то что я не парюсь с выбором сервера для большого количесва одновременных звонков. я знаю, что если я возьму плату на 24 канала - все 24 канала одновременно будут работать идеально, если я добавлю еще 48 каналов то все - 64 канала будут работать идеально.

Тем не менее тут возникает резонный вопрос, что мне толку от N каналов (где N например - 8) если я 5 отправил на сетевые звонки, а 3 отправли на междугородние и вот сейчас мне потребовалось 8 междугородних каналов, а завтра мне потребуется 8 сетевых звонков одновременно...
Это не удобно привязвать ресурсы (транки) к конретным каналам.
Но если вопрос касаемо ipLDK можно и не открывать потому, что станция в принципе имеет идеологию другую да и снимаются производства. А вот касательно iPECS-МG какраз еще все в переди. Тем более если я правильно понимаю такая идеология уже сделана в LIK, ну так к версии 2.5 осталось перенести ее в MG и все

Структура MG как раз соотвествует ipLDK !! Только управление платами сделано по IP, а не через HDLC.
Алексей! По поводу LIK, Вы заблуждаетесь. Относительно VOIP каналов в LIK точно такая же идеология, каналы тоже привязываются к SIP провайдеру. Т.е. для каждого SIP провайдера - свой транк.