Есть проблема с прохождением DTMF по следующей схеме:

Провайдер1 –SIP (G711)---> циска (3745) --> IVR –H323 (G729)--> Провайдер2

Циска шлет DTMF в теле 729 кодека и софт провайдера (Мера) не понимает такой DTMF, а заставить циску слать в сигналинке DTMF после SIPа не получается.

• Не проходит DTMF SIP -> H323,Alex., 12:13 , 03-Мрт-08
  • Не проходит DTMF SIP -> H323,rayden, 12:51 , 03-Мрт-08
    • Не проходит DTMF SIP -> H323,Alex., 15:13 , 03-Мрт-08
      • Не проходит DTMF SIP -> H323,rayden, 15:22 , 03-Мрт-08
        • Не проходит DTMF SIP -> H323,Alex., 17:01 , 03-Мрт-08
          • Не проходит DTMF SIP -> H323,rayden, 09:14 , 04-Мрт-08
            • Не проходит DTMF SIP -> H323,Alex., 11:14 , 04-Мрт-08
              • Не проходит DTMF SIP -> H323,rayden, 11:53 , 04-Мрт-08
                • Не проходит DTMF SIP -> H323,zaikini, 18:02 , 04-Мрт-08

Попробуйте посмотреть tcpdump, что происходит с rpt-nte. На MERA для H323-H323
подобного подавления не замечалось.

>Попробуйте посмотреть tcpdump, что происходит с rpt-nte. На MERA для H323-H323
>подобного подавления не замечалось.

Провайдер смотрел tcpdump`ом:

если 711 кодек, то он видет DTMF, если 729 то не видет

я смотрел со своей стороны дебагом на циске, и по логам было видно что циска DTMF видит отправляет.

Провайдер обращался к производителю Меры, вот что он сказал:

В данном случае, нет никаких неисправностей в MVTS II. Система отрабатывает DTMF так, как это и было задуманно.
Собственно, не совсем корректно сконфигурированные Cisco почти что единственные шлюзы, которые шлют в H.323 сигналы DTMF по протоколы rfc2833. При нормальной конфигурации, Cisco должен слать DTMF в H.323 в сигналинге (сообщения UserInput. Если H.245 Tunneling - TRUE, то тогда эти сообщения будут инкапсулированны в Facility), также как это делают все остальные H.323 устройства.

RTP-NTE имеет свой собственный payload type, обычно 101
, что и должно согласовываться в секции H245.
Как видно из приведённой схемы - на cisco ip-2-ip.
Попробуйте поставить на cisco outgouing dial-peer
только  dtmf-relay h245-signal h245-alphanumeric,
на входном  dtmf-relay rtp-nte.

>RTP-NTE имеет свой собственный payload type, обычно 101
>, что и должно согласовываться в секции H245.
>Как видно из приведённой схемы - на cisco ip-2-ip.
>Попробуйте поставить на cisco outgouing dial-peer
>только  dtmf-relay h245-signal h245-alphanumeric,
>на входном  dtmf-relay rtp-nte.

Так и есть

Исходящий
dial-peer voice 783 voip
translation-profile outgoing xxx1
huntstop
destination-pattern 8540xxxx$
session target ipv4:192.168.138.25
dtmf-relay h245-alphanumeric
!

Входящий:
dial-peer voice 212 voip
description Incoming from Gorod
huntstop
service ivr
session protocol sipv2
incoming called-number 781419xxxx
dtmf-relay rtp-nte
codec g711ulaw
no vad

Если cisco не проводит переобразование способа dtmf-relay,
что несколько странно. То попробуйте внути IVR поставить
event-handler dc-digit.

>Если cisco не проводит переобразование способа dtmf-relay,
>что несколько странно. То попробуйте внути IVR поставить
>event-handler dc-digit.

Есть такое :)

puts "\n GotDest start"
    global NumDestPrompt;
    global DestPromptFlag;
    global account;
    global destination;
    global Pin;

    set status [infotag get evt_status];
    switch $status {
"cd_001" {
puts "\n GotDest cd_001"
#fsm setstate DISCONNECTED
    fsm setstate CHECKDEST        
GetDest
return;
}
"cd_002" {
puts "\n GotDest cd_002"
#fsm setstate DISCONNECTED
    fsm setstate CHECKDEST        
GetDest
return;
}
"cd_004" {
set destination [infotag get evt_dcdigits];
puts "\n************dest_number = $destination";
set msg "Call from Pin="
append msg $Pin
append msg " to destination "
append msg $destination
append msg [clock format [clock seconds]]
log -s INFO $msg
leg setup $destination callinfo leg_incoming
fsm setstate CALLSTATUS        
return;
}
default {
puts "\n GotDest default"
#fsm setstate DISCONNECTED
    fsm setstate CHECKDEST        
GetDest
return;
}
}
    }
set ivr_fsm(CHECKDEST,ev_collectdigits_done)       "GotDest same_state"

Сама циска видит DTMF и в логах об этом говорит... Проблема в том, что на выход она выкидывает DTMF не в том виде как нужно провайдеру. Он ждет DTMF в сигналенге  :(

Попробуйте
dtmf-relay h245-signal
или лучше
dtmf-relay h245-signal h245-alphanumeric rtp-nte
попробуйте out dial-peer.

>Попробуйте
> dtmf-relay h245-signal
>или лучше
> dtmf-relay h245-signal h245-alphanumeric rtp-nte
>попробуйте out dial-peer.

Попробовал, DTMF не проходит :(

>>Попробуйте
>> dtmf-relay h245-signal
>>или лучше
>> dtmf-relay h245-signal h245-alphanumeric rtp-nte
>>попробуйте out dial-peer.
>
>Попробовал, DTMF не проходит :(

Я так думаю что циске надо запретить передавать dtmf через rtp-nte
команда dtmf-relay h245-signal h245-alphanumeric rtp-nte  указывает порядок приоритета для обработки dtmf но не запрета использования того или иного метода.

Возможно (предположение) надо сделать следующим образом:

Входящий:
dial-peer voice 212 voip
description Incoming from Gorod
huntstop
service ivr
session protocol sipv2
incoming called-number 781419xxxx
dtmf-relay rtp-nte digit-drop
codec g711ulaw
no vad

исходящий так и остается
dial-peer voice 783 voip
translation-profile outgoing xxx1
huntstop
destination-pattern 8540xxxx$
session target ipv4:192.168.138.25
dtmf-relay h245-alphanumeric