Report on the Technical Feasibility of Implementing a Video Relay Service in Canada

Disclaimer:

This report was commissioned by the Canadian Radio-Television and Telecommunications Commission ("the Commission) in November 2012 and was completed by Groupe Consult-Com Techno. This report presents some of the technical considerations for video relay service (VRS) and covers topics such as call routing, technical standards, and offers an architectural overview of available VRS solutions.

While the authors have endeavored to ensure that the information is current and accurate at the time of writing, significant changes may be occurring or have occurred in some areas by the time of publication. This report reflects the research, views and recommendations of the authors, and should not be construed as representing any views of the Commission.

PDF version

Table of Contents

Preface

About the authors

Introduction

Situation overview

State of technologies

Canadian characteristics

Canada

Language characteristics

Existing technologies in Canada

Teletypewriter relay service

IP relay service

Telus

Bell

Access with a mobile device

Integration of text or IP relay services into the VRS

Standards and trends

Video relay platforms

Platform

IVèS solution

nWise solution

Sorenson solution

Communication protocols

Types of devices that may be used

Mobile devices

Functions

Interoperability

Management and billing

Confidentiality of communications

Call routing

Implementing a video relay service

Possible options

The IVèS solution

Applications and specifications

For users

For the platform

Challenges ahead

Call routing

Calling 911

Conclusion

Appendices

Appendix 1: Flow chart of video relay service

Appendix 2: Call routing

Appendix 3: Description of various communications protocols

Appendix 4: Glossary of Technical Terms

Appendix 5: References for Manufacturers Mentioned in the Report

Preface

Our mandate was to focus on the technical aspects of video relay service in Canada. In the course of our research, we were able to collaborate with passionate and very talented individuals.

Groupe Consult-Com Techno would like to thank the members of its team who helped complete this study: Louis Houbart and Claude Dolembreux.

We would also like to take this opportunity to thank everyone who contributed to this study: members of various associations for the Deaf, hard of hearing, and speech impaired, and the manufacturers who answered our questions throughout this study. I would also like to thank the organizations that preceded us for completing excellent work which provided us with important information.

This collaborative work helped guide us as objectively and accurately as possible, while respecting the technological spirit of our mandate.

Sincerely yours,

Louis Houbart

President

Groupe Consult-Com Techno Inc.

514-777-5973

Louis.houbart@consultcomtechno.com

About the authors

Louis Houbart

Louis Houbart is passionate about telecommunications. Both a field worker and a trainer, he has been working in the area of wireless communication for over 33 years. His ever-developing career has enabled him to work with many different technologies.

Throughout his career, he has developed expertise in radiocommunications, cellular networks, external and internal networks in buildings, satellite and Wi-Fi. With the increase in speeds of cellular networks in particular, he has developed new expertise in the field of fibre optics.

Louis has published many articles and is a dynamic speaker; he knows how to explain technology in layman's terms so that anyone can understand it. He has also developed several training sessions for both technical and administrative personnel.

He knows how to surround himself with specialists to complete his projects successfully. He is pleased with the research conducted and the meetings that took place throughout this mandate that were used to write this report.

Claude Dolembreux

Claude Dolembreux has been a telecommunications specialist for over 25 years. He has state-of-the-art expertise in telephone network architecture and multimedia communication. He has been a technical support officer for both telephone system marketing and Telehealth support and the director of business development for multinational companies in the telecommunications field.

He was involved in the implementation of multimedia communications technology within organizations such as Sureté du Québec, CSST, the Saint Lawrence Seaway, several health organizations in Quebec and other large-scale organizations.

For the last ten years, Claude Dolembreux's team has included several engineers specializing in the telecommunications field, with in-depth knowledge of equipment structure, interfaces and networks. Our knowledge helps our clients make informed decisions.

Introduction

A video relay service (VRS) enables persons who are deaf, hard of hearing or have speech disabilities and who use sign language to use a video system to communicate. If the person called also uses sign language, the communication takes place between these two people. If the person called does not use sign language, the communication goes through an operator (interpreter) who relays the conversation between the two people.

Several of these systems have been implemented around the world. VRS helps improve communication between people with hearing or speech disabilities who use sign language, or with people who do not have these disabilities. Canada does not have a permanent video relay service, but the CRTC is continuing to examine the feasibility of such a service.

Telus conducted a trial in British Columbia and Alberta. The purpose of the 18-month trial was to test one of the existing platforms, and also to understand how it works, its long-term requirements and the costs associated with implementing the service, as well as user needs.

Further, a comprehensive study was subsidized by Bell and conducted by
Mission Consulting, a California company. The study covered various topics discussed with a number of participants, including representatives of associations of people with hearing or speech disabilities, and participants from various other sources.

Currently, teletypewriter (TTY) and IP relay services are available. The two services work in a relatively similar manner: a person writes a message using equipment with a keyboard, an intermediary receives the message and reads it to a third party. The third party's response is received by the intermediary, who uses the keyboard to write the message to the person who initiated the call. The process is repeated throughout the communication.

This type of communication is slow and not very demonstrative, because non-verbal cues are not transmitted. Conversely, a video relay service would bring more fluidity and emotion to communications.

The purpose of this report is not to repeat the work that has been done in the past, but to review the technical and technological aspects of implementing and operating such a service in the best interest of its users, while taking into account existing services and the evolution of technology.

For the purposes of our study, we analyzed several technical documents. We communicated with people in the field and product manufacturers, and attended demonstrations of certain VRS solutions.

Companies are presented in alphabetical order, without preference.

Situation overview

State of technologies

For over a hundred years, until the mid-80s, telephone communications went through equipment located in or near homes and offices. Mobile telephone services existed, but few people had the equipment in their vehicles.

The 80s and 90s were rich in technological developments. Communication protocols enabled both wired and wireless networks to increase their speeds. Today, it is easy to reach anyone using a conventional telephone, an IP telephone, a computer or a wireless device.

On July 1, 1985, a major change took place: cellular networks were officially launched in Canada. Who could have predicted, at the time, that this development would bring us the cell phone? The original large devices were replaced by smaller devices with multi-service platforms.

According to the Canadian Wireless Telecommunications Association,¹ at the end of the second quarter of 2012, there were 26,146,347 subscribers to various Canadian wireless service providers.

The 2011 Census of Canada showed that there were 33,476,688 people living in Canada.² Looking at the number of cellular service subscribers to the number of total Canadians, the cellular service penetration rate is just over 78%.

As we can see, the cellular phone has developed considerably over the past 27 years. In the coming years, current service providers and potential new entrants into the market as a result of the frequency auctions to be held in spring 2013, will implement new, higher-performance technologies, and open the door to new possibilities.

Cellular technology is not the only technology to have evolved. Computers and other means of accessing the World Wide wed have also developed a great deal. While speeds were only a few thousand bits per second in the 90s, most Canadians today have access to a rate of 1.5 Mbps or higher, at home and at work.

Availability of increased speeds for fibre optic networks deployed across Canada is nothing new. From research groups, such as the CANARIE project for the advancement of research and education to large telecommunication network providers, redundant fibre optic networks crisscross Canada from coast to coast.

In 2009, "the government had pledged $225 million to Industry Canada over three years to develop and implement a strategy on extending broadband infrastructure in unserved Canadian communities."³

Figure 1: CANARIE optical network⁴

Figure 2: Telus fibre network⁵

Here are some statistics on residential speeds and penetration rates from 2010:⁶

• 52% of homes had access to a speed of 5 Mbps or higher;
• 70% of homes had access to a speed of 1.5 Mbps or higher; and
• 74% of homes had access to a high-speed broadband.

As shown in the table below, broadband service penetration has evolved a great deal between 2010 and 2011. The table shows broadband service by speed and by province.⁷

Table 1: Broadband availability by speed and province in 2010

• Excludes HSPA
• Availability or speed greater than 25 Mbps have been combined due to the confidentiality of the data

Source: CRTC data collection

For the trial conducted by Telus in Alberta and British Columbia, the company asked that users had access to a minimum speed of 1.5 Mbps.

As shown in the table above, a very large majority of homes have access to broadband services with a rate of 1.5 Mbps. However, availability of the service does not imply subscription to the service.

As shown in the table below, the combination of all technologies resulted in a 98% access rate in 2010. This combination is important, because an increasing number of people choose to have a cellular phone as their only means of communication. The selected system for video relay services must take into account this reality to provide access to as many people as possible.

Figure 3: Broadband availability (% of households) (2010)⁸

Canadian characteristics

Canada

Canada is immense, spanning over 9,984,670 square kilometres.⁹ Its population of over 33 million is located mainly in the south of its provinces, as shown on the map below.

Figure 4: Canada's population distribution¹⁰

While most residents live in the southern part of the country, there are population blocks scattered in northern areas.

The chosen solution must be able to reach all Canadians who wish to have access to video relay services. However, remote population blocks who receive communications by satellite may encounter difficulties in using the service, given that technical parameters would be significantly affected by the satellite connection.

Language characteristics

English and French are the official languages of Canada. There are approximately
25 million Canadians whose first language is English or another language. Just over
8 million Canadians have French as their first language. The Francophone population is mainly located in Quebec, but there are also over a million Francophones and Acadians living in the other nine provinces and three territories.¹¹

This linguistic duality brings out two important points:

• People who are deaf from birth or who lost their hearing at an early age have sign language as a first language.
• As such, a future project would have to take into account two types of sign language interpretation: one for English and one for French

If implemented, there will be a need for two types of sign language for Canadians: American Sign Language (ASL) for Anglophones and Quebec Sign Language (QSL) for Francophones.

These two types of sign language highlight two factors: the human factor and the technical factor. The human factor is having interpreters to answer people who require video relay services. The technical factor is being able to identify the sign language being used by the person requesting the service or the person being called, and who needs the services of an interpreter.

User parameters will have to be taken into account when the call is being routed to an operator. Wherever a call comes from, it will need to be routed to an interpreter who has the proper skills to ensure that the call goes smoothly. This validation will help minimize transfers between interpreters, or between service providers.

Our proximity to our southern neighbours is also an important factor that must not be ignored. From business to arts and communication, to name just a few, America's influence is clearly felt in Canada. This proximity may result in a person using QSL needing to talk to an Anglophone. This element should also be considered, particularly in terms of a corporate service.

Existing technologies in Canada

Teletypewriter relay service

Teletypewriter relay services¹² are available throughout Canada. A person without disabilities who wishes to contact a person who is deaf or hard of hearing and who is equipped with a teletypewriter via a fixed device may simply dial a toll-free number (1-800-855-0511). The caller identifies him or herself and gives the contact information of the person to whom he or she wishes to speak.

The hearing-impaired person equipped with a teletypewriter dials 711 to be directed to the relay service. If the call is made from a wireless device, the caller has only to dial #711. The service is available 7 days a week, 24 hours a day. Operators can work in both English and French.

A person equipped with a teletypewriter may make calls to another person equipped with a teletypewriter by dialling 1-800-855-1155.

It is possible to call 911 using a teletypewriter, but the service provider is only a relay between the caller and the emergency service.

Though the system has identical parameters for Bell and Telus, there are a few differences with regard to the IP relay service.

IP relay service

The IP relay service¹³ uses the functions of online chat applications. Subscribers must have a computer and a personal identification code.

The minimum specifications required by major providers are listed below:

• A computer with a Windows or Mac operating system
  • Windows XP, Vista, Windows 7
  • Mac OS X
• A broadband Internet connection with a download speed of at least 1 Mbps
• A web browser (Microsoft Internet Explorer 6 or 7, Apple Safari 4 or higher, Mozilla Firefox 3.5 or higher, Google Chrome or Opera); other browsers may also be compatible
• A web browser for a wireless device
  • Bolt for Blackberry devices and Skyfire for Windows devices

For both Bell and Telus, the deaf, mute or heard-of-hearing person must create a profile with his or her telephone service provider.

The person wishing to make a call accesses the service through a hyperlink and follows the instructions on the wed page to initiate the call.

Telus

A person without disabilities dials 1-877-584-4747 to be connected to the IP relay centre. The operator will communicate with the subscriber using a chat application.¹⁴

IP-to-IP calls are not available.

Bell

A person without disabilities dials 1-888-735-2921 to be connected to the IP relay centre. The operator will communicate with the subscriber using a chat application.¹⁵

The caller then gives a nine-digit personal code for the person they wish to call.

Access with a mobile device

When a call is made from a mobile device, certain features are required to take full advantage of the service:

• A full QWERTY keyboard
• A web browser that supports Javascript and AJAX

When the IP relay is used, the network speed is not as important as it would be for video relay. The device must simply be able to access the Internet and communicate with the operator who will make the connection.

Integration of text or IP relay services into the VRS

At first glance, this seems like a good idea. From a technical standpoint, with the technology available today, it would not be a problem. Current service access links would need to be redirected to the new platform. But what happens then? Calls would need to be directed to the person with the correct skills–that is the difference.

The skills required to make a connection for communications via text or sign language are not the same. There is also a distinction between some information exchanged in text form during a sign-language communication and a communication that takes place entirely in text form.

People responsible for text-based relay have good typing skills and can easily type 60 words per minute, but they do not need to know sign language. Conversely, interpreters assigned to video relay services need to master sign language, but do not need to have quick typing skills.

The integration of text or IP relay services into the video relay services platform may be technically possible. Organizations that provide video relay services would also need to hire people with text or IP relay skills. Calls would be routed based on skills, just as they would be with the VRS based on the sign language being used.

If someone with the required typing skills were not available, routing of calls to the VRS platform would only needlessly take up bandwidth. Calls should be taken off the platform and be redirected to someone who has the required text relay skills.

Standards and trends

Visual communication or videoconferencing was introduced to the market by Bell Labs at Expo 67 in Montreal. Already well established and with multiple uses, this technology has become widely used by medium and large companies the world over since the 80s. The reduced cost of telecommunications following the arrival of new players has contributed significantly to the development of this technology in recent years. Technological progress and the development of smart portable devices have made visual communication a common means of communicating.

The methods and techniques for establishing video communications are not yet fully defined, which is why there are several types of communication protocols. However, there are international standards to allow for interoperability among various systems so that people can communicate using different systems.

The uses of video communications are varied. They have a wide range, from person-to-person communication to public conferences, corporate teleconferences, continued or interactive training, telehealth, telemedicine and collaborative work.

The perpetual progress of technology has opened up fields of application broader than that of videoconferencing. The number of multimedia users is constantly increasing as the options the Internet provides increases. This has given rise to a debate on many types of proprietary protocols versus standardized protocols, as well as the continuous development of free software on IP networks.

The H323 protocol is the main protocol used by Sorenson in the United States. However, the SIP protocol, which is used by IVèS and nWise, is gradually becoming the standard, not only for this type of communication, but also for others, such as land and cellular telephony.

From a technological standpoint, Sorenson confirmed that it supports the SIP protocol for communications between its VRS service facilities, and for its facilities outside the United States.

Video relay platforms

Currently, there is no video contact centre system on the market per se. It is sometimes difficult to ascertain whether providers offer an end-to-end solution or whether they are simply integrators.

The number of providers in the video relay service field is fairly limited. This study focused mainly on three players: IVèS, nWise and Sorenson. They have developed gateways to link various external technologies to the core of their system.

Each of these gateways has its own specificities and differences. To better understand these elements, we created a comparative table of the main characteristics of each platform.

The column on the left shows the different categories in bold, as well as the subcategories. Each of these categories will be explained in the pages following the table.

The following table shows the three providers mentioned and the different parameters of their platforms.

Table 2: Comparison of provider parameters

Platform

The video relay service (VRS) platforms available on the market are those of telecommunications technology integrators and developers. Currently, conventional call centre system manufacturers do not support video communications.

Gartner has published their analysis which shows that the large-scale deployment of a video call centre system is not expected in the short-term¹⁶. A more short-term deployment of VRS would need to take into account the customization and connection of various applications that are already available, and develop certain applications for very specific requirements.

To better understand what is currently available for video relay, we have concentrated on a sample of three existing solutions which have been adapted to provide the functionality required to meet the specific needs studied in this report. They are presented here in alphabetical order.

IVèS solution

IVèS is a French company that designs, develops and hosts video remote interpretation (VRI) infrastructures and video relay service (VRS) infrastructures. It is a platform and software provider whose intention is to build a call centre for a video relay service.

The company targets a clientele with various disabilities, such as hearing, visual or speech impairments. Its VRS infrastructure provides a solution for total conversation. "Total conversation" is a term in the telecommunications field; it describes a call service that allows for the simultaneous real-time use of audio, video and text, or any combination of the three.

Interpreters are connected to the VRS client-service website via a computer equipped with a webcam and a microphone, through which they receive calls. This is the client's call centre. Callers can see and communicate with the interpreters in the call centre. Interpreters enable users to communicate with people without hearing or speech disabilities.

Users of the service can make calls from various electronic devices. A computer equipped with a webcam, a microphone and Internet access is the preferred tool. However, the service is available on a wide range of electronic devices, such as videophones, computers, or 3G/4G telephones. To allow for the use of a videophone, the user must select a device from a list of videophones approved by IVèS.

The IVèS solution is based on the Asterix open platform. Asterix was designed for video call distribution in SIP mode. It includes an audio, video and text call centre, as well as related functionalities based on developments by IVèS on the Asterix platform.

This product can be interconnected with other automatic call distribution (ACD) platforms, but as all ACD functions can be found on the IVès platform, there is no technological advantage to integrating it with another platform. IVèS has agreements with manufacturers of video equipment that is compatible with their system. They have developed several gateways to enable users to use the product of their choice.

Here are some typical screens from IVèS' solution.

Figure 5: User screen, ElisionPro interface (Source: IVèS)

Figure 6: Interpreter screen, ElisionPro interface (Source: IVèS)

nWise solution

nWise was launched in June 2008 in Sweden. It was founded by a group of managers and investors with extensive experience in the fields of telecommunications and human sciences. Shortly after the company was founded, nWise purchased the MMX platform from the Ericsson group. Several nWise founders worked with the MMX ACD platform since the system was first developed in the early 2000s.

The company has capabilities in the areas of video telephony, mobile text messaging, traditional telephony, contact centre solutions, SIP and IMS architectures (IP Multimedia Subsystem), Java language, and external gateways and platforms for the development of a total communication tool.

The company offers a platform adapted for a call centre offering VRS. The product is called MMX5, and includes a set of multimedia communication tools for video relay services. The product, developed for people with hearing, visual or speech disabilities, or a combination of the three, includes ACD and various conversion gateways for user access. It enables users to communicate in sign language and receive assistance from an interpreter.

The MMX software is designed to work with national telecommunications systems. It works with standard hardware such as Cisco, Radvision and Dialogic. It is completely based on IP technologies, and it was developed to support the SIP protocol.

A device for VRS operators (interpreters) called MMXpro was designed by nWise; it is based on a personal computer with hands-free operation, and is specifically set up for VRS services.

MMXpro is a tool that provides call management functions. With MMXpro, interpreters have access to various types of information about the call, including duration, call history, queues, notifications and access to services offered.

It is easy to set up a three-way call, and to transfer a video call to another interpreter as required.

MMXpro proposes specific functions for VRS service providers:

• Intelligent call distribution – periodic sequence distribution
• Access to call statistics
• Real-time operator supervision
• Remote operators

Figure 7 – VRS interpreter using the MMXpro application (Source: nWise)

Sorenson solution

Sorenson is a major player in the United States. The Sorenson VRS platform is not sold as a product, but rather as one component of their complete offering. As such, this provider could be considered an end-to-end provider because it includes devices, training, support and interpreters for its video relay services. Sorenson's approach is more restrictive, in that Sorenson recommends the use of its own communication devices, which have been adapted for people with hearing disabilities. For example, when the device receives a call, it has a flashing light to attract the person's attention, rather than ringing like a telephone, which a deaf or hard-of-hearing person would not hear. To use Sorenson's services, users have to adapt their means of communication to Sorenson's requirements by purchasing a Sorenson device or installing a plugin provided by Sorenson. Non-adapted communication equipment cannot communicate with the Sorenson platform.

Sorenson VRS is the provider with the largest VRS market share in the United States. It provides interpretation services through various interactive platforms. In addition, Sorenson uses its own operators in its own contact centre.

Users may employ Sorenson's video relay services to communicate with an operator through various types of devices:

• Computer (webcam + microphone)
• Mac (webcam + microphone)
• Mobile (3G)
• Sorenson videophone or ntouch VP

The Sorenson ntouch VP is a camera, codec, remote control and software that the user installs on a television set (not provided). The device offers a range of functions adapted to VRS.

For computers (PC, Mac) and mobiles, Sorenson has plugins or client software, respectively ntouch PC, ntouch for Mac, ntouch Tablet and ntouch mobile. Users install these plugins to be able to use Sorenson's services. A client account on the platform is required to be able to use the client software.

Sorenson also offers the Sorenson Videophone. It is composed of an interface connecting a camera, a microphone, an IP network and the user's television.

Figure 8: Sorenson videophone, television not included (Source: Sorenson)

Sorenson uses its own contact centre and its own operators. As such, Sorenson sells a video relay service, not a product to build a VRS like nWise and IVèS. However, the installation of this product is much simpler, because Sorenson takes care of setting up the contact centre and hiring the interpreters required for the project.

Communication protocols

For standard communications (H.320, H.323, H.324) or proprietary communications (FaceTime, Skype, etc.), each protocol must be converted to the SIP protocol. These conversions must be bidirectional: they must be able to be converted back from SIP to their original format. Signal quality drops slightly with each conversion.

H.320

This International Telecommunication Union (ITU) standard was set out for multimedia networks (audio/video/data) on narrowband and integrated services digital networks (ISDN). It sets out technical requirements for narrowband videotelephony systems, videoconferencing equipment and videotelephony services.

The service requirements for videotelephony services are set out in ITU-T F.720 Videotelephony services and F.702 for multimedia conference services. These standards describe narrowband services with speeds from 64 kbps to 1920 kbps.

The main protocols for this suite are H.221, H.230, and H.242. The standard for audio codecs is G.711; the protocols are H.261 and H.263.

H.323

Rather than one protocol, H.323 is actually a combination of various protocols that can be grouped into three categories: signalling, codec negotiation and information transport.

Signalling messages are sent as a request to be connected to another person; they indicate that the line is busy, that the phone is ringing, etc. They also include messages sent to signal that a certain telephone is connected to the network and can be reached. In H.323, signalling depends on the RAS (Registration Admission Status) protocol for recording and authentication, and the Q.931 protocol for initialization and call control.

Negotiation is used to come to an agreement on how to encode the information to be exchanged. It is important that the telephones (or systems) speak the same language in order to understand one another. It would also be preferable for them to have several alternatives for languages and to use the one that is best adapted; this may be the codec that uses the least bandwidth, or the one that provides the best quality. The protocol used for codec negotiation is H.245.

Information transport uses the RTP (Real-time Transport) protocol, which transports voices, video and digitized data via codecs. RTCP (Real-time Transfer Control Protocol) messages can also be used for quality control and to renegotiate codecs if, for example, the bandwidth is dropping.

nWise uses the Cisco Codian videoconferencing bridge or the Radvision Scopia
Elite 5000 for converting H.320 and H.323 protocols.

Figure 9: Various protocols and their locations in the Open Systems Interconnection (OSI) model

Below is a list of protocols that can be used as needed:

• For control and signalling: H.225, H.245, Q.931, RTCP
• For voice: G.711, G.722, G.723, G.726, G.728, G.729
• For video: H.261, H.263, H.263+, H.264
• For data: T.123, T.124, T.125

H.324 

The H.324 protocol is recommended for voice, video and data transmission over conventional analog lines. It uses the H.263 codec for video transmission and G.723.1 for audio transmission.

H.324M 

The H.324M (3G-324M) protocol is an umbrella protocol for video telephony on 3G networks. nWise uses the LifeSize MCU 12 videoconferencing bridge or the Radvision Scopia Elite 5000 for converting H.324 and H.324m protocols.

Session Initiation Protocol (SIP)

The SIP is standardized by the IETF (Internet Engineering Task Force). It was designed to establish, modify and terminate multimedia sessions. It authenticates and locates multiple participants, and negotiates the types of media that different participants can use with SDP (Session Description Protocol) messages.

SIP does not transport data exchanged during the session, such as voice and video. SIP is independent of data transmission; all types of data and protocols can be used for these exchanges. RTP (Real-time Transport Protocol) is most often used for audio and video sessions. SIP is gradually replacing the H.323 protocol.

The FCC has also recognized this trend. In its notice, FCC 11-184, the FCC indicated that "in 2006 the industry migrated to a standard for transmitting real-time voice and video over packet-based networks called H.323, but has failed to make progress on the standardization needed to transition to the Session Initiation Protocol (SIP) family of standards, which has subsequently become the default for mass market Internet-based voice and video devices."¹⁷

Since 2007, this standard open protocol has been the most commonly used protocol for Internet telephony (Voice over IP or VoIP). SIP is not only used for VoIP, but also for numerous other applications such as videotelephony, instant messaging, virtual reality and video games.

T.140 (RFC 4103)

This conversation protocol works in text mode, for real-time multimedia applications.

FaceTime, Skype, Facebook and iChat

These are closed protocols with protected source codes owned by private companies. These companies do not share their source code with other developers. However, VRS providers have developed external interfaces to convert some of these applications to SIP mode. However, the quality is decreased, because it is impossible to convert directly at the core of the software in question.

Below are some examples of gateways used by nWise for the conversion of these applications to SIP:

• XMPP for social media such as Facebook, iChat, GoogleTalk (2013)
• Skype – external interface for the conversion of Skype to SIP
• For clients who use Skype or FaceTime, nWise recommends using a free client plugin that they developed; the plugin is compatible with the MMX platform.

Additional definitions of other protocols are provided in Appendix 3.

Types of devices that may be used

There are currently two schools of thought in the VRS industry. On one hand, some providers, such as Sorenson, provide an end-to-end solution. This type of solution is a closed ecosystem, and the choice of devices is limited to proprietary devices. The advantage is that client services are facilitated in technical terms, because the provider is familiar with the devices.

On the other hand, IVèS and nWise offer a more open solution that provides users with access to non-proprietary devices that meet their needs. The disadvantage is that client services are required to support a multitude of devices and all their respective specifications.

The most common devices are:

• Videophone
• Television interface (Setup Box, television not included)
• Software suite for MAC or PC
• Tablet software
• Android or iPhone software

Subscribers have a choice between equipment approved by the platform provider and/or online applications. It is important to note, however, that operators installing services prefer to start with a stable Internet connection and known equipment, so that they can check the quality of the network and make the required corrections. Users can also see the quality of the system, and if they encounter any problems, they are easier to diagnose.

Mobile devices

Mobile devices are quite advanced, and they are indispensable tools for active Canadians. Canadian Wireless Telecommunications Association¹⁸ statistics speak volumes about the appropriation of mobile technologies:

• Wireless carriers now offer coverage to more than 99% of Canadians.
• Advanced wireless networks that support handsets such as smartphones and USB sticks are available to 98% of Canadians.
• At the end of March 2012, Canadian wireless phone subscribers numbered
  26 million.
• Half of all phone connections in Canada are now wireless.
• 75% of Canadian households have access to a wireless phone.

Devices are so intuitive that tasks that used to be technically complex have become child's play. The applications available are practically limitless, and large screens make viewing much easier.

Internal processors manage images in high definition. Wireless technologies and networks can provide speeds that are relatively equivalent to those of terrestrial networks.

Many people are abandoning their wireline telephone in favour of mobile telephones. In the second half of 2009, 25% of American households no longer had a wireline phone.¹⁹ In the first half of 2011, this percentage increased to 32%.²⁰

In Canada in 2009, nearly 9% of households no longer had a wireline. According to the same article, in 2014, close to 25% of households will have cut the telephone cord.²¹ As such, it is essential that video relay services can be accessed via a mobile device.

Several mobile devices have interesting possibilities.²² Some are even made reference to by video relay service providers, including known brands such as Apple, BlackBerry and Motorola.

Users do not all have the same knowledge, skills, financial means, or habits. As such, users must be given as many opportunities as possible to use the devices and technology best suited to their situation.

The implementation of any new infrastructure takes time and adjustments. The same will also apply to video relay services. We suggest that the implementation be done in several phases, so that each is properly implemented and its parameters well controlled.

Certain parameters of a wireless network, such as latency, are similar, and will be added to wireline parameters. Several new parameters will also be required for high-quality communications.

Parameters such as download and upload speed are very dynamic in a wireless network; they are more stable in a wired environment.

Wireless network providers continuously improve and implement new technologies to improve user experience. Despite the fact that most communications are made without any problems, we have all experienced difficulties in our voice communications. These phenomena may be more frequent with VRS, because the transmission of a video signal with a wireless device is more critical than the transmission of a voice message.

A video signal requires more network bandwidth. This type of information also requires that the connection be more robust, both in terms of the signal and the bit error rate (BER) or even the latency. Whether a user lives in an urban or rural environment also makes a difference, mainly in terms of the number of accessible cellular sites and the number of users on the site. In an urban environment, the site density is higher, as is the number of users. Though these differences seem subtle to most people, they may be more apparent in real life.

Simple elements that have nothing to do with the technical aspects of the network or device, such as backlighting, blinding light and constant camera movement, can make the task difficult for both the operator and the user.

The conditions of a wireline connection may deteriorate temporarily:

• During peak periods
• If the speed is too low for the task being attempted
• If several users share the same connection in a household or an office

The conditions of a wireless connection may deteriorate temporarily:

• During major events (demonstrations, sports events, special events, etc.)
• Due to the distance of a cellular site
• Due to geographic, climate or summer conditions
• Due to the equipment used to make the connection (satellite, obsolete equipment, etc.)
• Due to the environment (too much or not enough light, movement of the device, etc.)

Permanent deterioration occurs when the device or connection used does not have the required features to correctly process or display the information. This is why it will be important to inform future users of the minimum technical requirements for good quality service. The choices of device and network will affect quality of service.

For example, if the device is equipped with a low-resolution screen, certain functions may not be supported, thereby diminishing the user's communication experience.

In the United States, certain wireless providers offer data packages (both text and data) solely for clients with hearing and speech disabilities. This minimizes the costs for such users who never use their devices to transmit voice data. Canadian providers could also use this strategy to attract clients and promote the adoption of wireless technologies as part of a VRS project.

Functions

There is no large-scale development of a server-type product for automatic call distribution (ACD) that support video in the same manner as existing products do for voice and text. Turnkey or piece-by-piece solutions are the result of integrating several available technologies and combining them using various custom software applications.

All solutions involve an Internet solution. Clients are responsible for choosing a provider, as well as compatible technology, such as an ADSL or cable solution, while also including other technologies. If the implementation model with a 10-digit telephone number were retained, this would be the best solution for integration with the telephone and VRS systems deployed worldwide. Users will be required to obtain this number, either via a service provider or an IP telephone number provider. This solution should be considered and developed in the implementation of these future services.

Two thirds of products use SIP connectivity, while the other third uses the H.323 protocol. To integrate them all, the use of protocol converters is common. Each product is developed to allow for communication via different standards to reach as many clients as possible.

For call distribution, management functions and billing, integrators use either a proprietary or a public automatic call distribution system, such as Asterix, an ACD open-source platform.

All functions, such as queues, various types of messaging, call transfer to another operator or site, and multi-way calls, are made available and managed by the proprietary or freeware ACD platform.

Call management features, such as queues, 911 calls, real-time operator supervision and control panels showing call statistics, are also managed by the ACD platform.

With each provider, clients will be able to use their own devices and applications with which they are familiar via plugin applications, which can be downloaded from the VRS service provider's website. Clients will also be able to obtain a dedicated proprietary device or subscribe to the VRS service from a VRS service provider.

Interoperability

At present, when we want to call someone, we do not worry about who their telephone service provider is or what kind of telephone they have. For that reason, interoperability is an essential component of the video relay system. The selected system must be compatible with various technologies. Users must be given the choice to connect to the VRS platform using a videophone, a computer or a wireless device to receive calls. Users must also be able to choose a device on which to answer, if more than one device is functional at the same time, using the same principle as Rogers' "One Number ^TM."

If established relay centres can work with different platform providers, they should communicate with each other like the major telephone networks in Canada. The subscriber database should be centralized and accessible to all providers.

The SIP protocol is recommended by all manufacturers for interoperability among different service providers.

Sorenson does not offer solutions for interoperability with other providers. nWise and IVèS use the SIP protocol; Sorenson also uses SIP for communication among its various service points.

For accessibility to subscribers in the United States and other countries, two main points must be considered: the protocols used in the various countries and access to subscriber information. Protocols may differ from one country to another; for example, certain platforms installed in Canada use the H.324 or SIP protocol, while in the United States, the H.323 protocol is used.

Figure 10: Interoperability among VRS services

The responsibility for access to subscriber information will likely be assumed by the organizations that manage telecommunications. They will need to agree on a way to make subscriber directories accessible, at least for subscribers who allow their numbers to be published.

Technically, databases should not be owned by a specific provider, because that provider may limit data access. Further, if data are outside a provider's network, another provider searching the database will not open the platform to intrusions into any system.

In RFC 3761, the International Telecommunication Union (ITU) described a standard that enables a telephone number to be associated with an IP address. The standard, E.164 Number Mapping²³ (ENUM), works using a special DNS that converts the telephone number to a Uniform Resource Identifier (URI) or an IP address that is used for Internet communications.

In Europe, certain countries such as Spain, France, Great Britain, Holland and Sweden use ENUM servers to share user directories for each of these countries.

If a subscriber knows the telephone number of another user in another country where the directories are not accessible, the subscriber can still communicate with that user by entering his or her telephone number and the domain name of the subscriber's provider, e.g. 123-456-7890@provider.com

In terms of the interoperability of video relay systems, the SIP protocol is the common communication protocol for all three providers analyzed in this report.

Management and billing

Management and billing are important elements when avoiding problems that have been experienced elsewhere.

The provider must be able to monitor, at all times, the platform, interfaces and gateways that allow protocols to communicate with each other. A number of platforms can download patches or updates to users' equipment in order to resolve issues quickly and effectively.

The provider must quickly respond to requests made by the managing organization in charge of implementing video relay service in Canada.

With regard to billing, some platforms can provide information on the caller, the duration of the relay, the company and operator who performed the relay, and any other relevant parameters requested by the managing organization. This information should be available in real time to the company providing the relay and to the national managing organization. These reports should enable data to be processed so that data management is made easier.

The payment method, billable time (starting when an operator answers a call or only when a relay is made), and the allocated amounts will be determined by the managing organization.

Detailed call data from the ACD system are used for the billing system. There are many independent providers in the Canadian market that can provide this component of the video relay service.²⁴

In the United States, the FCC is preparing to introduce regulations to standardize parameters and their disposition in electronic files in order to manage call data from each video relay service provider more easily. This in turn should help reduce fraud.

Solutions adopted in other countries are based on VRS service management principles. For example, Neustar is working on the possibility of providing special phone numbers for deaf individuals in order to identify them when a call is signalled. In the United States, the FCC requires video relay service companies to provide very specific parameters on the use of video relay systems, both for call data (for billing purposes) and for usage statistics.

In the United States, the FCC realized that some service providers were simulating calls in order to inflate their invoices. They discovered that a number of calls were made between the operators using the service, some called a radio station and offered sign language interpretation for listeners who called the service, and some even offered financial incentives to frequent users of the service.

In Europe, each country has its own rules for regulating video relay service providers.

Confidentiality of communications

Confidentiality of communications is important in all cases, but especially so when it comes to legal or business communications. There are two ways of ensuring confidentiality. The first is technical, using a Virtual Private Network (VPN). Communications over the Internet are thus encrypted end to end. Of course, this uses more bandwidth, but under certain conditions, the extra bandwidth is worth it. Adding a VPN is not necessarily for all communications, especially personal conversations that do not contain sensitive information.

Encrypting all communications would require connections with higher capacity and thus higher costs, not to mention the increased information processing load on the servers. This could require additional servers, whereas public Internet would be sufficient.

The other factor is human, because operators are privy to all conversations with which they assist. Very stringent policies will need to be put in place to prevent operators from disclosing information to other parties who were not involved in the conversation.

Call routing

The call routing process is not very important to users—what is important is that the call reaches the recipient and that communication is established.

The routing of video calls by a video relay service requires a different infrastructure from that required for traditional telephone calls. Knowledge of the new components and their implications, especially in the world of IP, is important for network personnel and for understanding how these components interact when a call needs to be routed to another VRS.

The various scenarios are outlined in another section of this document, but below are a few images that illustrate call routing and the protocols used.

Figure 11: Routing a call between subscribers without intervention

Figure 12: Routing a call using various Internet applications

Implementing a video relay service

As we have seen, implementing a video relay service has not been a simple feat so far. The choice of platforms, how they work, the implementation model, and the integration possibilities vary widely.

However, before we look at what could be done in Canada, let us look at what has been done in the United States: their successes as well as their lessons learned. Using this experience as a guide, Canada can launch a video relay service without repeating previous mistakes.

The U.S. Federal Communications Commission (FCC) has issued numerous directives and tightened up the rules,²⁵ leading to a sharp decrease in the number of video relay service providers in the United States. At first there were just over 40 such providers; now there are only six.²⁶

In terms of the technical aspect, the system infrastructure should be situated in multiple locations across Canada. This would help maintain the technical parameters and latency (less than 100 sm) or round-trip time at minimum levels. Furthermore, this geographic distribution would provide redundancy and thus reduce the risk of service disruption.

Figure 13: Distribution of main network equipment²⁷

Another technical consideration is the evolution of platforms, whether during implementation or with future technological advancements. This allows users to choose the best device for their needs: for example, videophone, smartphone, computer, or console that connects to the television. To accommodate this, the system should be open and not proprietary so as to avoid controlling users.

There should not be any problems with implementing the system in an urban environment; rural environments may pose more challenges. Thus, both urban and rural environments should be taken into consideration during the planning process.

As shown in Figure 1, the vast majority of Canadians have access to broadband in their home. Those who do not have broadband access at home, either because it is not available or they cannot afford it, can get access at work or in public or community buildings such as libraries and Internet cafes. Another example of this sort of building is the public communications terminals that have been installed in some cities in France. These "phone booths" allow people who are deaf or hard of hearing or who have speech difficulties to communicate with a third party using a video relay service. The services are paid for by the municipality or other organizations.

Subscribers to video relay services should have their own 10-digit telephone numbers, which would be associated with an IP address. This would allow anyone to contact the subscriber from any device.

Users would simply have to dial the phone number of the person they want to call (10 or more digits depending on where they are calling from). The call would be routed to the platform, then, depending on the phone number called and the parameters of the user's account, the platform would determine whether the call requires the services of an interpreter.

Possible options

Because there is no ready-made solution, we need to have a good idea of what we want. In order to get a representative price for the desired solution, the requirements must be outlined in a set of specifications and submitted to various solutions providers.

At this point in the technical feasibility assessment, it is not easy to discuss costs when the requirements have not been clearly defined. Service providers are somewhat reluctant to disclose this type of information. The needs assessment will therefore be essential for each supplier to determine the possible costs. The assessment will also identify options that could be chosen over the short and medium term and will also provide a better perspective of the amounts to be paid to the platform provider each year. Even so, we were still able to get some information about costs.

Here are a few possible technical options for providing a VRS:

• An approach using providers of turnkey services, such as Sorenson, which offers an end-to-end proprietary solution using a communications standard such as H.323 and/or SIP. Sorenson's technology is completely closed at each end. The provider and the client are separated by the Internet, H.323 and SIP.

Sorenson developed its ACD application and has all of the proprietary information. The same goes for videophones available to users. The products are not for sale; Sorenson bills only for the service provided. This technological platform does not include an interface to convert signals other than H.323 and SIP. Deaf individuals wanting mobility will need to use a Sorenson plugin, which can be downloaded free of charge from their website. The plugin is required in order to communicate with the provider using a mobile device. The use of H.323 and SIP protocols applies to mobile and fixed-terminal communications. In order for deaf individuals to be able to use the service, they must have access to the Internet, whether they are using a fixed or mobile device.

The advantage to this approach is that the manufacturer has already parameterized the equipment for deaf individuals with functions and buttons that facilitate communications, such as a button for making an emergency call vs. a regular call, and a flashing light to attract the attention of a deaf individual who cannot hear the videophone ringing.

• An open approach that can respond to any type of call will require a technical specifications document that outlines all of the specifications required for the service to be provided. IVèS and nWise, as integrators, offer a customized solution that can be adapted to all types of existing communications on the market.

Both manufacturers also offer adapted terminal devices as well as plugins for mobile devices. However, an IVèS or nWise solution can be fully customized for a specific market or different existing technologies using protocol converters.

The IVèS solution

Here are the guidelines of the IVèS video relay model for Canada:

• Research phase: This phase involves evaluating the specifications required to meet the needs of Canada's deaf or mute community.
• Implementation phase: This phase involves gradually deploying the platform according to user needs.

Projected capacity and upgrades:

IVèS already has infrastructure in Canada—it provides Canadian customers with videoconference and document sharing services for businesses. IVèS serves a U.S. company, Healinc, from its servers in Montreal. IvèS has the following infrastructure in Canada:

• Two SIP proxy servers that can serve a total of 60,000 users;
• Two call centre servers that can handle 200 calls simultaneously;
• Database of 4 million users (four servers); and
• H.323 gateway and peering with iTRS (USA).

IVèS believes the following upgrades would be necessary for a reliable cross-country video relay service:

• Two dedicated proxy servers in Canada: one in the west and one in the east;
• Adding a call centre server in western Canada;
• Adding a multimedia relay server in western Canada; and
• Developing a database containing details about ACD data.

Below is a diagram of the architectures that can be deployed with IVèS:

Figure 14 – Possible architectures of the IVèS solution depending on operators' requirements and budgets

Here are the cost estimates for the technology provided by IVèS. Note that they cover only the technical parameters.

• Provision of licences and physical servers;
• Updates and upgrades to server software, interpreters, clients, peering with other operators, etc.;
• Hosting; and
• Monitoring, maintenance and 24/7 Level 2 support.

Applications and specifications

For users

Here are the general parameters required to use a video relay service under current conditions:

• Minimum uplink/downlink speed: 256 kbps
• Maximum uplink/downlink speed: 512 kbps
• Average speed required: 384 kbps
• Latency: < 100 sm
• Compression: H.323 and SIP
• Resolution: H.261, H.263
• Audio: G.711, G.722, G.723, G.728, G.729

For the platform

Two servers can support a database of 30,000 users and respond to 200 calls simultaneously, as long as the human resources are available.

Connections of 100 Mbps are used to route incoming and outgoing communications.

To connect to telephone lines, IVèS goes through a third party that provides telephone numbers as well as IP logs.

Challenges ahead

One of the first challenges to be faced when eventually implementing the system in Canada is the country's size. The network will have to cover large distances, and distance increases the travel time of information. We must therefore ensure that the servers and the required equipment are installed in multiple regions of Canada in order to maintain the minimum parameters.

However, as has been previously discussed at the beginning of this study, the fibre optic infrastructures deployed in Canada suggest that information can be disseminated effectively, not only between major cities, but also between different parts of Canada to equipment installed in the eastern or western half of the country.

Call routing

Two dialling methods may be used: (1) a common toll-free number, or a local number for each region, to connect to the platform (common number method); or (2) a personal 10-digit phone number for each subscriber.

The common number method is similar to how teletypewriters work and would require at least four numbers: two toll-free (or two local numbers for all regions), and two regular numbers. A toll-free number and a regular number would be assigned for French services, with the other two numbers for English services.

The common number method was how VRS was originally implemented. According to IVèS, in France, this method is not used for relay services or even to establish communications between two signing individuals. With the common number, each user would have an identification code issued by the service provider. This method would require much more assistance from operators—they would have to answer calls from people who do not know the identification code of the person they want to call. If callers knew the identification code, they would dial the number to connect to the platform, then the identification code of the person they wanted to call. This method would not build on the technological progress available today and would unnecessarily tie up already limited interpretation resources.

The second method may take a bit longer when establishing the service, because each subscriber would need a telephone number, but it would greatly facilitate the service's operations over the long term and would provide an experience similar to existing telephony services.

Each user would have an individual phone number connected to an IP address that would provide access to a portal. The portal would allow users to connect more than one device and have more flexibility. Operators could then focus on interpretation work, since there are few specialists available.

While we are not making the decision, we strongly recommend choosing the 10-digit number option so that the user experience is similar to that of all Canadians who use the telephone.

To make it easier to understand the call routing in the various scenarios, only the main components of VRS networks have been depicted. Call routing scenarios may vary from one provider to the next depending on the specific characteristics of each system. Thus we will explain the general principles of call routing.

The first two scenarios are based on assigning a common number. The scenarios after that will be based on individual 10-digit numbers. The first 10-digit-number scenario involves calls originating from a wireless device, and the other scenarios have calls originating from a SIP device connected to the Internet (either by cable or through Wi-Fi).

The SIP protocol is used in the IVèS and nWise platforms. The main protocol used by Sorenson is H.323, but SIP can also be used.

If people who do not have speech or hearing difficulties are using a computer or wireless device that belongs to a deaf person, they should log out of the video relay application when making regular calls. Moreover, if a device is dedicated to using the VRS platform, it should not be used for regular calls. If it is, the call will be answered by an operator, who will then determine that the caller does not need video relay service. The call will be ended without billing for interpretation.

The whole issue of payment methods and billing is not covered in this study. That is for policy makers to look into.

With regard to call routing, the signal passes through the platform so that the parameters are compiled, but the video itself takes the best route if an operator is not involved.

A) Call made using a common number, with a deaf person calling a hearing person via a SIP device connected to the Internet by either cable or Wi-Fi.

Figure 15: Routing of a wireline phone call by a deaf person using a common number

• The deaf person uses the application to dial the common number for the platform.
• The call is sent via the Internet to the platform.
• No identification code is entered.
• The call is sent to a queue if all of the operators with the required skills (e.g. fluency in LSQ or ASL) are busy.
• The call is sent to an operator with the required skills, based on the number dialled.
• The operator answers the call and confirms the caller's needs.
• The operator speaks to the person being called and says that the call is a relay call.
• The conversation begins.
• When the call is finished, the operator disconnects both parties.

B) Call made using a common number, with a deaf person calling another deaf person via a SIP device connected to the Internet by either cable or Wi-Fi.

Figure 16: Routing of a wireline call by a deaf person to another deaf person without the assistance of an operator

• The deaf person uses the application to dial the common number for the platform.
• The call is sent via the Internet to the platform.
• The platform waits for an identification code to be entered.
• The caller dials the identification code of the person being called.
• No protocol conversion is required because the user's device and the platform both use SIP.
• The call is sent to the deaf person being called.
• The conversation begins.
• When the call is finished, either party disconnects the call.

All of the following scenarios are based on a personal 10-digit phone number.

C) A deaf person calls a hearing person via a mobile device using the cellular network.

Figure 17: Routing a wireless call by a deaf person with the assistance of an operator

• The deaf person uses the cell phone application to dial the number of the person being called.
• The call is sent via the cellular provider's network to the provider's cellular exchange.
• The provider's cellular exchange recognizes the call as an IP call and sends it via the Internet to the VRS platform.
• The server analyzes the caller's profile and the telephone number being called.
• The number being called is not found in the database, so it is concluded that the caller will need relay service. The call is sent to an operator with the required skills.
• Protocol conversion is done because the user has a wireless device and the platform uses SIP.
• The call is sent to a queue if all of the operators with the required skills are busy.
• The operator answers the call and confirms the caller's needs.
• The operator speaks to the person being called and indicates that this is a relay call.
• The conversation begins.
• When the call is finished, the operator disconnects both parties.

D) A deaf person calls a hearing person via a SIP device connected to the Internet by either cable or Wi-Fi.

Figure 18: Routing of a wireline call by a deaf person with the assistance of an operator

• The deaf person uses the application to dial the number of the person being called.
• The call is sent via the Internet to the platform.
• The server analyzes the caller's profile and the telephone number being called.
• The database does not find the number being called in its database and therefore concludes that the caller will need relay service. The call is sent to an operator with the necessary skills.
• No protocol conversion is done because the user's device and the platform both use SIP.
• The call is sent to a queue if all of the operators with the required skills (e.g. fluency in LSQ or ASL) are busy.
• The operator answers the call and confirms the caller's needs.
• The operator speaks to the person being called and indicates that this is a relay call.
• The conversation begins.
• When the call is finished, the operator disconnects both parties.

E) A deaf person calls a hearing person via a mobile device using the cellular network.

Figure 19: Routing of a wireless call by a deaf person with the assistance of an operator

• The deaf person uses the cell phone application to dial the number of the person being called.
• The call is sent via the cellular provider's network to the provider's cellular exchange.
• The provider's cellular exchange recognizes the call as an IP call and sends it via the Internet to the VRS platform.
• The server analyzes the caller's profile and the telephone number being called.
• The number being called is not found in the database, so it is concluded that the caller will need relay service. The call is sent to an operator with the required skills.
• Protocol conversion is done because the user has a wireless device and the platform uses SIP.
• The call is sent to a queue if all of the operators with the required skills are busy.
• The operator answers the call and confirms the caller's needs.
• The operator speaks to the person being called and indicates that this is a relay call.
• The conversation begins.
• When the call is finished, the operator disconnects both parties.

F) A hearing person calls a deaf person.

Figure 20: Routing of a wireline call to a deaf person with the assistance of an operator

• The hearing person dials the number of the person being called.
• The call is sent through the phone network to the platform.
• The server analyzes the profile of the person being contacted.
• The database recognizes that the person being called requires a relay service and sends the call to an operator with the required skills for the person being called.
• The call is sent to a queue if all of the operators with the required skills are busy.
• The operator answers the call and confirms the caller's needs.
• The operator speaks to the person being called.
• The conversation begins.
• When the call is finished, the operator disconnects both parties

G) A deaf person calls another deaf person in Canada (without going through an interpreter)

Scenario 1: The caller knows the 10-digit number of the person he or she wishes to call.

Figure 21: Routing of a wireline call between two deaf people, Without tthe assistance of an operator

• The deaf person uses the application to dial the number of the person being called.
• The call is sent via the Internet to the platform.
• The server analyzes the caller's profile and the telephone number being called.
• The database recognizes that both people are in the database and do not need a relay service.
• No protocol conversion is done because the user's device and the platform both use SIP.
• The call is sent to the person being called.
• The conversation begins.
• When the call is finished, both parties disconnect.

Scenario 2: The caller does not know the 10-digit number of the person he or she wishes to call.

• The deaf person consults the directory for his or her VRS provider. If the person he or she wishes to call is in the directory, the caller dials the 10-digit number. (See the steps under Scenario 1.)

H) A deaf person calls another deaf or signing person in another country. The number is known by the caller and is hosted on the same platform.

Note: In this scenario, the person being called is a friend or relative living in another country who has compatible video equipment and is registered on the same platform as the main user (the caller).

Figure 22: Routing of a wireline call between two subscribers on the same platform who speak sign language, one of whom is in another country

• The deaf person uses the application to dial the number of the person being called, using the appropriate dialling method.
• The call is sent via the Internet to the platform.
• The server analyzes the caller's profile and the telephone number being called.
• The call is sent to the appropriate interface to establish the connection between the protocols used between the subscribers.
• The call is sent via the Internet to the person being called.
• The call begins.
• When the call is finished, both parties disconnect.

I) A deaf person calls another deaf or signing person in another country. The number is known by the caller and is hosted on another platform.²⁸

Figure 23: Routing of a wireline call between two subscribers on two different platforms who speak sign language, one of whom is in another country

• The deaf person uses the application to dial the number of the person being called, using the appropriate international dialling method. (The caller can dial a 10-digit number if the two platforms have a connection or the IP address directly if there is no agreement in place.)
• The call is sent via the Internet to the servers of the caller's platform.
• The server analyzes the caller's profile and the telephone number being called.
• The call is sent via the Internet between the subscribers' two platforms.
• The call is sent to the appropriate interface to make the connection between the protocols used by the subscribers' platforms.
• The call is sent via the Internet to the person being called.
• The call begins.
• When the call is finished, both parties disconnect.

J) A deaf person calls another deaf or signing person in another country. The number is not known by the caller and is hosted on another platform. (This scenario assumes that subscriber databases can be accessed and shared between VRS providers.²⁹)

Figure 24: Routing of a wireline call between two subscribers on two different platforms who speak sign language, one of whom is in another country. The caller does not know the number of the person being called

• The deaf person looks up the number of the person being called in the VRS provider's database.
• If the VRS is connected to international databases, other databases can be searched for the 10-digit number of the person being called.
• The caller uses the VRS application to dial the number of the person being called, using the appropriate dialling method for calling the United States or another country.
• The call is sent via the Internet to the servers of the caller's platform.
• The server analyzes the caller's profile and the telephone number being called.
• The call is sent via the Internet between the subscribers' two platforms.
• The call is sent to the appropriate interface to make the connection between the protocols used by the subscribers' platforms.
• The call is sent via the Internet to the person being called.
• The call begins.
• When the call is finished, both parties disconnect.

NOTE:

There are two possible reasons that an individual may not be found in the directory:

• He or she is deaf but does not want to appear in the directory; or
• He or she is not deaf.

K) A deaf person in Canada calls a hearing person in the United States or another country.

It remains to be determined whether this type of call will be authorized.

L) A hearing person in the United States or another country calls a deaf person in Canada.

Figure 25: Routing of a wireline call from another country to a deaf person in Canada

• The hearing person dials the local number of the person being called in Canada, using the international dialling method for the hearing person's country.
• The call is sent via the telephone network to the platform.
• The database recognizes that the person being called requires a relay service, and sends the call to an operator with the required skills for the person being called. (NOTE: In this type of call, the platform to which the user subscribes will always be used. If a hearing Canadian calls a deaf person in the United States, the U.S. platform will be used.)
• The operator answers the call and confirms the caller's needs.
• The operator communicates with the deaf person being called.
• The conversation begins.
• When the call is finished, the operator disconnects both parties.

Calling 911

Figure 26: Routing of a landline call by a deaf person to 911

• The deaf person uses their application to dial 911 or presses the emergency button.
• The call is sent via the Internet to the platform.
• The server analyzes the caller's profile and the telephone number being called.
• The database recognizes the number and sends it on a priority basis to an operator with the required skills.
• The call is sent to a priority queue if all of the operators with the required skills are busy.
• The operator answers the call and confirms the caller's needs.
• The operator verifies that the address in the caller's file is correct.
• The operator dials the appropriate emergency services number for the caller's geographic location and informs the 911 operator that this is a relay call.
• The conversation begins. The operator gives the 911 operator the caller's coordinates and mentions that the caller is deaf.
• When the call is finished, the operator disconnects the caller and 911.

Emergency services in Canada such as 911 are not equipped to receive video calls at this time. This service may be offered by a VRS provider as a relay to conventional 911. Access to 911 must be offered by an operator at the same time as a VRS call.

Sorenson's website states that clients must be vigilant about updating their file. The information in user files helps the operator give 911 the right address in the event that users themselves are indisposed and cannot communicate with the operator.

When the service is offered with a pre-programmed terminal, an emergency services button is programmed on the device. Pressing the button automatically dials a direct inward dialling (DID) number, and the call centre (ACD) can identify the call using a dialled number identification service (DNIS) and route the call accordingly, with priority over other calls.

Calls to 911 must be supported, either by the video relay service provider or by the Internet provider, whether or not it has a telephone line to the client.

If the service is offered in the user's home or office, users' telephone numbers will be associated with an IP address as well as the user's geographic address. Unfortunately, the current systems cannot correlate an IP address with a geographic address. Subscribers will therefore be responsible for keeping their physical address updated in the event that they call 911. If a wireless device is being used, GPS positioning should be able to locate the caller.

In this situation, an ethics issue may arise with regard to being located at all times. It will be up to users to decide whether, in an emergency, their lives and the lives of their friends and family are more important than the fact that their position can be identified, especially if they cannot send additional information via real-time text.

Video relay centres must be able to handle 911 calls quickly. In addition, when the emergency call display appears on the operator's monitor, it would be useful for the operator answering the call to be able to see the user's address or position on a map (using the coordinates received) on one section of the screen.

Some organizations have explained the difference between text messaging, where the user types a message and presses a button to send, and real-time text (T140 protocol). Because the video relay system is intended to facilitate more interactive communication, it would also be useful to include real-time text.

In regular conversation, and especially an emergency, real-time text would be an asset for faster, smoother communication.

Figure 27: Topology of a 911 call

In France, calls to 112 (the equivalent of North America's 911) are routed to a national organization called REACH 112.³⁰ The service is offered in total conversation mode. This means that it can receive calls using voice, real-time text (T140), sign language, or a combination of the three.

This type of service does not exist in Canada, to our knowledge. However, there is a firm in Sudbury, Northern 911,³¹ that can manage 911 calls made over the Internet (using VoIP). The person answering the call is required to validate the caller's address. If the caller cannot speak, emergency services are sent to the last known address. The service is not offered in total conversation mode.

Conclusion

Implementing a video relay service requires a thorough assessment in order to clearly define user requirements. This step is crucial to make sure that there are no surprise gaps between expectations and reality. Not only must technological aspects be taken into account, but also user aspects, human resources required for interpretation and financial aspects.

Implementing a video relay service in Canada is completely feasible from a technical standpoint if equipment is installed in both western and eastern Canada. Fibre optic connections are already spread across all of southern Canada and serve all of the major cities. Other connections link the cities to towns near and far.

The distribution of equipment will also facilitate call distribution and provide redundancy in the event of an outage.

We believe that the combination of this study with others that have been or will be completed will provide the necessary tools and parameters to better inform the Canadian Radio-television and Telecommunications Commission.

It has been our pleasure to be able to collaborate on the video relay project.

Sincerely,

Louis Houbart

President

Groupe Consult-Com Techno Inc.

Appendices

Appendix 1: Flow chart of video relay service

Figure 28: Flow chart of video relay service (1 of 3)

Figure 29: Flow chart of video relay service (2 of 3)

Figure 30: Flow chart of video relay service (3 of 3)

Appendix 2: Call routing

Figure 31: Call routing

Appendix 3: Description of various communications protocols

AIM: AOL Instant Messenger, or AIM, is a proprietary instant messaging, VoIP and videoconference system developed by AOL. AIM can be used with a webcam for videoconferencing.

G.711: G.711 is an ITU-T standard for audio compression.

• Sampling frequency: 8000 Hz for telephone bandwidth between 300 and 400 Hz.
• Network bandwidth: 56 or 64 kbit/s.
• Encoding type: PCM (Pulse Code Modulation). It is the base for transmitting audio over the public switched telephone network (PSTN) or the integrated services digital network (ISDN) and is also used to transmit voice with little compression in IP networks.

G.722: The global encoding standard G.722, standardized by ITU-T, is used for voice over IP with "high-definition" voice quality (wideband telephony). The quality is obtained by doubling the frequency band being coded (50–7000 Hz); compare this with standard "narrowband" telephone quality (300–3400 Hz) used in traditional telephony on PSTNs. Users therefore feel like the listener is "present" with them and benefit from listening comfort and greatly improved intelligibility.

G.729: The ITU-T recommendation G.729 defines coding of speech at 8 kbit/s using code-excited linear prediction speech coding. G.729 uses less bandwidth than G.711. It is used to obtain high-quality telephony.

G.729 is

• supported by most PABX IPs;
• used for encoding audio in videoconferences;
• also used to transport VoIP on WANs; and
• is preferred by telephone operators.

H.264: H.264, also known as MPEG-4 AVC (Advanced Video Coding) or MPEG-4 Part 10, is a video compression standard. Today it is one of the most commonly used formats for recording, compression and distribution of high-definition video.

H.263: H.263 was originally developed to transmit video at very low bitrates for videotelephony applications using the H.324 switched telephone network. It was then integrated into H.323 and SIP videoconference IP protocol. The same codec was used for H.324m, which enables video calls to be made in circuit mode on 3G mobile networks.

H.263+: The second edition of H.263 (known as H.263+) was ratified in February 1998 and expands the areas of application, being more flexible and improving encoding efficiency while remaining compatible with the original version. To do this, new optional modes were added in the form of annexes.

H.264: H.264, also known as MPEG-4 AVC (Advanced Video Coding) or MPEG-4 Part 10, is a video compression standard. Today it is one of the most commonly used formats for recording, compression and distribution of high-definition video.

iLBC (Internet Low Bitrate Codec): iLBC is a free audio codec that is useful for robust VoIP communications. It uses little bandwidth (15.2 kbps), making it reliable for use on the Internet.

IMS: The IP Multimedia Subsystem (IMS) is a standardized Next Generation Network (NGN) architecture for telephony operators that allows them to provide fixed and mobile multimedia services. The system uses VoIP technology based on a standardized 3GPP implementation of SIP running on a standard IP protocol.

Existing telephone systems (packet switching and circuit switching) are supported. The purpose of IMS is not just to enable existing and future services to work on the Internet. Users must also be able to use these services equally well in their home region or when roaming. To do this, IMS uses standard IP protocols defined by the IETF. This means that a multimedia session, whether it is taking place between two IMS users, between an IMS user and an Internet user, or even two Internet users, is set up using exactly the same protocol. The service development interfaces are also based on IP protocols.

This is why IMS really helps integrate the Internet and cellular telephony. It uses cellular technology to provide access at all times and uses Internet technology to provide services.

RTMP (Real Time Messaging Protocol): RTMP is a proprietary network protocol developed by Adobe Systems, for streaming audio, video or other data between a server and a client, usually the Flash player.

RTP (Real-time Transport Protocol): Currently, RTP is used primarily for media transport for Voice over IP, videoconferencing and even streaming. RTP is used to advantage on a real-time network (for example, an ATM with guaranteed bandwidth, fibre optic channel, broadcasting or a satellite channel).

RTP is unidirectional but can be used in multicast mode via satellite. It is therefore very economical in terms of network resources when serving a large number of receivers, making it possible to considerably increase the useful speed and the quality of the content encoding.

In unidirectional mode, it is always associated with another signalling protocol that manages the setup of sessions and allows the exchange of port numbers used by equipment at either end. Examples of protocols include:

• SIP for VoIP and videoconferencing;
• H.323, also for these services (previous generation); and
• RTSP (Real Time Streaming Protocol) for streaming, although RTSP contains a TCP encapsulation mode.

The protocol adds a special heading to UDP packets in order to:

• Specify the type and format (codec) of the media being transported;
• Number the packets in order to be able to manage losses and packets being sent out of order;
• Manage time differences and smooth out jitter.

RTSP: RTSP, or Real Time Streaming Protocol, is an application-level communications protocol (Level 7 of the OSI model) used with streaming media systems. It makes it possible to control a media server remotely, providing the usual video player functions such as "play" and "pause" and allows access based on the position in time.

RTSP does not transport data; it must be associated with a transport protocol such as RTP or the RealNetworks RDT in order to do so. RTSP was developed by the IETF and published in 1998 as RFC 2326.

Speex: Speex is a free, patent-free codec. It is a lossy data compression format (like MP3 and Vorbis) and is specialized and optimized for the human voice. For voice, it obtains quality and size ratios that are greatly superior to similar compression formats designed for music file compression. At 12 kbit/s, the quality is sufficient for all types of conversations. Speex is used in a wide range of software, namely through plugins and filters. It is supported by software used for teleconferencing, data flow, sound processing, multimedia playback, P2P and games.

SRTP: Secure Real-time Transport Protocol (SRTP) defines a profile of RTP (Real-time Transport Protocol) intended to provide encryption, message authentication and integrity, and replay protection to RTP data in both unicast and multicast applications. SRTP was developed by Cisco and Ericsson.

TLS: Transport Layer Security (TLS), formerly known as Secure Sockets Layer (SSL), is a protocol that provides communications security over the Internet and was originally developed by Netscape. It was renamed Transport Layer Security (TLS) by the IETF when the IETF purchased the patent from Netscape in 2001.

XMPP:or Extensible Messaging and Presence Protocol, is a set of open protocol standards developed by the Internet Engineering Task Force (IETF) for instant messaging, and more generally a decentralized architecture for file sharing. XMPP is also a quasi-real-time collaboration and multimedia sharing system using the Jingle protocol. Examples of applications include voice over IP (VoIP), videoconferencing and file sharing.

XMPP is a TCP/IP protocol based on a client-server architecture that enables the decentralized exchange of instant and non-instant messages between clients in Extensible Markup Language (XML). XMPP is in ongoing and open development within the IETF.

Servers can be private (in an intranet, for example Facebook) or connected to each other within the JABBER network.³² XMPP is used around the world by hundreds of public and private servers and by millions of users. Numerous industry players use XMPP, such as Apple, Cisco, Gizmo5, GNOME, Google, IBM, Oracle Corporation, and more.

XMPP is divided into two separate parts:

• The basic protocol contains the fundamental concepts to run a Jabber infrastructure. It is defined by RFCs 6120, 6121, 6122 (which replaced 3920 and 3921 in 2011), 392 and 3923. Theoretically, this type of infrastructure cannot function without fully applying these protocols.
• XMPP Extension Protocols (XEP) provide additional functionalities for the Jabber protocol. Servers and clients are not required to adopt these extensions. This may block some functionalities between two users.

Unlike other popular and proprietary presence and instant messaging systems, XMPP was designed to be broader and more open than just instant messaging. It is therefore used by businesses and administrations in order to share data between applications (ETL, EAI, ESB) within information systems, but also as part of grid computing, notifications of alerts or information, system and network supervision, or cloud computing.

XMPP is also used for sharing and quasi-real-time collaboration such as whiteboarding or collaborative development and publishing, as well as Internet games (namely card and board games).

ACD server (automatic call distribution server)

Call distribution is the process for assigning incoming calls at a customer service centre to operators.

Call distribution is based on call qualifications, operator availability and priority rules.

Proxy server

In the more specialized network environment, a proxy server is a client-server computer application that is used to relay requests between a client application and a server application (layers 5 to 7 of the OSI model). Proxy servers are namely used to perform the following functions:

• speeding up browsing: cache memory, data compression, blocking advertisements or memory-hungry content (Java, Flash);
• logging;
• local network security; and
• screening and anonymous browsing.

Media server

Physical equipment or software program used to store and share files. This type of server normally handles video, image and audio files.

Gateway

A gateway is a network node that is used to interface with another network that uses different protocols.

Appendix 4: Glossary of Technical Terms

Table 3: Glossary of Technical Terms

Appendix 5: References for Manufacturers Mentioned in the Report

Links to cell phone manufacturers that offer devices adapted to the needs of people who are deaf or hard of hearing or who have speech difficulties.

Apple: http://www.apple.com/ca/accessibility/iphone/vision.html

BlackBerry: http://us.blackberry.com/legal/accessibility.html#tab_tab_overview

Motorola: http://responsibility.motorola.com/index.php/consumers/accessibility/

Manufacturers that offer call billing solutions using ACD data.

• www.oxilio.com
• www.cdscom.net
• www.komutel.com

Date modified:

2013-03-25