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

Это явно не 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: DTMF...

имеется 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 => 199,...