Okay, I have run across a situation that I have troubleshot with TAC extensively. As one final shot at resolving this I am bringing the question to all of you. The problem in a nutshell is DTMF is not passed to an "IVR" type of service that requests authentication codes for customer's LD use. This service runs on the network at the carrier. This works from everywhere except the Turret trader phones and even works from them to other IVRs, just not this service. The essential call flow is as follows:
Unigy Turret phone system -----SIP Trnk--->CUCM 8.6------SIP Trnk------>3945------tie line------>Nortel switch-------PRI----->AT&T
MTP (software) enabled on SIP trunk facing 3945
3945 IOS ver = 3900-universalk9-mz.SPA.151-4.M4.bin
Okay, hit me with all of the questions and requests for more info and I'll do my best to provide. I have seen similiar issues resolved the moment the MTP was checked. That is not the experience this time. I'm sure it has to do with early-offer and responses from the carrier on this particular service not reaching back across the system to the Turret and negotiating appropriate DTMF correctly or sending the correct notices. Would a hardware MTP work better perhaps? Would a different ver of IOS perhaps a "T" code work better? If you've seen this type of thing before please hit me up and let me know what the resolution was.
Thanks in advance for your assistance!!
Looking at the call flow, I see there are 2 SIP trunks. Which one do you have MTP enabled on? What codec are you using for this call flow end to end? What is the DTMF method configured on both the SIP trunks? What do you have configured on the matching incoming dialpeer on the 3945? Can you please post the running config of that gateway? Also, what version of UCM are you running?
MTP is enabled on the trunk "facing" the 3945. Also, this gateway was originally configured as MGCP and the same problem was evident. This should be a G.711 call. Tried, I believe, every combination of the DTMF method on the trunks but it should be RFC 2833 as that is what the Unigy wants. UCM = 18.104.22.16800-9
Running config is attached. Would match outbound the 9T dial peer
Which incoming dialpeer should be matched? I see quite a few VOIP dialpeers. I dont see any "incoming called-number" statement on those VOIP dialpeers. Are you sure you're not matching PID0? I would take "debug voip ccapi inout" to confirm incoming and outgoing dialpeers being matched.
If the config is validated and is fine by you, I would start working this backwards by 1st taking a PCM capture on the PRI channel. Here is a doc which shows you how:
Post it here and I'll decode it to see what DTMF is being sent (if any). Do mention the actual DTMF you had entered, so I know what I should be looking for.
Most likely the application doesn't support Early Media. Because of this, you will not have an RTP session to send the DTMF across.
We will need to see packet captures from the Turret device.