UCCX continues to send RTP Stream after Call Redirect Step ends script

Randall White · ‎08-30-2018

I am seeing some odd behavior from UCCX. I have a simple script that plays a prompt, then transfers the call to a CUCM Hunt Pilot with Native Call Queueing enabled.

The problem is that the initial audio after the transfer is badly distorted. It should be playing the "Welcome Greeting Sample" from the CUCM MoH server, then transfer the call to the Line Group member. All MoH after the initial "Welcome Greeting Sample" plays OK, and audio is good when the call connects to the Line Group phone. It's just that first audio file from the MoH server.

I did some troubleshooting with a packet capture from the Calling IP Phone. It looks like the Calling phone sends an "RTCP Goodbye" packet to the UCCX server during the transfer, but the UCCX server keeps sending an RTP stream to the phone. This is at the same time as the RTP stream from the MoH server. Both streams go to the same destination port on the calling phone. If I disable the Prompt step in script, then the UCCX server never sends an RTP stream and the "Welcome Greeting Sample" plays out OK. It looks like the bad audio happens when there is two RTP streams going to the same port on the phone.

The Call Redirect > Successful step has a Terminate (-Triggering Contact-) step. I thought that was supposed to stop the RTP stream? Are there any other Best Practices when you terminate a script with a Call Redirect step?

This is on UCCX 10.6 and 11.5, with CUCM 10.5(2). The calling endpoints are Cisco 8851 phones and CUBE (PSTN)

Thanks, Randy

will.alvord · ‎08-31-2018

Hi Randall. Unfortunately I don't have a solution to this, but thought I'd offer a couple of troubleshooting suggestions. Taking the packet capture from behind the phone is all good, but you might want to grab a capture from the server at the same time. Maybe before that, I'd try a UCCX debug and maybe you'll see something useful which will help steer you in the right direction.

Jonathan Schulenberg · ‎09-01-2018

What you describe sure sounds like a big in UCCX. One thing caught my attention though: replace the Terminate (ie hang up) step *after* a successful Call Redirect step with a simple End step. Terminate is going to throw an exception since the call has already left CCX. If that doesn’t fix it I would open a TAC case against CCX.

Randall White · ‎09-04-2018

Thanks. I tried a simple "End" under the successful transfer step, but still have the same problem.

I am also looking at the packet capture from the UCCX server, but don't see anything unusual.

SCCP calling endpoints don't seem have this problem, but I am still testing.

I have opened a TAC case, and I'll post any results.

Randall White · ‎10-15-2018

My TAC case is now closed, with a work around, but no solution. It appears I am hitting something similar to CSCvm68247.

The work around is to disable the Initial Announcement in the MoH Audio Source used by the Hunt Pilot set up for Native Call Queueing. I moved the Initial Announcement wav file to play in the UCCX script, right before the transfer step.

The key issue is that after the Transfer step, UCCX and the CUCM Annunciator are sending RTP packets to the same port on the calling phone (or CUBE gwy), at the same time. The phone's DSP is not designed to do this, so it drops both packet streams. The calling phone sends RTCP-Goodby and ICMP-Port Unreachable packets to UCCX, but these are ignored. The RTP packets coming from UCCX are blank (no audio content). It looks like there are two CTI transfer events. The first is when the UCCX Transfer step happens. It looks like this does not get completed. When the Initial Announcement is done, there is a second CTI event when the MoH music starts to play. UCCX stops the RTP stream when it gets the second CTI command.

None of this happens when you get rid of the Initial Announcement and go straight to the MoH stream. I will test it again when I upgrade to 12.5

Jonathan Schulenberg · ‎10-15-2018

Thanks for sharing the workaround of disabling the Native Call Queuing Initial Announcement. This has "defect" written all over it and it certainly wouldn't be the first one for CUCM NCQ. It's a shame that TAC didn't identify root cause for you; it would probably need both a CCX and CUCM engineer to pin it down.