SIP Pinger Tool

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,

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

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.

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

Which means it will be…


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

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).

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.


Tweet about this on TwitterShare on LinkedInShare on Facebook
Pin on PinterestShare on Google+Digg thisShare on RedditShare on StumbleUponEmail this to someone

About Graham Cropley

Working as a Senior Consultant for Skype for Business, Exchange, and Office 365.


  1. Very nice, works with my AudioCodes Mediants when used with TCP! Thanks!

  2. Really great work Graham, thanks for sharing!

  3. Very useful, tested with Sonus SBC1000. Cheers, for this!

  4. Hi Graham – great article!

  5. 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);

      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.

  6. 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.

  7. Excellent Tool! Just what we were looking for.

  8. 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.

  9. 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?

  10. Fantastic tool! I’ve been looking for a quick way to validate certificates. Thank you!

  11. 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.

  12. greate tool , But can it be compiled target a lower .net version ?

Leave a Reply

Your email address will not be published. Required fields are marked *