This was seen from both my side (network side) and the SIP side. The user on the outside would hit the 9 button to triger an option. It was a call from the network, through a CUBE router, into the telco (Verizon) SIP cloud. In this case, I was looking for a number 9. Outgoing Dial-peer=100, Params=0x73E5D890, Progress Indication=NULL(0) This is the outgoing dial peer according to the debugĭestination=, Calling IE Present=TRUE, Mode=0, Source Trkgrp Route Label=, Target Trkgrp Route Label=, CLID Transparent=FALSE), Call Id= Incoming Dial-peer=101, Progress Indication=NULL(0), Calling IE Present=TRUE, This is the dial peer it's hitting on the way in according to the debug 'voip ccapi inout' Do I need the 'dtmf-relay h245-alpha' command on both of these? Almost all of the calls use these two dial peers, according to the 'sho call active voice brief' and they are sip call legs. These are the dial peers in and out that the call is hitting. Router(config)# logging buffered 10000000 7 Router(config)# service timestamps debug datetime msec Collect:Ĭollect the debugs in the following manner, place a test call, and hit some DTMF: Likely a dial-peer match is incorrect, or the SIP side isn't using PT 101 for RTP-NTE. If you still have DTMF issues, it's a misconfiguration somewhere.
g.729 would only affect digits that are in the actual audio stream, which won't happen in a CUCM environment unless you invoke a transcoder and have dtmf-relay on one side and not the other. Hence, g.729 does not effect RTP-NTE digits in any way. I consider in-band to mean in-the-audio which RTP-NTE isn't since the payload type is different (and the digits are transmitted via data, not g.7xx audio) A lot of people refer to RTP-NTE as in0band, but I think that's a bad way to describe it.
0 kommentar(er)
