asterisk.ru

Есть Asterisk 11.7.0 Внешние линии PRI E1, внутренние линии тоже PRI E1 (идут на старую офисную АТС), т.е. в боевом режиме все каналы DAHDI. Для целей отладки заведено несколько внутренних SIP.
Тестировал процесс помещения внешнего входящего в очередь, обработка его агентом с последующем трансфером на другого абонента, реакции последнего на занятость, на неответы и т.п.
Делал через определение глобальной переменной TRANSFER_CONTEXT. Все проверил - все работает. Но при тесте у меня получилось так, что обрабатывающим очередь агентом был указан тестовый SIP, а телефон, на который переводили - DAHDI. Все работало на ура.
Поменял агента на DAHDI и все перестало работать. По логам, в указанный в TRANSFER_CONTEXT контекст вызов не попадает. Вроде, где-то попадалось, что TRANSFER_CONTEXT только для SIP. Поиском подтверждения этой инфы не нашел.
Соответственно, 2 вопроса:
1) TRANSFER_CONTEXT действительно не работает с DAHDI или все-таки я где-то накосячил
2) если все-таки не работает, то какие варианты есть обрабатывать переводы для DAHDI?

Что-то никто не отвечает ... Видать, не понятно изложил.
Переформулирую вопрос.
Внешние DAHDI, внутренние DAHDI, других каналов считаем нет.
Нужна схема: приходит звонок с внешней линии, становится в очередь и ждет, когда его обслужат. Оператор, получив звонок из очереди, определяет куда перебросить звонок и переводит его. Если что-то с переводом не срастается, звонок должен вернуться обратно. Т.е. классический вариант.
Не понимаю, как обработать процесс перевода. Входящий вызов попадает в контекст, допустим, incoming. В диалплане в этом контексте стоит команда Queue. Ограничений на количество попавших в очередь нет, тайм-аута нет (дабы никого не потерять, если сами не прервут).
Оператор освобождается, и к нему попадает звонок из очереди. Хотелось бы этот момент как-то проконтролировать, но не понимаю, как. Если в диалплане, то в каком контексте? Возможно, можно применить другие пути, без диалплана, я не знаю. Далее оператор осуществляет перевод. Сам звонок обратно не вернется. Опять нужны или контекст, или задействование других технолгий.
Подскажите, пожалуйста.
На всякий случай повторюсь, что с агентом очереди, подключенным по SIP, я все это без проблем реализовал. Но с DAHDI примененное мной решение не работает и нужен другой путь.

а честно не понимаю зачем вы ушли в TRANSFER_CONTEXT
что стандартный функционал через features не работает ?

Проблемы с features описаны здесь: http://linux.mixed-spb.ru/asterisk/call ... ansfer.php
В 2-х словах: оператор, вытащивший внешнего абонента из очереди и переключивший его на внутреннего абонента, выпадает из игры до тех пор, пока внешний и внутренний не соединятся.
я моделировал эту ситуацию, вроде, так и есть
В случае TRANSFER_CONTEXT удобно, что отдельный контекст - понятно, куда навешивать приложения.
В случае без TRANSFER_CONTEXT мне пока не понятно, куда навешивать приложения (старт/стоп записи разговоров, например)
Пытаюсь понять это по логу.

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

Есть слепой перевод и есть перевод с уведомлением
при использовании с уведомлением - не обязательно ждать когда на том конце поднимут трубку - достаточно услышать гудки
после этого уже работает features - и если там выставлено - если не взяли трубку то через 15 секунд (по умолчанию) - звонок вернется оператору который делал перевод
если у оператора к тому времени занято - то будет еще 2 попытки (по умолчанию)
Никто не запрещает - делать возврат не к оператору а в очередь - достаточно поймать переменные - а то что это не простой звонок а переведенный

при использовании с уведомлением - не обязательно ждать когда на том конце поднимут трубку - достаточно услышать гудки

Об этом и речь. Оператор (кто переводит) вешает трубку, но ни принять, ни позвонить не сможет, пока не произойдет соединение внешнего (кого переводят) и внутреннего (на кого переводят) абонентов.
Сейчас закончу пару экспериментов и еще раз попробую с features.

Нашел, что нужно, чтобы TRANSFER_CONTEXT работал. Надо для трансфера использовать dtmf код, прописанный в features.conf
Но операторы же будут жать flash, R (у кого что), потому что так привыкли.
Есть решение, чтобы астериск воспринимал эти действия (dtmf и flash) одинаково?

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

1. Кнопку flash удаляем из аппарата.
2. Штрафуем оператора за ТАКИЕ переводы.

Выбирайте.

3. Вставляем в зад оператору дистанционно управляемый пистон, который активируется кнопкой flash.
Обратная связь - налицо!