Победили проблему.
Итак:
1. К событию не прикреплялся ID звонка, так как время создания события при звонке через Панель телефонии составляло около 3-4 секунд
1.1 Оптимизировали определение кода города, создав временную таблицу кодов городов при первом обращении и поместили её в менеджер времемнных таблиц
1.2. Поиск записи в базу MySQL Asterisk шёл 1,8 сек, создали индекс для таблицы PT1C_cdr по полю uniqueid, поиск стал осуществляться за сотые доли секунды. Таблица содержит миллионы записей!
После этого время создания события сократилось до 1-1,5 секунд и ID стал прикрепляться.
2. Проблема с генерацией событий при переключении звонка решается автоматической записью события сразу после его создания и заполнения данными.
3. У нас для входящих вызовов используются Очереди в Астериск. При это поиск записи разговора по частичному ID (до точки) с выдачей LIMIT 1 - выдаёт в большинстве случаев несуществующее имя файла записи разговора (допустим в группе 10 номеров, пришёл звонок, взял трубку 1 номер, а в выдаче может быть любой из 9-ти оставшихся номеров к ID которых не привязан файл записи). Решается поиском по полному ID (с точкой и цифрами после неё)
3.1. Также выяснилось что компонента ищет по полю uniqueid, а эвышеозначенную проблему можно было бы решить поиском по полю Linkedid (оно одинаковое для всех записей uniqueid звонка), но это реализовать можете только Вы, как разработчики.
4. При совершении исходящего вызова из события или карточки контрагента искать заново набираемый номер не имеет смысла, так как мы чётко знаем кому звоним. Поэтому вместо поиска номера реализовали привязку звонка к конкретному контактному лицу чем добились отсутствия ненужного поиска и ОДНОЗНАЧНОГО определения ПРАВИЛЬНО контрагента и контактного лица даже если у нескольких контрагентов/контактных лиц указан одинаковый номер.
