Вы не авторизованы

Вы можете читать сообщения. Если вы хотите создать новую тему или присоединиться к обсуждению, пройдите процедуру регистрации или авторизуйтесь.

Выбрать дату в календареВыбрать дату в календаре

Очередь клиентов
 
Добрый день. FreePBX 2.8.1.4 Elastix 2.4
Организована такая схема работы: все входящие звонки в зависимости от транка попадают в очередь queue-sales, queue-support, etc. (разные приоритеты), и ждут соединения с оператором колл-центра. Возможно ли в режиме панели видеть список "ожидающих" клиентов в очереди и/или совершать какие-либо действия с ними (перевод/отбить/гол.почта)?
История вызовов, обычные формы.
 
Добавьте в запросе в условие соединения с таблицой cel фильтр по дате и будет намного быстрее грузится
Изменено: Павел Грабарь - 19.01.2015 17:12:50
(Fix) Временная таблица CDR записей
 
1.2.21.8 для обычных форм
(Fix) Временная таблица CDR записей
 
Очередной раз столкнулся с проблемой временной таблицы возвращаемых CDR записей при заполнении истории в панели телефонии.
Реализован фильтр истории по номерам из списка отслеживаемых линий.
Ситуация:
Запрашиваем историю по номерам 101, 102. Получаем ответ.
ОК. Меняем фильтр на номер 333. Снова запрашиваем историю. Получаем пустые строки CRD (звонков в эту дату не было), в панели истории по-прежнему отображаются предыдущие записи истории.
Решение - в процедуре ЗаполнитьТаблицуИсторииЗвонков
Код
Если (ТЗИсторииЗвонковВременная <> Неопределено) И (ТЗ = Неопределено) Тогда
ТЗИсторииЗвонковВременная.Очистить();
КонецЕсли;

Ситуация №2.
Запрашиваем истории звонков на дату, скажем, 20.10.2014. Вернулись записи, в таблице истории все красиво.
Передумали, сдвигаем дату истории на 25.10.2014. Получаем все те же записи истории, что и были ранее. Ситуация проявлялась при повторном обновлении истории с датой позднее выбранной ранее. Приходилось обозначать переменную при выборе даты из календаря и потом фильтровать таблицу истории
Код
Если ТЗ[к].calldate < ПериодЗвонковНачало Тогда Продолжить; КонецЕсли;
Но сейчас посмотрел фикс подошел и к данной ситуации
Несколько вопросов по интеграции в Elastix
 
Вопрос решился переопределением uniqueid при обнаружении файла записи к звонку в onUserEvent_FromCDR.

Далее:
1. Бесконсультативный перевод не работает вообще.
Лог чистый:

Цитата
Переводим звонок безконсультативно 80295310900 на номер 301
Результат безусловного перевода  <ajax-response>
<response type='object' id='unknown'><generic response='Success' message='Redirect successful' /></response>
</ajax-response>
При этом в линии слышен тональный набор и после этого ничего не происходит.
Конфиг стандартный:
Цитата


Builtin Feature           Default Current
---------------           ------- -------

Pickup                    *8      *8    

Blind Transfer            #       ##    

Attended Transfer                 *2    

One Touch Monitor                 *1    

Disconnect Call           *       **    

Park Call                                

One Touch MixMonitor                  
2. Консультативный перевод работает, но звонок не возвращается, если никто не ответил или линия занята, звонок теряется. В SDK не нашел атрибут для выставления таймаута для возвращения звонка. Это вообще реально?

3. Новые записи по-прежнему пишутся в PT1C_cdr, php скрипт для переноса в cdr в крон добавили, но это же не решение проблемы.
Изменено: Павел Грабарь - 26.08.2014 19:04:33
Несколько вопросов по интеграции в Elastix
 
Логично) Есть такая проблема со скачиванием записи, связанных с маршрутизацией.
Пример. Входящий звонок на транк 1004, ему присвоился id 1409042612.2681, дальше ответ оператора с номера 501 (ID 1409042622.2683, поле linkedid 1409042612.2681). Файл записи присутствует по второму событию g501-20140826-114342-1409042622.2683.wav.
В истории отображается нормально - участники 1004, номер контрагента и 501, файл записи присвоен, по запросу из панели файла для скачивания/прослушивания по ID 1409042612.2681 и файлом g501-20140826-114342-1409042622.2683.wav ничего не находит.
Т.е. ищет все-таки по полю uniqueid, а не по linkedid.

P.S. Строка ответа при получении истории onUserEvent_FromCDR для второго звонка:

Код
2014-08-26 11:43:42@.@375447551182@.@501@.@Local/501@from-queue-0000032b;2@.@SIP/501-0000041e@.@60.5792@.@ANSWERED@.@1409042622.2683@.@g501-20140826-114342-1409042622.2683.wav@.@SIP/501-0000041e@.@Dial@.@1409042612.2681@.@




Код
Просматриваем файл записи для разговора с идентификатором 1409042612.2681                       
Инициирован запрос имени файла записи CDR <ajax-response>
<response type='object' id='unknown'><generic response='Success' actionid='00c87' message='Originate successfully queued' /></response>
</ajax-response>

Внешнее событие:  <generic event="Newchannel" privilege="call,all" channel="Local/10000666@miko_ajam-000003cb;1" channelstate="0" channelstatedesc="Down" calleridnum="" calleridname="" accountcode="" exten="10000666" context="miko_ajam" uniqueid="1409051704.3168" />

Внешнее событие:  <generic event="Newchannel" privilege="call,all" channel="Local/10000666@miko_ajam-000003cb;2" channelstate="4" channelstatedesc="Ring" calleridnum="" calleridname="" accountcode="" exten="10000666" context="miko_ajam" uniqueid="1409051704.3169" />

Внешнее событие:  <generic event="NewAccountCode" privilege="call,all" channel="Local/10000666@miko_ajam-000003cb;1" uniqueid="1409051704.3168" accountcode="" oldaccountcode="" />

Внешнее событие:  <generic event="NewCallerid" privilege="call,all" channel="Local/10000666@miko_ajam-000003cb;1" calleridnum="" calleridname="" uniqueid="1409051704.3168" cid_callingpres="67 (Number Unavailable)" />

Файл с записью разговора не найден на сервере ASTERISK.
Изменено: Павел Грабарь - 26.08.2014 15:44:26
Несколько вопросов по интеграции в Elastix
 
ОК. С именем файла записи разобрался.
Еще вопрос: SIP транки в истории звонков участвуют в расшифровке звонка. Зачем?
Несколько вопросов по интеграции в Elastix
 
Добрый день. В процессе интеграции панели 1.2.21.8 в Elastix 2.4.0 возникли некие баги/фичи.
Астериск "готовился" по актуальным инструкциям из вики.

После того, как установили модуль PT1C записи в asteriskcdrdb пишутся в таблицу PT1C_cdr, поэтому все отчеты средствами астериска уже не получить. Пока сделали средствами php скрипт переноса записей в таблицу cdr. Это так и должно быть или новые записи должны писаться в обе таблицы?

Для формирования файла записи в mysql таки пришлось руками добавлять в блок macro-record-enable в extensions_override_elastix назначение переменной имени файла и править 1C_Download.php, т.к. имя файла записи по-прежнему писалось в формате audio:${CALLFILENAME}.${MIXMON_FORMAT}) в поле 'userfield'. После этого в phpmyadmin все записи видны, а при получении истории из панели атрибут recordingfile по-прежнему пустой. Решили вытягивать имена файлов прямым запросом к mysql из 1с по uniqueid, но жертвовать пришлось производительностью.