Internet DRAFT - draft-hellstrom-txtgwy
draft-hellstrom-txtgwy
Network Working Group G. Hellstrom
Internet-Draft Omnitor
Intended status: BCP B. Dingle
Expires: September 7, 2010
A. van Wijk
Real-Time Text Taskforce (R3TF)
G. Gybels
RNID, Department of New
Technologies
March 8, 2010
Real-time text interworking between PSTN and IP networks
draft-hellstrom-txtgwy-02
Abstract
IP networks can support real-time text communication. SIP-based
real- time text is called Text-over-IP or ToIP. PSTN networks
support real-time text using textphones (or TTYs). When real-time
text is supported by different networks, gateways are needed to
provide interoperability. Real-time text capable gateways may also
support real-time voice.
This specification describes procedures for interworking between ToIP
and PSTN textphones using a real-time text capable gateway (RTT
gateway). It also describes ways to route calls to RTT gateways for
several call scenarios.
Procedures that support the phased introduction of RTT gateways and
procedures that support the invocation of text channels at any time
during the call are included. Interworking of PSTN textphones that
do not support simultaneity of voice and text with IP User Agents
that support simultaneous voice and text is also described.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
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
Hellstrom, et al. Expires September 7, 2010 [Page 1]
Internet-Draft Real-time text in SIP gateway calls March 2010
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.
This Internet-Draft will expire on September 7, 2010.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.
Hellstrom, et al. Expires September 7, 2010 [Page 2]
Internet-Draft Real-time text in SIP gateway calls March 2010
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5
3. Functional goals of the procedures . . . . . . . . . . . . . . 5
4. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Locating RTT gateways . . . . . . . . . . . . . . . . . . . . 5
5.1. Types of RTT gateways . . . . . . . . . . . . . . . . . . 5
5.2. Locating a gateway . . . . . . . . . . . . . . . . . . . . 6
5.2.1. From the IP side . . . . . . . . . . . . . . . . . . . 6
5.2.2. From the PSTN side . . . . . . . . . . . . . . . . . . 6
6. SIP Call control . . . . . . . . . . . . . . . . . . . . . . . 7
6.1. SIP and SDP text indicators . . . . . . . . . . . . . . . 7
6.2. SIP/SDP Call procedures . . . . . . . . . . . . . . . . . 8
6.2.1. Calls from the PSTN . . . . . . . . . . . . . . . . . 8
6.2.2. Call from a ToIP User Agent . . . . . . . . . . . . . 10
6.3. Procedure for RFC 4103 and other real-time text
transports . . . . . . . . . . . . . . . . . . . . . . . . 12
7. Text medium interworking . . . . . . . . . . . . . . . . . . . 12
7.1. Handling of alternating text and audio . . . . . . . . . . 13
7.1.1. Non-continuous carrier PSTN textphones . . . . . . . . 14
7.1.2. Continuous-carrier PSTN textphones . . . . . . . . . . 14
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
9. Security Considerations . . . . . . . . . . . . . . . . . . . 14
10. Normative References . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
Hellstrom, et al. Expires September 7, 2010 [Page 3]
Internet-Draft Real-time text in SIP gateway calls March 2010
1. Introduction
Real-time text can be a component in IP multimedia telephony and
total conversation. Real-time text can be transported in IP networks
using standard IP protocols and be used as a medium in a
conversational service. IP devices such as multimedia telephones,
voicemail systems, IP phones, IVR systems or other devices, may
support the transmission of real-time text over IP networks. An IP
User Agent that supports real-time text over IP is called a ToIP User
Agent. A ToIP User Agent may also support text and voice.
The control of IP real-time text calls is defined in SIP RFC 3261
[RFC3261] and SDP RFC 4566 [RFC4566]. RFC 4103 [RFC4103] specifies
the carriage of real-time text in RTP packets between ToIP devices in
IP networks. RFC 5194 [RFC5194] describes the implementation aspects
of ToIP using SIP.
PSTN networks can support the transport of real-time text by
representing the text as audio. PSTN textphones (or TTYs) use modem
technology to carry the text encoded as tones. Some PSTN textphones
can support the transport of both voice and real-time text, but
usually not both at the same time. Some PSTN textphone protocols do
not include signalling to indicate whether or not the device is in
text or voice mode and therefore it is unclear if the audio signal is
to be treated as text or as voice.
Interworking between the different forms of real-time text transport
and the different call control protocols requires a real-time text
capable gateway (RTT gateway). It supports ToIP (and possibly VoIP)
protocols on the IP side and textphone protocols on the PSTN side.
PSTN textphones and multimedia IP User Agents usually support the
transport of both voice and real-time text. For calls that support
both voice and text media, the gateway needs to consider the lack of
media simultaneity imposed by some PSTN textphone protocols and
include procedures to support medium interworking.
The case where ToIP support is not provided at all PSTN/IP gateways
that could be selected to convey the call is also considered. It
requires specific routing actions for calls that may contain text.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Hellstrom, et al. Expires September 7, 2010 [Page 4]
Internet-Draft Real-time text in SIP gateway calls March 2010
2.1. Abbreviations
RTT real-time text
ToIP text over IP
PSTN public switched telephone network
2.2. Definitions
TTY: term used in some countries for PSTN textphone.
3. Functional goals of the procedures
The procedures described in this specification are designed to meet
the following functional requirements.
o The real-time text transport in the IP network shall use ToIP as
specified by RFC 5194 [RFC5194].
o The text medium shall be able to be established at any time during
the call for gateways that support text and voice.
o The voice medium shall be able to be established at any time
during the call for gateways that support text and voice.
4. Scope
This specification describes the procedures for call routing, call
control and media transport of real-time text calls between Text-
over- IP (ToIP) User Agents and PSTN textphones (or TTYs) using real-
time text capable (RTT) gateways. It specifies how to discover the
RTT gateways from the PSTN and IP sides and how to invoke the text
capability in them. It also specifies how to control media
interaction between PSTN and IP for calls that involve both real-time
text and voice.
5. Locating RTT gateways
5.1. Types of RTT gateways
Text capable gateways can be located in at least the following
distinctively different locations:
1. a residential text capable gateway with PSTN terminals directly
connected to it
Hellstrom, et al. Expires September 7, 2010 [Page 5]
Internet-Draft Real-time text in SIP gateway calls March 2010
2. a network text capable gateway that has PSTN technology on one
side and IP technology on the other
3. a network text capable gateway that is in the IP network that has
text transported to it from the PSTN that is still in audio
(modem tones) format but carried by IP transport (e.g. G.711
[RFC3551] A-law encoded audio) and with high QoS.
5.2. Locating a gateway
5.2.1. From the IP side
A call to a PSTN number will require the use of a gateway. If not
all PSTN/IP gateways are text capable, then some means of routing to
a RTT gateway is required. The methods resulting in one step calling
should be preferred. The following mechanisms are possible:
Option 1: Indications are used in the SIP header to indicate that
text capability may be required. RFC 3840 [RFC3840] and RFC 3841
[RFC3841] provide a means of doing that.
Option 2: ENUM RFC 3761 [RFC3761] procedures may be used to identify
and route to RTT gateways.
Option 3: Addressing is used consisting of the PSTN number as the
user name and the RTT gateway as the SIP domain address on the form
number@gateway_domain.
Option 4: Dial a special RTT gateway address. The gateway answers in
text mode. Then enter the destination number when requested by the
RTT gateway using text.
5.2.2. From the PSTN side
If a PSTN textphone is not directly connected to a RTT gateway or if
not all PSTN/IP gateways that are candidates for handling the call
are text capable, then some means of routing to a RTT gateway is
required. Most PSTN textphone calls appear as ordinary audio
telephone calls and do not provide an indication that a call could
involve text. A means of indicating the possible need to support
real-time text to the PSTN routing procedures is required. Several
options are available, the ones resulting in a one-step procedure
should be preferred
Option 1 - Use a prefix to destination number (e.g. 18001 +
'destination number')
Option 2 - Dial a special RTT gateway address. The gateway answers
in text mode. Then enter the destination number or address when
Hellstrom, et al. Expires September 7, 2010 [Page 6]
Internet-Draft Real-time text in SIP gateway calls March 2010
requested by the RTT gateway using text.
Option 3 - A PSTN line marking of 'text' that is carried by the
signalling
Option 4 - The call routing made after number analysis that results
in that a call to a real-time text user is routed through the text
gateway located in the IP network.
Option 5 - The destination SIP subscriber has an indication on SIP
registration level or call control level that text support is
required.
6. SIP Call control
6.1. SIP and SDP text indicators
SIP User Agents and RTT gateways SHALL announce support for real-time
text in the Contact field according to RFC 3840 [RFC3840] by sending
the following in an INVITE:
Contact: <uri>;text
A calling ToIP User Agent that does not want to give priority to text
can indicate an interest to use text according to RFC 3841 [RFC3841]
by sending the following in a Response to an INVITE:
Accept-Contact: *;text
A calling ToIP User Agent should indicate priority to establishing a
text connection according to RFC 3841 [RFC3841] by sending the
following in a Response to an INVITE:
Accept-Contact: *;text;require
PSTN textphones can support alternating text and audio during the
call. If this capability is known, the RTT gateway can indicate it
according to RFC 3840 [RFC3840] by sending an indication in the call
setup as specified in draft-hellstrom-text-turntaking
[I-D.hellstrom-text-turntaking].
This indication will allow ToIP User Agents to inform users of the
need to communicate in a turn-taking manner.
Hellstrom, et al. Expires September 7, 2010 [Page 7]
Internet-Draft Real-time text in SIP gateway calls March 2010
6.2. SIP/SDP Call procedures
The decision to include text when offering the call may be because:
a. textphone tones have already been detected by the gateway on the
PSTN line.
b. the gateway may be configured to be a dedicated RTT gateway.
c. it is known by subscription or other external means that the PSTN
user has preference for text
d. it is simpler to offer text initially.
Note - the examples below do not include all SIP and SDP fields.
They concentrate on the fields needed for ToIP operation and VoIP
operation (if required).
The audio medium description in the examples assumes ITU-T G.711
A-law encoding.
6.2.1. Calls from the PSTN
6.2.1.1. Text-only call
When a RTT gateway has information that indicates that only a text
medium is required, it SHALL include specifications in line with this
example in an INVITE:
Contact: <sip:gw-uri>;text
...
m=text 7202 RTP/AVP 99 98
a=rtpmap:98 t140/1000
a=rtpmap:99 red/1000
a=fmtp:99 98/98/98
The answering ToIP User Agent SHALL accept the text medium by
including specifications according to this example in its Response:
Contact: <sip:term-uri>;text
...
m=text 7202 RTP/AVP 99 98
a=rtpmap:98 t140/1000
a=rtpmap:99 red/1000
a=fmtp:99 98/98/98
Hellstrom, et al. Expires September 7, 2010 [Page 8]
Internet-Draft Real-time text in SIP gateway calls March 2010
6.2.1.2. Call with text and voice
If the RTT gateway has an indication that voice and text media are
required in the call, it SHALL include a media line for audio and a
media line for text in an INVITE in line with the following example:
Accept-Contact: *;text;require
Contact: <sip:gw-uri>;text
...
m=audio 7200 RTP/AVP 0
m=text 7202 RTP/AVP 99 98
a=rtpmap:98 t140/1000
a=rtpmap:99 red/1000
a=fmtp:99 98/98/98
The answering ToIP device can accept the audio and the text media by
sending the following in the Response:
Contact: <sip:term-uri>;text
...
m=audio 7200 RTP/AVP 0
m=text 7202 RTP/AVP 99 98
a=rtpmap:98 t140/1000
a=rtpmap:99 red/1000
a=fmtp:99 98/98/98
6.2.1.3. Voice call with text added later
A RTT gateway that wishes to establish an audio medium and indicate
support for text but does not wish to establish a text medium
immediately e.g. in order to avoid spending resources for text
transport on calls that do not carry text at all, SHOULD send an
INVITE with contents in line with the following example:
Contact: <sip:gw-uri>;text
....
m=audio 7200 RTP/AVP 0
The answering ToIP device can indicate text support and accept the
audio medium by including lines in line with the following example in
the Response to the INVITE:
Contact: <sip:term-uri>;text
.....
m=audio 7200 RTP/AVP 0
Then the text medium can be added later in the call.
Hellstrom, et al. Expires September 7, 2010 [Page 9]
Internet-Draft Real-time text in SIP gateway calls March 2010
6.2.2. Call from a ToIP User Agent
6.2.2.1. Text-only call
A calling ToIP User Agent can indicate that a text medium is required
in the call by sending an INVITE based on the following example:
Contact: <sip:term-uri>;text
Accept-Contact: *;text;require
...
m=text 7202 RTP/AVP 99 98
a=rtpmap:98 t140/1000
a=fmtp:98 cps=20
a=rtpmap:99 red/1000
a=fmtp:99 98/98/98
The network will route the call to a RTT gateway if the destination
address is in the PSTN and the Contact indicates 'text'. The RTT
gateway should then commence call establishment procedures on the
PSTN side.
The RTT gateway can accept the text request by sending the following
in the Response:
Contact: <sip:gw-uri>;text
....
m=text 7202 RTP/AVP 99 98
a=rtpmap:98 t140/1000
a=fmtp:98 cps=20
a=rtpmap:99 red/1000
a=fmtp:99 98/98/98
6.2.2.2. Text and voice call
A calling ToIP User Agent can request a text medium and a voice
medium in a call by including a media line for audio and a media line
for text in an INVITE as follows:
Contact: <sip:term-uri>;text
Accept-Contact: *;text;require
...
m=audio 7200 RTP/AVP 0
m=text 7202 RTP/AVP 99 98
a=rtpmap:98 t140/1000
a=fmtp:98 cps=20
a=rtpmap:99 red/1000
a=fmtp:99 98/98/98
The network will route the call to a RTT gateway if the destination
Hellstrom, et al. Expires September 7, 2010 [Page 10]
Internet-Draft Real-time text in SIP gateway calls March 2010
address is in the PSTN.
The answering RTT gateway can accept the text medium and the audio
medium by sending the following in the Response:
Contact: <sip:gw-uri>;text
Accept-Contact: *;text;require
...
m=audio 7200 RTP/AVP 0
m=text 7202 RTP/AVP 99 98
a=rtpmap:98 t140/1000
a=rtpmap:99 red/1000
a=fmtp:99 98/98/98
6.2.2.3. Voice call with text added later
If a calling ToIP device user is not depending on text, but wants to
have it available for occasional use, the INVITE that is sent could
include the following:
Contact: <sip:term-uri>;text
Accept-Contact: *;text
...
m=audio 7200 RTP/AVP 0
m=text 7202 RTP/AVP 99 98
a=rtpmap:98 t140/1000
a=fmtp:98 cps=20
a=rtpmap:99 red/1000
a=fmtp:99 98/98/98
The RTT gateway may decide to not establish the text channel
initially, but should indicate its text capability in the Contact
header of the Response as follows:
Contact: <gwy-uri>;text
Accept-Contact: *;text
....
m=audio 7200 RTP/AVP 0
m=text 0 RTP/AVP 99 98
During a call, if either party starts text activity, a text channel
can be added to the session by sending a re-Invite according to RFC
3261 [RFC3261]. This procedure can be executed even if no text
capability was expressed from the ToIP User Agent initially. A re-
INVITE from the gateway could include the following:
Hellstrom, et al. Expires September 7, 2010 [Page 11]
Internet-Draft Real-time text in SIP gateway calls March 2010
Contact: <uri>;text
...
m=audio 7200 RTP/AVP 0
m=text 7202 RTP/AVP 99 98
a=rtpmap:98 t140/1000
a=fmtp:98 cps=20
a=rtpmap:99 red/1000
a=fmtp:99 98/98/98
The receiving device should answer with a Response that includes the
following:
Contact: <uri>;text
...
m=audio 7200 RTP/AVP 0
m=text 7202 RTP/AVP 99 98
a=rtpmap:98 t140/1000
a=fmtp:98 cps=20
a=rtpmap:99 red/1000
a=fmtp:99 98/98/98
6.3. Procedure for RFC 4103 and other real-time text transports
In the case where a User Agent implements both RFC 4103 [RFC4103] and
other codecs for text transport, the procedures in this specification
can be complemented with the other transport establishment. When
establishing a call, a ToIP device may advertise support for real-
time text in accordance with other transport methods, and for real-
time Text over IP according to the procedures described above.
The capabilities of the other party in the call setup will lead to
the establishment of text transport according to either RFC 4103
[RFC4103] or the other transport method, or both.
7. Text medium interworking
Many PSTN textphones can support both voice and text on the one
analog 'voice' channel. The voice and the text make use of the
channel in an alternating fashion. This direction dependence is
however a usage convention, while the transmission can be made in
either direction. In most cases, voice is used in one direction and
text in the other direction, for example a hearing impaired user
talks to an relay operator, who then replies in text.
ITU-T V.18 V.18 [V.18] specifies a range of PSTN textphone protocols
that could be supported. On the IP side, text and voice are carried
in separate text and voice media.
Hellstrom, et al. Expires September 7, 2010 [Page 12]
Internet-Draft Real-time text in SIP gateway calls March 2010
The RTT gateway must be able to:
a) indicate to the ToIP User Agent if the PSTN textphone operates in
an alternating text and voice mode so that the IP User can be
informed and communicate appropriately, and
b) indicate to the ToIP User Agent if turntaking of text in one
direction and text in the other direction is required by the PSTN
textphone. The RTT gateway shall decode the characters received and
transmit them to the ToIP User Agent.
Determining the type of PSTN textphone device in use is the
responsibility of the RTT gateway. The ToIP User Agent need not
concern itself with what kind of PSTN textphone device is connected
to the RTT gateway.
When the ToIP User Agent first has characters to send to the RTT
gateway the ToIP device shall open the text channel if it was not
opened before. The ToIP device shall then transmit the characters to
the RTT gateway. The RTT gateway shall perform any required
signaling on the PSTN termination if the type of PSTN textphone s
needed to be known by the RTT gateway. While connecting, the RTT
gateway shall buffer any characters received from the ToIP User Agent
and transmit them when the RTT gateway has connected to the PSTN
textphone. The size of the character buffer should be sufficient to
hold the characters that may come from one side in a connection
before a response is expected.
If the RTT gateway does not support the modulation used by the PSTN
textphone device, the RTT gateway may:
a) transmit the received textphone signals via Voiceband Data (VBD)
or the audio stream, depending on the capabilities of the ToIP User
Agent.
b) discard characters received from the ToIP User Agent.
c) transmit the received characters to the PSTN textphone based on a
pre-provisioned indication of the modulation.
7.1. Handling of alternating text and audio
Many PSTN textphones support alternating voice and real-time text.
Some PSTN textphones can only handle text transmission in one
direction at a time. Most ToIP User Agents can send text and voice
simultaneously and in both directions at the same time. When
bridging between these two environments, turn-taking schemes must be
introduced both by the human users and by the RTT gateways. The
Hellstrom, et al. Expires September 7, 2010 [Page 13]
Internet-Draft Real-time text in SIP gateway calls March 2010
following procedures should be applied:
7.1.1. Non-continuous carrier PSTN textphones
For these PSTN textphones, audio is transmitted through the RTT
gateway between the PSTN circuit and the audio stream of the ToIP
User Agent. This is done as long as there is no text to transmit or
receive on the PSTN side. Text transmission and reception has
priority over audio transmission.
7.1.2. Continuous-carrier PSTN textphones
For these PSTN textphones, the recommended procedure is:
As long as carrier is maintained from the PSTN textphone, it is
maintained from the RTT gateway, and text transmission can occur. If
carrier is dropped from the PSTN textphone, the RTT gateway shall
transmit any remaining characters to the PSTN textphone and then drop
the carrier and transmit audio.
When carrier is received again from the PSTN textphone and if text is
to be transmitted to the PSTN textphone, carrier transmission will be
resumed from the gateway and text may be transmitted.
If, during a period of audio transmission, text is received from the
ToIP device, then audio transmission will be interrupted, carrier re-
established and the text transmitted.
If, during a period of carrier or text transmission, the Interrupt
command (INT) is received in the T.140 [T.140] stream from the ToIP
User Agent, the carrier should be dropped and transmission of audio
through the gateway established. In most cases the control of the
carrier can be left to the PSTN textphone user.
8. IANA Considerations
TBD.
9. Security Considerations
TBD
10. Normative References
[T.140] ITU-T, "Recommendation T.140, Protocol for Multimedia
Hellstrom, et al. Expires September 7, 2010 [Page 14]
Internet-Draft Real-time text in SIP gateway calls March 2010
Application Text Conversation and Addendum 1",
February 2000.
[V.18] ITU-T, "Operational and interworking requirements for DCEs
operating in the text telephone mode", November 2000.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and
Video Conferences with Minimal Control", STD 65, RFC 3551,
July 2003.
[RFC3761] Faltstrom, P. and M. Mealling, "The E.164 to Uniform
Resource Identifiers (URI) Dynamic Delegation Discovery
System (DDDS) Application (ENUM)", RFC 3761, April 2004.
[RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat,
"Indicating User Agent Capabilities in the Session
Initiation Protocol (SIP)", RFC 3840, August 2004.
[RFC3841] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller
Preferences for the Session Initiation Protocol (SIP)",
RFC 3841, August 2004.
[RFC4103] Hellstrom, G. and P. Jones, "RTP Payload for Text
Conversation", RFC 4103, June 2005.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message
Session Relay Protocol (MSRP)", RFC 4975, September 2007.
[RFC5194] van Wijk, A. and G. Gybels, "Framework for Real-Time Text
over IP Using the Session Initiation Protocol (SIP)",
RFC 5194, June 2008.
[I-D.hellstrom-text-turntaking]
Hellstrom, G. and A. Wijk, "Registration of the Real-time-
text Media Feature Tag",
draft-hellstrom-text-turntaking-02 (work in progress),
July 2009.
Hellstrom, et al. Expires September 7, 2010 [Page 15]
Internet-Draft Real-time text in SIP gateway calls March 2010
Authors' Addresses
Gunnar Hellstrom
Omnitor
Box 92054
Stockholm, 120 06
SE
Phone: +46-8-58900056
Email: gunnar.hellstrom@omnitor.se
Barry Dingle
3 Cosmo Court
Kilsyth, 3137
AU
Phone: +61-3-9725-3937
Email: btdingle@gmail.com
Arnoud van Wijk
Real-Time Text Taskforce (R3TF)
NL
Phone:
Email: arnoud@realtimetext.org
Guido Gybels
RNID, Department of New Technologies
19-23 Featherstone Street
London, EC1Y 8SL
UK
Phone: +44-20-7294 3713
Email: guido.gybels@rnid.org
Hellstrom, et al. Expires September 7, 2010 [Page 16]
