External Calls to VoiceMail drop after 40 seconds

[admin-netz]

When Calls are being connected to the VoiceMail of any users, callers can leave a message up to 40 seconds and then the call will be dropped.

I have extra configured RTCP on the CUBE because the CUC stops sending RTPs after the recorded message to let the caller leave the message.

router(config)#ip rtcp report interval 60000

router(config)#gateway

router(config-gateway)#timer receive-rtcp 5

That should allow 300 sec or 5 mins before the call will be cutoff. 60000 msec x 5 = 300000 msec / 1000 = 300 sec

I made again a test call and collected gateway logs. I see in the logs that we get the BYE from the provider. 

 

I contacted the provider and i was informed that the issue is related to the provider being used for the call; in this situation Telefonica Germany. I tried with Telekom Landline and i worked fine, even when i changed the RTCP timer to lower value, it has been worked fine as configured. I tried from other Mobile Providers and the issue is existing. Our Provider says that the issue that we do not send RTPs to Telefonica and that is why the calls drop after 40 seconds. CUC should not also send any RTPs as it receives only when a caller leaves a message and that should not an issue. I am wondering why when i call from Landline, the issue does not happen and only with Mobile providers.

Is there any config which i need to extra check on our CUBE? Or has our provider to change something from his side?

CUCM/ CUC 12.05 Version. Cisco CUBE ISR 4331 16.09.06

[admin-netz]

It is really sad that there is no one to help here...

I made diverse researches and have found this BUG: CSCvm68778

BYE received from Remote as Unity does not Stream RTP while recording in progress
I have enabled RTCP on Unity Connection and since that time all is working fine.

[M.Vredegoor@DZ]

Could you explain how you have enabled RTCP on the Unity Connection!

[Edward Lau]

I don't believe RTCP is supported by Unity Connection yet.

Rather it seems the workaround is to have Unity send comfort noise packets during recording so the call leg is seen as live if CUBE is doing media-inactivity detection.

https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/connection/14/administration/guide/b_14cucsag/b_14cucsag_chapter_0110.html#id_90949

[Stephen Lewis]

I've implemented this workaround but we are still seeing the occasional drop at around 20 seconds, I know it's a particular cell phone carrier and not our carrier otherwise I assume it would occur on every call where a voicemail is left. Are there any other suggestions other than using SCCP setup?

[Maren Mahoney]

Would it be possible to disable silence suppression on the link to the provider so that bi-directional RTP does not stop? There is a dial-peer command for this, or a SIP Profile could be used to modify any "sendonly" or "recvonly" to "sendrecv".

Maren

[Stephen Lewis]

The problem is with a particular carrier, not our provider so I wouldn't want break anything that's working for the vast major of cell callers but thank you for the suggestion.

Steve L.

[Edward Lau]

It really depends on what is disconnecting the call, ie where the "BYE" message originates from.

If it is from your PSTN provider then you'll need to work with them to dig further, they may be able to do something with their handoff to the other carrier.

[Stephen Lewis]

The BYE is coming from beyond our PSTN, that's why it isn't happening on every call that ends up leaving a voicemail. It's down to a particular provider/carrier so this might never be resolved for me. Even the work around didn't help for this carriers calls, made no difference, calls drop at 20 second mark while leaving a voicemail. Just frustrating that the supposed work around didn't help and it probably isn't affecting enough people for Cisco to start sending 2 way RTP streams while leaving voicemails.

[Edward Lau]

The work-around does implement 2-way RTP stream during Unity voicemail recording. If you take a packet capture you will see a RTP packet every 1 sec from Unity while the message is being recorded.

The fact the BYE is coming from your provider when the call disconnects then you should work with them so they can look further into their traffic with the other carrier.

[Stephen Lewis]

My mistake, i will attempt a packet capture to confirm, but it's so random/intermediate might be hard to duplicate to be able to capture. I message back if I able to capture. 

Thanks,

Steve L.