Эти параметры указаны верно. В примере лога я специально скрыл значения.

Настройки делались согласно этой статьи и практически во всем совпадают. За исключением bindaddr (указан локальный ip) в manager.conf и тем что features.conf в 13 астериске не используется, эти параметры указаны в res_parking.conf

Пока мысли закончились

Спасибо за совет. Значит вот что имеем.

1. Сохранил в файле все три запроса
2. Создал в базе asteriskcdrdb две постоянные таблицы вида cdr_$uid и linkedid_$uid с именами как в сохраненных запросах
3. Выполнил запросы в mysql. Обе таблицы заполнились
4. Результат работы третьего запроса выводит хорошие данные.
5. Сделал вывод что дело не в запросах.
6. Дописал в скрипте file_put_contents('/tmp/output.txt', $output); - получил пустой файл на выходе
7. Проверил значение переменной $db_name - оно точно равно "asteriskcdrdb"
8. Убрал в скрипте в месте где создаются временные таблицы TEMPORARY
$AGIDB->sql("CRE ATE   TABLE $name_tmp_linkedid  (linkedid varchar(32));", 'NUM'); - пример для первой таблицы
9. Выполнил скрипт и в базе не увидел созданных таблиц.

Во вложении лог при работе скрипта

Каким образом можно пошагово проверить что возвращают временные таблицы по мере выполнения скрипта?

Как вариант сейчас увидел, что можно убрать в скрипте дропанье таблиц cdr_$uid и linkedid_$uid
Сейчас посмотрю что в них собирается

База заполняется.

Результат запроса во вложении

Не помогло.
Или это не единсвенная проблема.


Дебаг лог во вложении

Спасибо за оперативный ответ.

1. АТС настраивали по этим инструкциям - http://wiki.miko.ru/astpanel:dialplan_miko_ajam?roistat_visit=101032&_ga=1.7984306.1059528925.147030...

2. Описание экстеншена:

;[miko_ajam_10000555]                                                        
exten => 10000555,1,NoCDR()                                                  
exten => 10000555,n,Noop(internal calling application: 10000555 1C_CDR)
exten => 10000555,n,AGI(1C_CDR.php)
exten => 10000555,n,Hangup

Скрипт прилагаю

3. cel.conf поправил

4. ASTVERSION=13 прописал, не помогло. Но пробовал только перезапустить asterisk и панель телефонии. Полностью 1С надо было перезапускать?

Добрый день

Находимся в стадии тестирования работы вашего продукта на демо лицензии.

Работаем на конфигурации 1С E-note "Управление ветеринарной практикой" с модулем телефонии Панель телефонии для 1С 1.4.26.5

Голый Asterisk 13.9.1, настроен согласно рекомендациям на wiki

Панель в режиме Панель телефонии + Внешний SIP телефон. Весь функционал работает хорошо, звонки отображаются, клиенты идентифицируются, возможно выполнить вызов клиента из панели.

Журнал звонков, если отрыт, то заполняется. Но если его обновить, поменять дату, закрыть/открыть то он очищается. Т.е. панель не может получить данные по запросу от asteriska. Просим помощь в поиске проблемы. Еще и триал должен закончиться 31.08

mail*CLI> odbc show PT1C_asteriskcdrdb

ODBC DSN Settings
-----------------

 Name:   PT1C_asteriskcdrdb
 DSN:    MySQL-asteriskcdrdb
   Last connection attempt: 1970-01-01 05:00:00


mail*CLI> cdr show status

Call Detail Record (CDR) settings
----------------------------------
 Logging:                    Enabled
 Mode:                       Simple
 Log unanswered calls:       No
 Log congestion:             No

* Registered Backends
 -------------------
   mysql
   csv
   cdr_manager
   cdr-custom
   Adaptive ODBC

mail*CLI> cel show status
CEL Logging: Enabled
CEL Tracking Event: ALL
CEL Tracking Event: CHAN_START
CEL Tracking Event: CHAN_END
CEL Tracking Event: HANGUP
CEL Tracking Event: ANSWER
CEL Tracking Event: APP_START
CEL Tracking Event: APP_END
CEL Tracking Event: BRIDGE_ENTER
CEL Tracking Event: BRIDGE_EXIT
CEL Tracking Event: PARK_START
CEL Tracking Event: PARK_END
CEL Tracking Event: BLINDTRANSFER
CEL Tracking Event: ATTENDEDTRANSFER
CEL Tracking Event: USER_DEFINED
CEL Tracking Event: LINKEDID_END
CEL Tracking Event: PICKUP
CEL Tracking Event: FORWARD
CEL Tracking Event: LOCAL_OPTIMIZE
CEL Tracking Application: all
CEL Event Subscriber: ODBC CEL backend
CEL Event Subscriber: CEL Custom CSV Logging
CEL Event Subscriber: Manager Event Logging


Вот что возникает в отладчике при попытке обновить журнал: (см вложение)