Good afternoon everyone!

I have recently been involved in a Lync Enterprise Voice Telephony pilot, coexisting with Cisco Call Manager (CUCM) during the pilot phase.

So to help give a better understanding of the issue, the below diagram summaries the setup.

 

 

I liked to provide as much info as possible, if you need a quick fix, scroll down to the resolution section 🙂

–ISSUE(S)

During the implementation, we encountered the following;

1. When a Lync user dials a Cisco Handset, that is provisioned against the Site A CUCM, all call control and media is OK
2. When a Site A CUCM user dials a Lync Endpoint, they are presented with an engaged tone
3. When a Lync user dials a Cisco Handset, that is provisioned against the Site V CUCM, call control was OK but as soon as the call was answered, it immediately disconnected
4. When a Site B CUCM user dials a Lync Endpoint, they are also presented with an engaged tone

If you are thinking to yourself right now, signaling is OK, media is not – I like the way you think 🙂

#SideNote – if I had it my way, I would turn off Cisco at 10am during the day (business hours) and migrate all DDIs to Lync…… I very rarely get things my way.

An ISDN and SIP trunk exist between CCM and Sonus SBC, this is because it is easier from a CCM administrative perspective to use a new SIP trunk as extensions are moved from the CCM appliance onto Lync (AD lookups do not cover all call flows).

–TROUBLESHOOTING

So initially, we reviewed the Sonus SBC configuration;

• Call Transformation Tables
• Call Routing Tables
• SIP Server Tables
• Signaling Groups
• Media Lists (Keep these in mind)

….which all seemed OK!

Next up, we reviewed the Lync Voice Routing configuration;

• Dial Plan
• Routes and PSTN Usages
• Trunk Configuration
• Finally Tested Voice Routing – sea of green, all OK we confirmed that the SBC would receive the correct calls

I don’t have any Cisco Call Manager specific knowledge, just voice in general so the customer went away and had a look at CCM, which seemed OK too.

Time to hit up PowerShell…. 🙂

Lync Management Shell;

Start-CsClsLogging -Pool -Scenario IncomingAndOutgoingCall

Reproduce issue….. (made a call between the two estates)

Stop-CsClsLogging -Pool -Scenario IncomingAndOutgoingCall

Sync-CsClsLogging -Pool

Search-CsClsLogging -Pool -Outoputfilepath c:\yourdirectory\yourfilename.txt

Opening the above captured log in Snooper, searching for the extension that was dialed, presented me with the initial issue, the oh so useful “503 Service Unavailable” error being reported by the SBC.

Not much more to troubleshoot in Lync, until we understand why the SBC is presenting us with the 503.

Over to Log Exchange (LX – an amazing tool produced by Sonus, which includes a SYSLOG application required to retrieve traces from your Sonus SBC)

When using the LX tool, it is important to make sure you are reviewing all of the legs for any given call, and not just say, Lync<>SBC log

After reproducing the issue and capturing a log using the Sonus LX logging tool, I then found out that it was the London CCM that was sending the 503 error to the session border controller, which was then passing the message over to the Lync Server and subsequently onto the Client.

So now we know the issue is arising from CCM, we know that signaling is OK, so therefore media must be our issue.

At this point, although the customer instructed me to accommodate for G711 only. Whilst doing some testing in a quite corner by myself, I decided to add the G729 codec into the CCM Media List, configured on the SBC.

NB: if G729 is not available as a codec to choose from then you will need to create the profile first, then assign it within the media lost assigned to the CUCM signaling group.

3 hours later, calls were working OK.

I would have expected to see more information in relation to SDP negotiation failure due to the codec mismatch.

–RESOLUTION

What appears to have been happening is the Cisco Handsets were unable to understand the G711 codec and were producing the engaged tone.

Whilst calls to the SBC SIP trunk connected CUCM1 appliance in Site A were ok, calls to the CUCM2 appliance in site B connected to CUCM1 via an inter site trunk route were failing.

Prioritising this codec, whilst still allowing for G711a law fixed it for me!

The three issues previously listed, were all related to media flow, applying the codec change gave us a quick win for all three problems!

Hope this helps!