Internet Engineering Task Force SIPPING WG Internet Draft van Wijk/Rosenberg/ Document: Schulzrinne July 2001 Ericsson/Dynamicsoft Expires: December 2001 /WCOM/Columbia U. Category: Informational SIP Support for Hearing and Speech Impaired Users Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [10]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 1. Abstract SIP is attracting more and more attention as a valuable tool to enable and support voice and multimedia communications over the Internet. However, some users of SIP-based services will be unable or severely restricted to use plain voice communication. In particular, people who are hearing impaired often cannot send and/or receive voice. This document is a merger between 2 previously written drafts [6] and [7] regarding SIP and The Hearing Impaired and its goal is to lay a foundation for design and implementation of SIP based services. These services are generally enabled by baseline SIP [1], or through the use of the caller preferences specification [3]. No additional extensions are proposed here in order to support universal access. 2. Terminology and Conventions Used in This Document In this document, the key words "MUST", "MUST NOT", "REQUIRED","SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED","MAY", and "OPTIONAL" are to be interpreted as described in RFC2119 [8] and indicate requirement levels for compliant SIP implementations. For the purposes of this document, van Wijk/Rosenberg/Gearhart/Sinnreich/Schulzrinne [Page 1 of 21] SIP for Hearing and Speech Impaired Customers July 2001 the term terminal will be used to represent the hearing impaired individual and his/her SIP-enabled end-user equipment; this could be a TTY[9], a personal computer or PDA, a specially equipped mobile phone, video phone, etc. The term user, in this document, shall be understood to mean a hearing or speech impaired individual. 3. Introduction The Session Initiation Protocol (SIP)[1] is used to initiate, modify, and terminate interactive sessions between sets of users. Typically these are voice sessions, described by the Session Description Protocol (SDP)[2]. However not all users or potential users have access to SIP services. Specifically, people who are Culturally Deaf, Audiologically deaf, hard of hearing, speech impaired or disabled, etc., on either a temporary or permanent basis, are unable to participate in plain voice-based communications. For the purposes of this document, this group of people will be referred to collectively as Hearing Impaired individuals. Also, the term Sign Language (SL), is used in this document to refer to the natural signed language used by the Deaf. In the United States and parts of Canada and Mexico, American Sign Language (ASL) is used. For Deaf individuals in other countries, for example Britain, British Sign Language (BSL) is used. Also, since Deaf people can and do use various types of manual communications systems in addition to SL such as Signed English for this document the term SL will be assumed to cover all forms of manual communications. Within the Public Switched Telephone System (PSTN), services have been defined that allow for access to circuit switched based relay voice services by these users. We believe it is important to offer similar or better services in an IP context. The flexibility of SIP affords us the ability to both offer and improve on these services, and to offer more extensive forms of universal service access to this group of customers. This is a formative time for the future of IP-based communications and as such it is an appropriate time to ensure that such requirements as are necessary to ensure full accessibility by all customers are included in planning the new networks using SIP, such as the 3G wireless network. 4. Purpose and Scope This document will first describe a few possible services using call flows that enable universal access of voice and multimedia sessions, initiated by SIP to users who are hearing impaired. And second, offers a proposed set of requirements based on the services and attempts to identify issues that need resolution to allow full accessibility for all customers to SIP-based Internet communications. These services are generally enabled by baseline SIP[1], or through the use of the caller preferences specification [3]. No van Wijk/Rosenberg/Gearhart/Sinnreich/Schulzrinne [Page 2 of 21] SIP for Hearing and Speech Impaired Customers July 2001 additional extensions are proposed here in order to support universal access. 5. Background In the current telephony world, most hearing impaired individuals have access to either standalone or PC-based TTY devices. These text-based devices or software packages are adequate for communication with other hearing impaired individuals or with hearing individuals that have similar devices or software. In addition, most if not all states in the United States have state- sponsored relay service, in which a human operator with both standard telephone equipment and TTY devices acts as a go-between ("relay operator" or interpreter), allowing a hearing impaired person with a TTY to place or receive calls from hearing individuals with standard telephones. Individuals with speech difficulties that render it impossible for the individual to use ordinary voice-enabled devices can use the same TTY equipment and relay services. Introduction of the relay service has been a great benefit to both the hearing impaired and hearing people because it has enabled communication between them, where, prior to this time, it was difficult or impossible. It has provided independence to hearing impaired people, allowing them to communicate on their own terms rather than being forced to rely on hearing friends to act as telephone interpreters. In recent years, other technology such as two-way e-mail pagers have become available that provide portable communications for hearing impaired people in a manner similar to cellular telephones for hearing people. These have provided a great benefit to hearing impaired people, allowing them the ease of near-instant communications that hearing people now take for granted. Some e- mail pager services have also supported interface with other devices such as TTYs and FAX. In addition, most European GSM phones and other mobile services elsewhere offer SMS (short message service) for exchanging short text messages to other subscribers. This will also allow hearing impaired people to communicate near-instantly. Most recently, the advent of video relay services has provided ways for hearing impaired individuals to converse with hearing individuals using their most natural means of communication, visual, through the use of an oral or sign language interpreter. The human interpreter is typically physically located at the relay center and provides interpreting services via video connection to the hearing impaired person and voice connection to the hearing person. It is not easy for a hearing person to understand the strong need for the hearing impaired people to have a reliable and easy to use relay service. But imagine yourself to live one day without a telephone. From doing business to simply ordering a pizza, the telephone is often unavoidable today. And that is no small feat. van Wijk/Rosenberg/Gearhart/Sinnreich/Schulzrinne [Page 3 of 21] SIP for Hearing and Speech Impaired Customers July 2001 Imagine then how this is if this was not just one day, but for the rest of your life? Now you may get an idea why the relay service is so important for the hearing impaired people. Even a small improvement will be received as a mayor improvement. The reader of this draft is supposed to have at least a superficial knowledge and understanding of the deaf and hard of hearing world and the communication problems that have been endemic in that population since the creation of voice-only, long- distance communications. This may not be realistic, so the authors recommend the interested readers the following books as supplemental readings [11] [12] [13] [14]. 6. Example Services and Call Flows We provide the following examples services and accompanying call flows: 1 - Redirect to IM: The caller has a phone and an IM client. The called party has a phone and an IM client. The phone call is redirected to IM and both parties use IM to communicate. 2 - One-way speech to text translation service: The caller has only a phone. The called party has a text terminal to receive and a phone to send. A relay service translates in one direction only from speech to text. 3 - One-way speech to sign language translation service: The caller has just a phone. The called party has a video terminal to receive and a phone to send. A relay service translates in one direction only from speech to video, with the video being a sign language representation of the speech. 4 - Two-way speech to text and text to speech with translation service: The caller has a phone only. The called party uses text both ways. A relay service translates in one direction from text to speech and from speech to text in the other direction. A computer can do the text to speech translation. 5 - Hearing impaired calling party calling through relay: The caller has text only. The called party only has a phone. A relay service translates in one direction from text to speech and from speech to text in the other direction. A computer can do the text to speech translation. 6.1 Redirect to IM One advantage of providing SIP based voice services through the Internet is the seamless access to other IP services that can be used in conjunction with voice. Instant Messaging (IM) is particularly useful for the hearing impaired. IM allows for van Wijk/Rosenberg/Gearhart/Sinnreich/Schulzrinne [Page 4 of 21] SIP for Hearing and Speech Impaired Customers July 2001 instantaneous text messaging between IP connected users. Using SIP for IM service is recently described [15]. One way to use IM to support the hearing impaired is to redirect a voice call to an IM ôcallö (provided the caller supports IM). The service works as follows. A voice call is initiated by a terminal that can support IM as well. Indication of support for IM is done through the caller preferences specification [3], which allows the caller to indicate characteristics of the URLs they are willing to be redirected to. In this case, they would indicate support of the MESSAGE method, used for instant messaging within SIP. Support for other instant messaging protocols, so long as they are described by standardized URL schemes, can also be indicated. When the call arrives at the user agent of the hearing impaired user, the UA checks for support of instant messaging. If such support is indicated, the UAS sends a 302 (Use IM - Hearing Impaired) redirect, containing a URL to be used for IM. This redirect is forwarded back to the calling party, whose IM tool pops up with an IM filled in with the address of the called party. The two can then communicate in a pure IM session. The service can also be provided by an application server serving the hearing impaired user. The application server, upon receiving the INVITE, would initiate its own INVITE towards the hearing impaired user (without indicating any kind of media session). This has the effect of alerting (through a flashing light or some other means) that an incoming call is taking place. If accepted, the application server can then redirect the initial caller to send an IM to a pre-configured IM address. Figure 1 contains a call flow for the service assuming it is being provided by the called UA. | | | F1: INVITE | | --------------------------> | | | | | | F2: 302 IM | | <-------------------------- | | | | | | F3: ACK | | --------------------------> | | | | | | | | | | F4: MESSAGE | | --------------------------> | | F5: 200 OK | van Wijk/Rosenberg/Gearhart/Sinnreich/Schulzrinne [Page 5 of 21] SIP for Hearing and Speech Impaired Customers July 2001 | <-------------------------- | | | | F6: MESSAGE | | <-------------------------- | | F7: 200 OK | | --------------------------> | | | Caller Hearing Impaired User Figure 1: Redirecting to an IM Message F1 is: INVITE sip:hiu@example.com SIP/2.0 Via: SIP/2.0/UDP a.example.com From: sip:caller@example.com To: sip:hiu@example.com Call-ID: 9asdg9a7@1.2.3.4 CSeq: 1 INVITE Contact: sip:caller@a.example.com Accept-Contact: *;methods=''MESSAGE,SUBSCRIBE'' Content-Type: application/sdp Content-Length: XX Message F2 is: SIP/2.0 302 Use IM - Hearing Impaired Via: SIP/2.0/UDP a.example.com From: sip:caller@example.com To: sip:hiu@example.com;tag=9ajsd9aumlaa Call-ID: 9asdg9a7@1.2.3.4 CSeq: 1 INVITE Contact: sip:hiu@example.com;method=MESSAGE 6.2 One-way Speech-to-text Translation Service The above IM service is very interesting and quite useful for short messages. But when a hearing impaired user needs to place or receive a telephone call, a relay service is necessary. A relay is a person who can listen to the calling party, type up the text, and send it to the hearing impaired user either through instant messages or through text over RTP [5]. In one variant of this service, a call is made to a hearing impaired person. If the hearing impaired user wishes to accept the call, they send a 183 (Using a Relay for Hearing Impaired) response to the call. van Wijk/Rosenberg/Gearhart/Sinnreich/Schulzrinne [Page 6 of 21] SIP for Hearing and Speech Impaired Customers July 2001 The provisional response to the caller is used by the client to alert the caller to the fact that the called party is hearing disabled and that a relay service will be part of the call. This is useful to help the caller to tune the speaking style, so as to adjust for such a type of communication. Then, after sending the 183, using the third party call control mechanisms [4], the called party launches a call to a relay server, with the INVITE containing SDP that indicates support for only the RTP payload format for text messages. The response from the relay speech to text (STT) server (presumably accepting the call), contains SDP where the relay server expects to receive audio to be translated to text. When this 200 OK arrives at the hearing impaired user, that SDP is placed into the 200 OK of the call. The result is that the caller will be sending media to the relay server, and the hearing impaired user will receive a textual version of it over RTP. However, the hearing impaired user sends audio directly to the caller voice carry over (VCO), assuming that the hearing impaired user is able to communicate verbally). When this is the case, it has the advantage of sending the speech directly between the participants in the direction that is possible, resulting in less latency and more privacy for the callers since the relay will now hear only half of the conversation. With the current PSTN, the relay interpreter would hear the whole conversation when VCO is enabled (relay acts then as a conference bridge in VCO mode). The call flow for this service is depicted in Figure 2. Message F1 is: INVITE sip:hiu@example.com SIP/2.0 Via: SIP/2.0/UDP a.example.com From: sip:caller@example.com To: sip:hiu@example.com Call-ID: 9asdg9a7@1.2.3.4 CSeq: 1 INVITE Contact: sip:caller@a.example.com Accept-Contact: *;methods=''MESSAGE,SUBSCRIBE'' Content-Type: application/sdp Content-Length: XX message F2 is: SIP/2.0 183 Using Relay for Hearing Impaired... Please Wait Via: SIP/2.0/UDP a.example.com From: sip:caller@example.com To: sip:hiu@example.com;tag=9ajsd9aumlaa Call-ID: 9asdg9a7@1.2.3.4 CSeq: 1 INVITE van Wijk/Rosenberg/Gearhart/Sinnreich/Schulzrinne [Page 7 of 21] SIP for Hearing and Speech Impaired Customers July 2001 message F3 is: INVITE sip:speech2txt@example.com SIP/2.0 Via: SIP/2.0/UDP b.example.com From: sip:hiu@example.com To: sip:speech2txt@example.com Call-ID: 88725392k@4.3.2.1 CSeq: 7 INVITE Contact: sip:hiu@b.example.com Content-Type: application/sdp Content-Length: XX message F4 is: SIP/2.0 200 OK - translating Via: SIP/2.0/UDP b.example.com From: sip:hiu@example.com To: sip:speech2txt@example.com;tag=1238827819 Call-ID: 88725392k@4.3.2.1 CSeq: 7 INVITE Contact: sip:speech2txt@c.example.com Content-Type: application/sdp Content-Length: XX message F5 is: SIP/2.0 200 OK Via: SIP/2.0/UDP a.example.com From: sip:caller@example.com To: sip:hiu@example.com;tag=9ajsd9aumlaa Call-ID: 9asdg9a7@1.2.3.4 CSeq: 1 INVITE Content-Type: application/sdp Content-Length: XX | | | | F1: INVITE | | | ---------------------> | | | | | | F2: 183 | | | <--------------------- | | | | F3: INVITE | | | ----------------------> | | | | | | F4: 200 OK | | | <---------------------- | van Wijk/Rosenberg/Gearhart/Sinnreich/Schulzrinne [Page 8 of 21] SIP for Hearing and Speech Impaired Customers July 2001 | F5: 200 OK | | | <--------------------- | | | | | | | | | F6: ACK | | | ---------------------> | | | | F7: ACK | | | ----------------------> | | | | | | | | | | | | | | RTP (audio) | | | ===============================================> | | <===================== | | | | | | | | | | RTP (text) | | | <====================== | | | | | | | | | | | | | | | | | | | Caller Hearing Relay Impaired STT User Figure 2: One Way Translation Service message F6 and F7 are standard ACK messages, not shown. 6.3 One-way Speech-to-Sign-Language Translation Service The caller from a normal phone makes a call to a hearing impaired user who needs to communicate with Sign language. The hearing impaired user establishes a connection with a Relay service that will listen to speech and "convert" it to sign language. The sign language is sent to the hearing impaired used through a video stream. This service is accomplished identically to the one-way speech to text translation service. The call flow is the same as listed in Figure 2. The only difference is that the SDP that indicates text, will instead indicate video. The RTP stream marked as containing text, will instead contain video. And the Relay STT should be read as Relay Speech to Sign language (STS). 6.4 Two-way speech to text and text to speech with Relay service van Wijk/Rosenberg/Gearhart/Sinnreich/Schulzrinne [Page 9 of 21] SIP for Hearing and Speech Impaired Customers July 2001 The service in the previous section can be extended to include one relay for speech to text and another that does text to speech (where the text is typed by the user who is unable to communicate verbally). The text to speech translation can be done by a computer this is cheaper then using a human operator). If people are used to translate in both directions, these translators may be the same person, but they need not be. As mentioned in 6.2 this has an interesting effect of introducing some form of privacy. With two different translators, neither receives the complete conversation, and in all likelihood, would not be able to ascertain what is actually being talked about. But since Relay operators adhere to privacy and security rules as mentioned in 7, it is expected to be the same (human) operator. A call flow for this variant on the service is shown in Figure 3. Messages F1, F2, F3 and F4 are the same as above. F5 is a standard ACK. F6 is: INVITE sip:text2speech@example.com SIP/2.0 Via: SIP/2.0/UDP b.example.com From: sip:hiu@example.com To: sip:text2speech@example.com Call-ID: 87765448902@4.3.2.1 CSeq: 88 INVITE Contact: sip:hiu@b.example.com Content-Type: application/sdp Content-Length: XX and F7 looks like: SIP/2.0 200 OK Via: SIP/2.0/UDP b.example.com From: sip:hiu@example.com To: sip:text2speech@example.com;tag=9asdgnzli98a0 Call-ID: 87765448902@4.3.2.1 CSeq: 88 INVITE Contact: sip:text2speech@d.example.com Content-Type: application/sdp Content-Length: XX F8 is a standard ACK. F9 looks like F5 from the asymmetric version of the service. van Wijk/Rosenberg/Gearhart/Sinnreich/Schulzrinne [Page 10 of 21] SIP for Hearing and Speech Impaired Customers July 2001 | | | | | F1: INVITE | | | | ---------------------> | | | | | | | | F2: 183 | | | | <--------------------- | | | | | F3: INVITE | | | | --------------------> | | | | | | | | F4: 200 OK | | | | <-------------------- | | | | | | | | F5: ACK | | | | --------------------> | | | | | | | | F6: INVITE | | | | ----------------------------> | | | | | | | F7: 200 OK | | | | <---------------------------- | | | | | | | F8: ACK | | | | ---------------------------- >| | | | | | F9: 200 OK | | | | <--------------------- | | | | | | | | | | | | F10 ACK | | | | ---------------------> | | | | | RTP (speech) | | |===============================================>| | | |<======================| | | | RTP (text) | | | | | | | | | | | | RTP (text) | | | |==============================>| |<=======================================================| | RTP (Speech) | | | | | | | | | | | Caller Hearing STT TTS Impaired User Figure 3: Two-way speech to text and text to speech This approach has also the advantage that any application service provider can be used for these translation services. Different providers can be used for each direction, and these providers do not need to be affiliated in any way with the ISP providing IP van Wijk/Rosenberg/Gearhart/Sinnreich/Schulzrinne [Page 11 of 21] SIP for Hearing and Speech Impaired Customers July 2001 services for the hearing impaired user. This provides the potential for competition, and thus improved service. This approach also has the advantage of allowing one direction (speech to text), the other direction (text to speech), or both, to be performed by automated systems. For example, text to speech technology is fairly robust, and could be used in one direction, whereas a human operator could be used in the reverse (speech to text) direction, since speech recognition is not (yet) that robust. The call flow is completely identical, independently of whether the translation is done by human or machine. A machine would simply answer all calls to a specific address (sip:translator@asp.com), and echo the media (text or speech) back to the caller after conversion (conversion direction would be determined by the media capabilities indicated in the INVITE). In fact, there are other applications for such conversion systems. Providers could not only enable services for the hearing impaired, but other applications as well. Examples include voice browsing of the web, e-mail to speech readout over phones, and instant message to voicemail services. In fact, the opposite direction is quite likely - providers that perform these services can reuse their systems, without any work, to also provide services to the hearing impaired, as long as a relay service is reachable across the net. 6.5 Hearing Impaired Calling Party through Relay In this section, we consider a relay where the calling party is hearing impaired. This service works much like the one described above, relying on third party call control mechanisms. The hearing impaired caller sends an INVITE with SDP containing no codecs, targeted for the called party. If the called party accepts, the caller launches an INVITE to one or two Relay services (depending on whether the hearing impaired caller is able to communicate verbally or not). The INVITE to speech to text translation service contains SDP where the caller would like to receive the text; the response contains SDP that the caller places in the ACK to the called party. This connects the called party with the speech to text translator, with the resultant text being sent to the caller. If text to speech service is also needed, the caller places the SDP it received in the 200 OK from the called party into an INVITE to the translator. The response contains SDP with an address where the caller can send text. Figure 4 shows a call flow using only speech to text translation services. | | | | F1: INVITE no SDP | | | --------------------> | | | | | | F2: 200 OK SDP1 | | | <-------------------- | | van Wijk/Rosenberg/Gearhart/Sinnreich/Schulzrinne [Page 12 of 21] SIP for Hearing and Speech Impaired Customers July 2001 | | | | | | | F3: INVITE | | | ----------------------------------------------> | | | | | | F4: 200 OK SDP2 | | <---------------------------------------------- | | | | | F5: ACK | | | ----------------------------------------------> | | | | | | | | F6: ACK SDP2 | | | --------------------> | | | | | | | | | RTP (speech) | | |======================>| RTP (speech) | | |========================>| |<================================================| | RTP (text) | | | | | | | | | | | | | | | | | | | | Hearing Called Speech to Impaired Party Text(STT)Relay Caller Figure 4: Hearing Impaired Caller Call Flow 7. General Requirements It is desired among the hearing impaired user community that a relay service to automatically be enabled depending on the pre-set user preferences. This enables avoiding the inconvenience of current relay services that requires a caller to call the relay service first and then having the relay call the called party. The above described call flows are only to illustrate the possibilities and are not considered final call flow designs. It may be a good idea work out the call flows for Relays calls, so that any IP relay service such as 3G wireless can expect the pre- defined scenarios. To aid the design of those scenarios, we could identify a number of general requirements that relay service providers and terminal manufacturers SHOULD adhere to. Keep also in mind that in some countries, relay services are NOT for free as in other. Another problem in some countries is that the availability of relay centers is severely limited. This will be reflected in some of the requirements. van Wijk/Rosenberg/Gearhart/Sinnreich/Schulzrinne [Page 13 of 21] SIP for Hearing and Speech Impaired Customers July 2001 The relay enabled terminal (from now on just named terminal) MUST be able to place calls transparently, the hearing impaired user does not have to call the relay center first and then tell the phone number to the operator who to call. It SHOULD be done automatically. The terminal will connect to the relay center and call the called party automatically. Very useful for ordering Pizza via the telephone for example. Placing a call should be as easy and comfortable for any user, including hearing and speech impaired users. The Relay Service providers and terminals MUST be able to interwork with each other regardless the Relay Service provider or the manufacturer of the (Relay enabled) terminal. This also means that when a hearing impaired user from the Netherlands calls a user located in the United States, that a Dutch Relay Provider or an American Relay Provider CAN be used without any problem during the call. This also means that modern terminals SHOULD be able to support the legacy relay protocols during the first years until all users have switched over to IP SIP based relay services. The terminal MUST be able to receive relay calls any time and from any location. This capability is already included in SIP. The user preferences in the REGISTER will indicate what relay requirements are desired (at minimum text support MUST be supported). Upon logging in, the terminal SHOULD be able to automatically download all user settings. The terminal MUST be able to activate the Relay service ANYTIME during a call without interrupting the call. It MUST also be possible to disable the relay service during the call. The terminal MUST be able to set up user preferences easily to specify language, mode of relay (such as: SL/video to/from speech, text to/from video or speech, also as an extended service English to i.e. Spanish text, relay can cross language barriers if supported). This is pre-set, but it can be overruled by one button or via a short list with alternative options. The terminal and relay service provider SHOULD be able to enable/deliver services like a "real-time closed captioning" where the terminal receives the video/audio of a caller/called, but the relay center will translate the audio and display the text as subtitles. This will also offer possibilities like commercial translation service (via voice-over or text). The terminal MUST be able to receive the correct Caller-ID of the caller that calls the hearing impaired user via the relay, and not the relay's Caller-ID (note: this is the caller ID and not the SIP Call-ID). The terminal MUST be able to specify which pre-defined numbers require the use of relay service and which are direct calls (TTY to TTY for text, video to video for sign language) and do not require relay. van Wijk/Rosenberg/Gearhart/Sinnreich/Schulzrinne [Page 14 of 21] SIP for Hearing and Speech Impaired Customers July 2001 The terminal MUST be able to download and upload the user settings and the address book, which should be stored as a database file at a centrally located server, which can be the relay service provider or the home provider of the user. It SHOULD be possible for a user to store user preferences and settings on a web service, similar to the "My Yahoo" type service, to allow the user access to his/her personal profile and services from any web-enabled device. In case of a mobile terminal user; the above described requirement SHOULD also be available via a wireless web service, where available. The terminal SHOULD be able to poll for the nearest Relay Proxy to reduce data traffic and reduce the cost of network usage. Also the terminal MUST be able to change relay service providers at any time (preferably via a menu with the relay service providers listed). The terminal SHOULD be able to use the relay service provider list to sequence the relay service providers in a preferred position: which to use first for outgoing calls and automatically move on to the next in the list if it is busy or does not support the required services. Relay service providers SHOULD be able to advertise the services they have and update for new services, perhaps via a central (voluntary) registration or via dialing into an info number. The terminal should be able to dial automatically to such info numbers or via the SIP INFO method. This would stimulate competition between relay service providers, which will lead to lower service prices and/or more different kind of services. Relay service providers SHOULD be able to act as an answering machine and provide (unified) message services. The terminal SHOULD have the capability to retrieve messages (answering machine mode). The terminal SHOULD have a pre-configurable setting that automatically connects a calling party to the relay service provider for answering machine service when the user does not want to receive incoming calls. This happens transparently without extra handling of the call (assumed that the called user is subscribed to such a service). Voice messages left for the hearing impaired user MUST be interpreted at the relay service provider into the format designated by the user (email, IM, video clip, etc.) and transmitted to the hearing impaired userÆs terminal on demand or when the terminal registers. Note: This "answering service" would also be a possible commercial service for hearing users. If a third party unified messaging service is used by the hearing impaired user; a specific relay service provider SHOULD be able to be authorized to access the unified message box and translate all van Wijk/Rosenberg/Gearhart/Sinnreich/Schulzrinne [Page 15 of 21] SIP for Hearing and Speech Impaired Customers July 2001 audio messages into a pre-selected form. For example voice to text (for fax or e-mail or IM) or voice to video for sign language. The terminal MUST be able to distinguish non-relay calls from relay calls and direct TTY calls, if this number is NOT listed in the address book (which stores the number and options for direct terminal to terminal calls such as TTY to TTY, which do not require a relay). A message will be sent to the originator of the call (183 Hearing impaired user RELAY call only). Depending on technological advances and the user's preferences, instead of the terminal returning a 183 message, the terminal MAY connect to the relay service provider and accept the call as if there is NO relay service provider in between. The Relay Service provider SHOULD be able to offer the STEALTH mode; invisible relay services for the hearing impaired caller, in this way the user can conceal his/her hearing impairment). This may be seen as a separate service and possibly charged extra due the speed of accepting the call (minimal delay on picking-up) and extra effort to be invisible to the caller. Special hardware and software may be required for computer run speech to text conversion (this may require specialized relay service providers). Note: this service can be used selectively for certain callers, and other callers are just notified by the 183 message. The terminal and the Relay Service Provider MUST be able to allow calls to be placed anonymously, so that the called user cannot see who is calling. The Relay Service provider MUST in this case keep the identity of the calling user confidential as described in 7. When starting a relay session; the Relay Service Provider MUST show the charges of the relaying service per minute. The user MUST be able to refuse the service if the charges are too high or opt for a cheaper service (use text instead of the video). An independent payment service provider SHOULD be used, so that any relay service provider is assured of payment of the charges. This requires that the hearing impaired users use some form of subscription for relay services that require extra features. This leaves room for subsidizing the hearing impaired users, for example a monthly pre-paid amount will be deposited to the relay account. If a user uses more then the pre-paid amount, the user will be billed for the additional charges. Wireless telephony systems (GSM, UMTS, CDMA2000, cellular systems etc) MUST enable the wireless phones to connect to relay service providers. This can be done directly via wireless IP connections OR via a special relay node. This node MUST be able to translate circuit switched (GSM, etc) relay into IP relay. The Relay Service provider MAY also offer remote interpreting, the terminal MAY be modified to enabled this service. This is van Wijk/Rosenberg/Gearhart/Sinnreich/Schulzrinne [Page 16 of 21] SIP for Hearing and Speech Impaired Customers July 2001 desirable in countries experiencing a shortage of Interpreters. And there are many situations where it just requires a short time of interpreting. 7. Security Considerations Because an interpreter is generally required when a hearing impaired individual has a conversation with a hearing individual, whether in person or using a medium such as the telephone, interpreters are privy to a great deal of private information. For this reason, both the Deaf and interpreter communities are vitally interested in the ethics and professionalism of the interpreter. For example, interpreters in the United States that are certified by the organizations recognized by the American Deaf Community, such as the National Association of the Deaf (NAD[16]) and the Registry of Interpreters for the Deaf (RID[17]), are required as part of their certification to support the Codes of Ethics of their organizations. Other countries may also have pertinent legislation. Hence these requirements: All relay operators and other interpreters or organizations involved in relaying calls SHALL be required to subscribe to a generally accepted Code of Ethics for interpreters. As an example, the Code of Ethics required for membership in RID is as follows: The Registry of Interpreters for the Deaf, Inc. has set forth the following principles of ethical behavior to protect and guide interpreters and transliterators and hearing and deaf consumers. Underlying these principles is the desire to insure for all the right to communicate. This Code of Ethics applies to all members of the Registry of Interpreters for the Deaf, Inc. and to all certified non-members. Interpreters/transliterators shall keep all assignment-related information strictly confidential. Interpreters/transliterators shall render the message faithfully, always conveying the content and spirit of the speaker using language most readily understood by the person(s) whom they serve. Interpreters/transliterators shall not counsel, advise or interject personal opinions. Interpreters/transliterators shall accept assignments using discretion with regard to skill, setting, and the consumers involved. Interpreters/transliterators shall request compensation for services in a professional and judicious manner. van Wijk/Rosenberg/Gearhart/Sinnreich/Schulzrinne [Page 17 of 21] SIP for Hearing and Speech Impaired Customers July 2001 Interpreters/transliterators shall function in a manner appropriate to the situation. Interpreters/transliterators shall strive to further knowledge and skills through participation in workshops, professional meetings, interaction with professional colleagues, and reading of current literature in the field. Interpreters/transliterators, by virtue of membership or certification by the RID, Inc., shall strive to maintain high professional standards in compliance with the Code of Ethics. This Code of Ethics is widely accepted and supported as a standard within the American Deaf community and the American community of interpreters. More information on RID can be found from the organizationÆs web site, see reference [16]. In addition to the standards required for individual relay operators, interpreters, and companies that provide relay services, the actual transmissions MUST be secured. An extension to the requirement for "STEALTH": relay operators/interpreters MAY act on behalf of the user, at the request of the user. For example, the user can ask the operator to call a company to file a complaint. This requires confidentially and an extension to the usual role of an interpreter. 9. References and Footnotes [1] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP: session initiation protocol," Request for Comments 2543, Internet Engineering Task Force, Mar. 1999. [2] M. Handley and V. Jacobson. "SDP: Session Description Protocol." Request for Comments 2327, Internet Engineering Task Force,April 1998. [3] H. Schulzrinne and J. Rosenberg, "SIP caller preferences and callee capabilities," Internet Draft, Internet Engineering Task Force, June 2001. Work in progress. [4] J. Rosenberg, H. Schulzrinne, J. Peterson and G. Camarillo, "Third party call control in SIP," Internet Draft, Internet Engineering Task Force, Mar. 2001. Work in progress. [5] G. Hellstrom, "RTP payload for text conversation," Request for Comments 2793, Internet Engineering Task Force, May 2000. [6] J. Rosenberg, H. Schulzrinne and H. Sinnreich, "SIP Enabled Services to Support the Hearing Impaired" Internet Draft, Internet Engineering Task Force, July 2000. Work in progress. van Wijk/Rosenberg/Gearhart/Sinnreich/Schulzrinne [Page 18 of 21] SIP for Hearing and Speech Impaired Customers July 2001 [7] C. Gearhart, A. Van Wijk and H. Sinnreich, "A Proposed Set of requirements for SIP Support for Deaf or Speech Impaired Customers" Internet Draft, Internet Engineering Task Force, November 2000. Work in progress. [8] S. Bradner, "Key words for use in RFCs to indicate requirement levels". Request for Comments 2119, Internet Engineering Task Force. March 1997. [9] TTY: an acronym for a text telephone device used by Deaf individuals to communicate via telephone systems; commonly referred to as a TDD by the hearing community. [10] Bradner, S., "The Internet Standards Process -- Revision 3", BCP9, RFC 2026, October 1996. [11] Baker, Charlotte, and Robbin Battison. "Sign Language and the Deaf Community: Essays in Honor of William Stokoe". National Association of the Deaf, June 1980. [12] Moore, Matthew, et al. "For Hearing People Only: Answers to Some of the Most Commonly Asked Questions About the Deaf Community, Its Culture, and the Deaf Reality". MSM Productions Ltd., 2nd Edition, September 1993. [13] Padden, Carol, and Tom Humphries. "Deaf in America: Voices from a Culture". Harvard University Press, Reprint September 1990. [14] Stokoe, William. "Sign and Culture: A Reader for Students of American Sign Language". Linstok Press, June 1980. [15] J. Rosenberg, R. Sparks, D. Willis, B. Campbell, H. Schulzrinne, J. Lennox, C. Huitema, B. Aboba, D. Gurle and D. Oran, "SIP extensions for instant messaging," Internet Draft, Internet Engineering Task Force, April 2001. Work in progress. [16] National Association of the Deaf. A national organization of, for, and operated by Americans who are Deaf or deaf. Organized in 1880, it is "the oldest and largest organization representing people with disabilities in the United States. The NAD safeguards the accessibility and civil rights of 28 million deaf and hard of hearing Americans in a variety of areas including education, employment, health care and social services, and telecommunications. A private, non-profit 501(c)(3) organization, the NAD is a dynamic federation of 51 state association affiliates, sponsoring and organizational affiliates, and direct members." See "www.nad.org" for more information on this organization. [17] Registry of Interpreters for the Deaf (RID). A national, professional organization of interpreters and transliterators for the Deaf in America. "The philosophy of RID is that excellence in the delivery of interpretation and transliteration services among van Wijk/Rosenberg/Gearhart/Sinnreich/Schulzrinne [Page 19 of 21] SIP for Hearing and Speech Impaired Customers July 2001 people who are Deaf, or Hard of Hearing, and people who are hearing, will ensure effective communication. As the professional association for interpreters and transliterators, the RID serves as an essential arena for its members in their pursuit of excellence. It is the mission of the Registry of Interpreters for the Deaf, Inc., to provide international, national, regional, state, and local forums and an organizational structure for the continued growth and development of the professions of interpretation and transliteration of American Sign Language and English." See "www.rid.org" for detailed information on this organization. 10 Acknowledgments The authors would like to thank the following deaf individuals, professional interpreters, and others who have contributed to the development of this document: Vint Cerf/WCOM. Teresa Hastings/WCOM. Charles Estes/WCOM. Helene Cohen-Gilbert, Coordinator, Collin County Community College, Texas, USA, Interpreter Preparation Program û Deaf. Nathan Charlton, Royal National Institute for Deaf People (RNID), London, United Kindom. Grant Laird. Brenden Gilbert. 11. Author's Addresses Arnoud van Wijk Ericsson EuroLab Netherlands BV P.O. Box 8 5120 AA Rijen The Netherlands Fax: +31-161-247569 email: Arnoud.van.Wijk@eln.ericsson.se Jonathan Rosenberg Dynamicsoft 72 Eagle Rock Avenue First Floor East Hanover, NJ 07936 email: jdrosen@dynamicsoft.com Cathy Gearhart Ericsson, Inc. P.O. Box 833675, M/S L-04 Richardson, TX 75083-3875 email: cathy.gearhart@ericsson.com Henry Sinnreich Worldcom 400 International Parkway van Wijk/Rosenberg/Gearhart/Sinnreich/Schulzrinne [Page 20 of 21] SIP for Hearing and Speech Impaired Customers July 2001 Richardson, Texas 75081 email: henry.sinnreich@wcom.com Henning Schulzrinne Columbia University M/S 0401 1214 Amsterdam Ave. New York, NY 10027-7003 email: schulzrinne@cs.columbia.edu Full Copyright Statement "Copyright (C) The Internet Society 2001. All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implmentation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. van Wijk/Rosenberg/Gearhart/Sinnreich/Schulzrinne [Page 21 of 21]