PRACK Causes No Ringback between CUCM and Lync

I recently had the pleasure of working with one of our customers to implement Lync Server 2010 Enterprise Voice with Cisco Unified Communications Manager (CUCM) 7.1.3. The integration between the two systems went pretty smoothly. During our testing phase though, we uncovered an issue with ringback. When a PSTN user or a Cisco IP Phone user would dial a Lync endpoint, the PSTN user and/or Cisco user would hear silence (no ringback) until the call was answered by the Lync user or diverted to Exchange Unified Messaging. Even stranger, we had a lab environment with the same CUCM version and Lync patch version which was working fine. After capturing a handful of call traces between the two platforms, we noticed:

• 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:

• Invite
• 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.

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!

Comments welcomed.