Ringback, Silence, Ringback

It can be easy to take things like the dial-tone, or ringback for granted… until they don’t act like you expect them to. And we all know that if something doesn’t act like¬†people expect, it can only mean one thing.. increased calls to the IT helpdesk ūüôā

Here’s my retrospective diagnosis, and a fix for a ringback¬†issue I encountered with a client recently.

First of all, let’s set the scene, the¬†client¬†had Lync Server 2010 behind a Dialogic with Mitel MCD 3300 upstream connected to the PSTN via ISDN30e.¬†And¬†the baseline user experience was…

  1. Enter a number or select a contact in Lync
  2. Hear the Lync ringing tone
  3. Call was answered

We’ll come back to why this worked in a moment, I don’t want to spoil the surprise. Let’s move on to what happened after the first change.

The Mitel and Dialogic was replaced with a Sonus SBC 1000, still connected to the PSTN via the same ISDN30e

And the user experience was now…

  1. Enter a number or select a contact in Lync
  2. Hear the Lync ringing tone for a second or two
  3. Hear a different ringing tone
  4. Call was answered

A small change, two types of ringing tone, but not the end of the world, it was acceptable. Again, more on why in a moment.

Final piece of the puzzle was when they migrated from ISDN to SIP. Then this happened…

  1. Enter a number or select a contact in Lync
  2. Hear the Lync ringing tone for a second or two
  3. 3-5 seconds of silence!!!
  4. Hear a different ringing tone
  5. Call was answered

What’s going on there? ‘Why the silence’ – I hear you ask, well it’s¬†lucky you’re reading this, I will explain…

How it used to work on ISDN

Here is a quick comparison between how ISDN Messages are translated into SIP Messages

CALL PROCEEDING or PROGRESS 183 Session Progress
CALL PROCEEDING (with PI:1 or PI:8) or PROGRESS (with PI:1 or PI:8) 183 Session Progress with SDP
ALERTING 180 Ringing

PI = Progress Indicator, and 1 = Not end-to-end ISDN, 8= Inband information available.

And here is a pseudo call flow.

Step Time Direction Message
1 0.0s Outbound SETUP
2 0.1s Inbound CALL PROCEEDING
3 0.2s Inbound PROGRESS with PI:1
4 4.9s Inbound ALERT
5 10.0s Inbound CONNECT

So if you will¬†follow me for a moment, judging by the reported experience it would seem the Dialogic or Mitel had Early Media disabled, or it wasn’t supported,¬†so the ringing tone was generated by Lync until the SDP was¬†exchanged and end-to-end media negotiated, which in this case was when the call was answered in step 5 and 6.

Next up the Sonus with ISDN, the 2nd ringback the user heard was being generated on the Sonus because Early Media was enabled. And the Sonus seemed to be interpreting the CALL PROCEEDING / PROGRESS in step 2 or 3 in such a way that caused it to generate ringback which was sent to the Lync user.

There is a ‘twist’ to this story, because after upgrading to it behaved the same as the SIP Trunk example, i.e. with added silence.

What can we change?

Under the Signalling Group on the Sonus you get the following¬†setting…

Play Ringback

Specifies when to generate local ring back

  • Auto:¬†Depends if inband audio is available
  • Always:¬†Always generate inband ringback
  • Never:¬†Never generate inband ringback

That’s nice, but they only apply when an ALERT (or a 180 Ringing) message is received. When set to Always the Sonus would generate a¬†ringback from step 4 (correctly), albeit the¬†firmware version previously installed by the client acted on step 2 or 3 above. For more information on this visit Creating and Modifying SIP Signaling Groups – Play Ringback, and click where it says “Click to see more information about this topic”¬†three times, yes there is more each time you expand, and scroll down, they must really want to hide those diagrams. First shows Auto, next shows Always, and finally shows Never.

It’s actually the newer firmware that is the ‘correct’ behaviour, however there is a workaround available using Message Translations to eliminate the silence – if I remember correctly it’s in the Sonus Solutions Base behind a partner / customer login so I can’t share the link here.¬†But it forces the Sonus to hear ALERT when it actually receives CALL PROCEEDING or something along those lines, this didn’t really apply because¬†the client was moving to SIP.

How it worked on SIP

Step Time Direction Message
1 0.0s Outbound INVITE with SDP
2 0.0s Inbound 100 Trying
3 0.4s Inbound 183 Session Progress with SDP
4 0.4s Outbound PRACK
5 0.4s Inbound 200 OK (for PRACK)
6 3.7s Inbound 183 Session Progress (without SDP)
7 3.7s Outbound PRACK
8 3.7s Inbound 200 OK (for PRACK)
9 10.0s Inbound 200 OK (for INVITE)
10 10.0s Outbound ACK

Because Step 3 arrived with SDP, the¬†Sonus established¬†Early Media with the Lync User and they heard what the provider¬†was sending – which was silence. But it wasn’t until step 6 that the provider sent ringback which was when the remote device¬†reported it¬†was¬†ringing.

Disabling Early 183¬†on the Sonus didn’t help¬†because the issue was on outbound calls, and the ITSP was responding to the INVITE with a “183 Session Progress with SDP” anyway, so the Sonus couldn’t ignore it.

Why the silence?

Silence is by design. Strictly speaking 183 Session Progress doesn’t mean the call is ‘ringing’ yet. There is another message for that,¬†180 Ringing. Either¬†of those can contain an SDP to support Early Media. When the Sonus receives 183 Session Progress with SDP, it passes that through to Lync, and whatever media is being generated by the remote device will be heard by the Lync user. In this case it’s silence, and it’s not until the called number (i.e. a mobile phone in this example) starts to physically ring, does the ITSP generate ringback.

But silence can be disconcerting, how many times have you tried to dial a number on your mobile phone, and waited with it to your ear, and then had to look back at the screen to make sure it still says “Dialling…” or “Calling…” etc, then¬†you hear the ringback.. If it’s just me, maybe I’m on a bad network. Anyway, essentially that’s the same thing happening here. The user hears the ringback when the device is ringing.

But whilst Lync is setting up the call with the Sonus, it generates¬†it’s own ringback to the user, so this is actually what’s happening, and why we had 2 ringback tones…

  1. Enter a number or select a contact in Lync
  2. INVITE sent to the Lync Server
  3. Hear the Lync ringing tone for a second or two
  4. INVITE sent to Sonus and it responds with 100 Trying, and creates the next leg of the call with the ITSP and sends back 183 Session Progress with SDP
  5. 3-5 seconds of Silence!!! while the call is being connected to the called party
  6. The remote device actually starts to ring and 180 Ringing, or another 183 Session Progress (this time without SDP) is sent back
  7. Hear a different ringing tone
  8. Call was answered

The Fix

Using SIP Message Manipulation Rules it was possible to change the 183 Session Progress¬†into 180 Ringing, therefore telling Lync that it’s ringing from the start and still maintain the Early Media and SDP negotiation, and therefore recovering the user¬†experience they originally had.

Go to SIP -> Message Manipulation -> Message Rule Tables -> +


Expand the new Message Rule Table and add a new Status Line Rule

SIP-183-180-Status-RuleWhen I expanded the Status Line Value at the bottom and¬†entered just the Status value, and left SIP Version as any, the rule didn’t work, and resulted in an empty status line.. Perhaps a quirk in the firmware. Entering it as above worked.

Test the message rule with a sample SIP Message


And finally, enable SMM on the Signalling Group and select this rule for inbound messages.



Final Word

Just another reason to ALWAYS deploy an SBC between Lync (or any PBX) and a SIP Trunk provider.

Thanks for reading.



Tweet about this on TwitterShare on LinkedInShare on Facebook
Pin on PinterestShare on Google+Digg thisShare on RedditShare on StumbleUponEmail this to someone

About Graham Cropley

Working as a Senior Consultant for Skype for Business, Exchange, and Office 365.


  1. Actually, depending on the SIP provider, you can use the same SMM method to STRIP 183 messages to and from the Lync server. The the Provider can control the message flow and generate proper ringtone.

    But yes, a very good reason to ALWAYS use a SBC

  2. @Graham Cropley: support at SIP trunk providers is usually crappy, and the people you can connect to if you report an issue is guaranteed to be always an idiot (professionally I mean), so they always deny being able to do any change on their side (even though they utilize carrier-grade Session Border Controllers)

  3. Seems like we give you all the best content for your blog ūüėČ

  4. One note of caution on this: it can mask an engaged tone leading to calls from users claiming ‘dropped calls’ i.e. ring ring ring (from the 180 which replaced the 183) then drop.

Leave a Reply

Your email address will not be published. Required fields are marked *