How to Build a Secure SIP Network

For the most part, I love my job as a communications architect.  I love sifting through Wireshark traces trying to find needles in SIP haystacks.  I get excited learning about new IP communications products.  My heart practically skips a beat when I read about another SIP service climbing out of its physical shell and going virtual.

However, the best part of my job is when I get to walk away from my PC, phones, and LAN analyzers to meet with the users of unified communications technology.   It doesn’t matter if it’s a regional user’s group or a series of one-on-one meetings with IT professionals.  I love solving problems and helping people understand the technology that’s near and dear to my heart.

The cream of the crop comes once a year in the form of the International Avaya Users Group’s “Converge.”  I have been speaking at IAUG conferences for many years now and look forward to each one like a Minnesotan waits for summer.  This year, Converge2014 will be held in Dallas, Texas during the last week of April and I’ve already received the green light to present three different topics.  Today I would like to spend a little time writing about one of those topics, “Building a Secure SIP Network.”

Building a Secure SIP Network

When you think about security in terms of SIP and VoIP, you need to consider four different areas.  First, you want to protect the SIP signaling.  Second, you need to protect the media stream.  Third, you need to ensure that people are who they say there are.  Lastly, you need to create a secure network edge that prevents the bad guys from sneaking into your business and compromising your VoIP network.

Let’s begin with protecting SIP signaling.  SIP is comprised of two types of messages.  The first is called the SIP Request or SIP Method.  This could be the INVITE that begins a SIP conversation, the BYE that ends it, or the REFER that moves an existing conversation from one party to another.  In all there are 13 SIP requests.

The second message type is the SIP Response.  This might be the “180 Ringing” response that’s generated when a telephone begins to ring or the “200 OK” response that’s sent when that ringing phone is answered.

To protect SIP signaling you need to encrypt it.  This is no different than encrypting your web traffic when you purchase something online.  In the case of web messages, that’s done with HTTPS or Secure Hypertext Transfer Protocol.  With SIP it’s called Transport Layer Security or TLS.  TLS encodes your SIP Requests and SIP Responses so they cannot be understood by anyone other than the sender or recipient of the messages.

In the SIP world, media is sent using something called Real-Time Protocol or RTP.  RTP is an encapsulation protocol for the data bits that make up the voice conversation.  The media might be G.711, G.729, or G.722.  It’s RTP’s job to get the data to where it needs to go without any concern as to what that data might be.  To protect RTP you must encrypt it.  This is known as Secure Real-Time Protocol or SRTP.  SRTP ensures that if someone captures a LAN or WAN trace of your voice conversation, it cannot be played back.  Only the sender and receiver of the RTP stream can decipher and listen to a conversation.

It is important to ensure that SIP messages have not been spoofed.  Just because I say that I am Andrew Prokop in a SIP message doesn’t guarantee that I really am Andrew.  I need to prove it.  Built into SIP is the ability to challenge messages.  A challenge forces the sender to return his or her encrypted credentials.   A subscriber database such as Active Directory is then queried to verify the authenticity of those credentials.   This prevents a rogue SIP client from pretending to be an authorized user on your network in order to gain access to your communications resources.

For a deep dive into SIP challenges, please see my blog, Proving it with SIP Authentication.

Session Border Controllers

The Session Border Controller (SBC) is the least understood component of SIP Security, but that really shouldn’t be the case.  In its most simplistic sense, an SBC is a firewall for SIP.  It prevents unauthorized SIP traffic from entering your network.  It also performs a deep packet inspection of all SIP messages to ensure that they don’t contain anything malicious.

So, why not just run SIP traffic through your data firewall? In theory you could, but you will probably regret that decision.  SBCs are designed to deal with the bursty, small-packet nature of VoIP communications.   Delay and jitter will destroy a VoIP conversation and SBCs are able to inspect and relay SIP messages and media at near wire speed.  The SBC is the first line of defense for secure VoIP.

Please make sure that you read my blog articles, The SBC Placement Bible and Andrew’s Session Border Controller Checklist for more of my thoughts on session border controllers.

Please Come to Dallas

We take for granted the need for firewalls, virus checkers, and secure browsers for our web activity and it’s essential that we think along those same lines when it comes to VoIP communications.  Thankfully, with the proper configuration, policies, and services, we can assure ourselves that every time we pick up a SIP telephone, start a video conference, or send an instant message, our identity has been protected and our conversation had been secured.


If you are attending Converge2014 (why wouldn’t you?) and would like to learn more about SIP security, make sure that you sign up for Session 501 with yours truly.  I promise to make it worth your while.

* * *

This article originally appeared on Andrew Prokop’s unified communications blog, SIP Adventures, and is reprinted with permission.

Related Articles:

2016 DevConnect Award Winners Choose to Innovate on Avaya

Platform innovation allows companies to disrupt the status quo for their business, their industry. Amazon, Zappos, Google, Uber are just a few of the success stories that embrace platform innovation and launched massive disruptions. I add to that list Avaya. Why? Like these companies, we too identified a problem and created a platform that solves it. The problem that we identified is that in this mobile-centric, 24X7-access-to-everything, gadget-crazy digital world, there is a huge problem for companies to be able to communications enable any customer experience now, not seven months from now. The platform we created for business communications innovation is Avaya Breeze™. And unlike our competitors, we are embracing the fact that an open, scalable platform with an OpEX business model option that our partners and customers can access on their own—without us—is good for business and the industry. Breeze is a business and industry disrupter not only for Avaya but also for the customers and partners who are innovating on it and transforming their own businesses and industries.

Avaya Breeze is an open framework that brings the necessary attributes for communication in the digital age: embedded, mobile, fast, low risk, and workflow enabled—a key requirement to automate previously manual processes to improve digital experiences. It is the second most visited content topic on The number of innovations developed on Breeze since its launch in March 2016 has been amazing, especially for an industry that has traditionally been focused on not empowering customers and partners to do things on their own. Customers and partners tell us they have developed hundreds of business communications applications and have hundreds more in development. One of the Avaya DevConnect partners said earlier this year that innovation on Breeze is a breeze. Many others agree. In fact, the DevConnect partners are consistently demonstrating the success of innovating on Avaya via the Breeze platform.

At Avaya, we believe that communications enabling almost anything is now possible through innovation on Breeze. Why not? If a company has a need or a use case, there is a solution and it can be readily available in days to weeks, just ask some of our DevConnect partners like Engelbart Software GmbH.

DevConnect’s 2016 Technology Partner of the Year, Engelbart demonstrated the best overall commitment to Avaya and their DevConnect partnership based on specific characteristics of excellence. The company developed leading-edge esuits2 ECI Server Snap-in for Breeze. This unique snap-in captures calling number information (CLID/ANI) and presents additional caller identification detail to called parties, enabling Avaya customers to enhance productivity and increase customer satisfaction. Engelbart has three solutions listed in the Avaya Snapp Store—Conferencing Whitelisting, esuites2 Enhanced Caller ID (ECI), and NG1-1-2/NG9-1-1 Location Extractor. The company has dozens more concepts under development.

Another example is Beta 80 Group, recently named DevConnect’s 2016 New Partner of the Year for demonstrating innovation and exemplary proactive partnering with Avaya. With a focus on delivering added value for Avaya 911 and second level public safety customers, Beta 80 Group’s innovative e911 (PSAP) solution integrates with Avaya Aura® to provide computer aided dispatch, radio integration, and reporting services for 911 organizations as well as emergency medical services, fire departments, and private medical services.

Three more examples are offered by DevConnect’s 2016 Innovation Award winners who were chosen for their ability to develop an innovative solution that addressed a unique solution in the market.

  • The eGain Knowledge Snap-in for Avaya Breeze from eGain Corporation guides callers to accurate answers online through self-service. Through the Snap-in, eGain enables Avaya customers to improve the overall experience and satisfaction of their own customers by making relevant information quickly available in a self-directed manner.

  • The Moxtra Snap-in for Avaya Breeze from Moxtra, provides rich, persistent chat and document sharing. This innovative Snap-in enables Avaya customers to create real-time continuity and collaboration between callers and contact center agents, increasing productivity and improving customer satisfaction. This Snap-in includes Moxtra’s Dynamic Task Type for Avaya Engagement Designer.

  • With ScoreData Corporation, Avaya customers can greatly benefit from the predictive behavioral analytics characteristics of the ScoreFast™ platform, which is capable of building complex statistical models to deliver custom solutions for specific business problems in near real-time.

On-demand applications such as those created by our award winners are about simplification, urgent need, and improved user experience. Innovating on Avaya is enabling these companies and many more to change their business for today’s digital experiences. Along the way if they also happen to disrupt the industries that they are doing business in, that is the power of innovating on Avaya.


For Unified Communications Pros: How to Record Calls with SIPREC

“This call may be recorded for quality assurance.”

It’s nearly impossible to call a contact center without hearing that message or something very similar.  A company will record calls for a variety of reasons.  It may be to help improve customer service.  Supervisors listen to their agent’s interactions for training and evaluation purposes. Companies also record calls to protect themselves.  A significant number of “he said, she said” arguments can be cleared up by simply playing a recording of the customer’s conversation.  There are also situations where call recording is required by law.

I began my career well before SIP and remember trunk-side recording with TDM taps.  These taps were devices that split a T1 into two links.  One went to the PBX and the other to a call recorder.  They were effective, but required one such device for every T1 line.

With the advent of SIP, we are able to move away from T1s and their channelized DS1s and DS0s to a network connection where the number of trunks is limited only by the amount of available bandwidth.

Tapping into a dedicated line is no longer an option with SIP.  Ethernet and MPLS are not physical mediums that lends themselves to hardware taps.  We need a new way to perform trunk-side recording.

As with many questions related to SIP, the answer is the Session Border Controller.  It is, after all, the device that sits between the carrier and your enterprise.  Can you think of a better place to “tap” into a SIP call and simultaneously send it to a call recorder and your communications system?  I can’t.

To help the SBC with the job of call recording, the IETF (Internet Engineering Task Force – the folks who manage SIP and most of the Internet protocols) came up with a framework that manufacturers of SBCs and call recorders can follow.  Session Initiation Protocol Recording, or SIPREC for short, defines the architecture, associated call flows, and metadata that can be used for call recording.

SIPREC identifies two players involved in call recording – the Session Recording Client (SRC) and the Session Recording Server (SRS).  Although SIPREC doesn’t limit the SRC and SRS to specific entity types, for the purposes of trunk-side recording, it is safe to say that the SRC is an SBC and the SRS is a call recording platform such as Nice.

The following diagram shows the relationship between the different entities.  Note that SIPREC message types are only applicable between the SRC and the SRS.  Normal SIP messages are sent between the SBC and the SIP carrier and the SBC and the communications platform.  Also, although I have shown a SIP telephone inside the enterprise, there is no reason why it needs to be SIP.  It could be any telephone type supported by a SIP communications system.

There are no new SIP message types to support SIPREC.  SIPREC utilizes common messages such as INVITE and BYE.  The big change lies within the message body of those INVITE and BYE message.  As is expected with all SIP call flows, Session Description Protocol (SDP) describes the session’s media (e.g. G.711 or G.729).  In addition to SDP, the message body of a SIPREC INVITE contains a second part.  In SIP parlance, this is known as a multipart MIME message body.  The first part of the message body is SDP and the second part contains SIPREC metadata.   This metadata is used to convey information that is specific to the process of call recording.

The metadata of an SIPREC INVITE is formatted as XML data.  This means that there will be tags that define the start of a section of data and tags that define the end of a section of data.  For example, a participant might be encoded as follows:




        <name xml:lang=”it”>Bob B</name>



A SIPREC INVITE will typically contain information about both participants in a call and descriptors for the recording session.  A SIPREC BYE will contain similar metadata to stop and archive the recording.

I am not about to present all the gory details of SIPREC metadata, but I can direct you straight to the source.

It is important to know that SIPREC is still in draft form and has not been ratified by the IETF.  However, a number of vendors have already begun to adopt it in anticipation of its ratification.  Among the SBC vendors, I’ve seen Sonus, AudioCodes, and Oracle Acme state their support for SIPREC.  Among the call recording platforms, I’ve seen Oracle Acme and Nice.  This doesn’t mean that other vendors don’t support SIPREC.  I simply haven’t run across documentation stating their acceptance one way or the other.

I have just discussed SIPREC as a mechanism for trunk-side recording.  However, there is nothing to say that it cannot be used for station-side recording, too.  Of interest is the Avaya SBC which is being positioned as both an edge and internal security device.  If an Avaya SBC was positioned between all SIP endpoints, it could easily use SIPREC to perform call recording for station to station calls.

Stay tuned for further developments.


This article originally appeared on Andrew Prokop’s unified communications blog, SIP Adventures, and is reprinted with permission.

A Timely Article About SIP Timers

Some things happen for a reason and some things just happen. Last week I hit a deer and I highly doubt that there was some cosmic reason for the deer to jump out into the road just as I was passing by. It was what it was, and that’s all there is to it.

However, there are other events in my life that feel much more significant and preordained. For instance, in June of 1983 I answered a want ad in the Minneapolis Star Tribune from a company looking for computer programmers.

The company was Northern Telecom and that job started me off on a career that now spans three decades. It’s what sent me down the road of ISDN, digital phones, signaling gateways, contact centers, and now, SIP services, applications, and endpoints.

Could I have done something different for all those years? I suppose so, but as silly as it might sound, I feel as if this was my calling. I truly love what I am doing and cannot imagine what my life would have been like if I took another job and ended up writing payroll or tax software. Yuck.

* * * * *
This article originally appeared on SIP Adventures and is reprinted with permission.

All of this leads me to what I want to talk about today – timing.

I am often amazed at which of my blog articles become “best sellers” and which ones practically die on the vine. I have written about all sorts of subjects, but believe it or not, my top two blogs both have to do with SIP timers.

Every day, people will click on Understanding SIP Timers Part I and Understanding SIP Timers Part II.

In fact, Google ranks me very high when it comes to Timer-B and Timer-F. You don’t believe me? Search for “SIP Timer-B” and look who shows up near the top of the list.

Timing is important in all aspects of life, and it’s very important with SIP. It’s important how long a user agent client is willing to wait until an INVITE message receives a response message. It’s important how long a registration or subscription will last.

As I explained in Understanding SIP Timers Part II, the Expires header is used to indicate the number of seconds a message can be outstanding.

For instance, if I put an Expires of 60 into an INVITE, that INVITE will timeout after one minute. As someone who hates listening to endless ringing, I see the value in automatically timing out calls that aren’t answered quickly.

SIP timing also has value outside of improving the user experience. Consider how a firewall permits a trusted application to open an IP pinhole for the traffic of a particular protocol. For security reasons, that pinhole will close if it goes idle after some period of time. Expires comes into play here, too.

An analog terminal adaptor (ATA) supports analog telephones on a SIP call server — the call server sends SIP to the ATA and the ATA converts SIP to analog signaling. Since analog phones can’t send REGISTER messages, that ATA does that on their behalf.

If there is a firewall between the ATA and the call server, that ATA needs to be aware that the SIP pinhole will close if messages stop flowing through it. To prevent this from happening, the ATA will ensure that registration expirations are shorter than the firewall timeout value. This way, even if phone calls aren’t made or received, the pinhole stays open.

In real life, I have seen ATAs use registration expirations of 60 to 120 seconds when firewall traversal is required and one hour when it’s not.

If you were to trace the SIP traffic on an Avaya system you will see that Avaya telephones set a fairly short Expires value. This allows them to use REGISTER for registration as well as a “here I am” message.

The distributed nature of SIP adds a new level of complexity when it comes to managing a network of SIP servers and services. It’s not like the old days of the monolithic PBX where one central brain controlled everything. SIP allows for intelligence to be shared amongst a collection of loosely connected servers.

However, those servers might need to know who is running and who is not at any given point in time. It’s also certainly useful for an administrator to be able to look at a maintenance console and see which elements are “up” and which are “down.”

SIP timing comes into play here, too. Since there is no SIP ping message, applications will periodically send OPTIONS messages to query the state of another element. You don’t want to flood the network with too many messages, so a reasonable timeout value should be chosen to balance the need to know with network bandwidth considerations.

Subscriptions are time-based and Expires headers are put into SUBSCRIBE messages, too. The rule of thumb is that a subscription should be refreshed halfway through the expiration time. This will ensure that it doesn’t unexpectedly disappear.

So, there you have it — three timely blog articles about SIP timing. I hope this one proves to be as popular as the previous two.