короче очередной, возможно баг-репорт, про злополучный трансфер. Как я уже сообщал, глючит именно Attended Transfer из очереди, так вот расскажу про свой диалплан. Входящий сип-звонок я направляю сначала на модуль Set CallerID:
http://www.freepbx.org/support/documentation/module-documentation/third-party-unsupported-modules/set-callerid
Это необходимо, чтобы отсечь лишние знаки и сформировать удобоваримый вид звонящего номера в виде линия@номер. Далее по назначению звонок попадает на очередь. В этом варианте Attended Transfer не работает, параллельно поймал еще один глюк: если агент очереди первым ложит трубку (ответив на входящий звонок), то у того внешнего абонента, который с ним разговаривал, не сигнал "занято", а просто тишина, атериск продолжает удерживать звонящего. При этом агент, который с ним говорил считается занятым, звонки ему не приходят. Может и вовсе зависнуть так, что приходится рестартовать астериск.
Если модуль Set CallerID убрать из пути обработки входящего звонка, то эти проблемы исчезают и Attended Transfer начинает работать!
Связано ли это с корявостью модуля или с версией астериска, кто нибудь может сказать? Сам модуль исправно обрабатывает свои функции. Вот часть кода, который он создает:

[app-setcid]
include => app-setcid-custom
exten => 7,1,Noop(Changing Callerid from ${CALLERID(all)} to CALLERID(name): , CALLERID(num): 490377@${CALLERID(num):5}; (gorod490377))
exten => 7,n,Set(CALLERID(name)=)
exten => 7,n,Set(CALLERID(num)=490377@${CALLERID(num):5})
exten => 7,n,Goto(ext-queues,500,1)

От модуля Set CallerID отказываться нельзя, он также используется для Callback.
Изменит ли ситуацию переход на trixbox CE 2.8.0.2 (Stable)? Я не прошу проделывать за меня всю работу, сроки поджимают, может просто у кого есть мысли, почему так происходит?
Да, забыл указать вот что: на странице system status trixbox указывает Bad destinations - именно то, что я входящий звонок направляю на этот самый Set CallerID. Но ведь он работает, только с очередью проблемы.

Вряд ли.

Merk:

Я не прошу проделывать за меня всю работу, сроки поджимают, может просто у кого есть мысли, почему так происходит?

Мысли есть.
Не пытаться решать проблему "в лоб".
А обойти изменением бизнес логики. Она должна быть гибче, чем очереди и перевод с уведомлением.
Теоретически, операторы очереди должны решать на 90% какой-то круг вопросов, а не тупо форвардить входящие.
А если не могут решить - форвардить тому, кто может. Вот тут видимо и понадобилось уведомление. Т. е. персона, на которую переводят нуждается в вводной, которую ему изложит оператор очереди, так? Если нет, то установить этой персоне флаг использования голосовой почты, персонифицировать сообщения, чтобы было не "Абонент 123 разговаривает по другой линии, но вы можете оставить сообщение!" а
"Виктор Петрович разговаривает по другой линии, но вы можете оставить сообщение!"
Это и есть в основном те фразы, которые проговаривает оператор абоненту. Поэтому - как один из вариантов.

Второй вариант - ещё проще, требует аппаратного рывка. Посадить операторов очереди на хардварные ИП телефоны, на них функции Attended transfer выполняются средствами самих телефонов, а не комбинациями show features.

ded, уж от вас я не ожидал предложения ухода или обхода проблемы, бизнес тут построен именно так и не иначе, заменить такую, казалось бы простую вещь, как переадресация, значит нарушить всю систему. К тому же ошибка оператора может привести к подвешиванию его линии, а это и вовсе неприемлимо. То происходящее, что я подробно описал, говорит о том, что "виной" всему модуль Set CallerID и, как я думаю, копать нужно в этом направлении, но возможно я ошибаюсь, поэтому и прошу совета. Есть мысли попробовать реализовать функции этого модуля в Dialplan Injection
http://www.freepbx.org/support/documentation/module-documentation/third-party-unsupported-modules/dialplan-injection
Но есть ли в этом смысл?

Лучше бы я мысли не высказывал.
Это обсуждение, или что? Не хотите тут сами с собой пообщаться?

Merk:

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

Почему такое отсутствие гибкости? Я предложил трансфер средствами IP телефонов, это осталось за рамками возможностей?
А других ошибок ввобще не предвидится?
Я бы решил проблему, любым подходом.
Вместо того, чтобы вникать в чужой app-setcid я бы направил в свой обработчик, который бы сделал то что надо в extensions_custom.conf

Merk:

Есть мысли попробовать реализовать функции этого модуля в Dialplan Injection
http://www.freepbx.org/support/documentation/module-documentation/third-party-unsupported-modules/dialplan-injection
Но есть ли в этом смысл?

Что-то мешает попробовать? Или хочется обсуждать больше смысл?

Попробовал. Получилось. Если кому интересно:
Направил входящие на Dialplan Injection, там прописал

Set(CALLERID(number)=${CALLERID(number):5}) ; обрезка ненужных знаков
Set(CALLERID(name)=500500@${CALLERID(number)}) ; формирование имени, удобного для просмотра во всплывающем окне X-Lite

Все заработало