Куда более удобней писать в это поле XML
в том же mysql уже давно есть XPath

Решил замутить такую же фичу как в switchvox:
http://www.switchvox.com/sv_images/screenshots/admin_call_log.gif

По-сути делается просто: в каждый макрос или контекст, в общем везде, где происходит обработка звонка, нужно вставить процедуру, которая записывает в какую-нить БД то, что сейчас происходит. если диалплан самописный, то сделать просто, если триксбокс (как у меня), то сложнее: нужно в код всех модулей добавить соответствующие инструкции.

другая часть проблемы заключается в том, что эту информацию нужно куда-то записывать. Поле userfield имеет размер всего 255 символов, чего явно недостаточно... варианты:
- команда диалплана MYSQL. пишет сразу в БД, но: 1) неизвестно, сколько ресурсов потребляет, 2) придется при каждом вызове открывать транзакцию, передавать данные и закрывать транзакцию. 3)в процессе одного вызова запись в БД может осуществляться несколько раз, т.е. десяток вызвов транзакций может сильно просадить производительность диалплана...
- тупо делать system(echo ${UNIQUEID} << ${STRFTIME(${EPOCH},,%d%mNaVH:NaVS)}); имя операции; ${CALLERID}). т.е. создавать маленький текстовый файл для каждого звонка. Из плюсов - работает быстро. но если в день проходит 10-15 тысяч звонков... 300 тыс. файлов за месяц это слишком...

также вопрос по очередям: после выхода вызова из очереди, он имеет тот же ${UNIQUEID} что и при входе? а как наследуются переменные?

какие могут быть варианты?

увеличить размер до нужных размеров ... )

switch:

команда диалплана MYSQL. пишет сразу в БД, но: 1) неизвестно, сколько ресурсов потребляет, 2) придется при каждом вызове открывать транзакцию, передавать данные и закрывать транзакцию. 3)в процессе одного вызова запись в БД может осуществляться несколько раз, т.е. десяток вызвов транзакций может сильно просадить производительность диалплана...

MySQL - является довольно производительной БД. Поэтому расчет нужно производить исходя из кол. одновременных запросов к базе ... Т.е. в данном случае это равно кол. одновременных вызовов. Если речь о высоконагруженной системе, то базу нужно строить - распределенную (кластер)
По поводу - транзакций. Речь наверное об открытии соединения с базой. Его не обязательно закрывать сразу после обращения к базе, т.е. в процессе вызова можно воспользоваться одним соединением несколько раз. Но ОБЯЗАТЕЛЬНО нужно проследить, что бы соединение было ЗАКРЫТО по завершению вызова (включая случаи срыва вызова, перехода в другой контекст и т.д. ...)

switch:

в день проходит 10-15 тысяч звонков...

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

switch:

также вопрос по очередям: после выхода вызова из очереди, он имеет тот же ${UNIQUEID} что и при входе?

Да ...

switch:

а как наследуются переменные?

http://voip.rus.net/tiki-index.php?page=Asterisk+Variables

1) что если увеличить поле таблицы cdr, которое содержит userfield, а в переменную userfield складывать события, а потом, когда завершится звонок, * запишет все переменные в таблицу cdr. Но тут вопрос: какая максимальная длина значения переменной в * ? Ибо событий можно натолкать более чем на 256 символов.
2) в том-то и дело, что трудно отследить, когда нужно закрывать соединение, поэтому придется каждый раз открывать/закрывать.
3) предполагается решение для предприятий все-в-одном, нагрузка до 50 одновременных вызовов, т.е. 300 пользователей...
4) по очередям понятно, завтра проверю...

не критично.
Б.Д. так и работают ... :) Просто в любом случае количество запросов нужно оптимизировать.

Только, если я правильно понял, то отдельных запросов к базе не будет. Все будет записываться в поле - userfield, а для этого не нужно создавать специально запрос. Значение этого (и других) поля можно устанавливать обычными средствами:

AppendCDRUserField: Append to the CDR user field
SetCDRUserField: Set the CDR user field

или Set(CDR(userfield)=XXX)

попробовал сделать. Выяснилось:
1) максимальная длина содержимого переменной в астериске не может быть больше 255 символов, остально просто отрезается. соответственно AppendCDRUserField не позволяет записать большие объемы, не смотря на то, что поле таблицы размером в 4096 символов.
2) в процессе вызова создается несколько записей, что в общем-то логично. ${UNIQUEID} состоит из двух частей, разделенных точкой. первая - уникальна для вызова, вторая отражает номер "плеча" (хз как назвать). например, при поступлении в очередь, будет формировано несколько записей, в которых первая часть ${UNIQUEID} одинакова, а вторая - для каждой попытки дозвона до оператора своя.

Короче, пришел к выводу, что сделать такую фичу с помощью UserField затруднительно. Думаю, что вариант с модулем для астериска, который будет писать все в БД как надо будет эффективней, на худой конец - диалпланом...

Так причем размер переменной? Переменная и поле в базе не одно и тоже.
Это не значит, что туда нельзя записать (с помощью - AppendCDRUserField) два (четыре ...) раза по 255.

дело в том, что AppendCDRUserField пищет не напрямую в базу, а в переменную. содержимое переменной записывается в базу вместе с другими переменными по окончанию вызова (INSERT INTO). Длинна значения переменной - 255 символов.
Если несколько раз вызывать AppendCDRUserField, то по достижении 255 символов больше информация не добавляется. проверял.

Даже еслиб добавлялась, все равно в коонечной таблице нужно отделять части ${UNIQUEID} друг от друга, иначе время выборки в конце концов будет очень большим, а запрос - сложным (Mysql медленно работает с инструкцией LIKE, что, впрочем, логично)

тогда только прямой записью в базу:

...
exten => _X.,n,MYSQL ...

да, придется так и делать...
а можно ли открыть одно соединение, хранить его номер в глобальной переменной и использовать его в диалплане постоянно?