26:23 _"все что вы напишите в extensions _override_ freepbx.conf наложится поверх extension_additional.conf"_ - тут желательно обратить внимание на слово *"наложится"*, а не "заменится". Т.к. можете получить неправильно работающий алгоритм если количество строк в контексте в файле override будет меньше, чем в исходном контексте файла extension_additional.conf.
28:07 _"У нас есть скрипт который делает отчёт, ... Все транки, маршруты"_ - интересно взглянуть на подобный отчёт. Почему-то я сомневаюсь, что мы увидим понятную схему входящих и исходящих звонков,. IVR, запрещённые направления и транки для каждого внутреннего номера (групп). _Я давно (полуавтоматически ;-)) делаю понятный отчёт клиентам об алгоритме работы АТС (Asterisk, Panasonic, LG, Samsung и т.п.)_
51:27 "я всегда добавляю сюда префиксы (в исходящий маршрут)" - можно иногда использовать, но я считаю это нерациональным. 1) Лучше сразу все входящие номера приводить к единой форме, например: а) российские номера к 8xxxxxxxxxx; б) международные - 810xxxxxx. (в т.ч. Казахстан, Абхазия, Южная Осетия). 2) Все префиксы при исходящей связи менять в соответствующих настройках транков. Почему так? Вариант-1. Например у нас три разных провайдера и каждый из них требует свой формат префикса: +7; 7; 8. В исходящих маршрутах вы прописывание последовательность занятия транков - сначала оператор1, затем оператор2, оператор3. Вы не сможете задать индивидуальные префиксы в при таком подходе. Вариант-2. Представьте, что у вас 100 абонентов и 10 транков. Если префиксы меняем в настройках транков - это всего 10 мест, где это потребуется делать. Если 100 абонентов мы разбили на 30 групп и для каждой создаём свой алгоритм исходящей связи (со своей последовательностью занятия транков), - нам придется 30 раз прописывать правила изменения префиксов.
26:23 _"все что вы напишите в extensions _override_ freepbx.conf наложится поверх extension_additional.conf"_ - тут желательно обратить внимание на слово *"наложится"*, а не "заменится". Т.к. можете получить неправильно работающий алгоритм если количество строк в контексте в файле override будет меньше, чем в исходном контексте файла extension_additional.conf.
28:07 _"У нас есть скрипт который делает отчёт, ... Все транки, маршруты"_ - интересно взглянуть на подобный отчёт. Почему-то я сомневаюсь, что мы увидим понятную схему входящих и исходящих звонков,. IVR, запрещённые направления и транки для каждого внутреннего номера (групп).
_Я давно (полуавтоматически ;-)) делаю понятный отчёт клиентам об алгоритме работы АТС (Asterisk, Panasonic, LG, Samsung и т.п.)_
51:27 "я всегда добавляю сюда префиксы (в исходящий маршрут)" - можно иногда использовать, но я считаю это нерациональным.
1) Лучше сразу все входящие номера приводить к единой форме, например:
а) российские номера к 8xxxxxxxxxx;
б) международные - 810xxxxxx. (в т.ч. Казахстан, Абхазия, Южная Осетия).
2) Все префиксы при исходящей связи менять в соответствующих настройках транков.
Почему так?
Вариант-1.
Например у нас три разных провайдера и каждый из них требует свой формат префикса: +7; 7; 8.
В исходящих маршрутах вы прописывание последовательность занятия транков - сначала оператор1, затем оператор2, оператор3.
Вы не сможете задать индивидуальные префиксы в при таком подходе.
Вариант-2.
Представьте, что у вас 100 абонентов и 10 транков. Если префиксы меняем в настройках транков - это всего 10 мест, где это потребуется делать.
Если 100 абонентов мы разбили на 30 групп и для каждой создаём свой алгоритм исходящей связи (со своей последовательностью занятия транков), - нам придется 30 раз прописывать правила изменения префиксов.
спасибо. интересно.
Интересно)))
а есть тоже самое, только без лишней болтовни на 1,5 часа?
вот бы еще файлики с командами были выложены цены небыло бы !!!
Ручками)
Если вы читаете лекцию или семинар, то не стоит одновременно отвечать на вопросы. Это сбивает и вас и зрителя с темы.
очень не профессионально конечно ничего не получается с первого раза для конторы которая на этом зарабатывает ну как то стыдно прям