Monthly Archives: August 2018

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.