Microsoft

Blog Categories

Subscribe to RSS feed

Archives

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.

Tags: , ,

5 thoughts on “PRACK Causes No Ringback between CUCM and Lync

  1. Keenan Crockett

    Hey Matt, are you able to capture a Net Mon or Wireshark trace? Lets see what the signaling is telling us.

  2. Matt

    I am having the same issue. Rings once, then no ring. Any other ideas? I tried the rel1xx disable, did not resolved the issue.

  3. Riyas

    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
    sip
    rel1xx disable

    I recently faced an issue with our Cisco VG and Lync integration. No CUCM is coming in the picture.

  4. Dovid

    Hmm, this sounds a lot like what I’m experiencing, but our setup is different

    CUCM ————-|
    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.

Leave a Reply