 распределить 150-200 номеров по 4м направлениям,  georgy.goshin, 21-Апр-11, 02:05 [смотреть все]Здравствуйте!Есть Cisco 1751, котороый работает между E1 и voip server. Работает замечательно. Теперь надо добавить маршрутизацию звонков. Задача - есть примерно 150 телефонных номеров, звонки на которые поступают из города по каналу Е1 на Cisco, номре не в серии, все в разнобой. Есть asterisk, на который пойдет часть номеров, есть еще 3 таких же Cisco, через которые я планирую подключить 3 станции. Вопрос - как распределить звонки, учитывая, что номера одиночные, т.е. есть таблица, в которой написано, что номер 8810906 на такой то IP, 6500200 - на другой и т.д. Какие есть варианты решения? Спасибо!
|
- распределить 150-200 номеров по 4м направлениям, Myxa, 09:06 , 21-Апр-11 (1)
> Какие есть варианты решения?А, собственно, какие они могут быть?
Диал-пиры, по возможности с регулярными выражениями, дабы сократить их количество.
- распределить 150-200 номеров по 4м направлениям, eek, 09:18 , 21-Апр-11 (2)
>> Какие есть варианты решения?
> А, собственно, какие они могут быть?Еще можно весь трафик сливать на астериск и разруливать там.
- распределить 150-200 номеров по 4м направлениям, georgy.goshin, 09:47 , 21-Апр-11 (4)
>>> Какие есть варианты решения?
>> А, собственно, какие они могут быть?
> Еще можно весь трафик сливать на астериск и разруливать там.Через тот астериск траффик пускать не желательно поскольку это купленное допиленное до multi tenant решение, но без поддержки sip trunk. новый заводить тоже не охота, у 1751 же должно хватить и проца и памяти, что бы всю эту работу выполнить, вопрос только в конфиге...
- распределить 150-200 номеров по 4м направлениям, eek, 10:43 , 21-Апр-11 (5)
> что бы всю эту работу выполнить, вопрос только в конфиге...Проблема не в конфиге. Проблема в дизайне. Если с номерным планом бардак, то от кучи пиров вы никуда не денетесь, а значит нагрузка на проц. Рабочим решением, можно считать пробу нагрузить задачей железо, если не потянет - тогда думать. Номера думаю блоками давали, значит будет не 200, а штук 30-50 пиров с этим уже можно жить. На самом деле, учитывать нужно не только количество пиров, но и количество лукапов в еденицу времени, что в свою очередь зависит от объема голосового траффика. А 200 номеров это совсем маленький трафик.
- распределить 150-200 номеров по 4м направлениям, georgy.goshin, 12:29 , 21-Апр-11 (6)
> Проблема не в конфиге. Проблема в дизайне. Если с номерным планом бардак,
> то от кучи пиров вы никуда не денетесь, а значит нагрузка
> на проц. Рабочим решением, можно считать пробу нагрузить задачей железо, если
> не потянет - тогда думать.
> Номера думаю блоками давали, значит будет не 200, а штук 30-50 пиров
> с этим уже можно жить. На самом деле, учитывать нужно не
> только количество пиров, но и количество лукапов в еденицу времени, что
> в свою очередь зависит от объема голосового траффика. А 200 номеров
> это совсем маленький трафик.при чем тут бардак то? номера действительно одиночные. у нас в стране операторы обязаны отдавать номера, если клиент уходит к другому оператору, вы тоже когда-нибудь до этого дорастете. примерно 200 - это одиночные номера, плюс 4-5 серий по 100 номеров и серия 1000 номерво, но она пока что малоиспользуется
- распределить 150-200 номеров по 4м направлениям, georgy.goshin, 09:44 , 21-Апр-11 (3)
>> Какие есть варианты решения?
> А, собственно, какие они могут быть?
> Диал-пиры, по возможности с регулярными выражениями, дабы сократить их количество.Я думал, что можно было бы на входе странслировать номера с 4мя префиксами и потом сделать 4 dial-peer, однако voice translation-rule содержит только 15 правил, а как то по другому можно странслировать номера?
Это было бы удобнее, точнее нагляднее, тогда весь "рутинг" задавался бы в одном месте конфига, иначе получится 200 dial-peer :(
- распределить 150-200 номеров по 4м направлениям, mdenisov, 15:51 , 27-Апр-11 (7)
Единственно верным решением в данном случае будет написание стаи пиров. Не нужно переживать за процессор - 200 пиров это не то количество чтобы серьезно нагрузить процессор, для этого нужны запредельные CAPS. Из минусов - 1 пир требует примерно 6 килобайт памяти, ну и повышение PDD на долю секунды, которым скорее всего можно пренебречь. Не городите трансляции, они как раз процессор больше нагрузят.
|
Версия для распечатки
