call/video not working between Cisco jabber for Windows and VCS control C40s

[Gustavo Moreschi]

Hello,

I've been struggling with no luck how to make a call using Cisco Jabber for Windows 9.6.0 registered to CM 8.6.2 with intercluster ICT to another CM 8.6.2 where we have a VCS Control 7.0.2 via GK H225, and all C40s are registered as H.323.

The VCS has interworking between H323 and SIP, however not sure if there is any problem with that. Assuming it is ok, not sure either if I'm facing any interoperability issue because in my remote site I have C40 (H323 registered at VCS and SIP listening mode) and cisco jabber for windows which is SIP based.

If is not possible, would I be able to change my C40 from H323 to SIP at VCS, or have both H323/SIP registered at VCS? If so, will I need to change as well instead of GK I'll have to establish a SIP Trunk between the CM and VCS?

Another thing I do not believe either I would be able to have one VCS connected with two clusters, right?

I'm just trying to find a solution in case my current topology is not compatible, but feel free if you have any better idea to make it work.

Anyway here is what is happening:

When I make a call from my cisco jabber windows to C40 using alias number. The call is being redirected just fine to the C40 and it rings, however when someoene or the auto answer picks it up, the call dropped right away.

However, if I enabled the MTP in my CSF device, the call gets longer before dropping. I was even able to see my jabber " start video" turns green, before was grayed out all the time and the call dropped faster. I hear a fast busy tone. 

I'm able to provide SDI traces, logs, diagnostic sip/h323 calls from VCS in order to know for sure if this is an incompatible issue or something I can workaround.

Let me know if someone of you are interested in read these logs or could point me on the right direction.

Thanks!

[Ayodeji Okanlawon]

Please send both cucm sdi logs and VCS diagnostics logs..include calling and called number as well as time of call in the logs

[Gustavo Moreschi]

Ayodeji, thanks so much for looking into this for me.

For VCS time logs will be 10:50pm with MTP enabled, and 10:52pm without MTP;

For CM SDI log will be 9:50pm with MTP, and 9:52 without MTP;

Calling #: 4122107 (from cisco jabber for windows)

Called alias #: 7597 (C40)

I'm sending you in the word file all kind of details logs for VCS. Also the VCS diagnostic, and CM SDI traces.

Please let me know if you need anything else.

Once again thank you!

[Ayodeji Okanlawon · Accepted solution]

Ok,

I have looked at both logs. I have to mentinon though that you didnt

provide the log that shows the h323 setup between cucm and the VCS. This

is  most likely because the call originated from a different cucm than

the ones you provided the logs from.

The call would have orginated from the first cucm in the cucm group of

this trunk: Name=RL_TRUNK_VIDEO

The cucm ip will be : 10.252.53.10.

This is the VCS log that confirms where the h323 request originated

from:

pr 10 22:50:29 TWELDVCS01 tvcs: UTCTime="2014-04-11 01:50:29,187"

Module="network.h323" Level="DEBUG":  Src-ip="10.252.53.10"  Src-

port="54000"
 Received RAS PDU:

Having said that here is my analysis of the logs that you sent..

Jabber sent an INVITE to CUCM and advertised all the codecs (audio and

video it can support)..

Observer that Jabber says it doesnt support G729 anexB

21:55:16.576 |//SIP/SIPTcp/wait_SdlReadRsp: Incoming SIP TCP message

from 10.223.20.73 on port 54677 index 90661 with 2220 bytes:
[862370,NET]
INVITE sip:7597@10.223.25.11;user=phone SIP/2.0
Via: SIP/2.0/TCP 10.223.20.73:54677;branch=z9hG4bK000029d3
From: "4122107" <sip:4122107@10.223.25.11>;tag=00059a3c78000011000070b0

-00000e65
To: <sip:7597@10.223.25.11>
Call-ID: 00059a3c-78000008-00002e6e-00006ff2@10.223.20.73
Max-Forwards: 70
Date: Fri, 11 Apr 2014 01:55:16 GMT
CSeq: 101 INVITE
User-Agent: Cisco-CSF/9.4.1
---
---
---
m=audio 19252 RTP/AVP 0 8 18 105 104 101
c=IN IP4 10.223.20.73
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:105 G7221/16000
a=fmtp:105 bitrate=24000
a=rtpmap:104 G7221/16000
a=fmtp:104 bitrate=32000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv
m=video 28878 RTP/AVP 97
c=IN IP4 10.223.20.73

++++Now lets observer the capabilites exchange during h245 negotiation

between cucm and VCS++++

Here CUCM advertises its caps to VCS (afterreceiving caps from VCS)
Note that G729A, G729AB, G729 is all advertised..

Apr 10 22:50:31 TWELDVCS01 tvcs: UTCTime="2014-04-11 01:50:31,017"

Module="network.h323" Level="DEBUG":  Src-ip="10.252.53.10"  Src-

port="45660"
 Received H.245 PDU:
 value MultimediaSystemControlMessage

::= request : terminalCapabilitySet

---
--
 capabilityTableEntryNumber 2,
       capability receiveAudioCapability :

g729wAnnexB : 6
     },
     
     {
       capabilityTableEntryNumber 3,
    

   capability receiveAudioCapability : g729AnnexAwAnnexB : 6
     },
     
 

    {
       capabilityTableEntryNumber 4,
       capability

receiveAudioCapability : g729 : 6
     },
     
     {
       

capabilityTableEntryNumber 5,
       capability receiveAudioCapability :

g729AnnexA : 6
     },

++++++
After doing MSD (master slave determination, we move to the OLC phas e..
Here we see that the far end..c40 wants to use G729AB for media++++

Apr 10 22:50:31 TWELDVCS01 tvcs: UTCTime="2014-04-11 01:50:31,783"

Module="network.h323" Level="DEBUG":  Src-ip="10.224.114.11"  Src-

port="11163"
 Received H.245 PDU:
 value MultimediaSystemControlMessage

::= request : openLogicalChannel :
 {
   forwardLogicalChannelNumber 1,
   

forwardLogicalChannelParameters
   {
     dataType audioData :

g729AnnexAwAnnexB : 20,
     multiplexParameters

h2250LogicalChannelParameters :

+++Next VCS sends G729AB as the codec to use to CUCM+++
Apr 10 22:50:31 TWELDVCS01 tvcs: UTCTime="2014-04-11 01:50:31,784"

Module="network.h323" Level="DEBUG":  Dst-ip="10.252.53.10"  Dst-

port="45660"
 Sending H.245 PDU:
 value MultimediaSystemControlMessage

::= request : openLogicalChannel :
 {
   forwardLogicalChannelNumber 1,
   

forwardLogicalChannelParameters
   {
     dataType audioData :

g729AnnexAwAnnexB : 20,
     multiplexParameters

h2250LogicalChannelParameters :

++++The next thing we get is an OLC reject from CUCM and this is where

th call drops++

Apr 10 22:50:31 TWELDVCS01 tvcs: UTCTime="2014-04-11 01:50:31,790"

Module="network.h323" Level="DEBUG":  Src-ip="10.252.53.10"  Src-

port="45660"
 Received H.245 PDU:
 value MultimediaSystemControlMessage

::= response : openLogicalChannelReject :
 {
   

forwardLogicalChannelNumber 1,
   cause dataTypeNotSupported : NULL
 }
 
Apr 10 22:50:31 TWELDVCS01 tvcs: UTCTime="2014-04-11 01:50:31,790"

Module="network.h323" Level="INFO":  Dst-ip="10.224.114.11"  Dst-

port="11163"
  Detail="Sending H.245 OpenLogicalChannelRejResponse

+++We then receive a call release from cucm with cause code of 47:

resource unavailable++++

Apr 10 22:50:32 TWELDVCS01 tvcs: UTCTime="2014-04-11 01:50:32,365"

Module="network.h323" Level="DEBUG":  Src-ip="10.252.53.10"  Src-

port="50913"
 Received H.225 PDU:
 Q931
 {
   Message Type: Release

Complete
   Call reference flag: Message sent from originating side
   

Call reference value: 0x7b
   Info Element : Cause
   {
     Location: Usr
 

   Cause Value: Resource unavailable
   }
   Info Element : User User
   {
 

   Length = 22

Suggestions:

Change the region setting between the ICT trunk to VCS and Jabber to use

G711 and test again.

[Gustavo Moreschi]

I have no word how to describe your prompt help on this matter...once I setup G711 all the way down to another cluster, it worked right away....very impressive your ability to identify the problem...thank you very much!

[Ayodeji Okanlawon]

I am happy I could help.

George thanks for the compliments.

[Gustavo Moreschi]

Another possibility issue is the Trunk between local cluster and VCS inbound calls is set 4 for significant digits, maybe that's why it worked when I did a test call from C40 to cisco jabber for the local cluster CM8.6 using just 4 digits.

In my case I would need to set 13 significant digits without breaking calls from VCS to the local cluster to send this call to remote cluster. How that would be possible?

[azeem.haider]

Hi everyone,

I have problem that calls are not working from Cisco jabber to an Video Endpoint registered on VCS Control..

But if i call from VCS Control registered end point to cisco Jabber, calls is working fine with Video and Audio.

Any Suggestions please..

[Ayodeji Okanlawon]

Azeem,

Please open a separate thread for this..

[azeem.haider]

Sorry..But how to open a new Thread..

[Ayodeji Okanlawon]

On the IPT page, look at the right hand side, you will see Actions>create a new discussion

[azeem.haider]

Hi Ayodeji,

This is the Link...

https://supportforums.cisco.com/discussion/12420751/video-calls-jabber-vcs-c-registered-end-points-not-working

[George Thomas]

+5 to Ayodeji for the wonderful explanation. You rock!

[Gustavo Moreschi]

Ayodeji, I was able to make call to C40 from cisco jabber. However, I'm not able to call from C40 to Cisco Jabber.

As I'm pretty new in video, I believe the issue is the route in the VCS.

Based on my call history I'm getting h323 <> sip, instead of h323-h323, connection failed due to interworked.

For some reason this call is being sent to traversalzone (vcs expressway), instead of Defaultzone. Not sure how to redirect it to Defaultzone...Any idea?

I tried to create a specific rule for the dial plan to call from VCS intercluster to my cisco jabber, but no success. Not sure either if the rule I created was right...

Although I was able to make another call from C40 to Cisco Jabber extension where the VCS is connected to the local cluster. I'm not able to call from C40 to another cluster that I'm connected to. The difference is 4 digits dialed for local cluster against 13 digits for remote cluster (my cisco jabber) from C40. 

I can collect the logs for both calls one which is working for local cluster and another one which doesn't even ring for remote cluster (my cisco jabber). Let me know if you would be able to check what's going on.

Any help is much appreciate!

[Ayodeji Okanlawon]

Your call will go via the traversal zone because you need VCSc to stay in the media path for any calls that require inter-working ie sip-h323. Do you have a sip based neighbor zone to cucm or h323 peer?

To dial the remote cluster, you need to have a neigbour zone created to that cluster. You then need to configure a search rule and set that rule to be routed out via that neighbor zone.