Issue with a SIP Trunk between VCS and CUCM

[bruno zenkri]

Hi everyone,

I have created a SIP Trunk between a VCS control (X7.1) and a CUCM 8.6.

I have followed this deployment guide  Cisco_VCS_Cisco_Unified_Communications_Manager_Deployment_Guide_CUCM_6-1_7_8_and_X7-0.pdf.

The trunk is up, but I have the following issue: I can ring from an EX90 registered on the VCS to a 9951 registered on the CUCM but when I pick up the call, I have a busy tone (both audio and video). When i Ring from 9951 to the EX90, I have the following message on VC: cannot reach the contact.

I have a status 503/service unavailable on the call history, and a "call rejected" on the event log.

My transform is OK and the call is sent to my CUCM neighbor zone

Do you have any idea to fix this issue?

Thanks for your help

Best regards

Bruno Z.

[Simon Battye]

Bruno,

How have you set your SIP trunk up, TCP or TLS? What have you set your zone authentication to?

I would suggest the following:

- What does a locate search return on the VCS for the 9951's alias: @VCS-DOMAIN

- Take a Netlog on the VCS and reproduce the call scenario, download the log and check what messages you are getting between CUCM and VCS.

- Check software revisions on both your 9951 and EX90, are they up-to date?

Thanks, Si

[bruno zenkri]

Hi Simon,

I have set up  my trunk in TCP, with no authentification .

When I do a locate search on the 9951 alias ex:2004@vcs-domain, it returns 2004@CUCM_IP:5060.

Both EX90 and 9951 are up to date, but I'm not even able to establish a call between EX90 an non-video phone (same problem).

You will find in attached file the netlog: the search rule is applied and the call is sent through my CUCM Zone SIP INVITE with the good alias. I have a SIP response 200 OK. Codecs are negotiated, then I have A SIP message 180 RINGING.

Then the problem is maybe here:

Jul 24 16:18:51 AzlanVCS tvcs: UTCTime="2012-07-24 14:18:51,194" Module="network.http" Level="DEBUG":  Message="Response" Src-ip="127.0.0.1" Src-port="4370" Dst-ip="127.0.0.1" Dst-port="40790" Response="200 OK" ResponseTime="0.002704" Ref="0x7f18d522fa20"

The source and destination IP is the loopback. Then, i got the SIP message 503.

Maybe you will see other issues...

Thanks for your help!

Best regards

Bruno Z.

[Patrick Pettit]

Hi Bruno.  For some reason, the CUCM is returning 503 Service Unavailable here.  Are you running a cluster of CUCM's in this case?  Do you have sdi trace from CUCM Side? 

You get as far as 180 ringing which is good, but then 503 Service Unavailable is returned to the VCS Side.  Plus the user agent says TC4.2.1.  Maybe give TC5 a try here if your able to upgrade. 

Let us know?

VR

Patrick

[bruno zenkri]

Hi Patrick,

I 've tried to call from a SX20 running in TC5, and I've got the same isue.

In the SDI file attached, I've seen some strange thing such as "can't find remdest 77100 in map", but maybe you will see more issues...

Thanks a lot

Bruno Z.

[Alok Jaiswal]

Hi Bruno,

are you sure that the software is TC5? because in RTMT logs invite shows.

INVITE sip:2004@172.16.24.200:5060 SIP/2.0

Via: SIP/2.0/TCP 172.16.23.100:5060;egress-zone=CUCMZone;branch=z9hG4bK4fd747c6489f994766abc092debc531b5224.a37f2d94465321e6f2e3d9108a0e13f0;proxy-call-id=497414dc-d638-11e1-a95e-0010f323097e;rport

Via: SIP/2.0/TCP 172.16.23.1:5060;branch=z9hG4bKd948e0c0e7738a631f0fd9441db5da0e.1;received=172.16.23.1;rport=56297;ingress-zone=DefaultSubZone

Call-ID: c9ecc18ab4067157@172.16.23.1

CSeq: 100 INVITE

Contact: <>77100@azlan.fr;gr=urn:uuid:1c604cf2-9820-513f-978b-25b74065b021;ob>

From: "77100@azlan.fr" <>77100@azlan.fr>;tag=76560d02c81d1148

To: <>2004@azlan.fr>

Max-Forwards: 15

Record-Route:

Record-Route:

Allow: INVITE,ACK,CANCEL,BYE,UPDATE,INFO,OPTIONS,REFER,NOTIFY

User-Agent: TANDBERG/515 (TC4.2.1.265253)

so it seems software is still TC 4.2.1

also the logs are truncated..it doesn't have full log after 180 RINGING message..so we don't  know what happened after that..

but i do see some normalization script errors in the logs.

have you checked the codecs? is it proper? if you attach full logs from RTMT then it will give you more details..if possible open a TAC case for faster resolution as it might require deep analysis of logs from CUCM as well as VCS side both.

Thanks

Alok

[bruno zenkri]

Hi Alok,

The log I sent you comes from a TC 4.2 endpoint, but I have tried with a TC5 endpoint,and I have the same issue.

I'm going to collect another SDI log and RTMT log.

Thanks for your support.

Bruno Z.

[Alok Jaiswal]

Hi Bruno,

looking at the logs i see the below in the message for 503

Detail="Receive Response Code=503, Method=INVITE, To=sip:2004@azlan.fr, Call-ID=9e4b7baaaf69c9e4@172.16.23.1"

Jul 24 16:18:53 AzlanVCS tvcs: UTCTime="2012-07-24 14:18:53,238" Module="network.sip" Level="DEBUG":  Src-ip="172.16.24.200"  Src-port="5060"

SIPMSG:

|SIP/2.0 503 Service Unavailable

Via: SIP/2.0/TCP 172.16.23.100:5060;egress-zone=CUCMZone;branch=z9hG4bKabf1fa9a37a90edd21907eec698e09c43012.5ac9f05f6460c8c61f659f8de98c3433;proxy-call-id=7ddcdbc6-d59a-11e1-81d2-0010f323097e;rport,SIP/2.0/TCP 172.16.23.1:5060;branch=z9hG4bKa64fa924fc5ed6d07a9aca6502b15bb9.1;received=172.16.23.1;rport=56297;ingress-zone=DefaultSubZone

Call-ID: 9e4b7baaaf69c9e4@172.16.23.1

CSeq: 100 INVITE

From: "77100@azlan.fr" <>77100@azlan.fr>;tag=f28da7f3b5b36d30

To: <>2004@azlan.fr>;tag=18116~9706be09-5d26-47fd-b90e-1aeb1e365089-19182674

Date: Tue, 24 Jul 2012 14:22:33 GMT

Allow-Events: presence

Reason: Q.850 ;cause=47

Content-Length: 0

it seems to me  a issue with codec i guess!!check the codec at CUCM side. set it to G.711

Thanks

Alok

[Alok Jaiswal]

pulling RTMT logs from CUCM will also help.

cheers

Alok

[Patrick Pettit]

HI Bruno.  Alok is right.  After the 180 Ringing, do not see any more traffic from this CUCM.  Do see that an INVITE is sent to a .18 address. 

Call-ID: ccc13c80-f1b866-1d-c81810ac@x.x.x.200

Do you know what this address is?  I'm curious why we do not see the 503 service unavailable here either. When the time frame you pulled the traces, maybe it didn't include it?

I'm curious to the .18 address.  Is this the phones IP address?

If we can get the full trace, would be best.

Also, as Alok stated, there are some normalization script errors listed as well.  What script do you have selected on the SIP trunk by chance? 

Let us know?

Thanks in advance.

VR

Patrick

[bruno zenkri]

Hi Patrick,

You will find another SDI file taken from the RTMT.

IP .200 is CUCM

.18 is the phone

I use the VCS interop script, but it seems to generate errors, but I have the same issue without using it.

Unfortunately, my company didn't bought smartnet warranty, so I'm unable to open a case...

Thanks for your help!

Bruno Z.

[Patrick Pettit]

Hi Bruno.  Seems its trying to allocate MTP, but no resource is applied and it fails.  The phone profile in CUCM, can you verify MTP is checked or not?  If so, uncheck, apply config, restart, reset, wait for the phone to come online  and try again? 

VR

Patrick

[Patrick Pettit]

Hi Bruno.  Also, re-verify the region settings for this region the phone resides.  Its trying to allocate MTP cause the audio codec may be trying to run at G729.  Since the caps don't match, it tries to allocate MTP and its not configured and fails.  This section seems relevant to me:

14:30:53.844 |DET-MediaManager-(37)::preCheckCapabilities, region1=R_FRBSY, region2=SC Azlan Region, Pty1 capCount=9 (Cap,ptime)= (43,0) (44,0) (45,0) (46,0) (6,20) (40,0) (41,0) (4,20) (2,20), Pty2 capCount=7 (Cap,ptime)= (6,20) (89,60) (4,20) (2,20) (86,20) (11,20) (12,20)|1,100,63,1.22277^172.16.24.18^*

14:30:53.844 |RegionsServer::MatchCapabilities -- kbps=8, capACount=9, capBCount=7|*^*^*

14:30:53.844 |DET-MediaManager-(37)::preCheckCapabilities, caps mismatch! Xcoder Reqd. kbps(8), filtered A[capCount=0 (Cap,ptime)=], B[capCount=2 (Cap,ptime)= (11,20) (12,20)] allowMTP=0 numXcoderRequired=1 xcodingSide=1|1,100,63,1.22277^172.16.24.18^*

Then:

14:30:53.844 |DET-MediaManager-(37)::allocateProxies, j=1 XferMode(16 0) CI(19182711 0) mrid(0 0) resrcCI(0 19182713)|1,100,63,1.22277^172.16.24.18^*

14:30:53.844 |SIG-MediaManager-(37)::allocateProxies, allocating resources(1), additional res(0)|1,100,63,1.22277^172.16.24.18^*

14:30:53.844 |MediaResourceManager::waiting_MrmAllocateXcoderResourceReq - CI=19182713, Count=2|1,100,63,1.22277^172.16.24.18^*

14:30:53.844 |MediaResourceManager::waiting_MrmAllocateXcoderResourceReq - CREATING CHILD USING MRGL LIST|1,100,63,1.22277^172.16.24.18^*

14:30:53.844 |MediaResourceManager::sendAllocationResourceErr - ERROR - no transcoder device configured|1,100,63,1.22277^172.16.24.18^*

14:30:53.844 |DET-MediaManager-(37)::wait_AllocateMtpResourceErr, resCI=19182713, numRes=1, numPreRes=0|1,100,63,1.22277^172.16.24.18^*

14:30:53.844 |DET-MediaManager-(37)::reAdjustConnectionList, CIXcoderWRFC2833=19182713|1,100,63,1.22277^172.16.24.18^*

If you can, double check the region settings and verify its not configured for G729 if possible.  Slate it for G711 like Alok mentioned if you can, and retry the call and let us know? 

VR

Patrick

[Alok Jaiswal · Accepted solution]

Hi,

yes, thats right!!this seems to me at first sight a issue with codec negotiation when i see the cause code 47.

anyways set the region settings to G.711 from trunk to phone in case if you have different device pool and region for trunk and ip-phones.

make it G.711 end to end and test again.

Thanks

Alok

[bruno zenkri]

Hi everyone,

I have changed the region setting to G711 and it' working!

Many thanks to all of you for all your support!

Cheers.

Bruno Zenkri