The Audio Conference Call is Dying. Here's Why.

angry lady yelling at phone

The traditional conference call has taken quite a beating over the past few years. This David Grady spoof was the first “laugh so hard, I cried” satire I came across. I think what struck me with this one was each time I thought it was getting old, he threw in something that made me laugh even harder… for nearly five minutes!

This week, the video “A Conference Call in Real Life” by Tripp & Tyler is making its rounds through social media. It’s funny too, although I think I’m still partial to the David Grady version.  And just today, I came across an article on “the existential despair of the conference call,” to which one of my colleagues replied, “I laughed, I cried, I kept watching! This would be a good clip of what can (and does) go wrong … unless you use Scopia.” She did include a “winky face,” but the truth of the matter is that Scopia does overcome almost all the issues identified in these conference call parodies. Not the barking dog, of course, and not the random background noise, but Scopia does take out A LOT of the guesswork.

Sometimes, I feel like I’ve been at Avaya for years, and other times, I’m blown away that it’s already been 20 months since the acquisition of Radvision. Where have the past (almost) two years gone? When I look back at the changes I’ve seen at Avaya, one of the biggest is that we have an incredibly strong video conferencing culture. And if you think I’m making it up, the proof is in the numbers below:

avaya scopia in house usage

Last month, we had almost 40,000 video meetings on Avaya Scopia with 340,000+ attendees. From June 2012 through December 2013, we had more than half a million video meetings and have surpassed the 3 million mark on number of participants. That’s A LOT of video, and that doesn’t even count the video calls I host (which often feels like another half million or so per year :) ).

Why is video usage so high within Avaya? I have a few theories, and they go to the core of the spoofs mentioned above.

  1. Get rid of the unknown: When I joined Avaya, conference calls were mostly audio-only. As a newbie to an organization of 15,000+ employees, I never knew who was talking. I was constantly IMing colleagues asking, “Who’s speaking now?” With Scopia video, active speakers are highlighted in the virtual meeting room, and names are displayed. There’s never any question who’s speaking, and all participants are clearly identified in the participant list.
  2. A picture is worth a thousand words: The ability to see who is speaking and to read his/her body language as well as the body language of other participants is huge. You get fewer interruptions, fewer questions, and richer communication because your meetings are taking place face-to-face.
  3. Get on the same page: Content-sharing is easy on Scopia, and content is displayed in high definition. There’s no more asking, “Are we looking at the same page?” or “Can you send the deck you’re referring to?” What’s more, participants can easily scroll through content that’s already been presented without interrupting the active speaker (a feature that is totally unique to Scopia).
  4. The power of mute (and more): With Scopia, you always know who the speaker is thanks to active speaker tracking. That means you also know when someone is “speaking” without meaning to… i.e. furiously typing on their keyboard, crinkling papers, having a side conversation, etc. The beauty of Scopia is that all users –whether in a conference room, on Scopia Desktop or joining via Scopia Mobile – have full meeting moderation. That means you can mute the noisemakers without interrupting the call. The ability to mute the far end can be beautiful thing when you have a lot of people on the line. And Scopia moderation goes far beyond mute – you can add or disconnect participants, take “control” of content-sharing (without having to ask for it), change your layout so content appears larger or smaller, etc.

Of course, I’d be exaggerating if I said every Scopia call goes off without a hitch. But when I read articles or watch videos like those mentioned above, I have to say, the death of the traditional conference call must be on the horizon. Why use audio only when you can use video, too? If you ask me, video conferencing is a no brainer, especially with the leaps we’ve made in personal video conferencing at the desktop and on the go.

What are your thoughts? If you use video, have your conference calls been more effective? I’d love to hear from you.

Related Articles:

Survivability and Avaya Media Gateways

Writing these technical articles serves two purposes. First, I love having the opportunity to play unified communications professor. I’ve been in this industry for a long time, and I truly enjoy sharing what I’ve learned about telephony, SIP, WebRTC and VoIP in general. Second, I find that I don’t really understand something until I’m forced to explain it to someone else.

I can’t tell you how many times I’ve started writing an article, got stumped about how to say something, did some research, and found that what I thought I knew was either inaccurate or not complete. So, as much as I hope that I’m helping my readers, I’m helping myself just as much.

Today, I’d like to tackle one of those “do I really understand this well enough to explain it to someone” subjects – Avaya media gateway survivability.

Are you ready? Great! Let’s go.

Avaya Media Gateways

Avaya supports two styles of media gateways. The first, and oldest, is the G650. The G650 is an 8U high, 14 slot chassis that was developed to give new life to Avaya TN card types. These are the cards used in the much older MCC and SCC cabinets. Examples include the TN799 C-LAN, TN224 digital line card, TN2602 IP Media Processor (DSP resources) and the TN2312 IP Server Interface.

These gateways communicate with a Communication Manager (CM) server through the TN2312 IP Server Interface.  Affectionately known as an IPSI, this card provides the control link between the CM and the gateway. A single G650 can support multiple IPSIs for redundancy purposes.

Traditionally, IP stations and trunks connected to a C-LAN. Like the IPSI, there can be multiple C-LAN cards in a single G650. These cards are used for both redundancy and capacity. You can configure different sets of phones to connect to different C-LANs.

C-LANs can also be used to connect to what I really want to write about today – H.248 gateways.

The H.248 gateway family consists of the G700, G250, G350, G430 and G450. Of those, only the G430 and G450 are available for purchase today.  The rest have been end-of-sale for a number of years.

Like the G650, the H.248 gateways support a variety of line cards and DSPs. However, these are newer vintage cards such as the MM710 T1 interface and the MM711 analog card. H.248 gateways do not support the TN form factor cards.

Also, H.248 gateways do not use C-LANs or IPSIs. Instead, these gateways connect to a CM server via a C-LAN in a G650 or directly to the CM through something called Processor Ethernet (PE). Think of PE as the network interface and IP address of the CM.

Media Gateway Lists

Now that I have the basics out of the way, I want to spend some time explaining how an H.248 gateway determines which CM to connect to.

I’ve mentioned “the CM server” a few times, but that’s not quite accurate. There can be several CM servers, and the gateways need to know which one they should hitch their wagon to.

There will always be a prime CM server. This is the main brain that runs the entire system. Call processing, vectors, call center, routing and device management all live there

What happens if the main brain dies? No problem. Avaya allows gateways to failover to another brain called an Enterprise Survivable Server (ESS).   Under sunny day conditions, an ESS is running, but it will not perform call processing or other CM tasks until a gateway registers to it. At that point, it wakes up and functions as if it was the prime processor.

Although Avaya supports up to 63 ESS processors in a single system, most enterprises implement far less than that.

There is another form of brain called a Local Survivable Processor (LSP). An LSP was originally designated to be a server that provides survivability for a branch location, but over the years, Avaya has increased its capacity and scale to the point where it now looks like its ESS brother.

How does an H.248 gateway know who to talk to?

This is where the Media Gateway Controller (MGC) list comes in. The MGC list instructs the H.248 gateway which processors it can connect to, in which order and under what conditions.

For example, an MGC list might consist of the IP addresses of the main CM’s PE, a C-LAN associated with that CM, an ESS and the 8300D processor embedded within the gateway itself. These IP addresses are priority ordered and the gateway attempts to register to them in the order that they are listed … sort of.

If the main processor’s PE or C-LAN doesn’t immediately respond, you might want to hold off trying the ESS or LSP. It would be smarter to attempt registration to the main processor a few times before entering into disaster recovery mode.  You don’t want a brief network hiccup to be the cause of a major reconfiguration.

This is where the transition point (TP) comes into play. The TP separates the primary server(s) from the survivable servers.

An H.248 gateway will first attempt to connect to the processor(s) above the TP. If my example had a TP of 2, the PE and C-LAN of the main CM will be tried several times (with 10 seconds between each attempt) before the gateway decides that they are not going to answer.

Honestly, I would love it if there were two transition points. One would divide main from ESS and the other would separate ESS from LSP. This would allow me to create a policy for enterprise survivability and another policy for local survivability. What say you, Avaya?

So, how long does a gateway keep trying? Every gateway will attempt to register to an IP address above the TP until the primary-search time is reached. After that, it attempts to connect to the servers below the TP.

With a TP of 2 and a primary-search of 10, a gateway will cycle through the two IP addresses of the main CM (PE and C-LAN) for 10 minutes before deciding it’s time to move on. At that point, it will try any IP addresses below the line following the same rule of 10-seconds between each registration attempt.

There is another value we need to be concerned with. The total-search time is the maximum number of minutes a gateway will attempt to register itself before giving up and rebooting.  This time includes attempts above and below the TP.

Making it real

Unfortunately, there is no centralized way to configure this. You make the magic work by setting the configuration parameters on every gateway in your Aura system.

The commands to create an MGC list similar to my example will look something like this:

clear mgc list

set mgc list 10.100.4.63 10.100.4.12 10.100.4.103 10.100.4.203

set reset-times transition-point 2

set reset-times primary-search 10

set reset-times total-search 15

In words, we have this:

Main Server (Processor Ethernet)

Main Server (C-LAN)

—————-Transition point————————————

ESS Location (Processor Ethernet)

LSP (Processor Ethernet)

Mischief Managed

That wasn’t too difficult, was it? Heck, even I learned something today. I wasn’t sure about the 10-second timer until I did a little research. So, even if you are still scratching your heads, it was a truly satisfying experience for me.

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.

What Our Predicted 2016 Trends Reveal About the Future of Business

At Avaya, we’re always looking forward. When creating a road map for the future of the company and the benefit of our customers, my team and I look ahead to anticipate the communications needs of tomorrow.

Last year, we predicted that midmarket companies would move to more cloud-based solutions; video would become a formidable channel; and Web chat would play an increasingly pivotal role in delivering omni-channel support. Do these trends sound familiar? These are all very real business conversations happening today. As we enter 2016, we couldn’t help but ask ourselves yet again, “What’s next?”

We thought long and hard about the trends that businesses should expect to see in 2016. Interesting conversations led us to an even more interesting question, “What do these projected trends say about the future of business?” We concluded that the world revolves around the customer now more than ever. As a result, when making purchasing decisions about communications tools and technologies, there needs to be a greater emphasis on customer use cases. Ask yourself, “What specific use cases am I solving for?”

We identified key trends to look for in 2016, and each says something really exciting about where the enterprise is heading:

More networks lean on Fabric

The increasing volume of data and bandwidth utilization from the burgeoning number of Internet of Things (IoT) sensors and “smart,” connected devices such as healthcare devices, home security systems and appliances, vending machines, check-out stands, etc. will drive traditional networks to the breaking point. Mesh topologies and Fabric-based technologies will become increasingly attractive as the answer for cost-effective solutions that can accommodate the capacity needed and flexibility required for the constant changes in network traffic. Decades of client server architectures are coming to an end.

Customer contact centers become more flexible and connected

Omni-channel access/pre-routing will gather momentum as smartphones become the interface of choice for customers. This means much more efficient handling of customer inquiries, leading to greater satisfaction, lower costs for balancing and distributing incoming customer communications over multiple locations, and easing IT operations for the business.

The percentage of people connecting to an enterprise will continue to be increasingly digitally dominated from browsers and mobile applications, which will drive specialized ways of serving those customers from the customer experience (CX) perspective. This dynamic will also drive customer relationship management (CRM) and marketing-oriented projects for the more innovative companies.

As customer satisfaction scores for video within the contact center outrank other channels, we will continue to see more video deployed as an option to increase customer engagement. Video capabilities enhance the ability to develop the personal relationship with a customer, establish trust more quickly and allow agents to better understand the customer’s need, which can lead to improved time to resolution.

Enterprise-grade WebRTC gains momentum

Enterprise-grade WebRTC conferencing from desktop and mobile browsers will speed the ability for participants to join common virtual areas without launching separate applications.

Automotive telecommunications will become a fast-growing customer contact center channel

With sensors and telematics systems becoming more common in automobiles today, information on vehicle usage and driver behavior is more readily-available, providing an opportunity for manufacturers, dealers and OEMs to forge closer relationships with customers, increase loyalty to their brand and increase margins. Specifically, sensor-based reporting on car maintenance and usage enables more convenient, proactive services for car owners, alerting them to upcoming maintenance, repairs or safety issues. Sensors and telematics also provide opportunities for tie-ins with insurers, such as safe driver discounts, not to mention access to a myriad of other services.

Further proliferation of wearable technology will drive customer satisfaction

Over the next four years, sales of wearables worldwide are predicted to increase almost eight-fold from last year. The explosion will make the most important device we carry – our smartphone – even more significant by expanding its role as our personal hub by serving as a proxy for our wearable tech.

But a less talked about, must-watch dynamic is the evolution of wearables in in the workplace, beyond the contact center. As headset and communications technologies continue to evolve, new wearable technologies hone in on special applications for workers who need hands-free access to information and communications capabilities. For example, a remote healthcare worker could use communications-enabled wearables to video call with city-based surgical teams when operating on a patient.

The “guest” experience in sports and hospitality gets connected and smart

Analytics for sports and entertainment will no longer be just about the athletic performance. Fan analytics − or the analysis of data collected from fans across several touchpoints − will help venues measure, optimize and monetize the fan experience.

And with Facebook’s release of Oculus, we can expect to watch the virtual reality scene play out for sports fans. The technology will provide the red button experience both in the stadium and at home. For example, using just a smartphone, fans could choose 50+ camera angles to watch the game from while still in their seat. This could include views from the goal, corner flag or the umpire’s hat, even the players’ shirts. The hotel room will be an extension of your home as – with your permission – it will know your context and provide all your usual connectivity.

Connected Government will become the new normal

Connected Government will emerge, embracing social media through multimedia communications. Text-to-911 will ramp up quickly, but fade just as fast, as citizens embrace total immersion in Face2Face911 through video and pictures from their broadband-enabled smart devices.

They try really hard, but messaging apps will not replace email

Email is a communication tool that by now is simply part of doing business worldwide. Unlike messaging apps, email has structure. There are subject lines, the ability to reply to one or many, the ability to categorize, create folders, and the list goes on. The basic structure is, for the most part, consistent between email providers. Furthermore, a Gmail user can email an Exchange user and so on. While messaging apps are trendy and fun to use socially, they are the newborns of the written communications world who have no organization skills and  a lot of growing up to do.

Hybrid/private clouds remain the business critical application workhorse for next 5 years  

Going to the cloud has many benefits, but it can lead to some new challenges that businesses need to consider. As solutions move from homogenous, monolithic technology to heterogeneous technology running on layers upon layers of cloud infrastructure, customers get increasingly concerned about cloud security and accountability for service delivery/support of the full solution. Customers will demand accountability and value from their “point” vendors, requiring strong relationships and mastery of the infrastructure implications, which includes the cloud applications, as well as the network and desktop/mobile devices that serve them.

Customer relationships rule for vendor differentiation, as support increasingly relies on self-service and self-healing systems   

The value-add of contracted support is becoming less visible as leading-edge vendors put more remediation and proactivity into tools and systems. As a result, vendors need to develop strategies and underlying system intelligence to improve customer experience with offers that help increase adoption and full value realization. Vendors will need to intentionally work to maintain the human factors of the service event to overcome the depersonalization that may result from increasingly technical solutions by implementing things such as relationship-based routing and service deliverables combined with high-satisfaction channels, most notably, video.

Understanding SIP PRACK for Avaya Aura

As many of my readers know, every few months I teach a two and a half day class on “all things SIP.” My students are exposed to everything from “why SIP” to the nitty-gritty of SIP requests, responses and call flows. I even speak about some of the more esoteric topics such as To and From tags, the Replaces header, nonce values and TR-87.

Included in the esoteric list is the PRACK (Provisional Response Acknowledgement) method. PRACK wasn’t in the original SIP specification and was introduced later in RFC 3262. It came about after it was realized that some user agent servers need to know that a provisional response was received by a user agent client. Before PRACK, 1xx responses sent using UDP might get lost, and the sender would never know. PRACK adds a layer of reliability to an otherwise unreliable call flow.

I previously addressed PRACK in my article “Ducks Go Quack. SIP Goes PRACK.” Although I addressed most of the pertinent material, I was short on examples and real-life call flows. As I walked my most recent students through live calls on my company’s Avaya system, I happened to notice a few PRACKs and decided it was time to update my old article.

The following screenshots were gathered using the Avaya traceSM utility. I simply started traceSM on a live Aura system, let it run for a few minutes, and then stopped it after I noticed a few PRACK messages fly by. This was simply because I was unsure as to when Avaya uses PRACKs and when it does not.  In other words, “When in doubt, trace it out.”

prack1

Let’s start at the beginning. PRACK messages aren’t just sent out-of-the blue. The sender of an INVITE message must indicate that it is capable of sending PRACKS. It does that by including the header in the INVITE message:

Supported: 100Rel

This tells the recipient that, if requested, it will send PRACK messages for 1xx Responses.

The following shows an INVITE with such a header.

prack2

Now that the user agent server knows that PRACK messages are possible, it will include headers similar to the following in all 1xx Responses it wants to be PRACKed:

Require: 100Rel

Rseq: 1

The Requires header with a value of 100Rel tells the user agent client (the sender of the INVITE) that a PRACK is expected for this response. It’s important to know that the user agent server (the sender of the Response messages) has to request the PRACK. It’s not an automatic process and must be initiated with an Rseq header.

The value in Rseq is used by the user agent client when it creates a PRACK message. The user agent server is responsible for setting and incrementing this number.

The following 180 Ringing indicates that it expects a PRACK.

prack3

Upon receipt of this 180 Ringing, the user agent client must respond with a PRACK message. Of interest to this article is the Rack header. This header must contain the Rseq value sent in the previous 180 Ringing. Additionally, it will indicate the original INVITE session’s CSeq number. Look back at the INVITE in this call flow, and you will see a CSeq value of 1 (one). Therefore, the Rack will look as follows:

Rack: 1 1 INVITE

prack4

Next, the user agent server will send a 200 Ok for the PRACK. This tells the user agent client that the PRACK was received and processed.

prack5

For grins, I will now show you the 200 Ok for the original INVITE. Note that it does not have a Rseq header and 100Rel is not in the Requires header. Why not? That’s because this is not a provisional response. PRACKs are only sent for 1xx responses.

prack6

Mischief Managed

Before I close things out, I want to address the question I hinted at near the top of this article.  When does Avaya use PRACK?

While I honestly don’t know all the permutations, it appears that an INVITE from an Avaya endpoint will always indicate that it supports PRACK (Supported: 100Rel).  However, as you just learned, it’s the recipient of the INVITE that indicates if PRACK messages are required.

In the example above, the Avaya Modular Message voice mail server requests PRACK messages.  Additionally, PRACK is used when direct media is enabled.

There is a good chance that PRACK is used in other situations, but I am going to have to start up a few more traceSM sessions to learn where they show up.

That’s about all I really need to say about PRACK. I invite you to take a look at the RFC if you want to learn about any PRACK subtleties I might have missed, but for all practical purposes, I’ve said all that needs to be said. I hope you had as much fun today as I did. As is often the case, I learned something in the process of writing this article, and that’s always a good thing.