Attended transfer тремя последовательностями

[Vlad1983]

а если в features.conf так
[applicationmap]
attenraz => *1,peer,SendDTMF(*2)
attentri => *3,peer,SendDTMF(*2)

[Sfinx]

Не забываю, пробовал все. Каналы пробрасывал из custom dynamic feature макроса с помощью ChannelRedirect app. Но все равно остается проблема соединения канала третьего лица с позвонившим абонентом. Сейчас накидаю простой модуль и проверю вариант вызова void ast_register_feature(struct ast_call_feature *feature) из него - если resolve проканает, то проблема в принципе решится написанием кастомного модуля, но все равно чувство что все это как-то через ж#пу.

[Sfinx]

а если в features.conf так
[applicationmap]
attenraz => *1,peer,SendDTMF(*2)
attentri => *3,peer,SendDTMF(*2)

Это тоже самое что предложил zzuz, просто он не дописал что exten должен быть в макросе. Естественно это не работает хотя DTMF (*2) слышен в голосовом канале

[Vlad1983]

тогда только в макросе считывать куда хотит и далее cmd TRANSFER() или ChannelRedirect()

[Sfinx]

Еще раз - Transfer имеет ограничения и толку от него никакого - я вообще не понимаю зачем он нужен, заменяется или Goto или Dial. ChannelRedirect - это уже неплохо, но во-первых у него только один параметр и соединяет он только свой канал, а нужно соединить 2 внешних канала, нужно что-то типа ChannelConnect(каналA, каналБ) и во-вторых - как достать номер третьего канала куда произошел attended трансфер ? Вобщем этот путь весьма и весьма геморен.

[Vlad1983]

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

[Sfinx]

Вобщем через кастомный модуль работает, если не будет никаких других вариантов - поставлю модуль или пропатчу features.c, склоняюсь ко второму варианту, так как модуль получился в 900 строк, а патч в 3.