Tag Archives: Gateway

Trunks, gateways and ports (oh my!)

Posted on by
Reply

I was commiserating with a co-worker recently about how challenging SIP trunks can be when they’re new to you. Specifically we were talking about what port and protocol a device listens on, and what port and protocol the peer device will listen on. Somehow, I agreed that I’d write a blog post about this topic, so here it is!

Here’s a snippet from the SfB topology builder for a gatewaysfb tb gateway

 

Our Gateway has an FQDN, which must resolve to the IP of the peer device. You could also use the IP address here. In larger environments, a meaningful FQDN can be helpful vs trying to memorize or find your (probably outdated) list of IP addresses and gateways.

At the bottom, we see a list of trunks that are configured for this gateway in SfB. You can have more than one, but that’s a more advanced configuration and we’re shooting for basic understanding. Similarly, you can ignore the IPv4 addresses and Alternate Media entries.

Here is the associated the topology builder entry for the trunk:

sfb tb trunks

We’ve got a name for the trunk, which also happens to be the FQDN of the gateway. This is the default that SfB creates, you can change it during (but not after) the creation process.

The PSTN Gateway line has the FQDN and SfB Site (in brackets, HQ here) of the gateway/peer device.

The Listening port and SIP Transport Protocol indicate what protocol and port the gateway device is listening on. We’ll see that in the gateway configuration in a minute.

Mediation Server indicates the FQDN of the mediation server (or mediation pool, if you’ve got a pool of them).

As promised, here’s the configuration on the other end of the trunk, in this case from an AudioCodes SBC, showing what port it’s listening on:

audc sip interface

Here you can see that the device is listening on TCP port 5060. Note that it also appears to be listening on port 0 for UDP and TLS. That’s just AudioCodes configuration for “not listening”

notlisteningemoji

And here’s the entry from the Proxy Set on the AudioCodes SBC showing the SfB mediation pool, and what port and protocol it’s listening on.  Proxy Sets on the AudioCodes devices are the equivalent of the Gateway in SfB topology.

 

audc proxy set

 

Here you can see that the AudioCodes expects the peer device at 10.12.1.101 to be listening on TCP port 5068.

Okay, so why do I have an IP address here, but an FQDN in SfB? Well, you can use either, as we discussed above. However, one thing that we do stumble across (too) often, is someone poking the DNS records for the SfB mediation pool. They don’t understand that “FEPool1.example.com” *should* in fact have one entry per front-end server, so they decide to do some “cleanup”.

There are some common (incorrect) assumptions that we often see. The first is that the port and protocol need to be the same on the devices at both ends of a trunk. This isn’t true. They need to be the same protocol, but it’s perfectly normal for two devices to be listening on different ports.
The other issue we see is the assumption that a specific port/protocol has to be used. You’re restricted to using the protocol(s) that your device supports. That’s always TCP for SfB, and UDP and TCP for most SBCs and gateways. You can use any available port that you wish, though there are some conventions to use 5060 for SIP, and 5061 for SfB’s encrypted SIP, 5068 shows up by default for the Mediation pool to listen on, you can change that if you want too, just don’t get too creative. Somewhere down the road, someone will need to support what you’re creating, and a port of 8765 for SIP traffic is going to seem odd.

AudioCodes Configuration for SfB

Posted on by
1

I’ve worked with a couple of organizations in the past several months that have had… inconsistent configuration on their AudioCodes gateways and SBCs for proper connectivity to multiple (or in some cases single) SfB pools. For simplicity, I’ll use the term “SBC” to mean both the SBC and Gateway, unless there’s a particular need to call out one versus the other.

In an AudioCodes SBC, you can route traffic to/from your SfB system using a variety of uncivilized methods, including specifying IP addresses. Yuck. Do yourself – and those who’ll look at your config after you’re done – a favor and use Proxy Sets. You’ll find those under “Signaling & Media”, then “Core Entities”, then “Proxy Sets”.

A Proxy Set lets you specify a number of characteristics for a system that you want your SBC to communicate with, allowing for much less clumsy and random configuration. Here’s a Proxy Set configured for one simple SfB server:

ProxySetSE

This could be a standalone mediation server, a Standard Edition server, or a solo Enterprise Edition Server. Let’s have a more detailed look at the configuration.

General

ProxySetGeneral

The General section is pretty straight forward. You need to give your Proxy Set a name. There aren’t any particular requirements here, so use something that make sense to you. The first part of your SfB pool name is a good choice “LAXSfBPool”, for example. The name of your telco provider is a good choice for connections to the PSTN. For the rest of this post, I’ll assume you’re connecting to an SfB Standard Edition server.

Next you need to specify the SIP interface that your SfB server will connect on.  A SIP interface is a network interface plus a few other characteristics, like what port and protocol the SBC will listen on. The TLS context is the group of TLS settings that you’ll use to talk to your SfB server.

Keep Alive

ProxySetKeepAlive

SfB uses SIP OPTIONS (yeah, it’s capitalized, I’m not yelling) for two purposes. One is to advertise capabilities (“options”) and the other is as a heart-beat or keep alive mechanism. For connecting an SBC to SfB, you’ll want to set the Proxy Keep-Alive to Using Options. There’s a timer for how often you want these sent – the default is every 60 seconds, and you can leave that in place.  The remainder of the variables here are for tuning the specific behavior of your connection if OPTIONS aren’t received, and what criteria need to be met for the connection to be “up” again. Generally, you can leave these alone – I’ve never had to tweak them in a couple decades of doing this stuff.

Advanced

ProxySetAdvanced

The advanced section has only two settings. Classification Input determines whether the SBC will listen to anything from the specified IP addresses (we’ll see that part later) or if the port and transport type – TCP,UDP.TLS  must match too. Go ahead and change this to include Port & Transport Type if you’re super security aware, otherwise leave it at IP address. For DNS resolve method, you can leave this blank to use the global parameter “Proxy DNS Query Type”. You can do some funky things here, but I’ll talk about FQDNs and IPs later when we specify those.

Redundancy

ProxySetRedundancy

This section is where I see the most misconfiguration. For a Standard Edition server, however, you don’t need any settings here, so leave them at their defaults (having them set won’t affect anything, but sure is confusing to look at when troubleshooting).

Proxy Address

ProxySetProxyAddress

This is the spot where you add the FQDN or IP address, port, and transport type for you SfB servers. You can use server FQDNs if you like, especially for more advanced configurations that use the various DNS Resolve Methods in the Advanced section… However, for SfB, most everyone that I know uses the IP addresses of the servers – they’re unlikely to ever change, and using IPs means you’re not dependent on DNS infrastructure. This also guards against changes or deletions of DNS records, though you have other problems if that happens! I always specify the port and transport type, to prevent any gotchas should the system defaults ever be changed.

Next post, we’ll have a  look at the changes that need to be made when you have an Enterprise Edition pool with multiple front-ends, as well as multiple pools. Just for fun, there are some differences in configuration here if you have a gateway or an SBC.

Normalization and Translation with Gateways and SfB

Posted on by
Reply

Skype for Business has a number of areas where you can normalize or translate a number. When we’re dealing with users, normalization is the process of taking the number that they’ve entered or “dialed”, and converting it to a standard format for further processing. This normalization allows the user to maintain local dialing habits, and convert them to a standard format. That standard format is E164, which also ensures the number is globally unique. When we’re dealing with calls received from the telco or PBX, normalization refers to the process of converting the called number into E164 standard format.

Normalization is a form of translation, but not all translation is normalization. When we’re sending a call out of SfB, we might need to translate to a format that’s expected by the device we are sending the call to. That format might not be standard or globally unique. This translation can take place on both the called and calling numbers. This translations is configured in Trunk Translation Rules.

Trunk Translation rules can only match and translate same field. For example, SfB cannot match on Calling Number and translate the Called Number. However you can match and modify a called number and match and modify the calling number, on the same call.

Outside of SfB, number translation can happen

  • At a PSTN gateway or SBC
  • At an analog gateway
  • At a PBX
  • At the telco (few and far between, but some do!)

The options you have within these systems will vary. Generally speaking, the gateways and SBCs are very flexible, PBXs somewhat flexible, and telcos are something that you shouldn’t count on.

Depending on what are we’re talking about, there are a number of overlapping options available, so which ones should you use?

In general, you’ll want to avoid a smattering of different translations. Where ever possible, keep all of your translations in one system. Which system? Usually SfB, because most organizations have more people that understand SfB more thoroughly than gateways. For example, when you’re sending a call to +14258675309, the telco probably wants you to send only 4258675309 to them. You could strip the +1 within SfB before you had the call to the gateway, or you could strip it at the gateway before you hand it to the telco. SfB is my preferred option here.

Sometimes, your hand will be forces. Let’s say you want all calling numbers (your caller ID) to be changed when you call to a certain area code. You need to match on the called number, but change the calling number. SfB doesn’t handle complex translations like this, so you’ll have to use a gateway.

When you’re considering analog devices dialing through SfB, you can perform normalization in the gateway or in SfB.  If you use a dialplan within SfB, you can take advantage of the “select” feature to select normalization rules that already exist in SfB. Generally, you would want to use the same rules that are in the Dialplan that apply to the local users.

There’s some confusion over how to assign a Skype for Business Dial Plan to an analog device. Technet states “you can then manage the analog device by assigning policies and dial plans to the contact.” It turns out that you can’t apply a dial plan to a CsAnalogDevice. Well, you can apply it, it just won’t work.

When you look at how user level dial plans work, this makes sense. User dial plans are applied at the device level: your SfB client on your PC, your mobile client, or your AudioCodes 440HD phone – any SfB client. An analog phone isn’t an SfB client, nor is the gateway that it plugs into, so there is no place for the normalization rules to be downloaded to and applied. Instead, you need to use a pool level, site level, or global dial plan. These dial plans will apply at the server level for inbound calls, but will also be used for users if a user level dial plan doesn’t exist.

For gateways, I’ll use the Global Dial Plan in smaller environments, and Pool level Dial Plans in more complex or geographically diverse environments. The Global Dial Plan can quickly get messy if you try to stuff in enough rules to handle larger, global deployments.

FXO vs FXS in Skype for Business

Posted on by
Reply

Analog trunks and devices are less and less of a factor in many of the projects that I work on. Areas where I still see analog are branch office trunks, faxes, door buzzers/enterphones, paging systems, and ring-down phones that you might see in a parking lot to contact security or a cab company.

To integrate analog trunks or devices with SfB, you connect them to a gateway. The gateway can come with two types of ports: FXO, and FXS. FXO is an abbreviation for Foreign eXchange Office, and FXS for Foreign eXchange Subscriber.

So, clear as mud and we’re done here, right? If you’re an old school telecom guy, you know there’s a lot of complexity hidden behind that simple jack in the wall. The good news is for nearly all SfB use cases we can boil things down so they’re very simple.

FXO is a port that you plug a telco trunk line into. FXS is a port that you plug your phone or other device into. Mostly. Confusion pops into the picture when you have paging systems or enterphones, which may oddly use the opposite interface than you’re expecting, or give you the option for both.

You can think of FXO and FXS as North and South on a magnet, or male and female, or whatever pairing you’d like. A FXO device plugs into an FXS device, and all is well, like this:

Your phone, which has an FXO jack on it, plugs into the wall, which is an FXS interface.

Your phone, which has an FXO jack on it, plugs into the AudioCodes MP-118 gateway FXS port.

The AudioCodes MP-114 gateway FXO jack plugs into the wall, which is an FXS interface.

 

MP114 back

An AudioCodes MP-114 gateway. From the left are power, Ethernet, RS-232 serial console, two FXS ports and two FXO ports.

Great, so why then would a paging system offer both FXO and FXS interfaces? The answer is that there are two different use cases for the paging system.

One use case is a standalone, where a phone plugs directly into the paging system. You pick up the phone, maybe enter some digits to indicate what zone to page, and you talk away. The paging system is acting as a PBX in this scenario.

The second use case is PBX integrated, where the paging system acts as a phone. You dial the extension for the paging system, it rings and then answers, you maybe enter some digits to indicate what zone to page, and you talk away.

These two use cases also apply to things like enterphones or gate/door buzzers. You can have a phone plugged directly into the enterphone, or you have have the enterphone act as an extension on your PBX.

The standalone option is simple, but restricts you to interacting via a single phone. The PBX integrated option is more complex, but allows you to interact via any phone on the PBX.

Caution: “interact via any phone on the PBX” in the SfB world means that in a global deployment, you could have a prankster user in New York telling jokes over a paging system in Paris. Configure your dial plans appropriately if your paging system doesn’t offer PIN functionality!

If you have a choice between using an FXO port or FXS port on a gateway to integrate with an analog device that offers both, I recommend you pick the FXO port. This has the device act as a PBX, which means that there is no ringing when you call it, and call setup is faster. Disconnects are usually quicker too, which is important if the paging system or enterphone is used a lot.

When you configure the device to plug into an FXO port on the gateway, set the gateway to route calls to that number out via the FXO port you’ve connected it to. If the device will be sending calls to the gateway, set the gateway to

You’ll need to use an FXS port on your device to connect to the gateway’s FXO port. If your device has one port that’s switchable between FXO and FXS, read the manual carefully – I’ve seen some that aren’t clear whether they mean FXO mode is “setting this device to FXO” or “setting this device to talk to FXO”. If it’s really unclear, plug a boring analog phone in. If the line is dead, the device is set to act as an FXS device and the port is configured as an FXO interface.