Checking connectivity to a TCP SIP Trunk is easy enough, “telnet” is the Swiss Army knife of any techie toolkit, and it should show that routing and firewall rules are configured correctly.
However, I’ve had a couple of situations where that wasn’t enough.
First example involved Checkpoint firewalls between all client sites, and it seems the built-in policy for TCP/5061 has SIP Inspection enabled, apart from Lync not working, the only symptom was a short delay with telnet, not very helpful.
Another example I had was where a TLS SIP Trunk kept immediately closing the connection with no error, turned out to be the certificates incorrectly configured by the remote party, it would have been fantastic to see which certificate they were using, and its issuer.
And finally, I recently had to provide a SIP Trunk for a deployment which included a Lync Call Centre (the particular solution was not my suggestion) – which *requires* a UDP SIP Trunk. Suddenly my trusty ‘telnet’ is not looking so useful.
For this UDP SIP Trunk, I searched through a number of SIP Testing tools that I found online, but they all were focussed on call testing, and load generation. I just wanted to see if the trunk was ‘up’ and if I could route to it. ICMP was blocked by the firewall, so ping didn’t work either. All of this needed to be checked prior arranging an engineer to deploy the software and configure.
I knocked up something quick that supports UDP, TCP, and TLS/MTLS SIP Trunks, and emulates a pretty standard SIP OPTIONS Message and listens out for a response.
According to the RFC, setting Max-Forwards to ZERO in the SIP OPTIONS message should prompt the device to respond itself, rather than forwarding on if it happens to be a SIP Proxy, or a firewall with packet inspection enabled, giving you some transparency to see see what device you’re actually connecting to, or what’s intercepting your messages.
It also shows you some handy details about the certificate used by the remote party for TLS connections.
Originally this was designed to be used with SIP Gateways, or SIP Trunks, but it turns out it also works pretty well against Lync Servers too.
Tested successfully against,
|Lync Mediation||N/A||Yes (5068)||Yes (5067)||Yes (5067)|
|Lync Front End||N/A||N/A||Yes (5061)||Yes (5061)|
|Lync Edge||N/A||N/A||Yes (443)1||No (5061)2|
|Sonus SBC / NET UX||Yes||Yes||Yes||Yes|
1 = Responds with 483 To Many Hops etc, because the Lync Edge is basically a SIP Proxy, and you DO get a response, which is the point to this.
2 = TLS/MTLS connection is established and you can see the server certificate used, but it gets forcibly closed by Lync, due to not being the ‘right sort’ of SIP OPTIONS. But again, you’ve made a connection AND you can see which certificate is used. Which is an adequate consolation prize in my eyes.
Send-SIPOptions – Version 1.0
- Version 1.0 – 24/06/2014 – First release!
Just unzip and run from command line – requires .NET Framework 4.5
And obviously – This Software is provided ‘as is’ without warranty of any kind.
If you run it with no parmaters, you’ll see usage details…
Send-SIPOptions.exe <SIP Gateway> <Port> <Protocol> (Local IP) (Local Port) (<Certificate> <Password>)
|SIP Gateway||Remote IP Address or FQDN of SIP Gateway|
|Port||Remote Port for SIP Gateway|
|Protocol||SIP Protocol must be udp, tcp, or tls|
|Local IP||Optional, Local IP Address (Must be valid, and assigned to this computer)|
|Local Port||Optional, Local Port or 'highport' to use random high port|
|Certificate||Optional, Client Certificate (.pfx) used for Mutual-TLS|
|Password||Optional, Password for Client Certificate|
Send-SIPOptions.exe 184.108.40.206 5060 udp 192.168.5.103 5060
Which means it will be…
Sending SIP OPTIONS to 220.127.116.11 on port 5060 as UDP
From 192.168.5.103 on port 5060
OPTIONS sip:18.104.22.168:5060;transport=UDP SIP/2.0
Via: SIP/2.0/UDP 192.168.5.103:5060;branch=z9hG4bK1dftos00203hllce83c1
CSeq: 1 OPTIONS
Allow: INVITE, ACK, CANCEL, BYE, UPDATE, NOTIFY, OPTIONS, REGISTER
Waiting for response...
SIP/2.0 403 Forbidden
Via: SIP/2.0/UDP 192.168.5.103:5060;received=22.214.171.124;branch=z9hG4bK1dftos00203hllce83c1
CSeq: 1 OPTIONS
Allow: CANCEL, ACK, INVITE, BYE, OPTIONS, REGISTER, NOTIFY, INFO, REFER, SUBSCRIBE, PRACK, UPDATE, MESSAGE, PUBLISH
Because I was trying this against the IP Address of Gamma’s SIP Gateway, and I don’t have a Gamma SIP Trunk you can see I’m receiving a 403 Forbidden. Which is good… How else would you know?
Cool huh.. wait there’s more.
Send-SIPOptions.exe 126.96.36.199 5060 tcp 192.168.5.103 5060
Much of the same really, but it uses TCP instead of UDP.
Note that Windows Network Stack keeps TCP Connections open for a short time after they are closed. Identified as TIME_WAIT. This is so any stray packets that arrive after the connection is closed, get sent a RST response, rather than potentially creating a new connection. So if you specify the local port, you will have to wait before running the command again, as the IP:Port combination specified is not available. An easy fix for this is to just wait until Windows times-out the connection, or to use the ‘highport’ so that a random highport is used, and therefore not blocked from running again.
TLS / Mutual-TLS Example
For TLS / MTLS you have to specify the remote device by its FQDN instead of IP Address, so the Subject Name of the certificate can be verified.
The difference between doing TLS or MTLS is down to whether you specify a client certificate (and password) or not. The client certificate needs to be in a PFX (with its certificate chain).
Send-SIPOptions.exe gateway.sipdomain.co.uk 5061 tls 192.168.5.103 highport
Send-SIPOptions.exe gateway.sipdomain.co.uk 5061 tls 192.168.5.103 highport .\cert.pfx Password123!
The following screenshot is from a Lync Edge Server on port 443 using TLS (using client certificate). The only visible difference is a few extra lines.