Solved: CUCM (Cisco Jabber) - VCS - MCU (SIP-SIP Call Failed)

Stefan Walter · ‎10-30-2012

Hello everyone,

in our Videoinfrastructure their is a little problem with cisco jabber client register on the CUCM to our MCU.

The MCU is registered on the VCS.

If I do a SIP call from my Cisco Jabber Client the call failed. I'm calling the Number 4925488XXX. The callingparty is the 25203232.

In the CUCM there is a Routepattern which translate the number to "Called Party Number = 8099" (this is the SIP Trunk to the VCS).

Called Party Transformations:

Called Party Mask = 8XXX

Discard Digits Instruction = None

Prefix =

Called Number = 8099

In the VCS their is a transform for the called Number 8099.

The MCU is registerd with 99@xxxx.xxx on the VCS - this is the auto attandant.

In the Cisco Jabber client I never receive video or sound of the MCU AA - it's look like that the call isn't connect.

If I spent a look in the VCS I see the call as active and connected.

Also I traced the call from the VCS in debug mode.

SIPMSG:

|SIP/2.0 180 Ringing

Via: SIP/2.0/TLS CUCM IP SIP ;branch=z9hG4bK10ea4511f7965;received=CUCM;ingress-zone=CUCMUC

Call-ID: b6958600-8a19125-10424-6083ca0a@10.202.131.96

CSeq: 101 INVITE

Contact: <sip:99@MCU;gr=urn:uuid:c4a744d7-5975-52db-b21c-8c519fbab06e>;isfocus

From: "Stefan Walter" <sip:25203232@10.202.131.96>;tag=252394~c75f2de1-fd7b-43c2-8bd0-6b72860c9048-46890229

To: <sip:8099@VCS IP>;tag=11B05829C2080000

Record-Route: <sip:proxy-call-id=b7e41e30-1f71-11e2-a211-0010f32081f0@VCS SIP;transport=tls;lr>

User-Agent: Codian MCU 4505 v4.3 (2.18)

Content-Length: 0

|

2012-10-26T15:33:25+02:00 DDUCP001 tvcs: UTCTime="2012-10-26 13:33:25,230" Module="network.sip" Level="INFO": Src-ip="CUCM IP" Src-port="39813" Detail="Receive Request Method=CANCEL, Request-URI=sip:8099@VCS IP, Call-ID=b6958600-8a19125-10424-6083ca0a@CUCM IP"

2012-10-26T15:33:25+02:00 DDUCP001 tvcs: UTCTime="2012-10-26 13:33:25,230" Module="network.sip" Level="DEBUG": Src-ip="CUCM IP" Src-port="39813"

SIPMSG:

|CANCEL sip:8099@10.202.80.21:5061 SIP/2.0

Via: SIP/2.0/TLS CUCM IP SIP ;branch=z9hG4bK10ea4511f7965;received=10.202.131.96

Call-ID: b6958600-8a19125-10424-6083ca0a@CUCM IP

CSeq: 101 CANCEL

From: "Stefan Walter" <sip:25203232@CUCM IP>;tag=252394~c75f2de1-fd7b-43c2-8bd0-6b72860c9048-46890229

To: <sip:8099@VCS IP>

Max-Forwards: 70

Date: Fri, 26 Oct 2012 13:33:25 GMT

Reason: Q.850 ;cause=3

Content-Length: 0

########################

Reason: Q.850 ;cause=3 ;text="No route to destination"

You have any hint for me where I can troubleshoot further ? It is an MCU issue or CUCM or VCS ?

bye

Stefan

Patrick Pettit · ‎10-30-2012

Hi Stefan. I'd probably run an SDI Trace on the CUCM as well. Seems the cancel is coming from CUCM side and ending the call. To verify that your possibly running into: CSCty07061, I would run the SDI trace and see after it receives 180 Ringing from VCS if it tries to do a DNS Query for @mcu.

Entries may look like:

|2,100,63,1.3508793^10.52.36.15^*

11:20:09.377 |//SIP/SIPDns(2,72,1)/wait_SdlDnsSrvRecordRsp: Received SdlDnsSrvRecordRsp ReqCode is -1|0,0,0,0.0^*^*

11:20:09.377 |//SIP/SIPDns(2,72,1)/copyRecordRspToRecordReq: Retry SRV query as an 1 query|0,0,0,0.0^*^*

11:20:09.377 |//SIP/SIPDns(2,72,1)/wait_SdlDnsSrvRecordRsp: (DNS A or AAAA query called as SRV query Fail)hostname=mcu

--------------

If this is what your running into, fake address to resolve @mcu would be needed for the call to proceed. I'm basing this off an assumtion here, but can't actually guarantee this is what your running into. But check the SDI trace AFTER the 180 ringing and see.

Hope this helps.

VR

Patrick

View solution in original post

Patrick Pettit · ‎10-30-2012

Hi Stefan. Need to resolve domain.domain.de. CUCM tries to resolve the address in contact header and it fails hence the bug. The DNS server being used by CUCM, create an A record for domain.domain.de and it can resolve to any IP address. It doesnt matter where it resolves to as long as it passes to proceed the call.

Hope this helps.

VR
Patrick.

Sent from Cisco Technical Support Android App

View solution in original post

Patrick Pettit · ‎10-30-2012

Hi Stefan. I'd probably run an SDI Trace on the CUCM as well. Seems the cancel is coming from CUCM side and ending the call. To verify that your possibly running into: CSCty07061, I would run the SDI trace and see after it receives 180 Ringing from VCS if it tries to do a DNS Query for @mcu.

Entries may look like:

|2,100,63,1.3508793^10.52.36.15^*

11:20:09.377 |//SIP/SIPDns(2,72,1)/wait_SdlDnsSrvRecordRsp: Received SdlDnsSrvRecordRsp ReqCode is -1|0,0,0,0.0^*^*

11:20:09.377 |//SIP/SIPDns(2,72,1)/copyRecordRspToRecordReq: Retry SRV query as an 1 query|0,0,0,0.0^*^*

11:20:09.377 |//SIP/SIPDns(2,72,1)/wait_SdlDnsSrvRecordRsp: (DNS A or AAAA query called as SRV query Fail)hostname=mcu

--------------

If this is what your running into, fake address to resolve @mcu would be needed for the call to proceed. I'm basing this off an assumtion here, but can't actually guarantee this is what your running into. But check the SDI trace AFTER the 180 ringing and see.

Hope this helps.

VR

Patrick

Stefan Walter · ‎10-30-2012

Hi Pettit,

thanks for your reply.

I collected the SDI Traces from the CUCM and see this output:

SIP/2.0 180 Ringing

Via: SIP/2.0/TCP 10.137.163.69:51340;branch=z9hG4bK3554c54f

From: "Stefan Walter" <25203206>;tag=d4a02a88c49b40133af4b1ab-15462b0d

To: <4925488099>;tag=296200~c75f2de1-fd7b-43c2-8bd0-6b72860c9048-46890660

Date: Mon, 29 Oct 2012 14:55:56 GMT

Call-ID: d4a02a88-c49b003e-7b07060d-5361483f@IP

CSeq: 101 INVITE

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

Allow-Events: presence

Call-Info: ; security= NotAuthenticated; orientation= to; ui-state= ringout; gci= 2-13915; call-instance= 1

Send-Info: conference, x-cisco-conference

Remote-Party-ID: <8099>;party=called;screen=yes;privacy=off

Contact: <4925488099>;isfocus

Content-Length: 0

|2,100,63,1.301260^10.202.80.21^*

15:55:57.059 |//SIP/SIPDns(2,72,1)/wait_SdlDnsSrvRecordRsp: Received SdlDnsSrvRecordRsp ReqCode is -1|0,0,0,0.0^*^*

15:55:57.059 |//SIP/SIPDns(2,72,1)/copyRecordRspToRecordReq: Retry SRV query as an 1 query|0,0,0,0.0^*^*

15:55:57.059 |//SIP/SIPDns(2,72,1)/wait_SdlDnsSrvRecordRsp: (DNS A or AAAA query called as SRV query Fail):hostname=domain.domain.de, ReqType=1,serversused=0

|0,0,0,0.0^*^*

Seems so that we are running in

CSCty07061 .

Can you explain me what to you mean with fake address to resolve the @mcu
??

BR

Stefan

Patrick Pettit · ‎10-30-2012

Hi Stefan. Need to resolve domain.domain.de. CUCM tries to resolve the address in contact header and it fails hence the bug. The DNS server being used by CUCM, create an A record for domain.domain.de and it can resolve to any IP address. It doesnt matter where it resolves to as long as it passes to proceed the call.

Hope this helps.

VR
Patrick.

Sent from Cisco Technical Support Android App

Stefan Walter · ‎10-30-2012

Hi Patrick,

I'm understandig that the CUCM (the DNS) will resolve the domain.domain.de.

Tommorow I'll contact our DNS Admin to fixed it.

Think that I create a A record to the IP-Adresse of our VCS. Think that will fixed the problem.

It's right that with SW 9.0 XXXX the bug is fixed ? Can we also upgrade the CUCM to 9.0 ???

Thanks a lot for your help!

Patrick Pettit · ‎10-30-2012

Hi Stefan. Sure. I do believe upgrading to CUCM 9 should fix this. Or, when the address in the Contact Header is looked up, all you need is CUCM to resolve it so it can complete, cause if it can't, the call will fail. So maybe pointing domain.domain.de to the IP of the VCS and that should be ok. If calls still fail, will need to see another trace to see whats going on.

VR

Patrick