News from Industry

The VoIP Users Conference is celebrating 8 years on the air. The weekly online meetup is going to have its 535th session during a 24 hours voipathon, starting at 12:00pm PDT (20:00 London time) on Thursday, the 2nd of April, 2015. You can find more details about the session, including the options to join via audio, video or irc, at:

• http://www.voipusersconference.org/2015/voipathon-2/

Big credits to Randy Resnick, who started VUC, kept it going every week for the past years and he is still steering its future. Kamailio developers and users are glad to have been part of many sessions, presenting about latest news related to the project or joining sessions to debate hot topics of the real time communications world at the moment.Prepare yourself to pop up online and join the VUC voipathon even for a bit, say hi and tell shortly what is new in your world of communications!Randy and many VUC friends will be at Kamailio World Conference 2015, May 27-29, in Berlin, Germany, with VUC Visions session – be sure don’t miss the event where you can meet the people that had a relevant impact in transformation of the real time communications over the past years and work on defining their future!

Unnatural shrinkage. Photo courtesy Flikr user Ed Schipul

 

One evening last week, I was nerd-sniped by a question Max Ogden asked:

That is quite an interesting question. I somewhat dislike using Session Description Protocol (SDP)  in the signaling protocol anyway and prefer nice JSON objects for the API and ugly XML blobs on the wire to the ugly SDP blobs used by the WebRTC API.

The question is really about the minimum amount of information that needs to be exchanged for a WebRTC connection to succeed.

 WebRTC uses ICE and DTLS to establish a secure connection between peers. This mandates two constraints:

1. Both sides of the connection need to send stuff to each other
2. You need at minimum to exchange ice-ufrag, ice-pwd, DTLS fingerprints and candidate information

Now the stock SDP that WebRTC uses (explained here) is a rather big blob of text, more than 1500 characters for an audio-video offer not even considering the ICE candidates yet.

Do we really need all this?  It turns out that you can establish a P2P connection with just a little more than 100 characters sent in each direction. The minimal-webrtc repository shows you how to do that. I had to use quite a number of tricks to make this work, it’s a real hack.

How I did it Get some SDP

First, we want to establish a datachannel connection. Once we have this, we can potentially use it negotiate a second audio/video peerconnection without being constrained in the size of the offer or the answer. Also, the SDP for the data channel is a lot smaller to start with since the is no codec negotiation. Here is how to get that SDP:

var pc = new webkitRTCPeerConnection(null); var dc = pc.createDataChannel('webrtchacks'); pc.createOffer( function (offer) { pc.setLocalDescription(offer); console.log(offer.sdp); }, function (err) { console.error(err); } );

The resulting SDP is slightly more than 400 bytes. Now we need also some candidates included, so we wait for the end-of-candidates event:

pc.onicecandidate = function (event) { if (!event.candidate) console.log(pc.localDescription.sdp); };

The result is even longer:

v=0 o=- 4596489990601351948 2 IN IP4 127.0.0.1 s=- t=0 0 a=msid-semantic: WMS m=application 47299 DTLS/SCTP 5000 c=IN IP4 192.168.20.129 a=candidate:1966762134 1 udp 2122260223 192.168.20.129 47299 typ host generation 0 a=candidate:211962667 1 udp 2122194687 10.0.3.1 40864 typ host generation 0 a=candidate:1002017894 1 tcp 1518280447 192.168.20.129 0 typ host tcptype active generation 0 a=candidate:1109506011 1 tcp 1518214911 10.0.3.1 0 typ host tcptype active generation 0 a=ice-ufrag:1/MvHwjAyVf27aLu a=ice-pwd:3dBU7cFOBl120v33cynDvN1E a=ice-options:google-ice a=fingerprint:sha-256 75:74:5A:A6:A4:E5:52:F4:A7:67:4C:01:C7:EE:91:3F:21:3D:A2:E3:53:7B:6F:30:86:F2:30:AA:65:FB:04:24 a=setup:actpass a=mid:data a=sctpmap:5000 webrtc-datachannel 1024

Only take what you need

We are only interested in a few bits of information here: 

1. the ice-ufrag: 1/MvHwjAyVf27aLu
2. the ice-pwd: 3dBU7cFOBl120v33cynDvN1E
3. the sha-256 DTLS fingerprint: 75:74:5A:A6:A4:E5:52:F4:A7:67:4C:01:C7:EE:91:3F:21:3D:A2:E3:53:7B:6F:30:86:F2:30:AA:65:FB:04:24
4. the ICE candidates

The ice-ufrag is 16 characters due to randomness security requirements from RFC 5245. While it is possible to reduce that, it’s probably not worth the effort. The same applies to the 24 characters of the ice-pwd. Both are random so there is not much to gain from compressing them even.

The DTLS fingerprint is a representation of the 256 bytes of the sha-256 hash. It’s length can easily be reduced from 95 characters to almost optimal (assuming we want to be binary-safe) 44 characters: 

var line = "a=fingerprint:sha-256 75:74:5A:A6:A4:E5:52:F4:A7:67:4C:01:C7:EE:91:3F:21:3D:A2:E3:53:7B:6F:30:86:F2:30:AA:65:FB:04:24"; var hex = line.substr(22).split(':').map(function (h) { return parseInt(h, 16); }); console.log(btoa(String.fromCharCode.apply(String, hex))); // yields dXRapqTlUvSnZ0wBx+6RPyE9ouNTe28whvIwqmX7BCQ=

So we have So we’re at 84 characters now. We can hardcode everything else in the application.

Dealing with candidates

Let’s look at the candidates. Wait, we got only host candidates. This is not going to work unless people are on the same network. STUN does not help much either since it only works in approximately 80% of all cases.

So we need candidates that were gathered from a TURN server. In Chrome, the easy way to achieve this is to set the iceTransports constraint to ‘relay’ which will not even gather host and srflx candidates. In Firefox, you need to ignore all non-relay candidates currently.

If you use the minimal-webrtc demo you need to use your own TURN credentials, the ones in the repository will no longer work since they’re using the time-based credential scheme. Here is what happened on my machine was that two candidates were gathered:

a=candidate:1211076970 1 udp 41885439 104.130.198.83 47751 typ relay raddr 0.0.0.0 rport 0 generation 0 a=candidate:1211076970 1 udp 41819903 104.130.198.83 38132 typ relay raddr 0.0.0.0 rport 0 generation 0

I believe this is a bug in chrome which gathers a relay candidate for an interface which is not routable, so I filed an issue.

Lets look at the first candidate using the grammar defined in RFC 5245: 

1. the foundation is 1211076970
2. the component is 1. Another reason for using the datachannel, there are no RTCP candidates
3. the transport is UDP
4. the priority is 41885439
5. the IP address is 104.130.198.83 (the ip of the TURN server I used)
6. the port is 47751
7. the typ is relay
8. the raddr and rport are set to 0.0.0.0 and 0 respectively in order to avoid information leaks when iceTransports is set to relay
9. the generation is 0. This is a Jingle extension of vanilla ICE that allows detecting ice restarts

If we were to simply append both candidates to the 84 bytes we already have we would end up with 290 bytes. But we don’t need most of the information in there.

The most interesting information is the IP and port. For IPv4, that is 32bits for the IP and 16 bits for the port. We can encode that using btoa again which yields 7 + 4 characters per candidate. Actually, if both candidates share the same IP, we can skip encoding it again, reducing the size.

After consulting RFC 5245 it turned out that the foundation and priority can actually be skipped, even though that requires some effort. And everything else can be easily hard-coded in the application. 

sdp.length = 106

Let’s summarize what we have so far: 

1. the ice-ufrag: 16 characters
2. the ice-pwd: 22 characters
3. the sha-256 DTLS fingerprint: 44 characters
4. the ip and port: 11 characters for the first candidate, 4 characters for subsequent candidates from the same ip.

Now we also want to encode whether this is an offer or an answer. Let’s use uppercase O and A respectively. Next, we concatenate this and separate the fields with a ‘,’ character. While that is less efficient than a binary encoding or one that relies on fixed field lengths, it is flexible. The result is a string like:

O,1/MvHwjAyVf27aLu,3dBU7cFOBl120v33cynDvN1E, dXRapqTlUvSnZ0wBx+6RPyE9ouNTe28whvIwqmX7BCQ=, 1k85hij,1ek7,157k

106 characters! So that is tweetable. Yay!

You better be fast

Now, if you try this it turns out it does not usually work unless you are fast enough pasting stuff.

ICE is short for Interactive Connectivity Establishment. If you are not fast enough in transferring the answer and starting ICE at the Offerer, it will fail. You have less than 30 seconds between creating the answer at the Answerer and setting it at the Offerer. That’s pretty tough for humans doing copy-paste. And it will not work via twitter.

What happens is that the Answerer is trying to perform connectivity checks as explained in RFC 5245. But those never reach the Offerer since we are using a TURN server. The TURN server does not allow traffic from the Answerer to be relayed to the Offerer before the Offerer creates a TURN permission for the candidate, which it can only do once the Offerer receives the answer. Even if we could ignore permissions, the Offerer can not form the STUN username without the Answerer’s ice-ufrag and ice-pwd. And if the Offerer does not reply to the connectivity checks by Answerer, the Answerer will conclude that ICE has failed.

 

So what was the point of this?

Now… it is pretty hard to come up with a use-case for this. It fits into an SMS. But sending your peer an URL where you both connect using a third-party signaling server is a lot more viable most of the time. Especially given that to achieve this, I had to make some tough design decisions like forcing a TURN server and taking some shortcuts with the ICE candidates which are not really safe. Also, this cannot use trickle ice.

¯\_(ツ)_/¯

(thanks, Max)

So is this just a case study in arcane signaling protocols? Probably. But hey, I can now use IRC as a signaling protocol for WebRTC. IRC has a limit of 512 characters so one can include more candidates and information even. CTCP WEBRTC anyone?

{“author”: “Philipp Hancke“}

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 The Minimum Viable SDP appeared first on webrtcHacks.

Back in 2009 I published the article on this blog about doing autotyping in Keepassx for Mac OS X using AppleScript and some other helper application, MoreInternet. That article is available at:

• http://by-miconda.blogspot.de/2009/07/keepassx-mac-os-x-and-auto-typing.html

It is still a popular reading on my blog, however MoreInternet is no longer available for recent releases of Mac OS X. But that's for a better option as now Mac OS X can auto-register URL handlers on first run of an application that advertises the capability.
Lately I am using mainly iTerm2 instead of the classic Terminal.app, therefore I spent a bit of time in upgrading the AppleScript to fit better with my current environment, Mac OS X 10.10 (Yosemite) and iTerm2 (as main option).
The AppleScript is available on GitHub, feel free to fork and make pull requests with enhancements:

• https://github.com/miconda/keepassx-autotyping-macosx

With the new version comes few alternatives of specifying the URL schema in order to make it nicer looking inside the Keepassx. The old format with 'kpx' is still available, allowing the variants:  kpx://proto?username:password@address:port/path
  kpx://proto?username:password:address:port/pathThe proto field can be ssh, http or https.
The new variants use kpx-proto for URL schema, getting rid of the strange url with 'proto?' inside it, resulting in something more closer to actual URLs. The new URL format is:kpx-proto://username:password@address:port/pathAgain, the proto can be ssh, http or https. For both formats, old and new, the port and path are optional. For ssh, the path must not be provided. Next are some examples:kpx-ssh://alice:secret@10.0.0.10 kpx-https://alice:secret@mywebsite.com/login
It is possible to use the KeePassX self expanding variables such as {USERNAME} or {PASSWORD}.
kpx-https://{USERNAME}:{PASSWORD}@mywebsite.com/login
Installation
Download the kpx.as file from GitHub repository.
Open Script Editor from Applications => Utilities, paste the content of kpx.as into it and export it as 'Application', save it as kpx.app somewhere on your disk.
With a text editor like 'vim', edit kpx.app/Contents/PkgInfo and set the content to "APPLokpx" (no double quotes). Edit kpx.app/Contents/Info.plist and set the bundle signature to the last 4 letters of the value in PkgInfo file and add details about 'kpx' URL handling, you should get to something like this:    <key>CFBundleSignature</key> <string>okpx</string> <key>CFBundleURLTypes</key> <array> <dict> <key>CFBundleURLName</key> <string>KeePassX</string> <key>CFBundleURLSchemes</key> <array> <string>kpx</string> <string>kpx-ssh</string> <string>kpx-http</string> <string>kpx-https</string> </array> </dict> </array>Note: CFBundleSignature should be there already, just update the string value. CFBundleURLTypes (and the array value) must be added.
Save the files you edited and the execute kpx.app from Finder. This operation is registering the kpx URL handlers. The execution is practically exiting immediately, but afterwards Keepassx will be able to launch it for its registered URL schemes.
Again, if you have an older version of Mac OS X, you may need to install More Internet application to register new URL handlers, for more details see the blog for older version of this script. Read that article if you didn't do it in the past, because it provides other useful hints for testing and using as well as screenshots.
Mentioned before that iTerm2 is preferred terminal, if you prefer the Terminal.all, edit the downloaded kpx.as and replace the line:set myTerm to "iTerm2"with:set myTerm to "Terminal"Then do the same steps as above for installation.
The terminal application is used for ssh handling. For http/https, the Safari browser is used.
An important note is to re-install and run the application every time you change something in the AppleScript file kpx.as, before attempting to use Keepassx with the modifications done in kpx.as.
Hopefully this article will be useful for some people out there!
No effective time to work on at this moment, but it in the future I am thinking to add the option to start mosh instead of ssh and work with other web browsers Chromium/Chrome, Firefox or Opera -- I haven't checked which browsers have support for AppleScript commands. Of course, these or other contributions are welcome!

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