loop detected - ответ вполне ясный. Петля создана на уровне логики extensions.conf а не на уровне технологий. Пришедший звонок запетлёван через Goto. Мы тут этого не видим, так как приведён не весь диал план. Где-то там includes наставлены?
iax.conf
[prov]
type = user
host = X.X.X>X
transfer=no ...

Это явно не sip.conf, как указано, а extensions.conf

ну да, точно :)


но как корректно завернуть звонок сам на себя, так что при этом произошла перекодировка из IAX в SIP пока непонятно.
Принимайте IAX транк в спец контекст где

exten => _X.,1,Dial(SIP/${EXTEN}@localhost)

в Dial(SIP ...

всё дело в том что оно штатным способом в IAX вообще не анализируется. в самой спецификации протокола написано что DTMF передается out of band то есть не внутри голосовго траффика, а отдельным IAX служебным пакетом. и ловля DTMF и генерация этих пакетов лежит на той стороне, которая заворачивает ...

провел следственный эксперимент
сделал в ответе на звонок приходящий по IAX от провайдера звонок на SIP шлюз, который скроссирован парой с другим шлюзом, принявшим звонок по аналоговой соотв паре, загнавший его в SIP и вернувший в тот-же астериск... так вот - в этом SIP траффике распознаывание DTMF ...

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

когда идет соединение от меня - то
[Feb 5 18:28:07] DTMF[10708]: channel.c:2466 __ast_read: DTMF begin '2' received on SIP/1001-00000913
[Feb 5 18:28:07] DTMF[10708]: channel.c:2476 __ast_read ...

имеется IAX2 транк с провайдером, при получении входящего соединения выполняем:

iax.conf
[prov]
type = user
host = X.X.X>X
transfer=no
trunk=yes
context = incommingIAX
jitterbuffer=no


sip.conf
[incommingIAX]
exten => _7XXXXX,1,GoTo(incomming70,199,2)

[incomming70]
exten => 199,1,Answer
exten ...