Dialogic - ContactCenterWorld.com Blog Page 4
In life, saving money usually comes from giving up something, or reducing what you have. The same applies in business, but here’s an exception…SIP trunking – the convergence of voice and data delivered over a single broadband connection that lowers costs and offers better service. “Lowers costs and better service” sounds like an oxymoron, but in this case it is not, which is why SIP trunking is seeing explosive growth…
Compared to TDM and depending on the specifics of the business, SIP trunking can save a business anywhere from 25% to 60% on their telecom expenses. SIP trunking can support voice, data, and video all over IP, meaning a single SIP trunk can replace multiple TDM trunks, drastically consolidating and simplifying the voice architecture – companies pay for one service rather than separate voice and data plans. Additionally, a major reason for the cost savings comes from SIP trunking typically providing much more cost-effective long-distance calling than traditional solutions, as all long-distance calls basically become local calls.
SIP trunking also makes capacity planning/scaling and maintenance a lot less challenging because SIP trunks are virtual rather than physical. For example, during times of high call traffic when a business requires more voice capacity, SIP trunks can be easily adjusted in increments of one or more with a change to the software configuration within a matter of days. On the other hand, traditional T1 or PRI service typically requires purchasing an additional physical trunk with 23 or 24 voice channels even though all the business may need is 10 more voice channels, not to mention it can take months to install a physical trunk. This kind of flexibility and scalability which SIP trunking offers allows businesses to react swiftly to changing conditions.
Increased productivity is also another benefit SIP trunking brings through the combination of voice and data delivery. Regardless of whether on-site or remote, every employee can enjoy voice calls, instant messaging, video conferencing, address books synced between devices, and more. Employees who are on the road or working remotely never have to miss a call again, as their calls can be automatically routed to their mobile phone. The same is true if a line is busy or if the office is closed. [NOTE: click here for a good article on the difference between SIP Trunking and Hosted PBX, as although “these services are similar in function and feature, they also represent different means to the same end.”]
There really is very little doubt that SIP trunking is the way to go for a lot of businesses, but are there any businesses where SIP trunking may not be worth the investment? Typically, if a business has only one central location, or if offices are located in a very concentrated geographic area, then SIP trunking will probably not be worth the time. SIP trunking provides the most efficiency for businesses that have multiple locations spread out over a wide area, hence the cost savings noted above where long-distance calls basically become local calls.
According to a recent study by Frost & Sullivan titled Unshackling the Power of SIP Trunking, “SIP trunking effectively creates a new set of paradigms in business communications services. The defining distinctions that SIP trunking services have over legacy telephony services are in the unprecedented levels of flexibility, scalability, and control that enterprises can have over their communications infrastructure.”
As I bring my three-part series on Telecommunications in the Cloud to an end with this blog, here are a few summarizing thoughts…
- Network operators are in an ideal position to offer cloud-based telecommunications services based on their existing infrastructure.
- CaaS offers network operators the ticket to becoming relevant again to the lucrative enterprise customer.
- Today’s residential customer has higher expectations when it comes to their telecommunication’s requirements, largely due to the influence of the smartphone.
- Increased productivity, flexibility, and lower costs are all tangible features offered to the enterprise by Hosted IP PBX and SIP Trunking.
There is very little doubt that the future of telecommunications will be heavily in the cloud with application development companies like Dialogic taking the lead and offering network operators and enterprises applications like their PowerVille Cloud Centrex.
Publish Date: October 7, 2016 5:00 AM
I recently led a lively roundtable discussion on virtualization, NFV, and SDN at the recent IPX Summit in London. We had a healthy cross section of industry participants including representatives from carriers, mobile operators, equipment vendors, software centric solution vendors (like Dialogic), analysts, systems integration, and test and measurement. The question posed to the group was whether virtualization made sense for carriers and IPX operators beyond the confines of the traditional data center, and this definitely made for an interactive discussion.
The Central Office Reimagined: CORD
The title of the roundtable was misleading, I thought, because today, the central office has become or is becoming more of what we recognize now as a data center. Take the CORD initiative for example. The name alone, which is an acronym for Central Office Rearchitected as a Datacenter provides insight into the direction telecommunications is moving. The CORD project is all about virtualizing legacy hardware devices that are currently deployed in Central Offices. The reference implementation of CORD supports several elastically scalable multitenant services including access as a service.
What’s clear is that data center virtualization and automation techniques are being adopted by service providers and carriers in ways that will have a profound effect on how services are implemented and delivered.
Virtualization in the Access
There are quite a few examples of commercial offerings carriers have introduced that already incorporate SDN and NFV concepts. Some of the examples discussed at the roundtable included services and announcements such as:
- DTAG’s VPN service that includes firewall capabilities, web security, site to site connectivity, and customer self-serve features like subscription, activation, and modification.
- SD WAN or vWAN services involving SDN and NFV technology to deliver high performance, encrypted, traffic optimized bandwidth on demand across standard IP pipes
- PCCW Global’s VPN and Cloud offerings which feature on demand, self-service connectivity
- Telstra’s PEN SDN-based service that allows customers to connect their network services globally and with those of other PEN customers without having to wait for the delivery and installation of hardware appliances.
While the on-demand and self service capabilities of these services are appealing, there is an underlying physical resource aspect that can’t be overlooked. One of the operators indicated that these services were being primarily used to provide connectivity to Amazon and Azure. And while they definitely provide more traction to carriers and enable subscribers to adjust bandwidth as needed or burst when required, there is still a limitation in the access of the physical pipe used to service the customers. But the consensus was that virtualization in the access allows for:
- Rapid service turn-up
- A migration away from spreadsheet provisioning
- A high degree of automation and programmability
Regulations and Virtualization
One surprising insight from the roundtable was the impact that regulations played when it came to virtualization. This could become a particularly sticky issue in Europe where there are “some of the strictest data privacy regulations in the world.” According to those at the roundtable, regulation is an issue that could make certain uses of public cloud and virtualization not feasible or limit the services supported to the confines of the country served. This could impact operators providing hosted services via cloud infrastructure.
Skills Gap Still an Issue
Another roadblock on the road to virtualization observed by a systems integrator is the skillset gap within the operators when it comes to virtualization and cloud technology. Virtualization, NFV, and SDN introduce an entirely new set of terms, tools, and administrative practices that in many ways are orthogonal to traditional network and telecom deployments. Experience in hypervisors and cloud management systems like OpenStack require an expanded set of skills and scripting expertise with languages like YAML and YANG, and also requires an understanding of how the various OpenStack modules like Nova, Neutron, Glance and Ceilometer come into play. I touched on this topic and how one operator was addressing it in an earlier blog. Regardless, it is a problem or opportunity depending on how you look at it
Open Source Virtualization
One vendor brought up the issue of hypervisor uptake, particularly KVM as a source for slow rolling virtualization, however, the industry will have to account for operators deploying a mix of VMware, KVM and Xen as well as using public clouds like AWS for part of the service. Advances in virtualization technology have made NFV especially for real-time multimedia Virtualized Network Functions more of a reality, so support for different hypervisor environments will continue to be important.
Start the Journey Now
Are these challenges enough to slow roll virtualization? In fact it’s the opposite. A representative from one of the companies moving towards SDN-based offerings indicated it was important to deploy virtualized infrastructure and get comfortable with NFV/SDN now. Another operator was already underway with proof of concepts leading to commercial deployments for EPC components such as the authentication gateway. Small MNOs were seen to be more aggressive in moving forward with virtualization of infrastructure and services since they don’t have the massive inertia and baggage from legacy services and infrastructure from which they would need to migrate. The cost for moving off legacy TDM for larger operators can be substantial, but as one participant pointed out, it may cost more not to take action when taking into account the extra maintenance, inefficiencies and operational costs to support end-of-life infrastructure compared to virtualized environments.
The Market Reacts
Regardless, one Systems Integrator that has been helping operators formulate RFPs for moving to the cloud observed several trends that they are seeing with operators that they deal with:
- A hybrid approach using public and private clouds
- Seeking independent advice when it comes to cloud orchestration and management
- Use of open source approaches, ISVs, and major NEMs for orchestration
- Development of in-house orchestration and management
What is the business case? Is it a no brainer? One participant noted that when it comes to a green field approach to virtualizing infrastructure, there is definitely a business case. When doing the analysis, they advised the group to definitely take into account the cost of legacy infrastructure support since that cost will continue to rise as more functions go end of life. (Click here to get access to a white paper that quantifies the benefits of NFV and virtualization by PA Consulting.)
Interoperability is Paramount
Regardless of the quantitative benefits of virtualization and NFV, one of the bigger barriers seen by the group was multivendor interoperability. Interoperability is not only an issue between virtualized applications, but also between applications and the virtualized environment (MANO, VIM, hypervisor environments) in which they’re deployed. Even in the presence of standards and specifications emerging from ETSI, OpenStack, OASIS, Open Networking Foundation, Open Source MANO, and OPNFV, interoperability will still be an issue. While issues with interoperability could possibly slow roll the spread of virtualization in and outside data centers, this may be an opportunity for next generation telecommunications providers. Helping operators overcome interoperability issues between networks has long been the value-add of wholesalers and IPX operators. Who knows, in the future, wholesalers/IPX providers may be an enabler of hosted service options and interoperability between operator “clouds!”
Let us know what you think about virtualization in the wholesale/IPX space, and what new service features as well as new services are becoming possible as operators adopt this technology in their networks. You can tweet us at @Dialogic.
Publish Date: October 6, 2016 5:00 AM
Being born and raised in Buffalo, NY, I've heard every joke and stereotype imaginable:
- Yes, I know the acronym for BILLS is Boy, I Love Losing SuperBowls....
- No, Buffalo is not basically part of Canada, eh...
- Yes, we buy our your kid's halloween costume two sizes too big so it can fit over the snowsuit....
- No, everyone does not eat Buffalo wings (we just call them wings)....
Ok maybe the last one is true and to top it off, Buffalo has never been on the bleeding-edge of adopting technology. We're not luddites, but rather fashionably late to every party. But something caught my eye while I was walking through the Buffalo airport last week. It was something I've never seen in all my travels at any airport. There it was, near the luggage claim, next to the car pickup area - a brand new, shiny public videophone booth. Like a dog with two tales, I immediately needed to check it out.
Developed by Sorenson VRS (a Dialogic customer), the videophone booth is for individuals with hearing disabilities, enabling them to utilize sign-language interpreters for communicating with voice telephone users. For individuals with hearing disabilities and their interpreters, having high quality video is not important; it's critical. The subtleties of sign language need to be picked up by the interpreter and if missed, can mean the difference between 'I am sick' and 'I am disease'... close but not the same. Fortunately, WebRTC is the technology that enables high quality video to the clients/customers but it's those server-side infrastructure features such as transcoding and centralized recording that deliver a premium business-class service.
Perhaps WebRTC has closed the ubiquitous gap needed for video acceptance...or just maybe the arrival of video in Buffalo is a sign the times are changing. Maybe from now on we'll be to the party on time; don't worry we'll bring the wings, eh.
Publish Date: October 5, 2016 5:00 AM
In my first of three blogs on Telecommunications in the Cloud, I discussed how the growth and importance of telecommunications combined with the continually growing reliability, security, and cost-efficiency of the hosted model (in the cloud) has created enterprise and residential services that can’t be ignored. Specifically, I discussed Hosted IP PBX for enterprises, a Communications-as-a-Service (CaaS) that is a win-win for both the network operator to offer and the enterprise to subscribe to.
In this second blog, I would like to discuss how telecommunications in the cloud can benefit residential customers (including small office/home office) with high-quality, feature rich calling services, while once again being a profitable opportunity for network operators.
Today’s residential customer has higher expectations when it comes to their telecommunication’s requirements, largely due to the influence of the smartphone. They are interested in much more than a simple answering machine for their home; they are looking for features such as conferencing, voicemail, video calling, do-not-disturb, along with the standard caller ID and call hold/transfer/forward/wait. Much like their enterprise counterparts, they too are interested in a self-service component, where user configuration and control is provided via a standard web-based portal to make services like conference calling and call forwarding easier to manage and new services simpler to deploy.
For the network operator (a.k.a. service provider), offering Class 5/Residential Services can also be lucrative, but it is a number’s game based on the quantity of residential subscribers. What I mean is that network operators, like almost any other business, charge enterprises more for services than they do their residential customers, but they have less of them. However, the overall revenue difference can be minimized because the number of residential subscribers is generally more than enterprises.
At this point you may be asking yourself two questions…
1. What about all those residential customers who are dumping their landlines and only using their mobile phones?
2. Don’t residential customers need IP at home if they are going to subscribe to services in the cloud?
Two good questions. There is no denying that there has been a trend now for many years where residential customers are dumping their landlines. In fact, according to a study released by the National Center of Health Statistics (NHIS) in December of 2015, “Nearly one-half of American homes (47.4%) had only wireless telephones (also known as cellular telephones, cell phones, or mobile phones) during the first half of 2015—an increase of 3.4 percentage points since the first half of 2014.”
However, the beauty of telecommunications in the cloud is that you don’t need your landline. By using an Analog Telephone Adapter (ATA), you can connect your traditional analog telephone to the VoIP network (your internet) and start benefiting from all of the services offered in the cloud…pretty simple.
In my third and final blog on Telecommunication in the Cloud, I will discuss SIP Trunking, which is another service network operators should consider for revenue growth.
Publish Date: September 16, 2016 5:00 AM
It is pretty obvious these days that both in our professional and personal lives, telecommunications is playing a much bigger and more vital role than it has in the past. One doesn’t need to be an analyst to draw this conclusion, as the empirical evidence is pretty clear with all of the (mobile) devices (e.g. phone, tablet) everyone has one or more of. Add to this the continually growing reliability, security, and cost-efficiency of the hosted model (in the cloud), and you have enterprise and residential services that can’t be ignored.
One such service is the Hosted IP PBX for the enterprise, which is the topic of this blog and the first in my three-blog series I am calling Telecommunications in the Cloud.
The Enterprise: To buy or to lease? On-premise or in the cloud? These two questions are being asked more and more every day by enterprises of all sizes when it comes to their telecommunications needs. Both have their pros and cons, with two of the most obvious being control and cost. Large enterprises typically like to be in control of their telecommunications needs, which is why a lot, if not most, of them keep telecommunications in-house. On the other hand, cost is a top concern for small and medium-sized enterprises, which is where Hosted IP PBX finds its sweet spot.
The Network Operator: The growth and acceptance of cloud-based services combined with their existing infrastructure puts network operators in an ideal position to offer Communications-as-a-Service (CaaS) to their enterprise customers. One such CaaS is the Hosted IP PBX, which enables network operators to become “relevant” again in the lucrative enterprise market. NOTE: CaaS, such as Hosted IP PBX, can also be offered to enterprises by telecommunications service providers who are not network operators.
Knowing that Hosted IP PBX is a win-win for both network operators and enterprises, let’s look at what Hosted IP PBX has to offer. In short, Hosted IP PBX is a business-class phone service provided over the internet allowing small and medium-sized businesses to have a sophisticated telephone system without the CAPEX investment in telephone equipment. In fact, the entire telephone system is hosted (operated and maintained) at an off-site location by the network operator.
Hosted IP PBX also enhances the traditional telecom architecture by enabling a self-services component to the enterprise subscriber. Commonly through the secured web, user configuration and control is provided via a standard web-based portal that enhances basic phone functionality to make standard services like multi-device ringing, conference calling, call move, and call forwarding easier to manage and new services simpler to deploy. For example, with a simple click on a web page, the subscriber can choose to forward calls to their mobile phone or have it ring on all of their assigned numbers.
Which small and medium-sized business wouldn’t want to off-load the operation and maintenance of their telecommunications system that brings the following benefits and more?
- Personnel Savings – with employee salaries typically making up the largest portion of a business’s budget, eliminating the need for in-house telecommunications/IT staff to manage the system, address problems, perform upgrades, etc. is the first of many benefits of Hosted IP PBX.
- Total Cost of Ownership – not having to make an initial large upfront investment purchasing an office telephone system (shifting CAPEX to OPEX) allows that money to be used more strategically. Furthermore, on-going savings include low-cost inter-office/long-distance calling, and eliminating system maintenance and upgrades, with the added benefits of a predictable monthly cost and simplified vendor management for multiple services.
- Scalability – all businesses have spikes in their capacity demands, but not all have the luxury of meeting these demands, unless they have Hosted IP PBX, where they can quickly and easily expand and grow without having to add costly hardware and endure time-consuming installations.
- Flexibility – employees can work from just about anywhere that has an IP connection: home, hotel, airport, mobile phone, etc. while keeping features such as call transfer, auto attendant, music-on-hold, and conference calling, leading to enhanced productivity, all the while managing their own profiles through an on-line portal.
- Business Continuity – Hosted IP PBX service providers offer disaster recovery options as they have multiple carrier-grade hosting centers with fully redundant servers in case of emergencies, such as fire, flood, or power outage, quickly and easily routing calls to alternative locations or mobile phones, enabling for business as usual.
With most network operators looking for ways to increase revenue and not be diminished to the passive role of providing only dumb pipes, CaaS is a clear opportunity. Enterprises are always looking for ways to lower costs, while maintaining (or even increasing) their level of service and Hosted IP PBX is one such service that can accomplish both.
In part 2 of 3 of my blog on Telecommunication in the Cloud, I will discuss Class 5/Residential Services as another service network operators could consider.
Publish Date: September 2, 2016 5:00 AM
While OPNFV and Openstack provide a convenient virtualized environment for deploying and running network-oriented applications, there is another whole dimension to what may be done with it. With conventional computing, you need to wheel in another box, install things, and then modify your networked environment to take the new hardware into account. With a virtualization, you avoid dealing with hardware each time you need to increase an application’s capacity, and can “spin up” additional virtual machines and then configure the environment accordingly. And, in a well-designed OPNFV environment, all of this can be done automatically.
While OPNFV doesn’t come with a magic “gimme more” button, the components are there to put together such a button yourself. Here’s what’s involved:
- The Openstack Heat project. This “implements an orchestration engine to launch multiple composite cloud applications based on templates in the form of text files that can be treated like code.” This means that you can define exactly how you want to run your networked application – size of the instance(s) used, which application image(s) you want, networks and ports that need to be created to tie things together, static vs. DHCP IP addresses, and application-specific configuration. Like other Openstack components, you have a choice of invoking Heat templates through the Horizon GUI or through a CLI. While not a true programming language, Heat’s YAML format allows for a fair amount of flexibility, which makes things readable and maintainable.
- Telemetry. OPNFV, by default, comes with a telemetry node based on the Ceilometer project. By default, this node collects Openstack performance data and uses a Mongo DB to store it. It may also be used as a convenient place to store application performance data.
- Application-specific Key Performance Indicators (KPIs). These are statistics that pertain to the application itself, rather than the platform it runs on. This could be things like the number of simultaneous users logged in, the number of licenses in use vs. the number of licenses available on the node, or the number of people using some other limited application resource. By monitoring these sorts of values, it can become apparent that additional application resources are needed, and that new VMs must be started and connected. And, the opposite can happen when resources are no longer needed.
- Heat Orchestration Templates (HOT). This might be considered the first level of automatic scaling. The infrastructure to direct Openstack on how to add additional VNF components is defined by Heat. HOT has rudimentary abilities that allow some system-oriented performance indicators to be monitored. This would include CPU and disk usage and network performance indicators. Additional VNF components are then started when the need arises, and torn down when they are no longer needed.
- Full Management and Orchestration (MANO). Not really a part of OPNFV yet, but sure to be in the future. There are a variety of MANO products and projects out there in their formative stages, including the Openstack Tacker project, Open Source MANO/Rift.io and Open Baton.
While I’ve been trying to avoid mentioning too much specific to our media server VNF, it wouldn’t be bad to use it for an example of some things that have to be taken into account when scaling applications. Let’s look at video conferencing. There is a finite capacity to the number of caller sessions that can be done on a single VM, and callers are divided up into specific, discrete conferences. What happens if we are running out of room and need to expand? We can’t just allow more callers into an already jammed conference or put them in a new conference that they aren’t supposed to be in.
Well, there is another node in our VNF call a Media Resource Broker (MRB). Here, the intelligence is found that keeps track of the multiple media servers and their capabilities - things like codecs and resolutions available. Knowing what sort of conferencing facilities are available, it is able to quickly move conferences from an almost “full” server to one with spare capacity. All of this can happen when a new caller arrives and puts the media server over the edge.
But, one thing it can’t do is start up additional media servers. It can only deal with existing servers that it already knows about. That’s where OPNFV management and orchestration come into play. When a threshold (as defined by an application KPI) is exceeded, a new media server is started. As part of its startup and configuration, it registers itself with an MRB so that the MRB becomes aware of its additional resources, and can adjust the conferences it manages accordingly.
Now, your application may well work differently, and may require different KPIs and scaling schemes. But, the principles will be the same, and it’s likely that some application involvement will be needed.
This concludes my series of OPNFV blogs for now. But, more will be sure to follow. We might want to take a deeper look into Heat templates and MANO, and there will certainly be things to say about our proposed OPNFV-based, company-wide QA and test environment that is just getting off the ground. And I’m sure there will be other topics I haven’t even thought of yet.
Thanks for reading!
Publish Date: August 25, 2016 5:00 AM
Chetan Sharma has been discoursing on what he calls the “4th wave of mobile communications” for some time. And I’ve commented on some of this from time to time. He recently put out an update of the 4th wave paper called the “4th Wave Index: Benchmarking the Growth and Evolution of the Mobile Ecosystem.” It’s an excellent paper. On the last page, there is a bold subhead that totally caught my eye. It said “Voice and Messaging Revenue line items will disappear from operating financials in the next 5-10 years.”
First of all, it does not mean that there won’t be any voice or any messaging. Obviously, there will be voice minutes, and there will be messaging such as text messages, and there will be integrated social media type of communications, etc. But it does mean a few things:
1. Voice and Messaging erosion from the apps that run on the data networks obviate any need to continually point out this negative trend. When it gets small enough, there is no need to point it out anymore.
2. Social networking provides different kinds of communications. It could incorporate voice, it could incorporate text. It’s intertwined more now and not so disparate.
3. The mobile service providers will be moving to what Chetan calls the “4th wave of mobile revenues” and will report on that.
4. The move to IP means that everything is data. Voice is a type of data. Text is a type of data. Video streaming is a type of data. Different metrics will be used to measure success.
The 4th wave is extremely exciting not only for mobile service providers, but also for application developers such as Dialogic. There are opportunities to add value in very many different ways. One such way I have written about recently is real-time communications and value-added services that go with them.
Publish Date: August 23, 2016 5:00 AM
Robocalls have been getting quite a bit of ink lately in the United States. Robocalls are those annoying auto-dialer calls you may get. The US FCC has stepped in and asked the US service providers to provide robocall blocking services. In many ways, this really is nothing new. Robocalling has been a problem for years. I had put my name on a do not call list many many years ago with great success (Go to www.donotcall.gov). However, that was my home phone. They are now coming to my mobile phone, so I’m going to have to register that phone number.
Tricking callers by displaying fake caller IDs is easier now than it’s ever been, which is one of the reasons why this issue has come up again. If you go to Google and type “robocall” the first things you see are 4 sponsored ads that enable you to send robocalls!
However, it is illegal. The FTC’s website says “If you receive a robocall trying to sell you something (and you haven’t given the caller your written permission), it’s an illegal call. You should hang up. Then, file a complaint with the FTC and the National Do Not Call Registry.”
Note you can still get phone calls from “existing relationships.” For example, I periodically get automated, sometimes even somewhat personalized, phone calls from the New York Giants or members of the New York Giants as I have season tickets with them. And I don’t think it’s possible to escape the political robocalls if you are registered with a party, though especially this year, I wish I could.
What is new is that the FCC has asked the service providers to provide call blocking services, and not leave it up to the consumer to do all this work. There are multiple solutions to this issue at the network level, one of which is putting a call blocking application with the Class 4 switch. And the Dialogic ControlSwitch can help. To find out more, contact us here.
Publish Date: August 16, 2016 5:00 AM
I live in a small town outside New York City in a very densely populated area. However, ever since I’ve had a mobile phone, I have had inconsistent mobile phone service from my wireless provider – Verizon Wireless. When I make phone calls from my home, often I have to stand out on the back yard and find just the right location to get decent service. And forget about LTE service.
I know for sure that Verizon Wireless is trying to rectify the service problems in our town by applying to install a network of antennae. However, they are being delayed by town politics and townspeople worrying about radiation issues and aesthetics.
Most of us in the town have learned to live with this poor level of service, and no one is happy. When we get together with neighbors, the discussion always gets around to bad mobile service. That is, who is providing the least worst level of service: Verizon, AT&T, Sprint, or T-Mobile. These discussions have been going on for years. Everyone is willing to switch to a new provider once a good solution is found.
In this environment, I decided to configure my iPhone for Voice over WiFi service. My carrier, Verizon Wireless, enabled Voice over WiFi on the latest release of my iPhone. I was hoping that the voice quality was better and that there would be no more dropped calls.
I’ve been very happy. The voice quality has been consistently good and I’m having no dropped calls.
The mobile carriers are making big investments in a range of mobile technology and solutions to keep up with surge in usage. See Jim Machi’s blog with commentary on the latest Cisco VNI forecast.
I’ve always been loyal to Verizon Wireless, and have had to settle for inconsistent service when home. However, the new Voice over WiFi capability is something I’m very impressed with. I think I’ll be with Verizon for a while now.
The neighbors and I will have to find something else to complain about around town now.
Publish Date: August 15, 2016 5:00 AM
It’s been quite a while since I wrote about HD voice. When HD voice was first coming to the market 7 or 8 years ago, Dialogic was pretty active in marketing it’s importance and talking about it. We knew that HD voice would be used when VoLTE was implemented. And we saw many cases where Value Added Services needed to be upgraded to insure that HD voice was carried over from just a phone call to the Value Added Service (for instance, voice mail) in question. It’s taken longer than many of us thought.
However, it’s here and fairly ubiquitious now. Apple supports it in the their new phones, WebRTC has this capability built in, and HD voice codecs are used in all OTT offerings such as Google Voice and Skype. I am finally now taking calls on HD voice. I know this simply because I can hear the difference.
It’s interesting how the marketing of HD voice is working with the wireless service providers. In the US at least, service providers are actively marketing it as a benefit of VoLTE. AT&T makes a big deal about it and so does Verizon. Sprint, somewhat less, but it’s on their website if you dig a little.
This may be the last blog I write about HD voice, simply because it’s now integrated into many different offerings. I would expect the marketing of HD voice to start to subside now – it’s not really a differentiator anymore, so why market it when it’s not differentiated? I’m sure there will be a “next thing” to talk about with voice. Apparently, Enhanced Voice Services (EVS) is a big deal. Whatever the “next thing” is, I’ll be writing about it.
Publish Date: August 9, 2016 5:00 AM
In the beginning of June, I did a talk at Bynet Expo titled “Powering the Agile Operator.” Part of the talk was about how NFV could help power the agile operator. As most readers know, NFV promises lower CAPEX, lower OPEX, and faster rollout of services. In other words, agility. As such, NFV is a key component of the “agile” strategy.
But why and how? To me, NFV is about a service provider obtaining the best of breed VNFs (Virtual Network Functions – basically software-based functionality that the network requires to do its job) for what the service provider is trying to do, and putting them together in their network. It borrows concepts from the IT domain where you get the best functionality and have them all work together. This best of breed software approach is new for service providers and will be a game changer in the ability to roll out services. Lower CAPEX and lower OPEX are certainly byproducts of that.
As such, the service provider is not tied to a single supplier, which means they’re not tied to their schedule, or at the whims of their fees for doing special upgrades. The service provider will have software-based choices. The service provider can put the network they want together from the VNFs. Of course, there is work to do regarding interoperability, but that will come.
The fact that software can work on existing hardware, software VNFs can be spun up and down as network needs dictate, and that this software can be developed independently from the hardware is a huge step forward in network agility.
Publish Date: August 2, 2016 5:00 AM
Network Functions Virtualization is more than just moving network infrastructure functionality to a virtualized environment. It’s about orchestrating, delivering, and managing end-to-end services by chaining together software-based network functions, and doing this in an automated and programmatic fashion.
The NFV list of benefits definitely includes lower CAPEX and OPEX, but more than that, NFV allows operators to be more flexible. It does this by enabling a framework for operators to build networks and roll out services at software speed. It also allows them to automate many tasks that in a traditional network architecture - with elements running on proprietary hardware - cost prohibitive and not feasible.
This infographic highlights some of the areas within Cloud/NFV environments where automation can play a role. For example:
- Onboarding a Virtualized Network Function (VNF) into a data center cloud
- Scaling an application by automatically reserving, configuring, and turning up virtual compute and storage capacity as well as loading additional network function resources into those virtual machines
So take a look at ways that NFV is defining standards within data center cloud environments to automate the network infrastructure cloud.
Download the PDF Version
Publish Date: August 1, 2016 5:00 AM
With legacy circuit-switched equipment rapidly reaching retirement age, telecom service providers around the globe are focused on evolving to all-IP networks utilizing SIP and Diameter signaling, and additionally, on migrating to virtualized and cloud-based platforms. With compelling advantages that range from opex and capex cost savings to multimedia applications and service portability, all-IP Next Gen and IMS networks certainly do represent a big leap forward from the installed base of circuit-switched networks that rely on Signaling System 7 (SS7) protocols and Signaling Transfer Point (STP) switches for end-to-end connectivity.
However, despite the many compelling advantages of all-IP broadband networks, it would be premature to declare SS7 and STP’s “dead”. In fact, SS7 signaling is still very much alive and kicking. So the question is: why does SS7 live on and remain relevant today? Well, one reason for SS7’s continued vitality is that it serves as a central nervous system for the PSTN and PLMN, and can therefore be relied upon to guarantee global connectivity for both voice and SMS services as the world gradually transitions to all-IP networks over the coming decade. A second reason for SS7’s on-going relevance can be attributed to the success of mobile Short Messaging Service (SMS) and the fact that it continues to live on despite fierce competition from OTT Instant Messaging alternatives. In fact, SMS text messaging usage has actually been aided in recent years by its integration into compelling new applications such as Visual IVR, mobile marketing, and mobile payments. Clearly, with demand for these sort of applications on the rise, network operators will want to ensure that their SS7 and STP infrastructures remain fully supported well into the foreseeable future.
While the SS7 protocol itself is unquestionable robust and readily able to address most of today's networking challenges, in too many cases the same cannot be said about the associated STP switching infrastructure, much of which tends to be extremely dated and deployed on proprietary TDM hardware platforms. Unavoidably, end-of-life STP switches supporting E1 and T1 spans today will likely require appliance-based replacement solutions; however, there are also STP’s dedicated to supporting SS7 over IP-based facilities (SS7 over IP is called SIGTRAN), and these particular STP’s could be candidates for virtualized STP solutions that offer opex and capex savings along with improved service agility.
For operators around the globe, legacy SS7 services are neither dying out nor being rendered defunct by IP messaging applications. Moreover, with the number of global STP suppliers now dwindling, the question being pondered by many network operators is not “when will SS7 be dead?”, but rather, “when should I replace my unsupported STP’s?”
With a focus on solving today’s challenges, Dialogic offers a suite of both virtualized and appliance-based signaling solutions. If an STP replacement might be in your future, we invite you to learn more by downloading the Dialogic DSI STP datasheet.
Publish Date: July 29, 2016 5:00 AM
You may not have, as I did, the luxury of choosing the array of hardware – rack-mount servers (RMS) or Blade servers - to be used for your OPNFV implementation. I’m going to assume you’re not rolling in a rack full of blades, fiber switch fabric, and storage arrays, but have to make do with what you hope are adequate 1U or 2U machines. I’ll mention later some of the interesting twists encountered with a blade setup, but let’s start with RMS’s in the blog.
First, how many do you really need for a minimal but usable deployment? Yes, it is possible to do everything on a single large system by putting the various OpenStack nodes on virtual machines (often Oracle VBox). But, this leads to extra network configuration as what are normally physical NICs will now be virtual NICs. And, worse yet, the machine that will run your guest VMs will itself be a virtual machine. This added layer of virtualization will not be a pleasant thing.
In my mind, a set of 4 bare metal systems is needed for a minimal OPNFV deployment. This will give you a Fuel master node to deploy from and a place to park all of the necessary roles required for OPNFV. What you will lose is some speed because you have jammed several functions on the same system, and you will sacrifice redundancy/high availability. In addition, this configuration only provides a single compute node. So, this node should at least be a sizable system. My compute has 8 CPUs and 32 GB of memory – enough to start up at least a handful of guest VMs.
Let’s look at the overall picture of the deployment. Note that this shows only the RMS side of things, although the virtual Fuel machine is there.
Here are some important points:
- Machines need a minimum of 2 NICs. The NICs (or at least one NIC) must support VLANs.
- 1000BT NICs are the absolute minimum. 10 GB/s NICs would not be overkill! Our blade server deployment uses 10 GB/s and is noticeably faster.
- All internal OpenStack networks coexist on a single physical network by means of VLANs. The external/public network is also on a VLAN.
- The PXE boot network must be a flat (non-VLAN) network.
- Gateways in the ToR switch route traffic to other machines in the development lab environment, general corporate network, and public internet.
- Corporate and lab DHCP must be segregated from OPNFV/Fuel/OpenStack. DHCP servers are automatically set up there as needed. If there are conflicting DHCP servers, you will be in trouble.
If you are not huddled next to your stack of systems, you will likely wish you had viable remote consoles. Unless remote management capabilities are built into the server, this would be through an Ethernet-enabled KVM switch. You will probably need to change BIOS settings, check the progress of PXE boots and get to the systems when networked ssh is not functioning for reasons unknown.
Let’s move on to the Fuel setup. As a quick refresher, Fuel is an installer for your OpenStack/OPNFV environment that provides a GUI to lead you through the OpenStack configuration (If you need a refresher, here’s the link to an earlier blog). As I have mentioned, the OPNFV Fuel Installation Guide is quite comprehensive, laid out in cookbook fashion so that it can be followed from start to finish. So, nothing will be gained by rehashing it. What I will do is point out some “gotchas” that got me in the hope that they won’t get you.
Fuel setup tips:
- FUEL menu is kind of fidgety, especially with a remote console. Make sure the console is big enough, or strange behavior will occur. Status/error line can be lost, labels truncated and tabbing between fields may not work correctly. Make sure you have a full 80 character width and that you see the full menu:
- Most screens in Fuel have a “verification” function. Always give this a try before saving the values for the screen.
- Remember that there is a running system behind the Fuel menu. You can drop into it to verify things on the underlying system (most importantly, network connectivity) using “Shell Login.”
- The Fuel menu can be run after the installation to easily check on Fuel settings – “fuelmenu” will start it up. Remember to Quit Setup. Quit without saving so that it will not try and make any changes.
- I had trouble getting to the outside world for Ubuntu and OpenStack repositories and thus passing network verification. I set “Skip building bootstrap image” in the Bootstrap Image screen and set up the repositories later, before deploying.
- While it’s possible to set the default gateway on the screen for either network, you will likely only set it as part of the non-PXE network.
- Fuel on a virtual machine – worth the effort if you are using multiple deployments. While multiple environments within a single Fuel are possible, separate Fuels are more flexible, especially in a “mixed” (Blade and RMS) environment. “Bridged” networking devices should be used, as they explicitly map a VM’s virtual network device to a physical device on the host. This is important, as one of the physical networks is flat and used for PXE booting and the other is divided up into VLANs. Also, check closely to make sure the physical device you expect is connected to the bridge device you expect. Ethernet naming conventions can be confusing.
- Be patient once you start the Fuel setup. It can take a while. When finished - if you can get to the Fuel GUI - all is well.
- When booting the OpenStack nodes to make them available for Fuel, it is helpful to watch what happens on the console. If your PXE boot is not working, you may need to drop back into “legacy” boot mode instead of UEFI. I found I had to do that. This will depend on your servers. When the PXE boot works properly, OpenStack nodes will magically appear as ready-to-deploy in Fuel.
- If “Skip building bootstrap image” was chosen, you will receive a suggestion to set up a local repository on the newly-installed fuel node, using “fuel-createmirror.” Follow this suggestion, as this will replace the repositories you were not able to install as part of the Fuel node installation. This will conveniently update all of the URLs in Settings/General/Repositories screen.
As with the Fuel installation, the OPNFV Fuel Installation Guide does a good job of laying out the steps of setting up for and doing the OpenStack deployment using the Fuel GUI. However, there are some traps you can possibly fall into along the way. My next blog entry on my OPNFV journey continues with exposing some of those traps as well as highlighting some additional points to think about in deploying your OPNFV platform.
Publish Date: July 28, 2016 5:00 AM
This infographic is your GPS to help you map out the route to an evolved IPX on which to offer revenue-ready and customized voice and video applications along with advanced interconnection capabilities. Wholesale carriers and IPX operators can leverage their position as a trusted intermediary with MNOs and fixed line operators to provide secure any-to-any mediation and transcoding services for enabling VoLTE/IMS connectivity.
Download the PDF Version
Publish Date: July 28, 2016 5:00 AM