Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

New Member

Inter-Cluster Trunk between CUCM 6.0 & CUCM 8.6

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?

  • IP Telephony
Everyone's tags (1)
2 ACCEPTED SOLUTIONS

Accepted Solutions
Cisco Employee

The issue is on the other

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.
Cisco Employee

It's difficult to say without

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.

19 REPLIES
Cisco Employee

Hello,I'm not sure I

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

New Member

Hello Sree,Yes, you are right

Hello Sree,

Yes, you are right.

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

Cisco Employee

Do you see this with

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

 

New Member

1. All phones2. Is this

1. All phones

2. For both phones

3. No, it is a new connection

Which output in RTMT needed for fix this problem?

Cisco Employee

We need detailed Cisco

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.

New Member

Dear Sreekanth,All needed

Dear Sreekanth,

All needed traces in attachment.

 

Cisco Employee

What are the called and

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

New Member

I am call from 1199 to 222

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

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

Cisco Employee

I am seeing only calls from

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

434
Views
0
Helpful
19
Replies