I have this partially up in my lab. Although I don't have UCCX fully up and running, I was able to get the SIP trunk configured with DTMF interworking with CUBE without using MTP or transcoders. On my first attempt I was not seeing the SIP NOTIFY messages with the DTMF events, and on checking the CUCM SIP trunk configuration the DTMF Signaling Method was set to 'RFC2833'. I changed this to 'No Preference' and then the SIP NOTIFY messages were transmitted. My CUBE is a 2851 running 15.1(4)M10, and the dial-peer configuration is as follows: ! Inbound from PSTN dial-peer voice 1000 voip description Incoming calls from SIP carrier session protocol sipv2 session target ipv4:x.x.x.x incoming called-number ^<inbound patterns>$ voice-class codec 1 dtmf-relay rtp-nte dial-peer voice 35219 voip description 32519 pilot UCCX destination-pattern 35219 session protocol sipv2 session target ipv4:192.168.50.80 voice-class codec 2 dtmf-relay sip-notify no vad On CUCM, I do have Unsolicited Notify allowed in the SIP security profile, and DTMF Signaling is 'No Preference' In addition to the debug ccsip messages output, I can verify the DTMF interworking on CUBE with 'show call active voice'. On the PSTN leg I see 'tx_DtmfRelay=rtp-nte' and on the CUCM leg I see 'tx_DtmfRelay=sip-notify' I did another test where I changed the CUCM SIP trunk DTMF Signaling back to 'RFC 2833" and when I run 'show call active voice' on the CUBE, the PSTN leg has 'tx_DtmfRelay=rtp-nte', and the CUCM leg has 'tx_DtmfRelay=inband-voice'. I also tried this with the CUCM dial peer set with 'dtmf-relay sip-kpml', and while the 'show call active voice' command indicated 'tx_DtmfRelay=sip-kpml', no SIP messages were sent with the digits. This behavior is consistent with the documentation, although I wonder if this is a defect as I would have expected it to fallback to inband-voice. I'm going to get UCCX in my lab running next week and I'll let you know what the result. I'm pretty confident this will work because CUCM is getting out-of-band DTMF via SIP-Notify. I would suggest you try 'dtmf-relay sip-notify' and ensure your CUCM SIP trunk is configured with DTMF Signaling set for 'No Preference', and then review 'call active voice compact' to see if CUBE is handling DTMF the way you expect.
... View more
The document indicates that rtp-nte -> sip-KPML interworking is not supported, but rtp-nte -> SIP-NOTIFY is. The dial peer syntax would be 'dtmf-relay sip-notify'. Have you tried sip-notify, or just sip-kpml? Also, with sip-notify, the SIP trunk security profile should be set to support unsolicited notifications https://supportforums.cisco.com/blog/154706
... View more
I've been working on this issue as well, but I haven't yet had an opportunity to put it in a lab. Take a look at http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/dtmf-relay.html, the CUBE DTMF interworking should allow rtp-nte to SIP-NOTIFY interworking if you have the correct IOS version.
... View more
We have the same configuration in our organization, the best solution I have found is to set the DHCP lease time to something small, like 15 minutes or less. It's not exactly an elegant solution, but it also helps free up addresses from smartphones that briefly connect and then leave.
... View more
If you run is really short use a multi-mode patch cable. They will work with the GLC-LH-SM (see http://www.cisco.com/en/US/docs/routers/7200/install_and_upgrade/gbic_sfp_modules_install/5067g.html#wp34124 ). A 10-12m patch cable should be fine, and just coil up any excess. I wouldn't worry about attenuators unless you are using the high-power ZX optics.
... View more
You shouldn't have to live with it. I suspect your problem is cabling, and if it is cabling it could either be your patch cable or the proprietary dongle in the back of the cabinet.
... View more
You might check your cabling first. In many cases CRC errors indicate a physical cabling problem. You might try replacing your network cable with a known good cable. Now the bad news, if you're running a TN799DP CLAN card, I'm assuming it is probably in some sort of Avaya shelf. It's been a few years since I've messed with them, but at least the older Avaya shelves had a proprietary dongle that cabled the back of the actual shelf to the cabling panel where you would plug in your ethernet cable to the CLAN card. The really old shelves did not have CAT rated "dongle", and were not supported for speeds over 10mbps. I have seen these dongles go bad, and it usually required an Avaya tech to replace.
... View more
I would recommend using a flash-based player, and there are purpose-built MoH flash players. It's easy enough to rip a CD, and a flash player won't have any moving parts to wear out. However, if you are going to rip the CD, you might as well load it directly onto your MoH server and not worry about any extra parts. Look under "Media Resources"->"MoH Audio File Management". http://www.cisco.com/en/US/customer/docs/voice_ip_comm/cucm/admin/7_0_1/ccmfeat/fsmoh.html#wp1105575
... View more
1) I run an internal DHCP server on a 4402, I imagine the 5508's have it as well. Look under "Controller"->"Internal DHCP Server". 2) This really isn't a function of the 5508, you'll need to handle that with another router. The easiest way would be to configure a new router/firewall and put it on vlan 200 and make it the default gateway for that network. It would provide the routing to your separate Internet connection. Make sure you do not have a SVI on whatever switch your 5508 is plugged into.
... View more
Switching to LACP shouldn't make any difference. LACP just handles the etherchanneling, not the 802.1q trunking, and it sounds like your problem is specific to trunking. It could be that resetting the links reset something on the AIX server that caused it to start working. You might also have had something wierd happening with spanning-tree on that VLAN. If you can recrate the issue, or are having the issue with another host, you might take a look at the output of show spanning-tree int po 16 and show spanning-tree vlan , and see if everything is how you expect it to be.
... View more
I don't believe the 28xx/38xx uses the license key, so you don't need to purchase a license. Just download the image with the same feature set you currently have just like you do with the 12.4 code releases. I've upgrade a few dozen of my 2821 and 3845's and they don't use the license. If you are upgrading your feature set (e.g. IP SERVICES to ADVANCED ENTERPRISE SERVICES), then you are "required" to purchase an upgrade license. However, all you get is a piece of paper you stick in a drawer. When you have a 28xx or 38xx on version 15, you'll see somem reference to the license, but it will remain blank. The box will operate with the feature set you load on it: XXXXX>sho ver Cisco IOS Software, 3800 Software (C3845-ADVIPSERVICESK9-M), Version 15.1(1)XB, RELEASE SOFTWARE (fc1) Technical Support: http://www.cisco.com/techsupport Copyright (c) 1986-2009 by Cisco Systems, Inc. Compiled Mon 21-Dec-09 03:52 by prod_rel_team Cisco 3845 (revision 1.0) with 478208K/46080K bytes of memory. Processor board ID FTX1324AHVR 2 Gigabit Ethernet interfaces 4 Channelized E1/PRI ports 1 Virtual Private Network (VPN) Module 16 Voice E & M interfaces DRAM configuration is 64 bits wide with parity enabled. 479K bytes of NVRAM. 255488K bytes of ATA System CompactFlash (Read/Write) ... License Info: License UDI: ------------------------------------------------- Device# PID SN ------------------------------------------------- *0 CISCO3845-MB FOCXXXXXXXXXX Configuration register is 0x2102 The 29xx and 39xx, however, do use the common image and the license, and you will see sho ver Cisco IOS Software, C3900 Software (C3900-UNIVERSALK9-M), Version 15.0(1)M1, RELEASE SOFTWARE (fc1) Technical Support: http://www.cisco.com/techsupport License Info: License UDI: ------------------------------------------------- Device# PID SN ------------------------------------------------- *0 C3900-SPE100/K9 FOCXXXXXXXXX Technology Package License Information for Module:'c3900' ---------------------------------------------------------------- Technology Technology-package Technology-package Current Type Next reboot ----------------------------------------------------------------- ipbase ipbasek9 Permanent ipbasek9 security None None None uc uck9 Permanent uck9 data None None None Configuration register is 0x2102
... View more
If the connection plar .... command is effective, then MGCP is not working. When MGCP is involved, CUCM manages everything about the call setup, so all of the H.323 commands are ineffective. Because you have the "service alternate default" command defined, then H.323 processing takes over in the event that MGCP is down. The disconnect supervision is something that you have to get from the phone company. I have looked into trying to do something fancy in the gateways to detect the absence of the ring, but never figured it out. Plus, you still have the problem if someone leaves an IP phone off-hook and the remote end disconnects. Additionally, if you are using voicemail or some other automated system, it won't get notified to hang up, and you can have some interesting things happen.
... View more
I'm not really sure about your first problem, however, resetting the FXO port and the gateway in CUCM might help. Usually when MGCP is acting wierd, resetting everything usually fixes it. For your second problem, I've seen that a few times. Cisco FXO ports pickup the phone on the first ring detect and then generate their own ringback while the IP phone is being signaled. If the remote end hangs up the FXO port is expecting to get a battery-reversal indicating the disconnect. If it doesn't get the battery-reversal the port does not know the line has been disconnected and continues to signal the phone. Contact your telephone provider and ask them to add disconnect supervision to the line. An easy way to test your line for disconnect supervision is to hook up a test set (or an analog telephone) directly to the phone line. Place a call to or from that line to another phone (like your cell phone), it doesn't matter which direction you place the call. Hang up the remote end, but keep listening on the phone line. If you hear a click followed by a dialtone then you have the battery-reversal disconnect supervision enabled. If not you'll just hear dead air. Don't listen for too long to the dead air because the telco will play a off-hook tone which can be loud.
... View more