We have a strange issue when trunking between CUCM and VCS.
We have a cluster of CUCM's trunking to a single VCS. SCCP Phones registered to CUCM Subscriber 1 can call VCS endpoints fine but phones registered to subscriber 2 can't (it connects for a second but then disconnects). Internally to CUCM, all calls work OK.
VCS has a SIP peer with both subscribers in the same zone.
Usually for VCS to CUCM problems I would look at SIP profiles etc, but seeing as all phones are using the same trunk (with the same SIP settings) it doesn't seem that this is an issue. Could it be something to do with services running on Subscriber 2, or media resources?
The only difference in configuration between phones that work and don't work is the CUCM group which dictates which CUCM they subscribe to - all other settings are identical.
I'm using CUCM 8.6 and VCS 5.1. I know that I should upgrade VCS (and I will soon) but seeing as it works to one of my subscribers and not the other, I don't think this is the issue.
1. Please check the call routing first. The CUCM has a great tool for this called the Dial Number Analyzer (DNA). Once in the DNA GUI search by phone and then enter the called number. If routes are not present then you will receive the message “block this pattern.” Since the devices are registered to different subscribers I assume they may use different Calling Search Spaces. If the routes associated to the SIP trunks are in different CCS you may not have rights to use them. You may find more information concerning the DNA tool here: http://www.cisco.com/en/US/partner/docs/voice_ip_comm/cucm/dna/8_6_1/dnaguide.html
2. Verify the calling search space of the failed calling device does not allow CUCM translation to be implemented. This can cause a wrong number to be dialed.
3. Check the SIP BYE, 4XX or 5XX message. You will need to make a test call and pull the CUCM traces via RTMT. When a call ends one side of the SIP trunk will present a BYE or failure code. Determine which end closed the call and it an error code (4XX or 5XX) occurred. The SIP BYE message will include a “cause=” field.
They are definitely using the same Calling Search Spaces etc. The only difference between the phones is the CUCM group, all other settings are identical (I made a new Device pool with new CUCM group especially to test this).
I should also note that it seems to connect for a second then drop.
You have reached the Cisco Logistics Support Center.. To Check Status of
your RMA, visit Product Returns & Replacements (RMA). Need help? Contact
us by Phone or Email. North Americas Phone: 1800 553 2447 Option 4
Email: firstname.lastname@example.org Europe Phone: +3...
The short answer is that you don't.... That isn't entirely true while at
the same time it kind of is, but for the most part you don't configure
the softkeys. You enable or disable them via TCL. Here is the long
answer. Be sure to read the whole thing or e...
Topology: IP Phone > Switches > Microsoft NPS setup to forward 802.1x
proxy to > ISE 2.1 patch 3 Authentication: EAP-TLS using Cisco MIC SANs
Phone Models 802.1X support? 802.1x flavor Addtl Comment EAP-MD5 EAP-TLS
Cisco 3905 Y Y N Cisco 6911 Y Y N Cisco ...