cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1200
Views
0
Helpful
19
Replies

Inter-Cluster Trunk between CUCM 6.0 & CUCM 8.6

CiscoAzs
Level 1
Level 1

Good day colleagues.
I faced with a strange situation please help to understand.

There are two CUCM-a first CUCM1 v6.0, second CUCM2 v8.6.
between CUCM Inter-Cluster Trunk, a call to both sides successfully passes. But if the call immediately after the conversation, the call passes but not heard on either side, and 18-19 seconds after the connection is dropped. But if after a successful call to wait for about a minute and call everything works perfectly. It turns out that one of the CUCM can not immediately end the call and the session hangs. Anyone else encountered this problem?

2 Accepted Solutions

Accepted Solutions

The issue is on the other side. The other side of the trunk is not sending the OLC and OLCAck, causing a media timeout on this cluster where the call is made from.

 

\2014-04-21_11-07-25\cm\trace\ccm\sdi\ccm00000203.txt.gz
 
>> digit analysis for the number called.
12:06:09.970 |Digit analysis: match(pi="2", fqcn="1199", cn="1199",plv="5", ... dd="8222",dac="0")|1,100,56,1.3759697^10.100.4.55^SEPE84040A31567
12:06:09.970 |StationD:    (0000753) DialedNumber dialedNumber=8222 lineInstance=1 callReference=19418084.|1,100,56,1.3759697^10.100.4.55^SEPE84040A31567
 
>> setup is sent to the other side.
12:06:10.100 |H225Cdpc::handleCcSetupReq(153, 19418085): H225Setup sent to IP=192.168.106.10|1,100,56,1.3759697^10.100.4.55^SEPE84040A31567
12:06:10.101 |SPROCRas - {
  h323-uu-pdu 
  {
    h323-message-body setup : 
guid '8062566962C3413513003C010A640437'H
 
>> we get call proceeding and alerting.
12:06:10.238 |In  Message -- H225CallProceedingMsg -- Protocol= H225Protocol|*^*^*
12:06:10.243 |In  Message -- H225AlertMsg -- Protocol= H225Protocol|*^*^*
 
>> alerting tone is played to the phone.
12:06:10.244 |StationD:    (0000753) StartTone tone=36(AlertingTone), direction=0.|1,100,13,2612.6^192.168.106.10^*
 
>> the phone at the other side has picked up the call. Now audio has to be established.
12:06:12.575 |SPROCRas - {
  h323-uu-pdu 
  {
    h323-message-body connect :
    
>> IP Phone and h323 leg are connected on this cluster.
12:06:12.575 |ARBTRY-ConnectionManager-wait_AuConnectRequest(19418084,19418085)|1,100,13,2612.10^192.168.106.10^*
12:06:12.576 |ARBTRY-ConnectionManager- wait_AuConnectReply(19418084,19418085)|1,100,180,97.1^*^*
 
12:06:12.577 |StationD:    (0000753) CallState callState=5 lineInstance=1 callReference=19418084 privacy=0 sccp_precedenceLv=4 precedenceDm=0|1,100,180,97.1^*^*
 
>> H245 messages exchanged between the sides.
12:06:12.707 |H245ASN - TtPid=(97) -Outgoing #625 -value MultimediaSystemControlMessage ::= request : terminalCapabilitySet : 
12:06:12.839 |H245ASN - TtPid=(97) [0xfbc1298 2828 bytes] -Incoming #534 -value MultimediaSystemControlMessage ::= request : terminalCapabilitySet : 
12:06:12.839 |H245ASN - TtPid=(97) -Outgoing #626 -value MultimediaSystemControlMessage ::= response : terminalCapabilitySetAck : 
12:06:12.842 |H245ASN - TtPid=(97) [0xfbc1da8 1444 bytes] -Incoming #535 -value MultimediaSystemControlMessage ::= response : terminalCapabilitySetAck : 
12:06:12.842 |H245ASN - TtPid=(97) -Outgoing #627 -value MultimediaSystemControlMessage ::= request : masterSlaveDetermination : 
12:06:12.968 |H245ASN - TtPid=(97) [0xfbc1da8 1444 bytes] -Incoming #536 -value MultimediaSystemControlMessage ::= request : masterSlaveDetermination : 
12:06:12.968 |H245ASN - TtPid=(97) -Outgoing #628 -value MultimediaSystemControlMessage ::= response : masterSlaveDeterminationAck : 
12:06:12.971 |H245ASN - TtPid=(97) [0xfbc1da8 1444 bytes] -Incoming #537 -value MultimediaSystemControlMessage ::= response : masterSlaveDeterminationAck : 
 
>> This cluster sends OLC to the other side.
12:06:12.971 |H245ASN - TtPid=(97) -Outgoing #629 -value MultimediaSystemControlMessage ::= request : openLogicalChannel : 
        dataType audioData : g711Ulaw64k : 20,
 
>> For the next 12 seconds, there is no action. The other side did not respond with OLCAck. Nor did the other side send an OLC to this side.
So there is a timeout, and this cluster sends release-complete to the other side.
12:06:24.590 |Out Message -- H225ReleaseCompleteMsg -- Protocol= H225Protocol|*^*^*
12:06:24.590 |Ie - Q931CauseIe IEData= 08 02 80 AF |*^*^*
 
>> CUCM instructs phone to play busy tone to user
12:06:24.590 |StationD:    (0000753) StartTone tone=37(ReorderTone), direction=0.|1,100,13,2612.10^192.168.106.10^*
 
 
>> This is the SDL signal that shows there was a timeout.
005319461 |2014/04/21 12:06:24.589 |100 |SdlSig    |MXAudioPathCheckTimer                  |interfacesEstablished          |MediaExchange(1,100,135,8478)    |SdlTimerService(1,100,3,1)       |1,100,13,2612.10^192.168.106.10^*        |[R:H-H:0,N:0,L:0,V:0,Z:0,D:0] 
 
 
 
AF - Resources unavailable, unspecified The channel or service that the user requests is unavailable for an unknown reason. This problem is usually temporary.

View solution in original post

It's difficult to say without looking at the other side. However, it could be

1/ that a media resource such as an MTP/Xcoder may be needed on the other side, and for the second call, this fails. This is less likely because why should only the second call fail?

2/ a defect that the 6.0 cluster is hitting in the h323 protocol stack, causing this issue. This is most likely. The ICT may be behaving in a weird manner.

View solution in original post

19 Replies 19

Sreekanth Narayanan
Cisco Employee
Cisco Employee

Hello,

I'm not sure I understand your problem clearly. Do you mean that if you make a second call immediately after ending the first call, you have no way audio on the call? And if you make the second call after a minute, there is no problem?

hantale

Sree

Hello Sree,

Yes, you are right.

I think after the first call session for a long time (about 1 minute) is not closed.

Do you see this with particular phones only? Or is this across all phones?

Is this happening only for skinny/sip phones or both?

Has this ever worked before?

We need to look at detailed CUCM traces to see what's happening. Here's a doc which walks through what needs to be set in the CUCM traces.

https://supportforums.cisco.com/document/126941/cucm-trace-lookup-different-scenarios

 

1. All phones

2. For both phones

3. No, it is a new connection

Which output in RTMT needed for fix this problem?

We need detailed Cisco CallManager traces to see what's happening.In RTMT, you'll need to go to Collect Files -> select CCM service from all services and collect them for a time period.

Dear Sreekanth,

All needed traces in attachment.

 

What are the called and calling numbers? Did you face the issue on the second call?

I am call from 1199 to 222 numbers and backward. Yes 

(my route pattern 8.xxx and 8.xxxx)

I am seeing only calls from 2219, 2216, 2215, 2224, 2234  dialing to 222. Is it one of these calling numbers?

No calling number 1199, buy the way, how you see the traces?

Calling time: 17 Aprel 08:40

There are no traces for that time in the logs that you have provided.

I extracted the CiscoCallManager SDI and SDL trace zip files, and then searched for dd="222" in them. This stands for Digits Dialed. Every time the digits are dialed, there will be such an instance in the traces.

Dear Sreekanth,

I am collect only CM traces for test, please check it.

Dear ciscoazersun,

I checked the trace and am unable to find any call made to 222. Can you please check if the interval you selected for collecting the traces was right?

 

Dear Sreekanth,

I created a new trace and initiated first call from 1199 to the number 222 at 12:05, implemented through 8 pattern. Then I initiated a second incorrect call at 12:06

Please see attachment

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: