Смысл событий телефонии, полученных через ROM-Asterisk заключается в их последующей обработке в 1С исходя из бизнес-логики конкретной компании.
Но, обработка может занимать продолжительное время, что приводит к разрыву соединения по инициативе Asterisk. Что же делать в таких случаях?
Проблема
Например, кроме определения клиента и контактного лица по номеру телефона, часто выполняется сбор разнообразной аналитической информации — заказы, счета, продажи, сделки, взаиморасчеты и т.д.
При этом, запросы могут выполняться достаточно продолжительное время. Все это время пользовательский сеанс 1С «занят» и не может принимать новые события от сервера Asterisk.
Один из таких случаев уже обсуждался в одной из веток Форума
ROM-Asterisk имеет буфер приема, который может частично сглаживать такое поведение сеанса 1С. Но, любой буфер имеет предел и в конечном итоге, сервер Asterisk вполне резонно разорвет соединение с клиентом, который длительное время не отвечает.
Лучше никогда, чем поздно
Один из принципов телефонии: «Лучше никогда, чем поздно». Поясним этот принцип на конкретном примере…
Допустим, бизнес-логика обработки события входящего звонка сеансом 1С занимает 1 минуту. Все это время сеанс 1С «занят» вычислениями, а через минуту «освободился» и готов «разгребать» события, накопившиеся за минуту. Но, возникает вопрос — «А нужны ли нам эти события?».
Звонок может все еще продолжаться, а мог уже давно завершиться за это время. Есть ли в них смысл? На мой взгляд, смысла в устаревших событиях нет. AMI нужен для отслеживания актуальных событий, а не истории. Для истории есть CDR.
Решение
По-хорошему, нужно стараться не допускать такой длительной обработки. Что делать, если же это невозможно?
Можно увеличить значение параметра writetimeout пользователя AMI. Этот параметр отвечает за таймаут записи события в клиентское соединение. Указывается он в миллисекундах и по умолчанию равен 100 или 0,1 секунды. Например, для увеличения таймаута до 30 секунд, установите значение
1 |
writetimeout=30000 |
Хотя, исходя из принципа «Лучше никогда, чем поздно», рассмотренного выше, правильнее будет отключить чтение событий телефонии на период длительного запроса 1С. В этом случае, клиентское соединение разорвано не будет. По окончании длительного запроса, можно снова включить чтение событий.
1 2 3 4 5 6 7 8 |
// отключаем чтение событий перед длительным запросом Телефония.РежимПрослушивания(0); // длительный запрос ПолучитьПолноеДосьеКонтрагента(); // включаем чтение событий телефонии Телефония.РежимПрослушивания(1); |
Итог
В этой статье мы постарались описать проблему и показали возможные пути решения. Однако, в каждом конкретном случае методика решения может быть разной.
Как показывает практика, в 99% случаев разрыв соединения происходит по инициативе сервера Asterisk, а не внешней компоненты ROM-Asterisk. Библиотека лишь честно реагирует на событие разрыва связи.
P.S.
Если у вас другой случай — задайте вопрос на Форуме, он именно для этого и создан.