A common experience when a customer contacts a large company is that the initial call gets fielded by a contact center agent who asks for various information (such as your name, account number and a contact phone number). Perhaps a few minutes into the call, the agent says that they can’t help you, but they’ll transfer you to somebody who can. At this point, your call is transferred and often you will need to repeat the information you’ve already provided. This process could even happen multiple times before you are finally talking with the correct person who can help you. The situation is often compounded when each agent also asked for various types of security information to verify that you are the person you say you are. It’s a major inconvenience when you need to provide your identification and security information several times in order to get service. By now, you’re thinking: there must be a better way. And you’re right. What if your information could be collected once on an inbound phone call and then be available to the people you talk with during each stage of a call? Surely, that would be a better approach.
User to User Information (UUI) is a concept that was established in circuit-switched networks such as ISDN and SS7 for exactly this purpose. In ISDN, the UUI information element can be used to capture alphanumeric information on a call and then that data can be stored for future use. In a contact center, this means that UUI could be used to capture your customer number, phone number, or other identifying information, and then this information could be passed along if a call is transferred. One interesting aspect of the UUI is that it is opaque, meaning that the characters captured are determined by the designer of the application, so that numerous different use cases can all be supported by a single UUI data field.
Okay, so UUI can be captured for an ISDN call. What if the contact center uses Voice over IP? What then? Until recently, there was no standard way to transport UUI information within the Session Initiation Protocol (SIP) that is commonly used in today’s contact centers. The problem was identified several years ago. The Internet Engineering Task Force (IETF) reviewed the request and kicked off the work by approving a new CUSS working group. The CUSS working group identified requirements as a first step and then began work on a general mechanism for capturing UUI information within a new SIP header. Work was also initiated on a “package” for the fairly common use case of transporting UUI data from ISDN to SIP.
In the meantime, several vendors, including my own company, Dialogic, wrote prototype code and tested the use of UUI in a variety of different call scenarios. There was no standard, but early drafts written by Alan Johnston circulated among the interested community of potential users.
Let’s fast forward a few years. By 2014, there were several working implementations of UUI in the equipment and software vendor community and many customers were already getting the benefit of better service by having their information captured once and then transported along with the call. Let’s consider an example.
Suppose a customer makes a call which comes in on an ISDN or SS7 line. When the call is answered by an agent, they can ask the caller for certain information such as an account number or their phone number. This information can be stored within a User to User information element within the calling protocol. If the call is then to be re-directed to another agent via the SIP protocol, the stored UUI information within the gateway can be transported into the SIP UUI header on the outbound leg of the call. When the call is answered by the second party, the UUI information can be provided to the called person and the identity information – such as name, phone number or customer ID – does not have to be requested a second time, except perhaps for verification or security purposes. That’s a simple example, but if the call got transferred again – as often happens – the UUI information has already been collected and the same SIP header can be passed along for more complex SIP operations such as a SIP REFER.
At Dialogic, we implemented UUI in a pre-standard form, based on requests from our customers, within products such as the IMG 1010 and IMG 2020 gateways. We also participated in the standards activity as it spun up in the IETF and modified our implementations as the standards evolved. UUI has been a very popular feature and is widely used by our customers in the contact center market.
Earlier this year, the last two standards were completed and the CUSS working group closed. The resulting documents are RFC 6567 (Requirements), RFC 7433 (UUI Mechanism) and RFC 7434 (ISDN to SIP Package). I was pleased to participate in the work as a member of the working group and as a co-author of RFC 7433. The UUI concept had been used on ISDN / SS7 networks, but there were a number of adjustments that took place as the draft documents evolved in order to reflect the experience of the implementers across the globe.
So the next time you’re interacting with a contact center, whether it is based on traditional TDM networks or has moved over to SIP, there are now standard ways to capture user information in a “sticky” way, so that it can move along as you get transferred between agents. If your company is running a contact center, adoption of UUI is a way to be more customer-friendly and enable your agents to focus more on the business at hand and spend less time collecting basic identity information. Leading contact center solution providers already make extensive use of UUI and the standardization of SIP UUI approaches make it much more likely that their partners will also have UUI as part of their solutions.