cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1171
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?

19 Replies 19

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.

Thanks for the detailed answer, and what could be the reason? Do you have any idea?

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.

Dear Sreekanth,
I decided a long time not to waste time on ICT and the configured SIP Trunk.
The problem is solved thanks for your participation.

Great to hear that! SIP ftw! :)

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: