Monday, August 28, 2017

Change Caller ID for Individual Skype for Business/Lync 2013 Users on Sonus 1k/2k SBC

I've had multiple clients approach me with the same scenario in Skype for Business/Lync 2013: <NAME> in <DEPARTMENT> wants to change the caller id for their individual DID or extension to a different number.  For clients that have a Sonus 1k/2k SBC, this is very easy to do.

Transformation rules on the Sonus 1k/2k SBC allow for manipulating the 'Calling Party Address/Number' field. The 'Calling Party' is who initiates the call. If we change the calling party from the users number to the number they want, that addresses their issue.

First, we create a transformation rule. Below are examples for both an e164 number and an extension:

Extenstion Example

E164 Example

Lastly, we'll also need to include a 'catch all' rule. The 'catch all' rule catches any other number and passes it through without manipulation. Below is an example:





Catch All Example

After our rules are created, we'll need to make sure they are ordered correctly. Transformation rules are evaluated from top to bottom. If our 'catch all' rule was ordered above our e164 rule, for example, then our e164 rule would never be evaluated. Clicking the pencil icon at the top of the page will allow us to use arrows to move our rules up and down the list of tranformation rules. Use the arrows to move any rules you created above the 'catch all' rule and then click save.

Sunday, August 6, 2017

Skype for Business 30 Second Inbound Call Delay

A customer contacted me with an inbound call issue. Inbound calls were taking at least 30 seconds to connect, and some would not connect at all. While I've experienced call delays before, the root cause was different each time I investigated.

Since the issue was happening so frequently, I took a SIP trace from their Audio Codes Gateway. I noticed the following pattern in the SIP trace:

INVITE
SIP 183
INVITE
SIP 183
CANCEL
200 OK

If everything was working correctly, *I should* see the SIP 183 answered with a '200 OK' rather than an additional SIP 183. My initial thought was, "Why isn't the carrier answering my 183 message?" I spoke with an engineer from the carrier (AT&T) and he provided logs from his end showing they were, in fact, answering my SIP 183. The customer side, however, was not sending the SIP 200 back to them.

What's going on here? The carrier's log proved they weren't causing the problem. The other time I've experienced this issue was due to a network issue. Specifically, a customer's router was looping traffic due to misconfigured routes. The traffic appeared to be routed correctly, though. What else could be causing this?

I asked the customer if any changes had been made recently. The customer mentioned they recently shutdown ports 80 & 443 to the outside due to the WannaCrypt Virus.

Bingo! We found our culprit. 😉

During the ICE (Interactive Connectivity Establisment) Negotiation for audio/video, the Edge Server provides a list of candidates to help Skype for Business find the best possible path for media. The Edge Server *must* have ports 80 & 443 open to the outside world for HTTP/HTTPS traffic. Since the customer had shut off these ports, ICE Negotiation was disrupted. Once the ports were opened via the firewall again, the inbound audio delay disappeared.