News from Industry

Next major release of Kamailio is going to be versioned.The plan to release it was sketched during the last IRC devel meeting back in February, proposing to get it out by beginning of June 2015. Given there has to be at least one month of testing, the next milestones to release date were proposed:

• freezing the development: Wednesday, April 22, 2015
• if testing goes smooth, then branching 4.3 after about one month: During the week starting May 18
• test more in beta phase, prepare packaging, etc. and release after 2-3 weeks: One of the days between June 4 and 11

You can join the discussion with other suggestions or adjustments on Kamailio mailing lists.

Two months till the start of Kamailio World Conference & Exhibition 2015. Prepare yourself for three days full of interesting presentations and demos during May 27-29 in Berlin, Germany!With the accelerated propagation of LTE and hot discussions about what 5G is going to be, definitely VoLTE is a top topic these days. Kamailio has a consistent set of IMS extensions, making it one of the most flexible options to consider for rolling out VoLTE platforms, already with live deployments in Europe, Asia, Africa and South America.Kamailio World is the place where you can play with VoLTE yourself, FhG Fokus, Core Network Dynamics and NG Voice are preparing a testbed on site with a local LTE network and a Kamailio-based VoLTE platform. Bring your VoLTE capable device (e.g., iPhone 6 or most of the latest models with Android from Samsung, LG, Huaweii …) and experience yourself the technology of your calls in the near future, with high definition voice and proper integration with other IP based services, including WebRTC.
Don’t forget to check the other presentations, workshops and exhibitors, it is going to be one of the best events for real time communications and open source in Europe. Registration is open, be sure you secure your participation before the event is sold out!

Here is a short tutorial that helps building a PBX with FreeSWITCH.

Filed under: Networking Tagged: freeswitch, pbx, sip, voip

Eloy Coto Pereiro has published a very interesting article on his blog about using Kamailio and Statsd. Being the developer of the statsd module in Kamailio, he presents more details about the benefits and how to put all pieces together in order to have the statistics exported by Kamailio and graphs build by Graphite.Next is a screenshot from the article of what you can get as a result:

Enjoy!

Camille Oudot, from Orange, France, has recently published a new module for Kamailio, collecting a set of configuration file functions for operations on TCP/TLS connections. The module is named tcpops and the documentation is available at:

• http://kamailio.org/docs/modules/devel/modules/tcpops.html

The module allows admins to enable/disable keepalives per connection as well as setting custom lifetime for each connection.Camille has also added new functions to the usrloc module  that gives the admin the ability to close the TCP connection if the registration request that opened it has expired.TCPOPS will be part of the next release of Kamailio, which is labelled 4.3.

Here we are, the 8th edition of Kamailio Awards granted for the activity during the previous year, respectively 2014. Continuing the tradition, there are two winners for each category.The Kamailio project continued to grow in number of contributions and add plenty of new features. The second edition of Kamailio World Conference and the major release of version 4.2.0 are among highlights of 2014.
Next are the categories and the winners!

New Contributions

• statsd - provides native integration with statsd and graphite from Kamailio configuration file, allowing to publish statistics from Kamailio runtime environment and build graphics that makes the monitoring process easier. The module is developed by Eloy Coto Pereiro, from Foehn, UK
• tsilo - provides a mechanism to add new branches to not-yet-answered calls while other branches are still active. For example, in the world dominated more and more by mobile networks, the module enables Kamailio to forward the INVITE to a new endpoint that just registered (e.g., triggered by a push notification) event the INVITE was routed before to a different destination (e.g., desk phone). The module is developed by Federico Cabiddu, from Orange Vallee, France

Developer Remarks

• Lucian Balaceanu - from 1und1 AG - besides the work on the modules published over the time by 1&1,  he has the merits of being interested into the core components, providing several important patches on handling SIP replies via onsend route as well as pushing new features to modules such as acc, siptrace and sipcapture
• Luis Azedo - from 2600hz.com - the main developer for kazoo module, he provided valuable feedback and patches for improvements and new features to many other modules, such as presence, db_text, registrar and usrloc

Advocating

• Alex Balashov - from evaristesys.com - long time community member and developer of the project, Alex spent consistent resources traveling within and outside of USA for promoting Kamailio, relevant for 2014 would be Cluecon and Kamailio World conferences
• Giacomo Vacca - from rtcsoft.net - sharing a lot of useful information via his blog (like deploying Kamailio with Puppet or within Docker containers), Giacomo had a year very rich in traveling as well, covering Kamailio World, Cluecon and Astricon, presenting about automatic deployments of Kamailio

Technical Support

• Charles Chance - running Sipcentric Ltd, UK - he is an active developer, with many contributions to distributed message queue (dmg) and other components such as htable or registrar, Charles has been helping very often on mailing lists
• Will Ferrer - from switchsoft.com - very active on users mailing list, with good reports and troubleshooting of problems reported by others. He has been helping many to sort out their issues and get their Kamailio running smooth

Blogging

• beingasysadmin.wordpress.com - with blog posts for Kamailio deployment for IM and integration with FreeSwitch. Besides these, the site has couple of articles that are very useful for people managing realtime communication platforms
• loadmultiplier.com - it has a interesting set of blog articles related to Kamailio and IMS. Given that IMS has a complex architecture, any share of knowledge is very useful. As LTE is being deploying world wide as a fast pace, the Kamailio and its IMS extensions can help in deploying the VoLTE service

Related Projects

• Elastix - an open source unified communication server has now a variant targeting large deployments, packaged with Kamailio as SIP routing proxy and Asterisk for PBX telephony services
• Kazoo - an open source, scalable, distributed, cloud-based telephony platform that allows to build powerful telephony applications with a web management interface and a rich set of APIs to extend and integrate with other systems. Its telephony engine is built using Kamailio and FreeSwitch

Business Initiatives

• IT Center Portugal - known also for their deployment of several hundreds of Kamailio-Asterisk pairs offering unified communications services for the Portugal academic network, IT Center has built a VoIP core platform with Kamailio routing the SIP traffic, relying on OpenStack to offer the elasticity to scale based on load demands
• Toky.co - a venture from Carlos Ruiz Diaz with support by Wayra, Telefónica's startup accelerator, Toky is leveraging WebRTC technology for offering communication services without the hassle of installing applications. Kamailio with its websocket module is used for routing signaling between WebRTC endpoints.

Events

• AstriDevCon - somehow attached to AstriCon, the AstriDevCon is actually the top day within that week for developers working with IP telephony technologies. One of the rare moments within an year where you find a high density in the same room of people that have the experience and can find a solution for anything going wrong in real time communications
• KazooCon - the Kazoo project has a fast growing community, fuelling it with an event orgaized by 2600hz.com at the heart of IT industry: San Francisco - Silicon Valley. Embedding Kamailio, Kazoo has become a choice for those willing to start with an out of the box telephony system and enhance it with more features offered by Kamailio.

Friends of Kamailio
Awarded to people not necessarily working directly with Kamailio, but whose activity has a good impact on the project and open source real time communications.

• Matthew Jordan - he became a respected leader of Asterisk project in very short time, creating a new vibe around the development of the project, in a time of consistent refactoring for Asterisk application. The success to transform a big project to cope better with the new models of communications is demonstrating once again that one can rely on open source for long term business and not be afraid of being stuck with unmaintained or old technologies. Irrelevant to say that he supported always the efforts to make Kamailio-Asterisk integration simpler and clarify the role of the applications in real world deployments.  
• Peter Saint-Andre - he is one of the people that bridged (and still does it) the open source communities and standardisation bodies over a very long period of time. Getting involved in standardisation process is something that open source should do more, because it can ensure that their development model is protected and practical specifications are standardized instead of hypothetical and over complicated concepts. With open source being driven a lot by immediate needs and standardisation bodies caught a lot in bureaucratic and theoretic approaches, Peter's activity is really remarkable. Although mostly involved in XMPP, he has worked a lot on the specifications for SIP-XMPP interworking, welcoming always Kamailio when presenting about this topic. 

This is it for 2014. If you want to check the previous turn of awards, visit:

• http://by-miconda.blogspot.com/2014/03/kamailio-2013-awards.html

The activity within Kamailio project during 2015 so far is very rich, check the project web site for announcements on what is new and the plans for the future.
Looking forward to meeting many of you soon in Berlin, during May 27-29, 2015, at the 3rd edition of Kamailio World Conference & Exhibition.

A couple of decades ago if you bought something of any reasonable complexity, odds are it came with a call center number you had to call in case something went wrong. Perhaps like the airline industry, economic pressures on contact centers shifted their modus operandi from customer delight to cost reduction. Unsurprisingly this has not done well for contact center public sentiment. Its no wonder the web came along to augment and replace much of this experience –  but no where near all it. Today, WebRTC offers a unique opportunity for contact centers to combine their two primary means of customer interaction – the web and phone calls – and entirely change the dynamic to the benefit of both sides.

To delve into what this looks like, we invited Rob Welbourn to walk us through a typical WebRTC-enabled contact center infrastructure. Rob has been working on the intersection of telephony and web technologies for more than 8 years, starting at Covergence. Rob continued this work which eventually coalesced into deep enterprise and contact center WebRTC expertise at Acme Packet, Oracle, Cafe X, and now as an consultant for hire.

Please see Rob’s great technology brief on WebRTC architectures in the Contact Center below.

{“intro-by”: “chad“}

Robert Welbourn

Introduction

If ever there was an area where WebRTC is expected to have a major impact, it is surely the contact center.  By now most readers of this blog have seen the Amazon Kindle Fire commercials, featuring the get-help-now Mayday button and Amy, the annoyingly perky call center agent:

Those in the industry know that Mayday’s voice and video capability use WebRTC, as detailed by Chad and confirmed by Google WebRTC development lead Justin Uberti.   When combined with screen sharing, annotation and co-browsing, this makes for a compelling package. Executives in charge of call centers have taken notice, and are looking to their technology suppliers to spice up their call centers in the same way.

Indeed, the contact center is a very instructive example of how WebRTC can be used to enhance a well-established, existing system.  For those who doubt that the technology isn’t mature enough for widespread deployment, I’ll let you into a dirty little secret: WebRTC on the consumer side of the call center isn’t happening in web browsers, it’s happening in mobile apps.  I’ll say more about this later.

What a Contact Center looks like

Before we examine how we can turbocharge a contact center with WebRTC, let’s take a look at the main component parts, and some of the pain points that both customers and call center staff encounter in their daily lives.

(Disclaimer:  This sketch is a simplified caricature of a call center, drawn from the author’s experience with a number of different systems.   The same is true for the descriptions of WebRTC gateways in the following sections, which should be viewed as idealized and not a description of any one vendor’s offerings.)

Generic Contact Center Architecture

The web-to-call correlation problem

Let’s imagine that we’re a consumer, calling our auto insurance company.  Perhaps we’ve been to their website, or maybe we’re using their shiny new mobile app on our smartphone.  Either way, we’ve logged into the insurer’s web portal, to get an update on an insurance claim, update our coverage, or whatever.  (And yes, even if we’re using a mobile app, we’re most likely still communicating with a web server.  It’s only the presentation layer that’s different.)

Now suppose that we actually want to talk to a human being who can help us.  If we’re lucky, the web site will provide a phone number in an easy-to-find place, or maybe our mobile app will automatically bring up the phone’s dialer to make the call.  However, at this point, all of our contextual information, such as our identity and the web page we were on, gets lost.

The main problem here is that it is not easy to correlate the web session with the phone call.  The PSTN provides no way of attaching a context identifier from a web session to a phone call, leaving the caller ID or dialed number as the only clues in the call signaling.   That leaves us with the following possibilities:

• Use the caller ID.  This is ambiguous at best, in that a phone number doesn’t definitively identify a person, and mobile device APIs in any case forbid apps from harvesting a device’s phone number, so it can’t be readily passed into the contact center by the app.
• Use the called number.  Some contact centers use the concept of the steering pool, where a phone number from a pool is used to temporarily identify a particular session, which could potentially be used by a mobile app.  However, the redial list is the enemy of this idea; since the number is temporarily allocated to a session, you wouldn’t want a customer mistakenly thinking they could use the same number to call back later.
• Have the contact center call the customer back when it’s their turn, and an agent is about to become available.  This is in fact a viable approach, but complex to implement, largely for reasons of not tying up an agent while an attempt is made to reach the customer and verify they still want the call.
• Use WebRTC for in-app, contextual communications.

Customer-side interaction

But let’s continue with the premise that the customer has made a regular phone call to the contact center.  From the diagram above, we can see that the first entity the call hits is the ingress gateway (if via TDM) or Session Border Controller (if via a SIP trunk).  This will most likely route the call directly to an Interactive Voice Response (IVR) system, to give the caller an opportunity to perform self-service actions, such as looking up their account balance.  Depending on the vendor, the ingress gateway or SBC may itself take part in the interaction, by hosting a VoiceXML browser, as is the case with Cisco products; or else the IVR may be an application running on a SIP-connected media server platform.

Whatever the specific IVR architecture, it will certainly connect to the same customer database used by the web portal, but using DTMF to input an account number and PIN, rather than a username and password.  If the customer is lucky, they have managed to find an account statement that tells them what their account number is; if not, the conversation with agent is going to start by having them spell their name, give the last four digits of their Tax ID, and so on.  Not only that, but if a PIN is used, it is doubtless the same one used for their bank card, garage door opener and everything else, which hardly promotes security.  This whole process is time-consuming for both customer and agent, error-prone, and generally frustrating.

At this point the IVR has determined who the caller is, and why they are calling – “Press 1 for auto claims, 2 for household claims…”; the call now needs to be held in a queue, awaiting a suitably qualified agent.  The job of managing the pool of agents with their various skills, and the queues of incoming calls, is the job of the Automated Call Distributor (ACD).  An ACD typically has a well-defined but proprietary interface or protocol by which it interacts with an IVR.  The IVR will submit various data items to the ACD, notably the caller ID, called number, customer identity and required skill group.  The ACD may then itself interrogate the customer database, perhaps to determine whether this is a customer who gets priority service, or whether they have a delinquent account and need to be handled specially, and so on, so that the call can be added to the appropriate queue.  The ACD may also be able to provide the IVR with the estimated wait time for an agent, for feedback to the caller.

Agent-side interaction

Let’s turn for a moment to the agent’s side of the contact center.  An agent will invariably have a phone (whether a physical device or a soft client), an interface to the ACD (possibly a custom “thick client”, but increasingly a web-based one in modern contact centers) and a view into the customer database.  For business-to-business contact centers, the agent may also be connected to a CRM system: Salesforce.com, Siebel, Oracle CRM, Microsoft Dynamics, and so on.

For the purposes of our discussion, the agent’s phone is connected to a PBX, the PBX will provide call status information to the ACD using a standard telephony interface such as JTAPI, and the ACD will in turn use the same interface to direct incoming calls to agents.  This would typically be the case where an organization has a Cisco or Avaya PBX, for example, and the use of standard JTAPI allows for the deployment of a multi-vendor call center.  Other vendors, notably Genesys, have taken the approach of building their call center software using a SIP proxy as a key component, and the agents register their phones directly with the ACD rather than with a PBX.

The agent will log into the ACD at the beginning of their shift, signaling that they are available.  Call handling is then directed by the ACD, and when a call is passed to an agent, the ACD pushes down the customer ID to the agent’s desktop, which is then used to automatically do a “screen pop” of the customer’s account details from the customer database or CRM system.

Call handling in a contact center is thus a complex orchestration between an IVR, ACD, PBX and various pieces of enterprise software, usually requiring the writing of custom scripts and plugins to make everything work together  Not only this, but contact centers also make use of analytics software, call recording systems, and so on.

The caller experience

Let’s return to our caller, parked on the IVR and being played insipid on-hold music.  When the call eventually reaches the head of the queue, the ACD will instruct the IVR to transfer the call to a specific agent.  The agent gets the screen pop, asks the caller to verify their identity, and then begins the process of asking why they called.

To summarize, the contact center experience typically involves:

• Loss of contextual information from an existing web or mobile app session.
• Navigating IVR Hell.
• Waiting on hold.
• Re-establishing identity and context.
• A voice-only experience with a faceless representative, and lack of collaboration tools.

It’s no wonder this is judged a poor experience, for customers and contact center agents alike.

Adding WebRTC to the Contact Center

WebRTC is part of what is called in the contact center business, the “omnichannel experience”, in which multiple modalities of communication between a customer and the contact center all work together seamlessly.  An interaction may start on social media, be escalated to chat, from there to voice and video, and possibly be accompanied by screen sharing and co-browsing.  But how is this accomplished?

Contact Center with WebRTC Gateways and Co-browse Server

The key thing to hold in mind is that voice and video are integrated into the contact center app, and that context is at all times preserved.  As a customer, you have already established your identity with the contact center’s web portal; there’s no need to have the PSTN strip that away when you want to talk to a human being.  And when you do get put through to an agent, why shouldn’t they be able to view the same web page that you do?  (Subject to permission, of course.)

To do this, we need the following components (shown colored purple in the above diagram):

• A back-end to the web portal that is capable of acting as a pseudo-IVR.  As far as the ACD is concerned, it’s getting a regular incoming call, which has to be queued and transferred to an agent as usual.  The fact that this is a WebRTC call and not from the PSTN is totally transparent to the ACD.
• A co-browsing server – this acts as a rendezvous point between the customer and the agent for a particular co-browsing session, where changes to the customer’s web page are published over a secure WebSockets (WSS) connection, and the agent subscribes to those changes.  The actual details of how this works are proprietary and vary between vendors; however, the DOM Mutation Observer API is generally at the heart of the toolkit used.  When the agent wishes to navigate on behalf of the customer, mouse-click  events are sent back over the WSS connection from the agent and injected into the customer’s web page using a JavaScript or jQuery simulated mouse click event.  Annotation works similarly, with a mousedown event being passed over the WSS connection and used to paint on an HTML canvas element overlaying the customer’s web page.
• A WebRTC-to-SIP signaling gateway (as webrtcHacks has covered here).
• A media gateway, which transforms the SRTP used by WebRTC to the unencrypted RTP used by most enterprise telephony systems, and vice-versa.  This element may also carry out H.264 to VP8 video transcoding and audio codec transcoding if required.

The signaling and media gateways are common components for vendors selling WebRTC add-ons for legacy SIP-based systems, and are functionally equivalent in the network to a Session Border Controller.  Indeed, several such products are based on SBCs, or a combination of an SBC for the media and a SIP application server for the signaling gateway.  On the other hand, the pseudo-IVR and co-browse servers are rather more specialized elements, designed for contact center applications.

The work of this array of network elements is coordinated by the web portal, using their APIs and supporting SDKs.  The sequence diagrams in the next section show how the web portal and the ACD between them orchestrate a WebRTC call from its creation to being handed off as a SIP call to an agent, and how it is correlated with a co-browsing session.

Finally, it should be noted that a reverse HTTP proxy is generally required to protect the web servers in this arrangement, which reside within the inner firewall.  The media gateway would normally be placed within the DMZ.  The use of multiplexing to allow the media streams of multiple calls to use a single RTP port is a particularly noteworthy feature of WebRTC, which is deserving of appreciation by those whose job it is to manage firewalls.

Call Flows

In the diagrams that follow, purple lines indicate web-based interactions, often based on REST APIs. Some interactions may use WebSockets because of their asynchronous, bidirectional nature, which is particularly useful for call signaling and event handling.

Preparing for a call

Let us start at the point where the customer has already been authenticated by the web portal, and has been perusing their account details. Seeing the big friendly ‘Get Help’ button on their mobile app (remember, this is a mobile-first deployment), they decide they want to talk to a human. Inevitably, an agent is never just sitting around waiting for the call, so there is work to be done to make this happen.

WebRTC Contact Center Call Flow, Part 1

The first step in preparing for the call is for the web portal code to allocate a SIP identity for the caller, in other words, the ‘From’ URI or the caller id. This could be any arbitrary string or number, but it should be unique, since we’re also going to use it to identify the co-browse session. Next, the portal requests the WebRTC signaling gateway to authorize a session for this particular URI, because, well, you don’t want people hacking into your PBX and committing toll fraud using WebRTC. The signaling gateway obliges, and passes back to the web portal a one-time authorization token. Armed with the token, the portal instructs the client app (or browser) to prepare for the WebRTC call. It provides the token, the From URI, the location of a STUN server and information on how to contact the signaling gateway.

While the client is being readied, the portal makes a web services call to the ACD to see when an agent is expected to become available, given the customer’s identity and the nature of their inquiry. (The nature of the inquiry will be determined by what page of the website or app they were on when they pressed the ‘Get Help’ button.) Assuming an agent is not available at that very moment, the portal passes back the estimated wait time to be displayed by the client.

But what about the insipid on-hold music I mentioned earlier? Don’t we need to transfer the customer to a media server to play this? Well, no, we don’t. This is the Web we’re talking about, and we can readily tell the client to play a video from YouTube, or wherever, while they are waiting.

Next, the web portal submits the not-yet-created call to the ACD for queuing, via the pseudo-IVR component. Key pieces of information submitted are the From URI, the customer ID and the queue corresponding to the reason for the call. When the call reaches the head of the queue, the ACD instructs the call to be transferred to the selected agent.

(Side-note: Pseudo-IVR adapters for contact centers are used for a variety of purposes. They may be used to dispatch social media “tweets”, inbound customer service emails and web-chat sessions, as well as WebRTC calls.)

For modern deployments, agent desktop software may be constructed from a web-based framework, which allows third-party plugin components to pull information from the customer database, to connect to a CRM system, and in our case, to connect to the co-browse server. The screen pop to the agent uses the customer URI to connect to the correct session on the co-browse server.

Making the call

Now that the customer and agent are both ready, the web portal instructs the WebRTC client to call the agent’s URI. The actual details of how this is done depend on the vendor-specific WebRTC signaling protocol supported by the gateway; however, on the SIP side of the gateway they are turned into the standard INVITE, with the SDP payload reflecting the media gateway’s IP address and RTP ports.

WebRTC Contact Center Call Flow, Part 2

The fact that this is a video call is transparent to the ACD. The pool of agents with video capability can be put in their own skill group for the purposes of allocating them to customers using WebRTC.  The agents could be using video on suitably equipped phone handsets, or they could themselves be using WebRTC clients.  Indeed, some contact center vendors with whom I have spoken point to the advantages of delivering the entire agent experience within a browser: delivering updates to a SIP soft client or thick-client agent desktop software then becomes a thing of the past.

After the video session has been established, the customer may assent to the sharing of their mobile app screen or web-browsing session.  The co-browse server acts as the rendezvous point, with the customer’s unique URI acting as the session identifier.

Concluding thoughts: It’s all about mobile, stupid!

The fact that WebRTC is not ubiquitous, that it is not currently supported in major browsers such as Safari and Internet Explorer, might be thought an insurmountable barrier to deploying it in a contact center.  But this is not the case.  The very same infrastructure that works for web browsers also works for mobile apps, which in many cases are simply mobile UI elements placed on top of a web application, making the same HTTP calls on a web server.

All that is required is a WebRTC-based SDK that works in Android or iOS.  Happily for us, Google has made its WebRTC code readily available through the Chromium project.  Several vendors have made that code the basis of their mobile SDKs, wrapping them with Java and Objective-C language bindings equivalent to the JavaScript APIs found in browsers.

For contact center executives, a mobile-first approach offers the following advantages:

• You don’t want your customers messing around trying to install WebRTC browser plugins for Safari and IE.  If they’re going to download anything, it may as well be your mobile app.
• Mobile devices are near-ubiquitous.  Both Pew and Nielsen report their popularity amongst older demographics in particular, where regular PCs might not be used.
• Microphones and cameras on mobile devices are near-universal and of excellent quality, and echo cancellation works well.  That old PC with a flaky webcam?  Perhaps not so much.
• If your customer is having a real-world problem, then the back-facing camera on a phone or tablet is a great way of showing it.  The auto insurance industry comes readily to mind.
• Although the Great Video Codec Compromise now promises H.264 support in browsers, mobile SDKs have been able to take advantage of those devices’ hardware support for H.264 video encoding for some time.  When your contact center agents have sleek enterprise-class, video-capable phones that don’t support VP8, you don’t want to have to buy a pile of servers simply to do video transcoding.

In the call center industry, Amazon and American Express have shown the way in supporting video in their tablet apps, and both these services use WebRTC under the hood.  Speaking at the 2014 Cisco Live! event in San Francisco, Amex executive Todd Walthall related how users of the Amex iPad app who used the video feature had greater levels of customer satisfaction, through a more personal experience.  This should not surprise us, as it’s much easier to empathize with a customer service representative if they’re not just a disembodied voice.

For companies deploying WebRTC, it’s an incremental approach that doesn’t require significant architectural change or the replacement of existing systems. Early adopters are seeing shorter calls, as context is preserved and co-browsing allows problems to be resolved more quickly. One day we will look back at IVR Hell, waiting on endless hold with only a lo-fi rendition of Mantovani for company, trying in vain to find our account number and PIN, as if it were a childhood nightmare.

{“author”: “Robert Welbourn“}

Want to keep up on our latest posts? Please click here to subscribe to our mailing list if you have not already. We only email post updates. You can also follow us on twitter at @webrtcHacks for blog updates and news of technical WebRTC topics or our individual feeds @chadwallacehart, @reidstidolph, @victorpascual and @tsahil.

The post Avoiding Contact Center IVR Hell with WebRTC appeared first on webrtcHacks.

Next European edition of Kamailio Advanced Training will take place in Berlin, Germany, during March 23-25, 2015.The content will be based on latest stable series of Kamailio 4.2.x, released in October 2014. This version brought a large set of new features.The class in Berlin is organized by Asipto  and will be taught by Daniel-Constantin Mierla, co-founder and core developer of Kamailio SIP Server project.Read more details about the class and registration process at:

• http://www.asipto.com/index.php/kamailio-advanced-training/

HUAWEI MU609 Mini-PCIe card is available at aliexpress.com for about $40. Comparing to DW5550 card, MU609 is more expensive, but it”s a current hardware, actively supported by the manufacturer.

MU609 supports the traditional PPP interface, as well as CDC Ethernet interface for Linux.

It also has a built-in support for mobile voice calls, but its audio is only available on the physical PCM GPIO interface, which is wired to pins 45, 47, 49, and 51 on the Mini-PCIe plug. These pins are not standardized and marked as “reserved” in Mini-PCIe specification. The PC Engines APU board does not connect these pins to anything.

The card initializes 5 serial-USB devices (ttyUSB0 – ttyUSB4). ttyUSB0 can be used for modem control with AT commands. Detailed documentation for the rest of devices is available at Huawei website. The CDC Ethernet card is initialized as eth3 (because eth0-eth2 are onboard Ethernet adapters).

Setting up the card for automatic startup under Debian:

apt-get install -y picocom ppp cat >/etc/chatscripts/sunrise.MU609 <<'EOT' ABORT BUSY ABORT 'NO CARRIER' ABORT ERROR TIMEOUT 10 '' ATZ OK 'AT+CFUN=1' OK 'AT+CMEE=1' OK 'AT\^NDISDUP=1,1,"internet"' OK EOT cat >/etc/chatscripts/gsm_off.MU609 <<'EOT' ABORT ERROR TIMEOUT 5 '' AT+CFUN=0 OK EOT vi /etc/network/interfaces allow-hotplug eth3 iface eth3 inet dhcp     pre-up /usr/sbin/chat -v -f /etc/chatscripts/sunrise.MU609 >/dev/ttyUSB0 </dev/ttyUSB0     post-down /usr/sbin/chat -v -f /etc/chatscripts/gsm_off.MU609 >/dev/ttyUSB0 </dev/ttyUSB0
Filed under: Networking Tagged: 3G, GSM, linux, pcengines, UMTS

Call Center World 2015 takes place in Berlin, Germany, during February 24-26. I will meet some customers and visit the show for one day. If anyone wants to meet at the event or for some drinks in the evening at a nice place in Berlin, contact me.

Kamailio has a lot of features that can be useful in such deployments, including a module for music on hold queuing. Features such as load balancing or least cost routing can help scaling as well as saving costs on outbound calls.

Be sure you register for Kamailio World Conference, during May 27-29, 2015 - it is the place to meet the people behind the project and learn how to get the best out of Kamailio.

The registration for the 3rd edition of Kamailio World Conference & Exhibition is now open – more details and the registration form are available on the website of the event [1].The event spans over three days, May 27-29, 2015, taking place in Berlin, Germany. The first day contains the technical tutorials, the following two days are for conference presentations and exhibition.Details for a relevant group of speakers are already published [2], several talk proposals being still under review process. The first version of the agenda will be published in the near future.Looking forward to meeting many of you in Berlin![1] – http://conference.kamailio.com/k03/registration/
[2] – http://conference.kamailio.com/k03/speakers/

Here I wrote a simple call generator for FreeSWITCH, and it can be used for performance tests:

https://github.com/voxserv/freeswitch-perf-dialer

Filed under: Networking Tagged: freeswitch, pbx, sip, voip

Join 2600Hz Distributed Systems Engineer James Aimonetti as he leads our next Kazoo Training at Erlang Factory. The three-day training will take place March 30-April 1 and Early-Bird Pricing is still available! Register Here

In addition to Sierra Wireless MC8775 3G modem, there’s now a new offering for Dell DW5550 (or Ericsson F5521gw, which is the same hardware) mini-PCIe 3G cards at Aliexpress.com, in the price range of $20. This is a newer hardware (the ones I received were manufactured in mid-2012), and it supports higher UMTS speeds and an CDC Ethernet interface in Linux.

This page refers to Ericsson F3507g card, but all instructions are relevant for DW5550. The device identifies itself as Dell DW5550, firmware version R3B01 (Command for retrieving the version: AT+CGMR).

Default Linux kernel 3.2.0 in Debian Wheezy names the CDC Ethernet interface as usb0, and 3.16.0 from Wheezy backports names it as wwan0. Other than that, everything else works the same.

Out of 3 ordered cards, two worked immediately, and one was broken. The seller has kindly offered a replacement for additional $10.

for n in `ls /sys/class/*/*{ACM,wdm,usb0}*/device/interface`;do echo $(echo $n|awk -F '/' '{print $5}') : $(cat $n);done usb0 : Dell Wireless 5550 HSPA+ Mobile Broadband Mini-Card Network Adapter ttyACM0 : Dell Wireless 5550 HSPA+ Mobile Broadband Mini-Card Modem ttyACM1 : Dell Wireless 5550 HSPA+ Mobile Broadband Mini-Card Data Modem ttyACM2 : Dell Wireless 5550 HSPA+ Mobile Broadband Mini-Card GPS Port cdc-wdm0 : Dell Wireless 5550 HSPA+ Mobile Broadband Mini-Card Device Management cdc-wdm1 : Dell Wireless 5550 HSPA+ Mobile Broadband Mini-Card USIM Port

The following commands initiate a 3G connection for a sunrise.ch SIM card:

apt-get install -y picocom ppp picocom -b 115200 /dev/ttyACM1 AT+CFUN=1 AT+CGDCONT=1,"IP","internet" AT*ENAP=1,1 Ctrl-a Ctrl-x dhclient usb0

This Debian wiki page explains how to bring up the connection automatically at Linux startup:

cat >/etc/chatscripts/sunrise.DW5550 <<'EOT' ABORT BUSY ABORT 'NO CARRIER' ABORT ERROR TIMEOUT 10 '' AT+CFUN=1 OK \dAT+CGDCONT=1,"IP","internet" OK \d\d\dAT*ENAP=1,1 OK EOT cat >/etc/chatscripts/gsm_off.DW5550 <<'EOT' ABORT ERROR TIMEOUT 5 '' AT+CFUN=4 OK EOT vi /etc/network/interfaces allow-hotplug usb0 iface usb0 inet dhcp     pre-up /usr/sbin/chat -v -f /etc/chatscripts/sunrise.DW5550 >/dev/ttyACM0 </dev/ttyACM0     post-down /usr/sbin/chat -v -f /etc/chatscripts/gsm_off.DW5550 >/dev/ttyACM0 </dev/ttyACM0
Filed under: Networking Tagged: 3G, GSM, linux, pcengines, UMTS

I needed to connect a GSM gateway to my FreeSWITCH PBX, in order to receive SMS and mobile calls and emulate a normal mobile phone. I’ve got the Yeastar Neogate TG200 V2 for this purpose (Firmware Version: 53.18.0.39, running Asterisk 1.6.2.6 on an ARM processor).

This blog entry has helped a lot and saved a bunch of time.

The box supports OpenVPN, so you can place it in some remote location behind NAT, and manage it via the VPN connection. The client version is rather old (2.0.5), so it does not support embedded certificates in the client config, and also “topology subnet” option is not supported. You need to pack your vpn.conf and the certificates and pivate key into a TAR archive and upload to Neogate via its web interface.

It’s sufficient to configure one SIP trunk to your PBX, and manipulate the To: header in order to distinguish between SIM cards on incoming calls.

When the SIP trunk was configured (FreeSWITCH as a registrar), I started receiving the following warnings on FreeSWITCH, and the registration status was quickly removed after neogate’s REGISTER message:

2014-12-22 12:29:42.208567 [WARNING] sofia.c:5721 Sip user 'gsm01@xxxxx.net' is now Unreachable 2014-12-22 12:29:42.208567 [WARNING] sofia.c:5732 Expire sip user 'gsm01@xxxxx.net' due to options failure

My FreeSWITCH was sending SIP OPTIONS requests to all registered users and removed the registrations unless the clients responded with status 200 or 468. Neogate responds with 404 Not Found on such requests toward the trunk SIP user. I had to disable “unregister-on-options-fail” option in FreeSWITCH internal SIP profile.

In SIP trunk configuration, “Advanced->Caller ID” was automatically set to my trunk’s registration user name. Because of this, all incoming calls had this name as the caller ID, and the original caller number was lost. After setting this field to blank, the problem was resolved.

In “Mobile to IP” rules, you can set a different rule for each SIM card. The “Hotline” field should not be blank, and should contain some distinguishing number. It will be used in To field in the SIP INVITE on incoming calls. If you leave “Hotline” empty, the Neogate will respond with dial tone and collect DTMF digits before placing the call to your SIP trunk. So far I could not find any documentation that describes this.

Also in trunk configuration, sometimes I had to reboot the box in order for my changes to take effect.

The box uses the standard Asterisk management interface for sending and receiving SMS, and I’m planning to use this Perl module through the VPN connection.

Filed under: Networking Tagged: freeswitch, GSM, pbx, voip