Большое количество правил в маршрутизации вызовов

[electrod]

Всем привет.
Снова обращаюсь к вам за помощью. буду признателен если поможете.
У нас используется avaya s8400 (1000 внутр. номеров), так же внедряем астериск.
для постепенного перевода на астериск требуется каждый номер с авайа заворачивать в астериск.
В итоге. по моим подсчетам это будет порядка 1000 правил в маршрутизации вызовов в Avaya.
Подскажите насколько критично для АТС такое количество записей? Нет ли каких-то ограничений на количество правил маршрутизации.
Не будут ли медленно маршрутизироваться вызовы с таким количеством правил?
Подскажите пожалуйста, может кто-то сталкивался с таким на практике.
Спасибо.

[dsh]

Заменить Avaya(1000 абонентов) на астер это я даже не знаю как назвать, ну раз уж решили почитайте вначале про астер сможет ли он вообще прокачать через себя такое количество вызовов от 1000 абонентов, у Вас скорее астериск загнется от такого временного решения.

[electrod]

Именно внедрением астериска занимается другой человек. Утверждают что проблем не будет. Единственное что знаю будет несколько астерисков ( чтобы разделить нагрузку), соединенными транками с авайа, а так же между собой будут общаться.

Мне поставлена задача обеспечить маршрутизацию вызовов с avaya в транк астериска. ( транк есть).
Проблема в необходимости постепенного переноса номеров.
Если бы сразу все заворачивать тут проще, все номера завернуть в астер в маршрутизации и все.

Но стоит задача постепенно переносить марштрутизацию номеров в астер.
Вижу только одно решение - маршрутизировать каждый вызов отдельно, что чревато 1000 правилами. Вот и спрашиваю потянет ли столько авайа. нет ли ограничений ?
Может быть есть более правильный вариант и я изобретаю костыльный велосипед ?

[dsh]

Что бы не плодить астериски для разделения нагрузки и что бы было бесплатно я бы поставил например freeswitch набил бы конфиг и в один прекрасный момент когда все готово переключился на него, но с учетом такого количества абонентов проблемы почти всегда возникают. Для вас совет переносите группами например 1ххх или 2ххх или разбейте еще как-то.

[Pterodahtil]

если говорить точно, то нужно смотреть капасити по S8400 и версии СМ.
Был переезд порядка 800 абонентов. Переезжающему абоненту ставили CF, отключали телефон, ставили новый. В принципе - работает.

[electrod]

Спасибо за ответы.
Конфиг capacity s8400 и CM постараюсь на выходных скинуть или в понедельник.
Простите, я немного преувеличил с количеством абонентов по capacity station =453.( как я понял это внутр. номера) . Это конечно полегче, но сути вопроса не меняет ((
К сожалению перенести группами нельзя ( 1хх, 2хх и т.д.) т.к. переносятся филиалы поочередно, а номера в перемешку(( Менять номера под формат один филиал одну группа номеров не хотят.

Соотвестсвенно если переносить в разнобой, вижу два варианта.
1. создание для каждого номера отдельной записи в таблице маршрутизации ( тут надо смотреть ограничение паттернов и т.д.)
2. делать на номере cv , далее в vdn->vector->route to номер в астериске.
тут так же надо смотреть количество векторов и вдн.
подскажите, других вариантов нет?

[Pterodahtil]

Соотвестсвенно если переносить в разнобой, вижу два варианта.
1. создание для каждого номера отдельной записи в таблице маршрутизации ( тут надо смотреть ограничение паттернов и т.д.)
2. делать на номере cv , далее в vdn->vector->route to номер в астериске.
тут так же надо смотреть количество векторов и вдн.
подскажите, других вариантов нет?

1. станция сначала смотрит локальные station, а потом уже запись в UDP
2. вообще не понял, зачем? Или вам перед трансфером надо сообщение проговорить? Для вашей схему есть механизм cov rem

[electrod]

Добрый день.
1. Да, атс сначала смотрит локальные stattion.
Но ведь у нас avaya в дальнейшем будет просто как транзит между E1 и астериском. Номера будут переводиться на астер поочереди ( нумерация вразнобой (!) ).
Номер удаляем с авайа, затем прописываю в таблице маршрутизации что номер к примеру 331 находится в транке астериска .
А так как нумерация разная нельзя завернуть номера 3xx в транк астера полностью.
К примеру: 300 - авайа, 301 астер, 302,3033,304 авайа, 305,309 астер и т.д.
И вот тут я не вижу никакого варианта кроме правил маршрутизации для каждого.

2. Исходя из пункта 1, номера для авайа будут не локальными station , а CV на не локальные номера нельзя, только костыль с vector а оттуда уже на любой номер.

. У нас 454 номера, из них 323 dect , в которых номер транка меняется в карточке station. С ними проблем нет.
А вот менее 130 номеров аналоги. И их нельзя в транк завернуть, только правилами маршрутизации.
так ?
Прикладываю выгрузку disp cap.

[Pterodahtil]

К примеру: 300 - авайа, 301 астер, 302,3033,304 авайа, 305,309 астер и т.д.
И вот тут я не вижу никакого варианта кроме правил маршрутизации для каждого.

опять же, не понял проблему
в dial pla a - 3xx - ext
в change uniform-dialplan 3 прописываем весь диапазон 3 как aar
телефон снимается с рабочего места, в станции удаляются все записи связанные с ним. С этого момента он стал не локальным, а udp

2. Исходя из пункта 1, номера для авайа будут не локальными station , а CV на не локальные номера нельзя, только костыль с vector а оттуда уже на любой номер.

CV это что у нас такое?

[DarkHeavy]

Если кто-то вас хочет перевести с Avaya на Астерикс, то попахивает кидаловом и коррупцией. Это всё равно что пересесть с Мерседеса на Запарожец.

[Pterodahtil]

Если кто-то вас хочет перевести с Avaya на Астерикс, то попахивает кидаловом и коррупцией. Это всё равно что пересесть с Мерседеса на Запарожец.

Я хоть и работаю с Avaya, и считаю астериск несовсемстанцией, но ваше заявление не поддержу. Астериск может намного больше avaya! Разница в том, что за avaya стоит корпорация, а зв астериском конкретный инженер. Кто раньше уволится - вопрос

[dsh]

Согласен полностью с DarkHeavy, добавил бы еще развод на бабки, а вот интересны какие мотивы побудили на такое решение, чем Avaya то не угодила?

[electrod]

Как я понял, Астериск более гибкий и функциональный. На нем можно относительно бесплатно развернуть всякие вещи, которые в авайа стоят денег.
именно из-за необходимого бесплатного функционала переходят.
с астериском особо дела не имел, но авайа служит уже несколько лет и все надежно.

2 Pterodahtil
"CV" ,- это я опечатался, имелось ввиду CP ( coverage path)
Но вы подкинули интересную идею с dial plan и uniform dial plan.
Если я правильно понял, то
у меня сейчас в dial a
3xx ext
в uniform
31x ext
32x ext
............
Я прописываю в uniform 31 aar , настраиваю всё.
И в итоге при звонке на номер 311 к примеру авайа его ищет в локальных станциях, если находит вызов уходит по авайа.
Если не находит, то ищет в aar , и затем переходит в транк и в астер.
так ?
Попробую сегодня-завтра глянуть и напишу.

[electrod]

Добрый день.

Только сейчас смог вернуться к этому вопросу.
Pterodahtil, вы написали что
в dial pla a пишем 3xx - ext
в change uniform-dialplan 3 прописываем 3хх как aar.
После этого локальные номера для станции будут искаться в первую очередь в локально в атс. а если что-то не найдется, то уже пойдет в uniform-dialplan , далее в транк астериска.
я правильно понимаю?
Но есть маленький нюанс.
В dialplan parameters указано что UDP extension search order = udp table first.
В документации указано , что
===============================
● Если значение поля UDP Extension Search Order на
экране Dial Plan Parameters установлено как
udp-table-first, Communication Manager в первую
очередь проверяет на наличие совпадений таблицу
UDP. Если совпадений нет, Communication Manager
проверяет локальный сервер.
===============================
Не значит ли это то, что если мы пропишем в dial pla a - 3xx - ext , а в change uniform-dialplan 3 - 3хх как aar, то АТС будет все номера 3хх заворачивать в aar и далее в транк астера ?
мне же нужно чтобы он только определенные номера из 3xx заворачивал в астер остальное на авайа.

Извините если я пишу что-то не так. просто не сильно разбираюсь в авайа, но учусь.
надеюсь на вашу помощь

[Pterodahtil]

с такими настройками именно так, сначала udp. Надо менять на local-extensions-first

[electrod]

Спасибо за ответ.
Подскажите пожалуйста а может ли как то повлиять на работоспособность изменение этого параметра на local-extensions-first.
На горячую без уверенности менять не хотелось бы, люди работают.
вот прикладываю на всякий случай листинг dial pla a и uniform-dialplan

• display uniform-dialplan 0
  Matching Insert Node Matching Insert Node
  Pattern Len Del Digits Net Conv Num Pattern Len Del Digits Net Conv Num
  1 3 0 ext n 53 3 0 ext n
  1 4 0 aar n 54 3 0 ext n
  2 3 0 ext n 58 3 0 ext n
  31 3 0 ext n 6 3 0 ext n
  32 3 0 ext n 80 3 0 aar n
  33 3 0 ext n 81 3 0 aar n
  34 3 0 ext n 82 3 0 aar n
  35 3 0 ext n 85 3 0 ext n
  36 3 0 ext n 86 3 0 aar n
  37 3 0 aar n 87 3 0 ext n
  38 3 0 aar n 88 3 0 aar n
  39 3 0 aar n 89 3 0 aar n
  4 3 0 ext n n
  50 3 0 aar n n
  51 3 0 aar n n
  52 3 0 aar n n

• display dialplan analysis
  String Length Type String Length Type String Length Type
  1 3 ext 81 3 ext
  1 4 aar 82 3 ext
  2 3 ext 85 3 ext
  3 3 ext 86 3 ext
  4 3 ext 87 3 ext
  5 3 ext 88 3 ext
  6 3 ext 89 3 ext
  7 3 dac 9 1 fac
  73 3 ext * 3 fac
  74 3 ext # 3 fac
  75 3 ext
  76 3 ext
  77 3 ext
  78 3 ext
  80 3 ext