Virtualizing your UC Network Lets You Get More with Less

Getting more out of your network is a constant focus for many  enterprises in a world where success is measured in milliseconds.

Few know this better than Tac Berry, Senior Product Marketing Manager at Avaya. In this Webtorials?podcast, Berry discusses why virtualization is the name of the game when it comes to Unified Communications networks, which can yield:  

· Reduced costs

· Improved business agility 

· Always-ready productivity tools

· Enhanced customer experience

· Centralized administration  

“Convergence … is exactly the area that we’re spending our time on right now,” Berry says. “Once we’ve added applications to a virtual environment and virtual architecture, the next step is for the customer to understand how to implement these real time applications and new infrastructure into their existing data center and network.  And, of course, with many customers, this responsibility now falls  to both the IT and communication departments. They are starting to say, “I need resources to run conferencing” and the IT department is saying, “I’m using those resources to do database manipulation.”

“So, how do they combine that?  How do they get to one goal?  How do they get the benefits of virtualization–benefits which can include the reduction  of hardware, rack space, footprint, and energy consumption?”

For the answers to these crucial questions, listen to our podcast and learn how virtualization is the key to getting the most out of your Unified Communications suite.

Related Articles:

How to Realize Huge Cost Savings for Enterprise Telecom

This case study shares the steps taken by Avaya to reduce a sizeable telecom bill by 50%. The methods are trending tactics used by a wide range of organizations, and in combination have proven to produce especially favorable results. Keeping in mind that most IT operation budgets are flat, cost savings of this size can give your organization a greater opportunity to invest in innovation.

When every penny counts, internal telecommunication expenses must be closely accounted for. It’s a large expense and pain point for many organizations, and adopting change in this area is often associated with fear and uncertainty.

In reality, these fears disappear with a pinch of planning and excellent execution. Prioritizing telecom costs as a business initiative, establishing expectations, and determining a reasonable timeframe are some of the leading difficulties in taking on a project of this magnitude. These steps can have a great impact on the overall success of the project.

  1. Hire an expert to properly analyze your costs.

    There are many nuances in telecom, so if your organization does not have an expert internally, then it would be worthwhile to hire a third-party consultant to analyze the cost. They can provide better financial estimates of the cost and savings to ensure adequate ROI.

  2. Centralize trunking.

    To make it simple, paying for fewer circuits reduces cost. At Avaya, we reduced our total internal global telecom costs by 50% and got a 40% overall reduction of IT operational spending by doing so. Pay close attention to the amount of money paid in relation to the locations and compare centralized trunking cost to your current expenses. There are also considerations based on regional laws—for example, telecom laws in India may prevent this practice altogether.

  3. Reduce local trunking.

    Gartner estimates that “network architects and procurement managers can leverage SIP trunking services to slash enterprise telecom expenses by up to 50%.” As we all know, telecom does not come cheap, so these are results that cannot be ignored. Since IT operating budgets are often flat, this method can be a valuable way to extract savings from existing expense.

Gartner further suggests that, “enterprises should leverage the competitive SIP trunking market as U.S. service providers are reducing rates to win new business and retire their legacy TDM networks.” Needless to say, if you have yet to board the SIP train, you should strongly consider doing so now.

Previously at Avaya, all locations had their own local trunking and now we are saving cost by routing calls through a central location. In fact, SIP trunk consolidation provided an average savings of ~40% per month over PSTN trunks. We did it by implementing Avaya Aura to connect sites between a WAN used for both voice and data.

The Benefits Speak for Themselves

Consider what your company could do with these savings. We chose to reinvest 20% of our savings towards innovation and new capabilities. Gaining support from your colleagues should be a bit easier with these proof points in your back pocket and a strategic plan of action.

Understanding Avaya Aura SIP Registration

“Let’s start at the very beginning/a very good place to start/when you read you begin with A B C/when you sing you begin with Do Re Mi.”

I have always loved musicals, and Rogers and Hammerstein’s “The Sound of Music” is high on my list of favorites. Sure, it’s corny and far from historically accurate, but that doesn’t bother me in the least. I’m always willing to set aside any sense of reality for good singing, romance and adventure, and “The Sound of Music” has them all.

So … what does this have to do with unified communications? REGISTER, of course. Like Do Re Mi, you begin SIP with REGISTER.

This article is a continuation of the concepts I presented in A Close Look at Avaya Aura IMS Call Processing and An Even Closer Look at Avaya Aura IMS Call Processing, and I’d suggest you take a look at those before tackling this one.

Can you get SIP devices to communicate without REGISTER? Absolutely. In fact, when I teach my SIP class, the students put their SIP clients into point-to-point mode, which does not require REGISTER. This means that clients send SIP requests and responses directly to the other clients, not through a proxy. The clients can do everything all by themselves.

However, point-to-point without REGISTER has a serious downfall. The clients are required to know the IP addresses of all the other clients they wish to communicate with. While this is fine in a limited classroom environment, it becomes unwieldy after you grow beyond a handful of endpoints.

As an analogy, imagine having to know the IP address of everyone you wanted to send an email to. That’s the same problem you have if you don’t use REGISTER. It’s simply not practical.

The Tie that Binds

REGISTER associates a user’s identification, or Address of Record (AOR), with one or more locations. Note that I said locations. You are not limited to registering an AOR to a single device. Personally, I routinely register my AOR to a physical desk phone and multiple SIP soft-clients. Avaya Aura supports up to ten such registrations per user. That’s enough to make even the most device-crazy nerd happy.

You bind an AOR to an IP address with a Contact header.  For example, one of my soft clients might tell a SIP registrar that aprokop can be reached at with this Contact header.

Contact: Andrew Prokop <SIP:aprokop@>

Registrations are time-based and will eventually expire. This requires the client to periodically refresh a REGISTER with a new REGISTER. Actually, new isn’t the correct word to use for this. Subsequent REGISTER messages must contain the same Contact, To, From, call-ID and From Tag as the original registration. This allows the SIP registrar to know that it’s simply a refresh and not a new registration for the same AOR.

Note that CSeq will increment with each REGISTER sent.

Keeping Things Secure

I might tell my communications system that I am Andrew Prokop, but it would be foolish to trust me at face value. That’s why SIP allows a REGISTER to be challenged.

Before I go through a REGISTER challenge, allow me to define something known as a nonce.

Nonce stands for Number Once and is an arbitrary number used only once in a cryptographic communication. The recipient of a nonce will use it to encrypt his or her credentials. Number Once refers to the fact that encryption with this nonce can only be done one time. If someone were to sniff the LAN and obtain someone’s encrypted password, it won’t do them any good because it can only be used in a single transaction. It becomes stale and useless immediately after its first use.

A REGISTER flow is fairly simple and follows these steps:

  1. A user sends a REGISTER to the SIP registrar. For Avaya Aura, this is a Session Manager. The To and From headers contain the user’s AOR. The user specifies the number of seconds the registration should be valid in the Expires header. This value can be later raised or lowered by the registrar.
  2. The registrar returns a 401 Unauthorized response with a WWW-Authenticate header.  This header contains data that must be used to encrypt the user’s communications password. Specifically, it contains a nonce along with the name of the encryption algorithm that the client must use.
  3. The user sends a second REGISTER to the SIP registrar. This REGISTER contains an Authorization header. Within Authorization is the user’s encrypted password.
  4. If the correct password is received by the registrar, a 200 Ok response is sent to signify a successful registration. An Expires header may be present with a different value than what the user requested. This is the time the registration will be valid as determined by the registrar’s policies.

A registration is removed by sending a REGISTER with an Expires header value of 0 (zero).

In a picture, we have this.

Reg1Using the traceSM tool on an Avaya Aura Session Manager, I captured the following trace that shows a REGISTER, the challenge and a REGISTER with encrypted credentials.  Take a look at the headers, and you’ll see that they’re doing exactly what I said they would do.

Reg2 Reg3 Reg4


In the case of my daily work life, my various SIP devices will each send a REGISTER, be challenged and resend the REGISTER with the encrypted credentials. They periodically refresh their registrations to ensure that I am able to make and receive calls on all my devices until I am finished for the day.

Speaking of finished for the day, that’s about all I have to say about REGISTER. It’s not that complicated once you understand the basics. Just keep in mind that while registration isn’t absolutely mandatory, it enables a secure, scalable and easy to manage SIP solution.

… And these are a few of my favorite things!

Andrew Prokop is the Director of Vertical Industries at Arrow Systems Integration. Andrew is an active blogger and his widely-read blog, SIP Adventures, discusses every imaginable topic in the world of unified communications. Follow Andrew on Twitter at @ajprokop, and read his blog, SIP Adventures.

An Even Closer Look at Avaya Aura IMS Call Processing

Last week, I walked you through how Avaya implements IMS processing between Session Manager and Communication Manager.  Even though it may have looked fairly complicated and slightly convoluted, I actually did you a favor by greatly simplifying the call flow. The complete call flow is even more involved.

I also did myself a favor by presenting an abbreviated call flow. There were parts that baffled even me. So, I took it as a personal challenge to figure out the confusing parts as best as I could and put them into writing.

If you missed my previous article, it can be found at A Close Look at Avaya Aura Call Processing.

Allow me to begin by saying that nothing I wrote in my first article is incorrect. All that jazz about imsorig, origdone, imsterm and termdone is accurate. However, in terms of an outbound call from a SIP telephone, I started in the middle of the flow. There are quite a few messages that fly around the system before the actual IMS processing begins.

In the Beginning

Everything begins when an Avaya telephone informs Communication Manager that it has gone off-hook. In Avaya documentation, they refer to this as “Line Reservation.” Everything that Communication Manager does at the time of Line Reservation is a mystery to me, but it essentially sets aside resources required for call processing.

The telephone uses an INVITE message to kick everything off. However, this isn’t a typical INVITE. The To and From headers both refer to the caller. This is understandable because the user hasn’t started entering any dialing information. This is simply making Communication Manager aware that the telephone has been taken off-hook.

There also isn’t any SDP in the INVITE. That’s because dial tone will be generated locally by the phone. No media stream is required.

Lastly, the telephone tells Communication Manager that this is an off-hook event by putting the following in the To header.


I captured one of these INVITE messages with traceSM.

off2Upon receiving an off-hook INVITE, Communication Manager responds with a 183 Session In Progress. Now, I am used to 183 being used to deliver some form of early media, but there is no SDP in this response message. I can only assume that it is used to tell the telephone that the INVITE was received, and it’s safe to start playing dial tone.


Next, Communication Manager tells Session Manager that the phone is off-hook. This, of course, is done with a PUBLISH message. Since the telephone subscribed to Dialog events during its boot cycle, Session Manager will then send a NOTIFY message to the phone.  I am going to take a guess and say that the NOTIFY causes the phone to indicate an active line appearance.


There are no more SIP messages until the user has finished entering the complete dial string. Since the telephone is aware of the configured dial pattern (through Personal Profile Manager), it will wait until all digits have been entered before sending a new INVITE.

I have to admit to something. Since the dawn of time, I have always thought that an UPDATE was sent prior to a session being established and a re-INVITE was sent after the session was established. However, this new INVITE from the telephone is clearly a re-INVITE even though the off-hook session has not been established. I say this because the call-ID and From tag are identical between the two INVITE messages. This screams re-INVITE.

There are differences between the two INVITE messages, though. The To header now contains the dialed digits and the message body contains SDP. This INVITE looks like the kind of INVITE you would have expected in the first place. This INVITE can actually be used to make a call.


From here on out, the call flow will look like the one I described in my previous blog article. There is still something that needs to occur, though. The off-hook INVITE is out there and needs to be attended to.

To close out the first session, Communication Manager will send a 484 Address Incomplete response. This will cause the telephone to respond with an ACK.


Here now is the entire call flow. Note that I did not discuss the 407 Proxy Authentication Required response messages. For now you can ignore them, but rest assured that I will return to that subject in the very near future.

As you look at the flow, there is one more thing I want you to notice.  Session Manager sends both INVITE messages to Communication Manager as part of the imsorig processing, but only the re-INVITE will go through the origdone phase.  That makes sense, though, because the first INVITE received a 484 response. There is no point in sending it back to Session Manager for further processing.


Mischief Managed

Well, there you have — an even more complicated Avaya call flow than the last time around. I hope this helps you understand what I was saying in my previous article about the differences between SIP as a protocol and SIP as a solution.  Clearly, what Avaya is doing with SIP is far more involved than what you will find in a generic text book. Of course, a full blown PBX requires a little more than your run-of-the-mill call flows.

 Andrew Prokop is the Director of Vertical Industries at Arrow Systems Integration. Andrew is an active blogger and his widely-read blog, SIP Adventures, discusses every imaginable topic in the world of unified communications. Follow Andrew on Twitter at @ajprokop, and read his blog, SIP Adventures.