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.
The Solution
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,
| Endpoint | UDP | TCP | TLS | MTLS |
|---|---|---|---|---|
| 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 |
| Asterisk | Yes | Yes | Yes | Yes |
| Sonus SBC / NET UX | Yes | Yes | Yes | Yes |
| Gamma | Yes | Yes | N/A | N/A |
| HIPCOM | Yes | Yes | N/A | N/A |
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.
Download
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.
Usage Details
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>)
| Parameter | Description |
|---|---|
| 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 |
UDP Example
|
1 |
Send-SIPOptions.exe 88.215.61.201 5060 udp 192.168.5.103 5060 |
Which means it will be…
|
1 2 |
Sending SIP OPTIONS to 88.215.61.201 on port 5060 as UDP From 192.168.5.103 on port 5060 |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 |
Sending... OPTIONS sip:88.215.61.201:5060;transport=UDP SIP/2.0 To: sip:ping@88.215.61.201 From: <sip:ping@192.168.5.103>;tag=4fb5035f976b079b461ad25790da455c Via: SIP/2.0/UDP 192.168.5.103:5060;branch=z9hG4bK1dftos00203hllce83c1 CSeq: 1 OPTIONS Call-ID: call-2a17085a-42a6-1168-4c2f-9cb1@192.168.5.103 Allow: INVITE, ACK, CANCEL, BYE, UPDATE, NOTIFY, OPTIONS, REGISTER Max-Forwards: 0 Content-Length: 0 Waiting for response... Received... SIP/2.0 403 Forbidden Via: SIP/2.0/UDP 192.168.5.103:5060;received=82.35.95.200;branch=z9hG4bK1dftos00203hllce83c1 To: <sip:ping@88.215.61.201>;tag=3612637348-271785 From: <sip:ping@192.168.5.103>;tag=4fb5035f976b079b461ad25790da455c Call-ID: call-2a17085a-42a6-1168-4c2f-9cb1@192.168.5.103 CSeq: 1 OPTIONS Allow: CANCEL, ACK, INVITE, BYE, OPTIONS, REGISTER, NOTIFY, INFO, REFER, SUBSCRIBE, PRACK, UPDATE, MESSAGE, PUBLISH Content-Length: 0 |
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.
TCP Example
|
1 |
Send-SIPOptions.exe 88.215.61.201 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).
|
1 2 |
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.
Very nice, works with my AudioCodes Mediants when used with TCP! Thanks!
Really great work Graham, thanks for sharing!
Very useful, tested with Sonus SBC1000. Cheers, for this!
Hi Graham – great article!
Hi would it be possible to get the source code for this at all? Thank you in advance.
I just used the normal TcpClient and UdpClient classes, nothing fancy… Here is a rough ‘bare-bones’ example, exactly the same as you would use to send any data over TCP or UDP.
ipServer = new IPEndPoint(RemoteIP, RemotePort);ipClient = new IPEndPoint(LocalIP, LocalPort);
TcpClient client = new TcpClient(ipClient);
client.Connect(ipServer);
Stream stream = client.GetStream();
StreamWriter sw = new StreamWriter(stream);
StreamReader sr = new StreamReader(stream);
sw.Write("OPTIONS...."); // Send SIP OPTIONS Request
string response = sr.ReadToEnd(); // Read Response
And you can use SslStream instead, if you want to have certificates in the conversation.
I hope that helps.
You can add the following Audiocodes Mediant SBC responses to the table above:
TCP 5060 – 483 Too Many Hops
TLS 5061 – 483 Too Many Hops
Also, when sending to Exchange UM service, the utility crashes with this error:
Unhandled Exception: System.NullReferenceException: Object reference not set to an instance of an object.
at Send_SIPOptions.Program.Main(String[] args)
I’m not necessarily looking for support to the Exchange UM service, but more just adding a note in case someone else is trying it.
Excellent Tool! Just what we were looking for.
Great work! But why don’t do it with .NET 4.0 to be compatible with WinXP?)
Only because .NET 4.5 comes by default in Windows Server 2012. And Lync 2013 doesn’t work on XP or Server equivalent. If you really need it targeted for .NET 4, or 3, etc, just let me know.
Very nice tool Graham, just what I was looking for.
Tested against Oracle Communications Sesssion Border Controller (former Acme Packet SBC).
Unfortunately, it fails verification of Certificate Chain, without telling why.
Any possibility to log some debug information?
Great!
Fantastic tool! I’ve been looking for a quick way to validate certificates. Thank you!
Dear Graham, i have found your tools very useful, but one thing- feature missed (IMHO), would be great to have time in (ms) to see in which time response was received just like ‘Asterisk’ show when using CLI – ‘sip show peers’, it will also help to understand load of interface and/or SIP stack if i can say so.
greate tool , But can it be compiled target a lower .net version ?