Problem between VCS and CUCM

[Nick Halbert-Lillyman]

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.

[algalvan]

Hello,

• 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.

•SIP 1xx—Informational Responses

•SIP 2xx—Successful Responses

•SIP 3xx—Redirection Responses

•SIP 4xx—Client Failure Responses

•SIP 5xx—Server Failure Responses

•SIP 6xx—Global Failure Responses

A full list of SIP codes may be found here:

http://www.cisco.com/en/US/partner/docs/voice_ip_comm/cucm/managed_services/8_0_1/cucm/rtmtdeftalrt.html#wp1050638

If you have little experience reading logs you may want to use the Voice Log Translator (VLC) tool.

http://www.cisco.com/en/US/partner/docs/voice_ip_comm/cvlt/2_7/english/user/guide/vlt277.html

• 4.      If multiple routes are using the same Trunk you may want to verify that the routes do not change the digits in any way.   Please remember that route groups can be configured to change digits too.

Has this configuration ever worked?

[Nick Halbert-Lillyman]

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.

[cfiestas]

Have you collected the sip traces from ucm and the vcs?

[Nick Halbert-Lillyman]

Update: We got it working (Well, it just started working on it's own).

I suspect the issue was with the subscriber itself as it seemed to be doing some other funny things also.