Firstly, many thanks for the responses! Nishal, I did see the dtmf-relay rtp-nte digit-drop which looked very much like what we were trying to acheive. The only problem with that command on the CUBE <-> CUCM leg, is that it also configures the use of RTP-NTE rather than SIP-KPML, which causes an MTP to be allocated (something were trying to avoid for obvious reasons). What I was hoping for, unsuccessfully, was something like dtmf-relay sip-kpml digit-drop, though this obviously does not exist. I tried the same command on the CUBE <-> PSTN leg, however, and this proved successful. From the monitor captures performed on the PSTN side of the CUBE, however, I never saw any true inband DTMF, only the RTP-NTE event messages. Unless I missed something, its a curious fix for this issue. A little bit more investigation, and it appears this command, dtmf-relay rtp-nte digit-drop is quite suited to interworking, and again, for the inbound dial peer. http://www.cisco.com/c/en/us/td/docs/ios/voice/cube/configuration/guide/15_0/vb_15_0_Book/vb-gw-h323sip.html#wp1313530 Again, thanks for your response. Regards, Mike ... View more

Thanks for the response! The resolution is posted below, but to answer your questions: 1. The SIP trunks are configured for No Preference. This is actually an SME cluster, to be honest. As you know, you can force the use of RFC2833 (RTP-NTE) but not the use of OOB, so this is irrelevant for us. 2. The CUBE does have media-flow through and was performing DTMF interworking successfully, the problem was that it was converting RTP-NTE to SIP-KPML but not removing the RTP-NTE 3. Unity Connection is using SIP. I made an error in judgement comparing UCCX and UCXn after a long day looking at this. One is using SIP and the other SCCP. What I could see from network capture on the UCXn, however, was both the SIP-KPML notifications and the RTP-NTE packets were reaching the Unity Connection cluster. Again, thanks for your answer. Regards, Mike ... View more

Hi All, The response received was - as previously suggested - to migrate data fields from the CUCM 6.x template to the CUCM 8.x template. For UDP BAT, for example, the following fields need to be updated. This would also be a larger issue taking into account all the different BAT export / imports from non-matching versions of CUCM. Following the same method of matching the exported field headers with the template headers for the new version of CUCM is a timely but valuable exersize to achieve this. 6.X 8.X User Hold Audio     Source User Hold MOH   Audio   Source Login User Id Login User ID Partition x Route Partition x Line User Hold     Audio Source x Line User Hold MOH     Audio Source x Line Network Hold     Audio Source x Line Network Hold     MOH Audio Source x Visual Message     Indicator Policy x Visual Message     Waiting Indicator Policy x Alerting Name   ASCII   x ASCII Alerting   Name   x Line Text Label     ASCII x ASCII Line Text     Label x Call Recording     Option x Recording Option x Also required for removal from the CUCM 6.x UDP BAT export is all Forward All CSS Activation Policy x columns. It's also worth mentioning - correcting myself rather - that line information IS included in UDP BAT export for CUCM 6.x. Hope this helps anyone that experiences this issue. Regards, Michael ... View more

Firstly, thanks for the responses so far. I did notice upon looking into it a little further that CUCM 6.x UDP export includes the UDP profile, as well as all the associated lines. 8.x exports purely the UDP data, with no associated line data. After changing a couple of values, such as the mentioned User Hold Audio Source, the next field it errors on is the Partition field. I've got a case running with TAC to see what the final word on this is, however, it appears you're both right. In worst case, maybe Cisco can provide some feedback on how this can be attacked. Surely this is a common step in doing a rebuild-based migration. I'll provide any valuable feedback I receive once I get a response. Regards, Mike ... View more