I was reading and configuring a pair of CUBEs to be redundant according to the document:
and in particular, these lines:
ip rtcp report interval 3000 gateway media-inactivity-criteria all timer receive-rtp 86400 timer receive-rtcp 5
I found another document that provides more detail about the meaning of the timers:
The timer receive-rtcp value argument (or Mfactor) is multiplied with the interval that is set using the ip rtcp report interval command. If no RTCP packets are received in the resulting time period, the call is disconnected.
Ok. All that said. What happens is a call going through the CUBE pair will be dropped after 15 seconds if not answered!
The 15 seconds come from multiplying 3000 milliseconds by 5.
I changed the IP RTCP REPORT INTERVAL to 12000 and now callers have 60 seconds of not being answered before the CUBE drops the call.
I bring this up in this forum for two reasons. If I am right, perhaps some other soul can benefit from knowing this. The other reason to find out if I am right?
I think it incredible that the CUBE redundancy document would set up the CUBEs so calls must be answered in 15 seconds. Does anyone else have this configuration?
Thank you for your time.
I wouldn't expect an RTCP timer to kick in until such time as media is established, this doesn't normally happen until the call is answered.
Where is the call routing to? CUCM? Something else?
Do you have RTCP enabled on whatever system CUBE is routing to?
We discovered the issue when an incoming call to CUCM dropped after 15 seconds. We lowered the No Answer Ring Duration timer to less than 15 seconds and the call forwarded to voice mail (CUC) properly.
It appears the RTCP timer is ticking before the call is answered.
RTCP is disabled on all phones, however, once the call is established, it does not drop.
Another post in the forums (https://supportforums.cisco.com/document/111031/call-drop-after-25-seconds) suggests diabling the timers completely.