The Microsoft Support Team works around the clock to assist customers in troubleshooting issues with Lync Server. In each article in this NextHop series, senior Microsoft Support engineers walk you through a real-life support case, giving an insider’s view into the systematic approach they use to troubleshoot the issue. These incidents are picked based on areas seeing top support volume.
You know the saying: “Give a man a fish and you feed him for today. Teach a man to fish and you feed him for a lifetime.” Well, that is our intention with this series: To help you solve your own issues within specific areas with the same prescriptive steps that Microsoft Support engineers used to troubleshoot the issue.
Today’s article comes from our esteemed colleague, Jigar Dani. Jigar is a Microsoft Senior Support Escalation Engineer and has written numerous articles for NextHop.
Have you ever placed an outbound PSTN call from a Lync 2010 client and not heard a ringback tone? If this occurs, it’s hard to determine if your call is being connected or if you should disconnect and restart the call. I recently encountered this issue and decided to troubleshoot the cause. This article explains the techniques I used to troubleshoot the issue and provides suggestions you can use to prevent this from occurring in your Lync deployment.
Author : Jigar Dani , Microsoft Lync Program Manager
Publication date : September 27, 2012
Product version : Lync Server 2010
The easiest way to avoid the ringback issue is to use PSTN gateways or IP-PBX products that are certified by the Microsoft Unified Communications Open Interoperability Program (UCOIP). It is recommended to use certified gateways in all Lync Sever 2010 Enterprise Voice deployments. Use the Unified Communications Open Interoperability Program site to find links to deployment guides for recommended devices. If your deployment scenario is different than the scenarios suggested in the guides, work with the vendor to re-qualify the specific use case and version.
When users make an outbound call, they expect to hear a ringback tone or caller tune that signifies that the call is progressing and ringing at the other end. If the line is silent the user may think the connection has failed and cancel the call even though the called party is ringing. This article explains one of the main reasons why users do not hear a ringback tone when dialing out to the PSTN and explores ways to avoid this issue.
A normal call set up looks like this:
Figure 1. Normal Outbound Call Flow
The 180 Ringing message sent from the gateway to the Lync client, signals the Lync client to play a ringing tone. These tones are not transmitted from the callee to the caller in RTP media packets; the ringing tone is generated locally by the Lync client.
The most common reason a caller doesn’t hear a ringing tone is due to an early media setup conflict. Early media is the media exchange that occurs between the two end points before the call is accepted. In the call flow shown in Figure 1, this media exchange occurs before the 200 OK\ACK.
Early media was introduced to avoid media clipping. Media clipping occurs when the initial packets of a media call are dropped because a call is accepted before the connection is fully established. To learn more about early media see Early Media and Ringing Tone Generation in the Session Initiation Protocol RFC 3960 .
The RFC stipulates that as soon as an RTP packet is received, the receiving endpoint should start playing the RTP media and stop playing local ringing. Section 3.2 of RFC 3960 reads:
1. Unless a 180 (Ringing) response is received, never generate local ringing.
2. If a 180 (Ringing) has been received but there are no incoming media packets, generate local ringing.
3. If a 180 (Ringing) has been received and there are incoming media packets, play them and do not generate local ringing.
Note: A 180 (Ringing) response means that the callee is being alerted; a User Agent Server (UAS) should send such a response if the callee is being alerted, regardless of the status of the early media session.
Sometimes, we see that a media packet is received before or just after 180 Ringing is received. When this occurs the ringing tone is not played to the caller.
It’s possible that this incoming media packet is just comfort noise or it may be a packet to open the media channel (some gateways do that). Whatever the reason may be, if the Lync client receives a media packet, it does not play the ringing tone which effectively masks 180 Ringing.
By default Lync Server 2010 has early media enabled. If you always want to hear ringing, you need to work with the gateway vendor to disable early media. Sometimes, even with early media disabled, you will receive an inbound RTP packet – this may be caused by a bug on the gateway side or a race condition. Either way, it has to be fixed by the gateway vendor. Work with them for a resolution.
Reminder: only use gateways listed on the Microsoft Unified Communications Open Interoperability Program .
Obtain a network packet capture from the Mediation Server and follow the call to see if a media packet was received before or just after the 180 Ringing message.
Network traces are a great tool for troubleshooting media issues. In this case, the timing of the first RTP packet received from the gateway, in relation to the 180 Ringing packet determines whether local ringback is played.
After the changes are made, verify there are no inbound RTP media packets arrive, prior to call set up.
In this article we explained why early media is the top reason why Lync Server 2010 Enterprise Voice users do not hear ringback tones when making outbound PSTN calls. To insure that callers hear a ringing tone when placing a call, work with your approved gateway provider to resolve the issue for your Lync Server 2010 deployment. Stay tuned for more LyncMD blog posts in future.
Keywords : PSTN, outbound, Lync, ringback, 180 Ringing, early media, LyncMD, NextHop, Jigar Dani, Unified Communications, Office Communications Server, PBX, Enterprise Voice, Mediation Server, Gateway
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.