- CUCM was inserting a PRACK in the call setup signaling for every call to Lync
There were multiple 183 session progress messages between CUCM & Lync
- Cisco has a documented ringback bug (CSCtf87428) that was discovered in CUCM 7.1.3.
- According to the Cisco Bug Toolkit CSCtf87428, “OCS connected to CUCM via SIP and call coming in via H323 GW we get multiple “183 Session progress” from the OCS without any SDP information. At this point CUCM is sending “Progress” to the gateway with PI = 8, so the GW stops playing the ringback. As there is no SDP information received from OCS side the calling party gets silence.”
- According to the Cisco Bug Toolkit CSCtf87428, CSCtf87428 is resolved in 7.1(5.11006.2). Unfortunately, we were not in a position to upgrade the Cisco cluster and ringback was
working in the lab. We therefore opted to not upgrade CUCM and to investigate the issue further.
As outlined in the SIP RFC 3261, I expected to see something similar to the following:
- 100 Trying
- 183 Session Progress
- 180 Ringing
- 200 OK
- RTP (Audio)
After working with the client to compare settings between the lab and production CUCM environments, we uncovered an interesting setting. Under the CUCM Service Parameters for the Cisco CallManager service, there is a field called SIP Rel1XX Enabled. Below is a screenshot of the configuration that had been set. SIP Rel1XX Enabled had been set to Send PRACK for all 1xx Messages.
The IT Leader's Guide to Multicloud Readiness
This guide provides practical key insights and important factors to consider to make informed decisions in your multicloud journey.
Download the Guide
As indicated in the right-hand column of the screenshot, the default setting for SIP Rel1XX Enabled is disabled. We scratched our heads… This setting had obviously been manually changed, but by whom and for what reason. After circling back with other team members, we had uncovered that this had been enabled as part of a previous initiative. Long story short, the setting was deemed not critical and we received approval to change the setting back to the default value of disabled. Below is a screenshot of the updated configuration.
After SIP Rel1XX Enabled had been set back to the default value, we captured a few more call traces between the two platforms. As shown in the screenshot, the call setup signaling looked better and more importantly ringback worked!
Hmm, this sounds a lot like what I’m experiencing, but our setup is different
Cisco ISR 2901 — Voice T1 —— Verizon POP
Lync FE+Med —– |
Outside callers hear single ring, then silence until pickup. When we had UM misconfigured, there would be a ring once every 20 seconds or so, when Lync would attempt a non answer transfer, fail, and re-connect to the soft endpoint.
Still working on this.
YOu can disable this from the VG if the calls are going through VG using the command rel1xx disable under voice service voip
voice service voip
I recently faced an issue with our Cisco VG and Lync integration. No CUCM is coming in the picture.
did you get any update for this issue as I have the same scenario that you have.
I am having the same issue. Rings once, then no ring. Any other ideas? I tried the rel1xx disable, did not resolved the issue.
Hey Matt, are you able to capture a Net Mon or Wireshark trace? Lets see what the signaling is telling us.