Dialogic - ContactCenterWorld.com Blog Page 2
Back in March, I wrote a blog about the PSTN sunset. But in reality legacy technologies are still in use. I know this since we still sell them. Certainly, IP is growing and SIP Trunking is growing, but for most companies this means a gradual transition, not a full scale wipeout of existing technology. Why? Because what they have works. And because what they have is already paid for, minus any maintenance contracts. And because it works, and is primarily paid for, it makes sense to continue to use it, and do an orderly transition off it when it makes business sense for the enterprise.
Many companies are moving to SIP trunks as connectivity into the customer premise. SIP trunks can help enterprises move to cloud-based communications infrastructure over time. It’s certainly easier to upgrade and have flexibility with a cloud deployment. We have seen this in Dialogic when we have switched some of our enterprise communications applications to the cloud. And with these SIP trunks comes an enterprise SBC, to help “protect” the enterprise network from what might come down the SIP Trunk. This makes total sense for the IP network.
But as I said above, there will still likely be legacy infrastructure in the enterprise that works, that is paid for, etc. So they’ll want to use it. In this case, a gateway will be required to be placed between the legacy equipment and the SIP network. This is why the gradual transition to IP continues and will continue over time. And this is one of the reason gateways continue in the market and why Dialogic continues to sell them.
Publish Date: June 20, 2017 5:00 AM
Dialogic is a Technology Partner in the Avaya DevConnect program—an initiative to develop, market, and sell innovative third-party products that interoperate with Avaya technology and extend the value of a company’s investment in its network. In recent years, Dialogic has tested numerous products with various Avaya subsystems such as the Avaya Aura platform, which provides a foundation for several of Avaya’s customer engagement solutions. Products which have been tested and certified as Avaya Compliant in recent years include the IMG 2020 Integrated Media Gateway, the PowerVille™ Load Balancer and the Controlswitch™ System.
Dialogic has recently updated its web site to make it easier for customers and channel partners to find information about all of these Avaya compliant solutions by creating a Partner Page for Avaya. This page includes details on the most recently tested Dialogic solutions for Avaya and includes links to application notes, related press releases and customer success stories. There is also a link to an Avaya Solution Guide, which describes how Dialogic products can complement the Avaya-based technology within enterprises.
Dialogic has a rich heritage of providing products which can enhance the value of partner solutions by providing connectivity to a wide variety of networks, such as SS7, Sigtran, ISDN and SIP, and providing seamless interworking between components provided by multiple vendors. The partnership with Avaya is a good example of how Dialogic can add value to partner solutions. Customers can take advantage of the extensive testing conducting during the DevConnect process and reference the related application notes to build Avaya-based solutions which take full advantage of Dialogic’s gateway, load balancing and switching capabilities.
To find out more, check out the Avaya partner page on the Dialogic web site and review the full range of Avaya Compliant products from Dialogic.
Publish Date: June 14, 2017 5:00 AM
Last week, I wrote about how great of a tool the Cisco VNI is for mobile trend analysis and how it might not be best to use as THE ONLY definitive future forward-looking mobile trend predicter. The reason I really started looking at the Feb 2017 report, though, was because I wanted to see what it said about WiFi offload. I just went off on a tangent last week. This week, I return to the topic of WiFi offload.
My thesis has been that if WiFi offers lower costs for operators (who willingly support WiFi offload), then why do they not support this even more, as opposed to spending money on 5G? And what is 5G anyway? (Specs are not done yet.) If the service providers spend much more money on RAN infrastructure upgrades to 5G, then will this actually be better for their subscribers than spending likely less money on supporting WiFi offload? Their costs would go down and subscriber costs could also potentially go down.
Or better yet, if their pipe costs went down, they could spend more money on other value-added areas for their subscribers. Right now, just spending money on making better pipes will surely make them into the bit-pipe providers they say they don’t want to be.
According to the Cisco VNI, in 2016, 60% of mobile traffic was offloaded to WiFi, with expectations to grow to 63% by 2021. And also, according to the Cisco VNI, WiFi offload is higher on 4G networks (some have theorized it would be lower since 4G offers better speeds so people wouldn’t bother to offload) because of the data CAPS imposed by the service providers.
WiFi hotspots are also expected to grow 6x to 541 million by 2021. So it’s just a thought to think this through fully.
Is 5G really necessary right now? Is it a money pit? Might there be other options? And what as a service provider do you really want to be?
Publish Date: May 30, 2017 5:00 AM
This is the third in a multi-part blog series, explaining some of the many features and functions found in the newly released PowerMedia XMS 3.3 software.
If there is any question to the value of recording video, take note of any one of the viral videos of airline customer service “interactions” posted on YouTube.
The emergence of inexpensive storage completely changed customer service interaction and identity verification. Voice-only contact centers almost universally record all customer interactions – thus the pre-call warning that “this call may be recorded for quality and training purposes.” You should expect the same will be true with video customer care interactions. Recording helps resolve potential conflicts of “he said – she said” disputes with financial transactions. Contact centers, banking, legal, and other industries require by policy or regulation that all customer interactions are archived, requiring the capability to record video interactions.
However, recording video is significantly more resource intensive than a voice-only recorder. A VP8 video session at 720P @ 30fps results in a 1.2 Mbps stream. A two-way video stream is double this rate. A voice-only recording of a two-party interaction results in a 8 Kbps stream (1/150th of the video bandwidth required).
To address these needs, XMS 3.3 includes a new suite of performance-specific optimizations that increase the number of supported recording sessions to hundreds per server*. By using native record functionality (no transcoding) and WebM containers, many more video streams can be captured and stored.
A typical use case would be a video financial services agent application with a customer on their mobile or tablet, while the agent is using a browser-based application on a PC, both ends supporting VP8 or VP9 video codec. Because the conversation requires authentication and potentially instructions for a transfer of funds, regulations or policy would dictate that the conversation must be recorded. To facilitate the recording, the application would route the media streams between the agent and the customer through a PowerMedia XMS media server. Once the media streams are established, the XMS server would perform the recording, sending a recording of one or both sides of the conversation to a Network Attached Storage (NAS) cluster. The result would be a collection of WebM-formatted files, available for playback and management by the contact center archival/library function.
Interested in giving it a try? You can download a FREE trial copy of the software at the PowerMedia XMS Product Landing Page.
* Actual performance limitations depend on the processor performance and external factors – consult with your Dialogic account manager for a detailed analysis of your situation.
Publish Date: May 15, 2017 5:00 AM
This is the second of a multi-part blog series, explaining some of the many features and functions found in the newly released PowerMedia XMS 3.3 software.
Outbound calling applications – reverse 911, contact center call-backs, medication reminder notifications, and conferencing applications all depend on detecting whether an outbound call was completed, and then, whether it was answered by a person or a machine. Correctly detecting the success (or failure) of an outbound call allows an application to decide whether to retry the call, leave a voice message or connect the call to an agent. Dialogic has been a leader in developing reliable Call Progress Analysis (CPA) algorithms since the early board-level DSP products, carrying this expertise to XMS.
One of the challenges with CPA is the variability of network tones around the globe. If you’ve ever called into Europe or Asia, you know that ring-back, busy and network error tones vary based on the destination of the call. Automatic detection of these country-specific tones is sufficient for some applications, but having control over the algorithm detection parameters and profile can improve reliability and efficiency.
Previous PowerMedia XMS version have supported Call Progress Analysis (CPA) for some time, and XMS 3.3 enhances CPA with several API extensions to give the application developer more control over the process and detection profile.
“Notification and Reverse 911 applications depend on detecting whether an outbound call is answered and whether the call was answered by a person, answering system or received a network error,” said Diane Myers, Senior Research Director, IHS Markit. “The enhanced call progress analysis controls included in XMS 3.3 will be especially useful for developers.”
The newly released PowerMedia XMS 3.3 expands the CPA API controls and is ideal for outbound calling applications that will server a global marketplace. Interested in giving it a try? You can download a FREE trial copy of the software at the PowerMedia XMS Product Landing Page.
Publish Date: May 5, 2017 5:00 AM
According to some research from the GSMA, all is not lost with the SMS battle against the IP messaging services. With WhatsApp, Facebook Messenger, and WeChat at about 1 billion monthly active users, it would seem that it’s just a matter of time before SMS becomes extinct. However, according to this report, “SMS retains its lead in markets that were early adopters of unlimited SMS bundles,” which makes sense. Start using it and you get used to it, especially if there are no extra charges.
What does this mean for service providers? I mean, the concept of early adopters in this market is long gone. What’s done is done. And the IP messaging services also offers their own value added services such as video calling and making payments. So, I don’t think IP messaging services would suddenly go away even if all the service providers offered free SMS. In fact, due to the value add offered, they will continue to grow.
But it also doesn’t mean the end of SMS. SMS can be used on non-smartphones (not everyone has a smartphone!), and not everyone is on the same IP messaging service. But everyone can get an SMS. Additionally, we are seeing a resurgence of SMS due to IoT, as SMS can send messages to and from non-smartphone devices. So no, it is not over for SMS anytime soon.
Publish Date: May 2, 2017 5:00 AM
The Intersection of Real-time Voice and AI - Can Service Providers Turn Dumb Pipes Into Differentiated Services?
Ah, the pain of being called “boring,”, “not innovative,” “commodity,” or “dumb pipe,” and recently being spanked
by the CRTC (Canadian Radio-television and Telecommunications Commission – the equivalent of the FCC in US) for trying to offer a “free data” ride to certain OTT services to differentiate and attract users. Can we say the service providers are struggling? Yup! It has been tough and not a lot of fun.
I will not dwell on what’s apparently obvious or continue to jump on the bandwagon with the rest of the finger pointers. Rather, I want to take you on a fun trip into the future - a future where at least some of service providers will possibly take the spotlight. If massive corporations like IBM and Oracle can continue to “steer the ship” to be relevant and not end up like DEC, Polaroid, and Blockbuster Video, so can global service providers. They will just need to change the way they operate and innovate.
Service providers have an absolutely incredible asset. They have access to millions of customers, but they have lost touch with those users – or perhaps never had it. Have you tried calling Verizon, Bell, Telefonica, or Rogers? If it’s because of a problem, why are we having to call in the first place? Perhaps that could already have been figured out by the service provider and solved automatically so customers never need to attempt a call. Here’s a question for you. Can we please get rid of the old school IVRs that ask you to select your language and give you a set of random numbers to select while you’re hoping to talk to a human? That’s just cruel in this day and age. Sorry, I said I would not poke! Back to the future.
Artificial Intelligence (AI) is starting to touch our daily lives; we have robots that clean our floors, cars that self-park, and an intelligent personal assistant app on our phone that not only answers our questions but also can turns on the lights in our home. What is the next touch point when it comes to how we communicate? Can AI be something we can hope and expect from our communication service providers? Can AI be “connected” to the traditional services like voice and messaging? The answer is yes!
As a consumer, I want you to imagine a future where you have all your communication needs (messaging, voice, and video) assisted by intelligent automated bots that utilize artificial intelligence to turn current dumb IVR systems into exceptional experiences. Can you picture the following scenarios?
- Can I ask my Amazon Alexa to make phone calls? “Alexa, call grandma.” Surely that functionality belongs inside the service provider wheelhouse
- Can my messaging understand when I’m super busy (perhaps at a birthday dinner) and have an automated intelligent dialog with the person messaging me?
- Can I get a family-friendly voice and video conferencing app so that my kids in different parts of the world interact with their grandma or participate remotely during family events?
- Can the TV service send me a push notification when my favorite event is live on the screen or maybe enter the event into my personal calendar?
All the above scenarios are doable today, and the reasons why these actions are not ubiquitous is not a technology problem. It all has to do with three major roadblocks:
- Silos: For many years, service providers have been buying random “things” from random vendors. Most of those “things” are their own silos and do not interact much or at all with other “things.”
- Integration: The “things” both in the service provider network and in the Cloud need to talk to each other and be available for developers to leverage seamlessly.
- Speed: Service providers need to put together an environment where new, differentiated, exciting, useful, and valuable applications and services can be designed, developed, tested, trialed, and deployed FAST – not years, but months or even less!
Changing will be somewhat painful. Like as it was for developers moving from waterfall to agile development methodologies, speed and agility will need to be a key component to any new product introduction. Some ideas will fail, some will get adopted, and few will expose new killer apps that will bring amazing new solutions to the users.
The AI market is starting to heat up with the usual suspects including Apple, Amazon, Google, and Microsoft. Few service providers are moving in aggressively (Orange with Djingo) as they are afraid to partner with above “motley crew” but most are still wondering how to approach this fragmented space.
Dialogic is focused on helping service providers break into new applications and solutions quickly with our DialogicOne™ suite of solutions. We work on next generation solutions that bridge the silos and integrate platforms to create innovative applications quickly.
We are experts in telecom with over 30 years of experience as well as architects of next generation applications and services for the service providers globally. We have solutions to address the roadblocks service providers face, and a proven track record working with them to leverage the past and move aggressively into the future.
Next time, we will dive into the absolutely “Wild, Wild West” called the Internet of Things and how service providers can leverage that revolution for their return to the spotlight.
Cheers - here’s to the future!
Publish Date: April 28, 2017 5:00 AM
Everywhere in the world, small and big enterprises spend a considerable part of their budget on Antiviruses, Firewalls, and other appliances to protect their network and data. The typical network hacker usually targets the larger enterprises which are potentially a better mark with deeper pockets and lucrative secrets to keep. The PBX hacker though does not care about your enterprise size, because you can be as lucrative as any other company one hundred times bigger than you. When telephony shifted to IP, it brought many advantages, but it also exposed the voice to the same threats as the network. Being able to access your extension and use it outside the office via internet is great for both you and the hacker. It opens a potential door that the older PSTN PBX’s had not. Interestingly enough, most of the time, IT administrators are concerned about the Wi-Fi, router, email, and other services authentication processes but end up neglecting the PBX. Maybe the new mindset hasn’t settled in yet and the PBX is not being given the same importance as the company’s firewall or router as a defense point of the enterprise network.
Not long ago, I witnessed a situation at a small enterprise that got a two hundred thousand US dollar phone bill. The cause was simple: a default password had not been changed on the PBX which was connected to the Internet. This resulted in thousands of calls fraudulently made to exotic locations such as Sierra Leone and Moldavia. With typical network hacking methods, such as Ransomware or others, the victim has the choice to pay the hacker or not. The only consequence of the decision of not paying the hacker will be the data not being recovered. On the other hand, you cannot exactly tell your service provider you are not paying the phone bill because you were hacked…The severity of this issue is not to be ignored and can bring even a decent sized company to its knees. Yes, VoIP brought tremendous advantages but it also introduced several deadly traps. Luckily, protecting the enterprise voice service has evolved and it does not depend exclusively on the IT administrator using complex passwords or firewall rules.
The evolution of Unified Communications (UC) and subsequently Unified Communications as a Service (UCaaS) has hardened the defensive mechanisms of enterprise communications. The fact that the systems can run on a typical COTS server with increased compute power allows running complex defense mechanisms when compared to the ability of old hybrid PBXs. One of these mechanisms involves Machine Learning (ML). The typical voice protection systems are based on rules, which in my view can either be too permissive and still allow some dubious behaviors to occur, or too strict and have the IT administrator waste more time acknowledging false positives and adding certain numbers or routes to the whitelist. When it comes to enterprise voice, one cannot assume that the premise “one size fits all” applies. Each enterprise has different call behaviors. Just because a country is likely to be connected to call fraud, does not mean every single call to that country is fraudulent. This is where ML is extremely effective. It can analyze your typical trends and behaviors and flag only what is unusual. Rules are static and a hacker can get around them simply by testing the waters until he finds the weak spot. ML is dynamic and the alarm threshold changes based on the current call flows when compared with the historical behavior.
When choosing a UC or UCaaS system, do not overlook the type of protection it offers. Chose a system that offers real-time detection and dynamically changes the permissions based on your company’s profile. The previously mentioned small enterprise that got hacked could have benefited from this since an ML-enabled system could have flagged and blocked those calls. If not for the unusual destination, it would definitely have spotted the sheer unusual number of calls. The typical excuse for not getting proper protection for the voice system is that the enterprise is too small and doesn’t need to spend that amount in “just” protecting the voice system. Well, that voice system can be “just” the cause of the enterprise’s demise. So, when it comes to PBX hacking, no victim is too small.
Publish Date: April 25, 2017 5:00 AM
Can a Class 4 softswitch really run in the cloud? This was a question I got at Mobile World Congress from a prospect because he was questioning whether a core telecom infrastructure node can actually run in the Cloud / AWS. The answer is yes, for sure - the networks have improved so much, and AWS has been running many mission critical, latency critical apps outside of telecom that a switch can certainly run in AWS. In fact, we have made the Dialogic NGN Softswitch and IMS MGCF (Dialogic ControlSwitch System) run on AWS and have already sold it and deployed it with customers.
The reason someone would want to do this is obvious –a next generation customer would want to be able to transfer IP phone calls to the PSTN, but would need to do it via AWS because their entire infrastructure is already on AWS. The public cloud infrastructure offers enhancement of service agility (i.e. scaling up and down) and also offers transfer of CAPEX to OPEX, which fits their business model better.
For Dialogic, it wasn’t that difficult to move the Dialogic ControlSwitch System to run in the Amazon Cloud. The ControlSwitch already ran on COTS servers, and has a unique modular architecture that decomposes functionality into discrete building blocks / Virtual Machines (VMs). The underlying cloud computing infrastructure is used only when it is needed, for example, when processing a call request. The ControlSwitch System draws the necessary resources on-demand (like compute servers or storage), perform a specific job, then relinquishes the resources after the job is done. The ControlSwitch can then elastically scale resources based on traffic load and service demand and can execute the off net call to the satisfaction of the voice subscribers.
In other words, yes, a Class 4 softswitch can run in a cloud. If you want to read more, please read this whitepaper.
Publish Date: April 25, 2017 5:00 AM
Mobile World Congress, for me, has always been a combination of looking forward towards our future while at the same time reflecting on the massive changes I’ve seen in this industry. I mean, years ago, who would have thought that Microsoft today would be both a large service provider and an enterprise PBX behemoth via Skype for Business / Lync? (And I remember when Microsoft insisted Lync or whatever they called it back then was NOT a PBX.) More recently we’ve seen Facebook and Amazon respectively become huge movers and shakers. I saw it all in full force at MWC.
Facebook has always used MWC to drive its agenda. These days, Facebook is driving the Telecom Infra Project (TIP) that, according to the TIP Website, is “an engineering-focus initiative driven by operators, infrastructure providers, system integrators, and other technology companies that aim to reimagine the traditional approach to building and deploying telecom network infrastructure.” I bet half of those working on the project see opportunities while the other half are scared. Either way, it’s likely that Facebook will succeed in driving some software-based telecom infrastructure that is likely to have a large open source component.
Regarding Amazon, the whole telecom world wants to run their apps and/or infrastructure on Amazon ECs. I recently watched an Andy Jassy (CEO of Amazon Web Services) keynote from the Amazon reInvent conference in November and noticed that it’s a $13B revenue run rate business with 55% YoY growth. That kind of growth from that size of a company! Wow! If you didn’t think cloud computing was important, or didn’t think the move from customer premise equipment to the cloud was a trend, think again! And while Amazon Web Services had no presence at Mobile World Congress, their cloud was floating around everywhere, with many telecom services running on it.
Telecom is alive.
Publish Date: March 28, 2017 5:00 AM
Remember as a kid your TV show or radio broadcast being interrupted by an announcement, “this test of the Emergency Broadcast System,” followed by the squeal of a test tone? Reverse 911 has essentially made that old system obsolete – what is Reverse 911 and how does it work?
When I was a kid, I lived down the street from the volunteer firehall. If there was a house fire, car accident, or medical emergency, the fire company would summon the volunteers with loud siren mounted on the roof of the firehall. Once the firefighters arrived, they would hop on the side of the truck and roar off to the emergency. Eventually the ear-splitting siren gave way to the digital pager, giving a precise address to the firefighters in an instant, allowing them to drive their own cars directly to the emergency, saving valuable time.
Communicating to the wider community about fires, floods, rising water, or other natural disasters has always been a vexing problem. Sirens and the Emergency Broadcast System were a byproduct of the nuclear threat of the 1960’s and fortunately was rarely (if ever) used in most communities.
With television and radio listening habits changing, the advent of on-demand services and the invention of the mobile phone – community emergency response services needed a better way to communicate quickly and concisely to the citizenry within select geographic bounds. Since most every household has at least one telephone, it seems natural that calling those houses in the affected area with a voice message would be a good idea. The idea for Reverse 911 was born.
To create a Reverse 911 system that can call many households in a community, you need a few things:
1. The ability to make outbound automated telephone calls.
2. The ability to know if a person answered the call, an answering machine answered the call, or if there was no answer.
3. Allow the recipients to use DTMF responses to acknowledge.
4. To detect network error tones, including Busy, All Circuits Busy, and Out of Service tones.
5. The ability to record and playback a voice message.
6. The ability to scale massively, allowing thousands of households to receive the recorded message in a relatively short period.
7. A database of every household, their address, and phone number.
Any combination of media gateways or session border controllers and SIP trunks can provide the connectivity to the PSTN and initiate outbound telephone calls under the direction of an application server. The difficult parts are items 2-5, being able to accurately detect whether the person being called answered or not, and properly detecting responses and network errors. This capability is Call Progress Analysis (CPA), and in a SIP architecture, is accomplished by a media server.
To initiate an outbound call, an application instructs the gateway or SBC to dial the telephone number of the intended recipient and requests that the media (audio) during the calling process to be sent to a media server session. The media server uses the CPA algorithms to “listen” to the ringback tones, busy signal, network error tones, or for a human voice to answer. If a human voice is detected, a decision is made as to whether it was a simple “hello” or a longer greeting that ends with a beep tone, suggesting that an answering system picked up the call. The result of all this analysis is sent to the Reverse 911 application, allowing the application to play the prerecorded announcement or a message on the answering system. By having a high confidence on the result of the CPA, the Reverse 911 application can deliver the important message, waiting for the recipient to answer or the beep of an answering system. Without CPA, the application would likely not wait for the answer, leaving only half a message or must repeat the message multiple times, wasting resources and slowing the delivery of critical messages.
The Dialogic PowerMedia XMS media server software is ideally suited for this application as it includes advanced CPA algorithms. With over 20 years of improvement, the Dialogic CPA algorithms have been tuned and tested over millions of test telephone calls both domestically and around the globe. Accurate and quality CPA algorithms improve the efficiency of Reverse 911 applications, reduce network usage and more accurately inform the community about potentially harmful emergencies.
(And most importantly, we don’t have to suffer though the Emergency Broadcasting test tones any longer.)
Publish Date: March 16, 2017 5:00 AM
Robo-Calls are rightly getting negative press and regulation. But Call Progress Analysis (CPA) has many legitimate uses beyond enabling Robo-Calls. Dialogic has been getting quite a few questions lately about software based CPA because of the legitimate uses as discussed last week.
CPA was first enabled via sophisticated algorithms that first started being employed via DSPs. But as hardware such as call processing boards have morphed into software modules, the CPA algorithms might not be quite the same.Host processing, say using Intel CPUs, may not be as powerful. And porting algorithms from DSPs to software may not yield the same functional performance. As such, some software CPA clearly may not behave the same as CPA deployed via DSPs.
We know this since we’ve been through this. Dialogic has been shipping software based media servers since the early 2000’s. We were the first to do this as part of Intel. As we ported many DSP functions to our HMP product, we saw small variances in many functional areas. And we worked hard to correct the behavior in all areas (not just CPA) so it worked as much as possible the exact same as a DSP-based board system. And note that just because an API is the same doesn’t mean a function will behave the same!
As I said above, Dialogic has been getting questions about CPA lately. Take a look at our PowerMedia product line if you are interested in using the premier software based media server.
Publish Date: March 14, 2017 5:00 AM
Robo-calls are making the news lately. I even wrote a blog about them last year. We all hate getting those calls. While most contact centers follow the rules, there are companies that don’t and they are the ones that cause consumer frustration. But just because Robo-calls are bad, it doesn’t mean that the technology that allows those kinds of calls are bad. Call Progress Analysis (CPA) is one of those technologies, and CPA is but one of many technologies that enable the bad apple Robo-Calls to happen.
CPA is what enables the robo-call, as it rips through its many calls, to try and find a live person to talk to. The calling system uses CPA to see if a call is ringing, if the line is busy, or if a call is answered, and then to figure out if it’s an answering machine, fax machine, or a live person. In other words, analysis of the progress of the call, hence the term Call Progress Analysis. And the calling system does this by trying to figure out the background noise, overall energy of the answer, etc. The overall outbound calling system then uses this information to figure out when to put a live agent on the phone.
There are very legitimate uses for CPA and the outbound dialing systems that utilize them. For instance, you may have chosen to be contacted by mobile phone call by your airline. If say, the airplane is delayed, then the airline would need to contact everyone. Some may choose email, some may choose text, some may choose a voice call. If say 70 people chose voice call, then the airline can put this into their outbound system and have it call everyone. If someone answered, then they can choose to talk to the person with a live agent (maybe if they are a high status flier), or they may choose to play an announcement about the flight. I’m sure you can think of many other examples like this.
Next week I will discuss the impact of CPA moving to software based call systems.
Publish Date: March 7, 2017 5:00 AM
Whether it’s one bad connection degrading the quality of the entire conference, or problems with the underlying media server or conference call architecture, a poor conferencing experience is avoidable. For large scale video conferences, the Selective Forwarding Unit (SFU) architecture may be a good way to go.
SFU is a topology allowing for clients to send their encoded video stream to the centralized media server where it is then forwarded/routed to the other clients. The SFU topology is an attractive approach to addressing the server performance issue, as it doesn’t involve the compute expense of video decoding and encoding. Additionally, without encoding/decoding, the latency of the added SFU media server is minimal. Lastly, the clients with full correspondence with the SFU media server have complete control over the streams it receives, and because the client is receiving the streams it wants, it can have full control over the user interface flexibility.
While the SFU topology has become a popular choice among WebRTC communities, perhaps the most common overlooked shortcoming of SFU topology is the default to using the ‘least common codec’. This means every participant in the conference needs to use the same codec. For those multiparty conferences where all participants are using PC/laptops, the issue is negligible but introducing a mobile device that is hardware optimized for H.264 acceleration would be better suited using a different codec. The inability to transcode video streams can limit the type of clients that can be connected together.
Additionally, traditional SIP based platforms cannot handle the multiple streams produced by the SFU. For this reason, without a gateway function in the middle, the SFU topologies are restricted to WebRTC only.
However, since each architecture has its pros and cons, an architecture enabling both topologies could be better, depending on your application. I’ll talk more about the pros and cons of a hybrid architecture next week. Stay tuned.
Publish Date: January 24, 2017 5:00 AM
Over the summer, I wrote about how Internet of Things will sometimes need to merge with Real Time Communications. Dialogic even created an infographic on this concept. Let me explain more since I’ve had a few questions come in since then.
IoT in its simplest form is basically sensors sending data. That in and of itself is not that interesting. What is interesting is that some kind of analysis gets done on the data, and if something is akilter then an alert is triggered. In many cases, this alert will go to another machine (M2M!) and that machine will do something. For instance, if there is a system to measure soil humidity, and the soil humidity gets below a certain set threshold, then a sprinkler system could be turned on.
In other cases, the alert will go to a human. For instance, if water pressure is measured to be low in a pipe in a city system, then a human will be dispatched to look where the pressure is low and where presumably a leak is. And the pipe can be fixed. Or if a beer keg in a bar measures low beer, a text message can go to the beer provider so another keg can be dispatched to the bar in time before disaster strikes! Phew.
As we get further into when an alert will go to a human, in some of these cases, real-time communications will need to occur. As I wrote in my summer blog, there may be a case of a car crash and then the car can go into a mode to talk to the driver. This conversation can be overheard by a human who could then send help if required. I’m sure you as a reader can think of other examples of this. For instance, let’s say some emergency is happening (the IoT devices figured that out because of various anomolies in their standard readings), then a conference call to the proper authorities can be kicked off by the IoT system, replete with video of the emergency. Or maybe closer to home, if someone is ringing your doorbell, then a live video feed can go to your smartphone so you can see if you want to actually get up and go to the door. There have also been many healthcare examples written about where voice and/or video would be required.
Dialogic has been doing real-time communications since it’s inception almost 35 years ago. We have both the underlying technology to help you create a cloud-based RTC IoT application, or we can even create a customer application for you.
Publish Date: January 10, 2017 5:00 AM