Priority — Priority to use (requires Exten and Context)
Насколько я помню, так было всегда — еще с версии 1.4 и вряд ли это изменится.
Упрощенно, Priority — это номер строки в описании экстена. А сам экстен не располагается в вакууме — ему нужен контекст. Примере ниже 1,2,4 — это и есть Priority
Пример с Asterisk-Wiki
Within each extension, there must be one or more priorities. A priority is simply a sequence number. The first priority on an extension is executed first. When it finishes, the second priority is executed, and so forth.
Подумайте, какой смысл в Priority, если нет ни экстена, ни контекста? Что приоритезировать? Вы же отдаете управление в апликуху, а не в диалплан…
Все примеры из текущей статьи тестировалась на Asterisk 10.9.0.
Кроме того, используются в реальном проекте.
Версии Asterisk — начиная с 1.8 и заканчивая 13.
Алексей, у вас же не совсем Астериск, у вас его форк — Аскозия. Вполне возможно, что разработчики Аскозии что-то там подправили и просто тихо игнорируют параметр, в котором нет смысла. А вот Астериск выдаст ошибку и будет прав.
К сожалению, slave не доступен из Master-а как span 5-8. Из консоли Master-a вы никак не достучитесь к устройствам Slave. Чтобы работать со Slave-ом нужно поднимать отдельное соединение также, как вы это сделали с Master-ом.
Вижу здесь два выхода:
1) Физически подключить еще один сетевой кабель к eth1 (это поможет если у вас только 2 GSM-модуля)
2) Посадить внутрь прошивки свой php-скрипт
Наверное, здесь следует более детально пояснить, как работает штатный скрипт HTTP -> SMS, на который вы сделали ссылку…
1) Скрипт в качестве параметра принимает имя GSM, например gsm-2.1. По первой цифре он определяет board к которому нужно выполнить запрос.
2) Если board = 1, тогда запрос просто идет в консоль. Также как у вас. А если board >1 тогда скрипт поднимает дополнительное соединение через внутренний интерфейс кластера, который недоступен снаружи.
Т.е. span всегда находится в диапазоне 1-4. Board-ы автономны и управляются через внутренний сетевой интерфейс кластера.
В одном из проектов, мы сделали именно так, как я описал — всадили свой скрипт в прошивку, который позволяет выполнить любую CLI-команду.
Ибо мало просто отправлять SMS-ки, хочется видеть:
1) общую инфу о статусе каналов (gsm show spans)
2) детализацию каждого span-a (gsm show span 1-4)
3) Отправлять/получать USSD для контроля баланса (gsm send ussd)
ИМХО, без внесения именений в прошивку невозможно сделать какую-то универсальную вещь, которая не будет зависеть от кол-ва Board-ов. Печалька
У OpenVox есть такое понятие как Master/Slave по отношению к модулям из 4-х GSM. Что-то типа кластера.
Для Master-a ваш код работать будет. А как вы предлагаете работать со Slave-модулями?
Типовых с автоматическим режимом блокировок — великое множество. Только относительно новые конфигурации имеют управляемый режим блокировок.
Зачем народ с файловой БД переходит на SQL? Потому что, надоело лицезреть окошко блокировок. А в этом случае, они как были, так и останутся.
Поэтому, для конфигураций с автоматическим режимом блокировок нужно с файловой БД уходить в IBM DB2 Express (фришный). DB2 спокойно вытянет 20-30 юзеров.
Во многих типовых конфигурациях используется «Автоматический» режим блокировки. А это значит, что после внедрения Postgres SQL вы получите вид блокировки «на уровне ТАБЛИЦ». Вот пруф
То есть, тот же файловый режим только в профиль. Например, переводя на Postgres конфигурацию УТ-10.х вы получите расход бюджета и практически нулевой профит
Статья толковая. Мне лично, семинар был бы интересен. Но, вебинар удобнее, дешевле по времени и затратам на организацию.
Подумайте над его проведением. Как минимум сможете оценить фидбэк.
В принципе, можно и .Net использовать, можно и COM-обертку написать, не напрямую конечно, но способы есть к 1С их прикрутить. По большому счету, для реализации обмена с AMI кроме сокета особо ничего и не нужно. Все остальное легко реализуется средствами 1С.
Есть. Но, как написано выше, 1С хочет «особенных» библиотек для интеграции с собой родимой. 1С даже название для таких dll придумал — «внешняя компонента»
Да, только лучше. Появляется у сотрудника, на которого пришел звонок. Например, если секретаря нет на месте. Если все же звонок взял секретарь и потом переключил на специалиста, то в 1С создается сооттветствующая цепочка связанных событий
Как вы правильно заметили, компонента выполняется на клиенте. Она и не должна обрабатывать разделенный доступ — это делает Asterisk AMI. Компонента — это клиент AMI.
Насчет 200+ клиентов, то при большом количестве подключений, сам AMI начинает глючить — обрыв соединений, задержки. Лечится с помощью AMI-proxy.
У нас это применяется так:
1) При входящем звонке идет поиск клиента в базе 1С по номеру телефона, затем автоматически создается документ «Событие» с признаком «Входящий звонок»
2) Для исходящих звонков из различных форм 1С «click-to-call»
3) Автоматически создается документ «Событие» при исходящем звонке
4) Для хранения ссылок на файлы записи разговора с привязкой к документу «Событие»
5) Для прослушивания разговора «в один клик»
Еще, используется привязка клиента к его менеджеру для прямой маршрутизации клиента на своего менеджера. Это напрямую к теме не относится, но если интересно, то расскажу.
Он есть?
Вот цитата:
Насколько я помню, так было всегда — еще с версии 1.4 и вряд ли это изменится.
Упрощенно, Priority — это номер строки в описании экстена. А сам экстен не располагается в вакууме — ему нужен контекст. Примере ниже 1,2,4 — это и есть Priority
exten => 6123,1,do something
exten => 6123,2,do something else
exten => 6123,4,do something different
Подумайте, какой смысл в Priority, если нет ни экстена, ни контекста? Что приоритезировать? Вы же отдаете управление в апликуху, а не в диалплан…
Алексей, у вас же не совсем Астериск, у вас его форк — Аскозия. Вполне возможно, что разработчики Аскозии что-то там подправили и просто тихо игнорируют параметр, в котором нет смысла. А вот Астериск выдаст ошибку и будет прав.
Параметр Priority используется только вместе с Context, Exten
Команда Originate ответит вам «extension not found»
Channel: SIP/104
Application: PickupChan
Data: SIP/104-0000003c
Priority: 1
Callerid: 104
Variable: SIPADDHEADER=«Call-Info:\;answer-after=0»
Вижу здесь два выхода:
1) Физически подключить еще один сетевой кабель к eth1 (это поможет если у вас только 2 GSM-модуля)
2) Посадить внутрь прошивки свой php-скрипт
Наверное, здесь следует более детально пояснить, как работает штатный скрипт HTTP -> SMS, на который вы сделали ссылку…
1) Скрипт в качестве параметра принимает имя GSM, например gsm-2.1. По первой цифре он определяет board к которому нужно выполнить запрос.
2) Если board = 1, тогда запрос просто идет в консоль. Также как у вас. А если board >1 тогда скрипт поднимает дополнительное соединение через внутренний интерфейс кластера, который недоступен снаружи.
Т.е. span всегда находится в диапазоне 1-4. Board-ы автономны и управляются через внутренний сетевой интерфейс кластера.
В одном из проектов, мы сделали именно так, как я описал — всадили свой скрипт в прошивку, который позволяет выполнить любую CLI-команду.
Ибо мало просто отправлять SMS-ки, хочется видеть:
1) общую инфу о статусе каналов (gsm show spans)
2) детализацию каждого span-a (gsm show span 1-4)
3) Отправлять/получать USSD для контроля баланса (gsm send ussd)
ИМХО, без внесения именений в прошивку невозможно сделать какую-то универсальную вещь, которая не будет зависеть от кол-ва Board-ов. Печалька
Для Master-a ваш код работать будет. А как вы предлагаете работать со Slave-модулями?
Зачем народ с файловой БД переходит на SQL? Потому что, надоело лицезреть окошко блокировок. А в этом случае, они как были, так и останутся.
Поэтому, для конфигураций с автоматическим режимом блокировок нужно с файловой БД уходить в IBM DB2 Express (фришный). DB2 спокойно вытянет 20-30 юзеров.
Во многих типовых конфигурациях используется «Автоматический» режим блокировки. А это значит, что после внедрения Postgres SQL вы получите вид блокировки «на уровне ТАБЛИЦ».
Вот пруф
То есть, тот же файловый режим только в профиль. Например, переводя на Postgres конфигурацию УТ-10.х вы получите расход бюджета и практически нулевой профит
Подумайте над его проведением. Как минимум сможете оценить фидбэк.
Насчет 200+ клиентов, то при большом количестве подключений, сам AMI начинает глючить — обрыв соединений, задержки. Лечится с помощью AMI-proxy.
1) При входящем звонке идет поиск клиента в базе 1С по номеру телефона, затем автоматически создается документ «Событие» с признаком «Входящий звонок»
2) Для исходящих звонков из различных форм 1С «click-to-call»
3) Автоматически создается документ «Событие» при исходящем звонке
4) Для хранения ссылок на файлы записи разговора с привязкой к документу «Событие»
5) Для прослушивания разговора «в один клик»
Еще, используется привязка клиента к его менеджеру для прямой маршрутизации клиента на своего менеджера. Это напрямую к теме не относится, но если интересно, то расскажу.