cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3046
Views
0
Helpful
10
Replies

CTS --> EX90 / 503 Service Unavailable

Simon Battye
Level 2
Level 2

Hi all,

Another day another issue...

I have configured a SIP trunk between VCS-Control and CUCM, Trunk is active using TCP, Dialled Number Analyzer matches correct route pattern and resolves against SIP trunk. Locate tool on VCS confirms that my search rules and transforms are configured correctly.

Software Dependencies look like this:

CUCM: 8.6.2

VCS: X7.2

Endpoint: TC5.1.4

CTS: 1.9.2

The Issue Problem:

Calls initiated from CTS fail instantly; if i browse onto the CTS Endpoint and check the SIP log messages, i see the following 503 service unavailable message:

screenshot1.jpg

I've taken a netlog trace on the VCS, can't see any traffic hitting the VCS based on the CTS call - if i where to make a call in the other direction, the call would connect OK.

Anyone else come across this problem?

Thanks, Si

10 Replies 10

Alok Jaiswal
Cisco Employee
Cisco Employee

Simon,

from the logs we see that after 100 trying 503 service unavailable comes, however there is  ime difference between the 100 trying and 503 as in it take around 5sec.

so it seems CUCM is going in search but we can't say anyhting what happened on CUCM? as you said since in the netlog of vcs you don't see anything so i am assuming something is happening in CUCM..

collect the RTMT on the CUCM and check under that.

i had a issue for call coming from VCS to CUCM and then going to PSTN. eventhouhgh under DNA i see its going in proper search but it doesn't workout. So i created a new CSS and PRT and after that it started working.

but i can't say you have the same issue

Thanks

Alok

Alok,

I've taken an SDI trace from the CTS endpoint (SIP Stack)

Firstly, i can confirm that their are no dial plan conflicts, and the alias in the logs '81000' (EX90) is resolvable based on the Route Pattern and SIP Trunk.

Looking over the trace, it appears that the communication between CUCM and VCS times out, CUCM then closes the TCP connection resulting in the 503 Service Unavailable message.

Is there a particular error/statement within the SDI which i need to look out for? A common one based on the 503 Service Unavailable message maybe>?

Thanks, Si   

Hi Simon,

Defintely a configuration problem,

Have you configured the Zone in VCS to have CUCM, if yes which protocol are you using between CUCM and VCS.

Make sure of 2 things:

1. CUCM SIP Trunk to VCS using TCP or UDP

2. VCS Zone to CUCM matches whatever protocol you are using in 1.

Reset SIP trunk in CUCM

Verify Zone in VCS to CUCM appears as green an active

You can use network capture and you will be able to see if TCP socket from CUCM to VCS is open.

Question: From VCS to CUCM calls work?

Hi Simon,

As pointed by Gonzalo check the protocol used on the zone.

Also if you captured the RTMT logs and you see 503 seervice unavailable coming in can you paste the message here??

what is the cause code??

Thanks

alok

Hi,

Gonzalo: I can verify that the SIP Trunk is configured correctly, SIP Trunk Security Profile is configured as TCP+UDP, VCS using TCP for connection. Zone is active (green) on VCS. I'm having another issue with calls from VCS to CUCM, where the call connects, CTS drops out of the call after 3 seconds but the EP and VCS believe the call is still 'active' displaying a frozen image - I have this one logged with TAC.

Alok:

Below is the 503 service unavailable message:

SIP/2.0 503 Service Unavailable

Via: SIP/2.0/TCP 137.205.161.1:34317;branch=z9hG4bK2064518f

From: "01239000001" <01239000001>;tag=001da2393d1600762fd37a4d-00aa878e

To: <81000>;tag=986392~313aa1b9-d8e7-444e-ba36-3647c3466273-18697326

Date: Tue, 11 Sep 2012 14:23:35 GMT

Call-ID: 001da239-3d160008-4ed8f849-29db028c@137.205.161.1

CSeq: 101 INVITE

Allow-Events: presence

Content-Length: 0

This SIP Handler is the only thing i can find outlining the actual cause/disc code:

15:23:40.013 |//SIP/SIPHandler/ccbId=0/scbId=0/ccsip_api_call_disconnected: ccb->cc_disc_cause (38); ccb->sip_disc_cause(503)|1,100,63,1.997442^137.205.161.1^SEP001DA2393D16

Does this help?

Thanks, Simon

Simon,

From the logs it seems you have issue with SIP trunk. I see code 38 which is network out of order. a couple of checks for you.

- check the device pool on SIP trunk and phone ( any geolocation policies???)

- try to delete the sip trunk and re-add again.

is this CUCM in a cluster?? if yes, which server is the primary call agent ?

Thanks

Alok

Alok,

Interesting, Device Pool is OK, there are no geographiocal policies as its only a small deployment, all registered CTS's are local.

Deleted the SIP Trunk and Route Pattern, re-added with the same results. There is only a single PUB in this deployment, no SUB (I know its not best practise )

I'm going to be out of the office now for a day or so, so i'll pick this up when im back - possibly get a SR raised.

Cheers, Si

Simon,

I believe you didn't have changed the outgoing transport type under the sip trunk security profile.

i couldn't find anything and may be this require a deep dive in CUCM logs and probably VCS logs for both the issue you are facing.

Please go ahead and open the TAC case.

Thanks

Alok

Hi Simon,

Couple of things:

a) Any firewall in the middle? or VCS and CUCM in same LAN

b) The zone type in VCS is CUCM ?

c) In CUCM SIP trunk are you using the vcs-interop LUA SIP normalization script for Media best-effort?.

If not a problem can you upload SDI/SDL traces I can take a look.

-Gonzalo

There are lots of things that can cuase this issue, you can usually tell by looking at the call logs on the VCS.  The issue that I came across the device was registered to the vcs with a sip alieas of 1001@vcsdomain.com, the call logs showed that the destination was 1001@10.10.10.10:5060.  The exact same error message was noted, a 503 service unavailable.  To fix this a transform was added to replace the IP address of the vcs with the configured sip domain.

Pattern Type = REGEX
(^.*)@10.10.10.10(:5060)
Replace
\1@vcsdomain.com

All the search rules configured to search the local zone are configured for the SIP configured domain, so transform applied first and then the search rule.  This may not be the issue some are running into, but it is one of many that can cause the 503 service unavailable error.