Я создавал настольное приложение WinForms с использованием С#, которое взаимодействует с Asterisk с использованием Aster.NET (ранее/разветвленного от Asterisk.NET). У нас серьезные проблемы с надежной идентификацией и отслеживанием вызовов, связанных с отдельным добавочным номером/пользователем.
Проблема, с которой мы сталкиваемся, связана с непредсказуемым/нечетким характером событий, запускаемых/инициируемых Asterisk, причем они сильно варьируются в зависимости от того, как маршрутизируется вызов до того, как он попадет на добавочный номер.
Например, последовательность/формат событий различаются, когда: вызов попадает в IVR до того, как его переводят вслепую; если вызов поступает в IVR до того, как он будет переведен; если вызов идет прямо на добавочный номер пользователя.
Этому также препятствует то, что Asterisk отслеживает каждую сторону вызова, используя разные уникальные идентификаторы (например, входящая сторона вызова имеет другой UID, чем полученная сторона вызова). Хотя нам удалось учесть это в (впоследствии уродливом!) коде, мы все еще сталкиваемся с проблемами учета различных путей маршрутизации, которые может пройти вызов.
Таким образом, я ищу любые советы о том, как мы можем сделать следующее:
- Reliably identify an incoming call to a user's extension
- We need to be able to identify the extension being called and the originating caller ID (after either a blind or attended transfer and direct call from external)
- Надежно отслеживайте уникальный идентификатор входящего звонка, поскольку он используется для ссылки на запись звонка.
- Reliably identify an outgoing call from a user's extension
- With the same caveats as above in mind
На данный момент у нас есть чрезвычайно сложная цепочка обработчиков событий, которые работают по-разному в зависимости от «текущего состояния» приложения.
Приведу один пример: если мы обнаруживаем NewStateEvent с ChannelState равным 6 ("Up"), мы проверяем, есть ли текущий вызов в процессе и совпадают ли UID, и если да, то текущий на звонок ответили. Если UID не совпадают, но совпадают другие факторы (например, канал, connectlinenum и т. д.), то мы рассматриваем это как «другую сторону» вызова (т. е. принимающую или входящую сторону).
Я не уверен, связана ли проблема с API или с AMI, но в любом случае это вызывает у нас настоящую головную боль.
Любые советы очень ценятся.