Thread Subject: RFC 4103 reference for real-time text.

Return to this mailing list's archives

From: Gunnar Hellström
Date: Wed, May 23 2007 3:22 PM
Subject: RFC 4103 reference for real-time text.

I want to comment on today?s meeting discussion on 1194.23(b), about the
explicit reference to RFC 4103 for real-time text.

It sounds good with many voices understanding the great benefits that are
within reach by moving to IP and getting a real-time text channel easily
integrated with other media in the calls.



However, Fred Lucas / TIA had some questions and concerns that I can answer
and hopefully resolve.



I will take them in portions.



Concern 1: ?RFC 4103 is not so much known protocol. Any protocol can be
decided now for this purpose.?



Answer: IETF RFC 4103 ?RTP Payload for text conversation? is an open
standard now referenced from at least 20 other standards from IETF, ITU-T,
3GPP and ETSI. It has for example been included as one of the three media
together with video and audio in IMS Multimedia Telephony. IMS is the next
environment we will see grow for establishing IP based telecom services.



These standards comprise:

-Transmission

-Service specification

-Terminal functionality

-Gateways

-Emergency services

-Relay services



No other standard for real-time text has the ambition to have this wide
coverage. It has taken some years to reach this acceptance level.



Here are a few excerpts:



1. From RFC 4305, SIP telephony device requirements:

?Req-55: SIP telephony devices that include a display, or have a

facility for connecting an external display, MUST include

protocol support as described in RFC 4103 [23] for real-time

interactive text.?



2. From ietf-draft-ecrit-requirements: ?Requirements for Emergency Context
Resolution with Internet Technologies?

?Emergency calling must support a variety of

media. Such media should include voice, conversational text
([RFC4103]), instant messaging and video.?



3. From ITU-T V.151 ?Procedures for the end-to-end connection of analogue
PSTN text telephones over an IP network utilizing text relay?

?In general, ITDs transmit text characters when communicating with other
ITDs using RFC 4103, which specifies the establishment of a separate RTP
stream specifically for transmitting text characters.? ( ITDs are IP text
devices )



Etc.



Conclusion: Well covered in standards, ready for wider deployment.



Regards



Gunnar Hellström

-------------------------------------------------------------------

Gunnar Hellström

Omnitor

= EMAIL ADDRESS REMOVED =

Tel: +46708204288

www.omnitor.se

From: Paul E. Jones
Date: Wed, May 23 2007 4:40 PM
Subject: Re: RFC 4103 reference for real-time text.

Gunnar,



Not to drive the committee into a deep hole on this much-debated issue, but
in spite of the many references to RFC 4103 (which I do favor for native IP
devices), there are concerns with the ability to utilize RFC 4103 on gateway
devices. When developing TIA-1001, we were presented with a laundry list of
requirements that, unfortunately, RFC 4103 could not always satisfy for
gateway devices (or not very well). Thus, TIA-1001 and V.151 prescribe
something different, yet very similar in capability, as a primary means of
relaying text over IP.



Perhaps more important is the loud voices I hear in the industry that are
actually deploying equipment. As much as I?ve pushed to get support for a
text relay mechanism between analog TTY devices over IP, it is very
difficult to even get DSPs in the market that can do proper tone detection,
let alone error-free character extraction. Even if that issue is solved
(which it could be), we?re still faced with other problems:



· RFC 4103 consumes more resources on large gateways, which would
lead to higher port costs and/or lower port density

· The PSTN circuit is a multiplex of voice and TTY signals.
Separating text and voice into separate steams on IP, only to put them back
together again on a remote gateway, is a zero-gain exercise (i.e., it?s a
complete waste)

· It takes time to establish an RFC 4103 stream, especially if there
are H.248 media gateways, two media gateway controllers, and one or more
proxies in the call path (and we have all of this and more in the IMS
architecture), so RFC 4103 might introduce delays in initial communication
which can be avoided with TIA-1001

· For legacy TTY devices, carriers seem to not favor text relay at
all, preferring to use G.711 and simply pass TTY signals over G.711 (much to
my dismay)



So, simply declaring that a gateway device shall support RFC 4103 and citing
standards references is insufficient. The problem is a complicated on a
number of levels, which is why carriers seem to favor treating TTY as voice.
Placing a requirement on gateway equipment to relay modulated TTY signals is
an uphill battle, and one that simply cannot be met with many of the tens of
thousands of already-deployed gateway devices in the field. When we can get
a foot in the door, to then further complicate the problem with multiple RTP
streams, multiplexing issues, and higher per-port costs, increased signaling
overhead, etc., will likely mean we stick with G.711 for legacy TTY support
indefinitely.



So, if I were to place bets on what I think stands the greatest chance of
succeeding on gateway devices in the carrier space, it would be (in order):

· V.152 (Voice Band Data, i.e., use G.711 or better for
pass-through)

· TIA-1001 / V.151 (if we can convince folks to do relay at all)

· RFC 4103



Paul





From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Gunnar
Hellström
Sent: Wednesday, May 23, 2007 5:19 PM
To: Teitac-telecom
Subject: [teitac-telecom] RFC 4103 reference for real-time text.



I want to comment on today?s meeting discussion on 1194.23(b), about the
explicit reference to RFC 4103 for real-time text.

It sounds good with many voices understanding the great benefits that are
within reach by moving to IP and getting a real-time text channel easily
integrated with other media in the calls.



However, Fred Lucas / TIA had some questions and concerns that I can answer
and hopefully resolve.



I will take them in portions.



Concern 1: ?RFC 4103 is not so much known protocol. Any protocol can be
decided now for this purpose.?



Answer: IETF RFC 4103 ?RTP Payload for text conversation? is an open
standard now referenced from at least 20 other standards from IETF, ITU-T,
3GPP and ETSI. It has for example been included as one of the three media
together with video and audio in IMS Multimedia Telephony. IMS is the next
environment we will see grow for establishing IP based telecom services.



These standards comprise:

-Transmission

-Service specification

-Terminal functionality

-Gateways

-Emergency services

-Relay services



No other standard for real-time text has the ambition to have this wide
coverage. It has taken some years to reach this acceptance level.



Here are a few excerpts:



1. From RFC 4305, SIP telephony device requirements:

?Req-55: SIP telephony devices that include a display, or have a

facility for connecting an external display, MUST include

protocol support as described in RFC 4103 [23] for real-time

interactive text.?



2. From ietf-draft-ecrit-requirements: ?Requirements for Emergency Context
Resolution with Internet Technologies?

?Emergency calling must support a variety of

media. Such media should include voice, conversational text
([RFC4103]), instant messaging and video.?



3. From ITU-T V.151 ?Procedures for the end-to-end connection of analogue
PSTN text telephones over an IP network utilizing text relay?

?In general, ITDs transmit text characters when communicating with other
ITDs using RFC 4103, which specifies the establishment of a separate RTP
stream specifically for transmitting text characters.? ( ITDs are IP text
devices )



Etc.



Conclusion: Well covered in standards, ready for wider deployment.



Regards



Gunnar Hellström

-------------------------------------------------------------------

Gunnar Hellström

Omnitor

= EMAIL ADDRESS REMOVED =

Tel: +46708204288

www.omnitor.se

From: Gunnar Hellström
Date: Tue, Jun 05 2007 3:55 PM
Subject: Re: RFC 4103 reference for real-time text.

Paul and all,

I want to return to the discussion on 1194.23(b) about real-time text
interoperability.

We left it with too much uncertainty.



A. IP to IP

If we look through the arguments, we easily find that there is quite good
agreement on how to handle real-time text in the pure IP environment.

You, say:

?in spite of the many references to RFC 4103 (which I do favor for native IP
devices), there are concerns with the ability to utilize RFC 4103 on gateway
devices.?

This is also what the statements in 1194.23(b) say.

So, in fact there is an emerging agreement that RFC 4103 is to be favoured
between IP terminals. This agreement can also be seen in the growing number
of references in standards and policy documents.



Based on that agreement we can build a new class of high functionality,
fully interoperable IP Text capable phones and IP Total conversation devices
corresponding to the draft requirement 1194.23(b). Knowing that there is an
agreement on this level will encourage a good new market. Interoperability
is the key to popularity.



Do we have more parties agreeing on this?

----------------------------------------------------------



B. PSTN to IP in large gateways

With that agreement settled we may approach the issue of gateways between
TTY and IP Text capable terminals.

We use RFC 4103 in small scale PSTN/IP gateways without problems. But you
talk about possible concerns in large scale PSTN/IP gateways.



You correctly state:? Placing a requirement on gateway equipment to relay
modulated TTY signals is an uphill battle, and one that simply cannot be met
with many of the tens of thousands of already-deployed gateway devices in
the field.?

Other methods than forcing all ports to support TTY are required to achieve
TTY / IP text interoperability. It is very likely that we need to agree on
some way to route the calls that MAY contain TTY so that they pass gateway
ports with special capability of conversion between TTY and an IP real-time
text format. Such methods are discussed in standards groups, and they should
be encouraged to come to workable solutions.



C. PSTN to IP in residential gateways and ATAs.

Another problem is what to recommend for the analogue terminal adapters.
There you have no choice. If it provides a PSTN device port, it should
behave properly for attached TTY:s.



This is what RFC 4504 ?Sip Telephony devices? says about the ATA or
residential gateway:

-----From RFC 4504------



Req-57: SIP telephony devices MAY provide analog adaptor

functionality through an RJ-11 FXS port to support FXS

devices. If an RJ-11 (FXS) port is provided, then it MAY

support a gateway function from all text-telephone protocols

according to ITU-T Recommendation V.18 to RFC 4103 text

conversation (in fact, this is encouraged in the near term

during the transition to widespread use of SIP telephony

devices). If this gateway function is not included or fails,

the device MUST pass through all text-telephone protocols

according to ITU-T Recommendation V.18, November 2000, in a

transparent fashion.







--------------------------------

D. PSTN to PSTN through IP

This is another, more operator internal area that might need its own
discussion.





With A solved, we can carry on discussing B, C and possibly D.

The current language in



Gunnar

-------------------------------------------------------------------

Gunnar Hellström

Omnitor

= EMAIL ADDRESS REMOVED =

Tel: +46708204288

www.omnitor.se

_____

From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Paul E. Jones
Sent: Thursday, May 24, 2007 12:34 AM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.



Gunnar,



Not to drive the committee into a deep hole on this much-debated issue, but
in spite of the many references to RFC 4103 (which I do favor for native IP
devices), there are concerns with the ability to utilize RFC 4103 on gateway
devices. When developing TIA-1001, we were presented with a laundry list of
requirements that, unfortunately, RFC 4103 could not always satisfy for
gateway devices (or not very well). Thus, TIA-1001 and V.151 prescribe
something different, yet very similar in capability, as a primary means of
relaying text over IP.



Perhaps more important is the loud voices I hear in the industry that are
actually deploying equipment. As much as I?ve pushed to get support for a
text relay mechanism between analog TTY devices over IP, it is very
difficult to even get DSPs in the market that can do proper tone detection,
let alone error-free character extraction. Even if that issue is solved
(which it could be), we?re still faced with other problems:



* RFC 4103 consumes more resources on large gateways, which would
lead to higher port costs and/or lower port density

* The PSTN circuit is a multiplex of voice and TTY signals.
Separating text and voice into separate steams on IP, only to put them back
together again on a remote gateway, is a zero-gain exercise (i.e., it?s a
complete waste)

* It takes time to establish an RFC 4103 stream, especially if there
are H.248 media gateways, two media gateway controllers, and one or more
proxies in the call path (and we have all of this and more in the IMS
architecture), so RFC 4103 might introduce delays in initial communication
which can be avoided with TIA-1001

* For legacy TTY devices, carriers seem to not favor text relay at
all, preferring to use G.711 and simply pass TTY signals over G.711 (much to
my dismay)



So, simply declaring that a gateway device shall support RFC 4103 and citing
standards references is insufficient. The problem is a complicated on a
number of levels, which is why carriers seem to favor treating TTY as voice.
Placing a requirement on gateway equipment to relay modulated TTY signals is
an uphill battle, and one that simply cannot be met with many of the tens of
thousands of already-deployed gateway devices in the field. When we can get
a foot in the door, to then further complicate the problem with multiple RTP
streams, multiplexing issues, and higher per-port costs, increased signaling
overhead, etc., will likely mean we stick with G.711 for legacy TTY support
indefinitely.



So, if I were to place bets on what I think stands the greatest chance of
succeeding on gateway devices in the carrier space, it would be (in order):

* V.152 (Voice Band Data, i.e., use G.711 or better for
pass-through)

* TIA-1001 / V.151 (if we can convince folks to do relay at all)

* RFC 4103



Paul





From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Gunnar
Hellström
Sent: Wednesday, May 23, 2007 5:19 PM
To: Teitac-telecom
Subject: [teitac-telecom] RFC 4103 reference for real-time text.



I want to comment on today?s meeting discussion on 1194.23(b), about the
explicit reference to RFC 4103 for real-time text.

It sounds good with many voices understanding the great benefits that are
within reach by moving to IP and getting a real-time text channel easily
integrated with other media in the calls.



However, Fred Lucas / TIA had some questions and concerns that I can answer
and hopefully resolve.



I will take them in portions.



Concern 1: ?RFC 4103 is not so much known protocol. Any protocol can be
decided now for this purpose.?



Answer: IETF RFC 4103 ?RTP Payload for text conversation? is an open
standard now referenced from at least 20 other standards from IETF, ITU-T,
3GPP and ETSI. It has for example been included as one of the three media
together with video and audio in IMS Multimedia Telephony. IMS is the next
environment we will see grow for establishing IP based telecom services.



These standards comprise:

-Transmission

-Service specification

-Terminal functionality

-Gateways

-Emergency services

-Relay services



No other standard for real-time text has the ambition to have this wide
coverage. It has taken some years to reach this acceptance level.



Here are a few excerpts:



1. >From RFC 4305, SIP telephony device requirements:

?Req-55: SIP telephony devices that include a display, or have a

facility for connecting an external display, MUST include

protocol support as described in RFC 4103 [23] for real-time

interactive text.?



2. >From ietf-draft-ecrit-requirements: ?Requirements for Emergency Context
Resolution with Internet Technologies?

?Emergency calling must support a variety of

media. Such media should include voice, conversational text
([RFC4103]), instant messaging and video.?



3. >From ITU-T V.151 ?Procedures for the end-to-end connection of analogue
PSTN text telephones over an IP network utilizing text relay?

?In general, ITDs transmit text characters when communicating with other
ITDs using RFC 4103, which specifies the establishment of a separate RTP
stream specifically for transmitting text characters.? ( ITDs are IP text
devices )



Etc.



Conclusion: Well covered in standards, ready for wider deployment.



Regards



Gunnar Hellström

-------------------------------------------------------------------

Gunnar Hellström

Omnitor

= EMAIL ADDRESS REMOVED =

Tel: +46708204288

www.omnitor.se





__________ NOD32 2285 (20070522) Information __________

Detta meddelande är genomsökt av NOD32 Antivirus.
http://www.nod32.com

From: Paul E. Jones
Date: Thu, Jun 07 2007 2:15 PM
Subject: Re: RFC 4103 reference for real-time text.

Gunnar,



A. Yeah, I think we can agree on RFC 4103 for IP text-capable devices.
(That does not change my argument for also wanting V.151 support to work
with gateways, though. But direct IP-terminal to IP-terminal should be RFC
4103.)



B. This is the sticky problem. Do we need to demodulate signals and
transport real text from large gateways, or do we just send G.711 audio?
Several years ago, there was a lot of concern expressed with packet loss and
unacceptable character error rate. ATIS held a meeting on this topic. We
initiated work on V.151 and completed that. But now, it seems that there is
a growing consensus that we no longer need to consider legacy TTY support.
So, I?m very confused. Do we need to further consider support for legacy
TTY devices?



C. ATAs ? What this requirement fails to consider is that more ATAs will
have fax devices connected to them than text phones. There will also be
standard modem devices and other devices (e.g., security alarm systems,
point of sale terminals, etc.) that may not use standard modulations. There
is little we can do for non-standard modulations, except to use G.711. But,
for standard modulations, we can to T.38 for fax, V.150 for modem, and V.151
for text. RFC 4103 could be considered, but it must be introduced in such a
way that fax calls and modem calls still work. For this reason, V.151 may
still be the better choice.



D. This sounds like a GW to GW case, which fits precisely within the scope
of V.151.



Paul



From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Gunnar
Hellström
Sent: Tuesday, June 05, 2007 5:52 PM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.



Paul and all,

I want to return to the discussion on 1194.23(b) about real-time text
interoperability.

We left it with too much uncertainty.



A. IP to IP

If we look through the arguments, we easily find that there is quite good
agreement on how to handle real-time text in the pure IP environment.

You, say:

?in spite of the many references to RFC 4103 (which I do favor for native IP
devices), there are concerns with the ability to utilize RFC 4103 on gateway
devices.?

This is also what the statements in 1194.23(b) say.

So, in fact there is an emerging agreement that RFC 4103 is to be favoured
between IP terminals. This agreement can also be seen in the growing number
of references in standards and policy documents.



Based on that agreement we can build a new class of high functionality,
fully interoperable IP Text capable phones and IP Total conversation devices
corresponding to the draft requirement 1194.23(b). Knowing that there is an
agreement on this level will encourage a good new market. Interoperability
is the key to popularity.



Do we have more parties agreeing on this?

----------------------------------------------------------



B. PSTN to IP in large gateways

With that agreement settled we may approach the issue of gateways between
TTY and IP Text capable terminals.

We use RFC 4103 in small scale PSTN/IP gateways without problems. But you
talk about possible concerns in large scale PSTN/IP gateways.



You correctly state:? Placing a requirement on gateway equipment to relay
modulated TTY signals is an uphill battle, and one that simply cannot be met
with many of the tens of thousands of already-deployed gateway devices in
the field.?

Other methods than forcing all ports to support TTY are required to achieve
TTY / IP text interoperability. It is very likely that we need to agree on
some way to route the calls that MAY contain TTY so that they pass gateway
ports with special capability of conversion between TTY and an IP real-time
text format. Such methods are discussed in standards groups, and they should
be encouraged to come to workable solutions.



C. PSTN to IP in residential gateways and ATAs.

Another problem is what to recommend for the analogue terminal adapters.
There you have no choice. If it provides a PSTN device port, it should
behave properly for attached TTY:s.



This is what RFC 4504 ?Sip Telephony devices? says about the ATA or
residential gateway:

-----From RFC 4504------



Req-57: SIP telephony devices MAY provide analog adaptor

functionality through an RJ-11 FXS port to support FXS

devices. If an RJ-11 (FXS) port is provided, then it MAY

support a gateway function from all text-telephone protocols

according to ITU-T Recommendation V.18 to RFC 4103 text

conversation (in fact, this is encouraged in the near term

during the transition to widespread use of SIP telephony

devices). If this gateway function is not included or fails,

the device MUST pass through all text-telephone protocols

according to ITU-T Recommendation V.18, November 2000, in a

transparent fashion.







--------------------------------

D. PSTN to PSTN through IP

This is another, more operator internal area that might need its own
discussion.





With A solved, we can carry on discussing B, C and possibly D.

The current language in



Gunnar

-------------------------------------------------------------------

Gunnar Hellström

Omnitor

= EMAIL ADDRESS REMOVED =

Tel: +46708204288

www.omnitor.se

_____

From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Paul E. Jones
Sent: Thursday, May 24, 2007 12:34 AM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.



Gunnar,



Not to drive the committee into a deep hole on this much-debated issue, but
in spite of the many references to RFC 4103 (which I do favor for native IP
devices), there are concerns with the ability to utilize RFC 4103 on gateway
devices. When developing TIA-1001, we were presented with a laundry list of
requirements that, unfortunately, RFC 4103 could not always satisfy for
gateway devices (or not very well). Thus, TIA-1001 and V.151 prescribe
something different, yet very similar in capability, as a primary means of
relaying text over IP.



Perhaps more important is the loud voices I hear in the industry that are
actually deploying equipment. As much as I?ve pushed to get support for a
text relay mechanism between analog TTY devices over IP, it is very
difficult to even get DSPs in the market that can do proper tone detection,
let alone error-free character extraction. Even if that issue is solved
(which it could be), we?re still faced with other problems:



· RFC 4103 consumes more resources on large gateways, which would
lead to higher port costs and/or lower port density

· The PSTN circuit is a multiplex of voice and TTY signals.
Separating text and voice into separate steams on IP, only to put them back
together again on a remote gateway, is a zero-gain exercise (i.e., it?s a
complete waste)

· It takes time to establish an RFC 4103 stream, especially if there
are H.248 media gateways, two media gateway controllers, and one or more
proxies in the call path (and we have all of this and more in the IMS
architecture), so RFC 4103 might introduce delays in initial communication
which can be avoided with TIA-1001

· For legacy TTY devices, carriers seem to not favor text relay at
all, preferring to use G.711 and simply pass TTY signals over G.711 (much to
my dismay)



So, simply declaring that a gateway device shall support RFC 4103 and citing
standards references is insufficient. The problem is a complicated on a
number of levels, which is why carriers seem to favor treating TTY as voice.
Placing a requirement on gateway equipment to relay modulated TTY signals is
an uphill battle, and one that simply cannot be met with many of the tens of
thousands of already-deployed gateway devices in the field. When we can get
a foot in the door, to then further complicate the problem with multiple RTP
streams, multiplexing issues, and higher per-port costs, increased signaling
overhead, etc., will likely mean we stick with G.711 for legacy TTY support
indefinitely.



So, if I were to place bets on what I think stands the greatest chance of
succeeding on gateway devices in the carrier space, it would be (in order):

· V.152 (Voice Band Data, i.e., use G.711 or better for
pass-through)

· TIA-1001 / V.151 (if we can convince folks to do relay at all)

· RFC 4103



Paul





From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Gunnar
Hellström
Sent: Wednesday, May 23, 2007 5:19 PM
To: Teitac-telecom
Subject: [teitac-telecom] RFC 4103 reference for real-time text.



I want to comment on today?s meeting discussion on 1194.23(b), about the
explicit reference to RFC 4103 for real-time text.

It sounds good with many voices understanding the great benefits that are
within reach by moving to IP and getting a real-time text channel easily
integrated with other media in the calls.



However, Fred Lucas / TIA had some questions and concerns that I can answer
and hopefully resolve.



I will take them in portions.



Concern 1: ?RFC 4103 is not so much known protocol. Any protocol can be
decided now for this purpose.?



Answer: IETF RFC 4103 ?RTP Payload for text conversation? is an open
standard now referenced from at least 20 other standards from IETF, ITU-T,
3GPP and ETSI. It has for example been included as one of the three media
together with video and audio in IMS Multimedia Telephony. IMS is the next
environment we will see grow for establishing IP based telecom services.



These standards comprise:

-Transmission

-Service specification

-Terminal functionality

-Gateways

-Emergency services

-Relay services



No other standard for real-time text has the ambition to have this wide
coverage. It has taken some years to reach this acceptance level.



Here are a few excerpts:



1. >From RFC 4305, SIP telephony device requirements:

?Req-55: SIP telephony devices that include a display, or have a

facility for connecting an external display, MUST include

protocol support as described in RFC 4103 [23] for real-time

interactive text.?



2. >From ietf-draft-ecrit-requirements: ?Requirements for Emergency Context
Resolution with Internet Technologies?

?Emergency calling must support a variety of

media. Such media should include voice, conversational text
([RFC4103]), instant messaging and video.?



3. >From ITU-T V.151 ?Procedures for the end-to-end connection of analogue
PSTN text telephones over an IP network utilizing text relay?

?In general, ITDs transmit text characters when communicating with other
ITDs using RFC 4103, which specifies the establishment of a separate RTP
stream specifically for transmitting text characters.? ( ITDs are IP text
devices )



Etc.



Conclusion: Well covered in standards, ready for wider deployment.



Regards



Gunnar Hellström

-------------------------------------------------------------------

Gunnar Hellström

Omnitor

= EMAIL ADDRESS REMOVED =

Tel: +46708204288

www.omnitor.se





__________ NOD32 2285 (20070522) Information __________

Detta meddelande är genomsökt av NOD32 Antivirus.
http://www.nod32.com

From: Gunnar Hellström
Date: Thu, Jun 07 2007 3:20 PM
Subject: Re: RFC 4103 reference for real-time text.

Paul,



A. IP to IP

Fine. This is an important step for good progress in design for all in
telecomms. Are there more parties who can join in this agreement?



B. PSTN to IP in large gateways

Just sending G.711 audio is likely not sufficiently reliable for TIA 825.
Because of its long character time of 165 ms, and its letter shift ? figure
shift technique, it is extremely sensitive to packet loss. The quite high
acceptable limit of 1% character errors require a theoretical packet loss
rate of a maximum of 0.1% when using plain G.711. That is too risky even in
good networks.

Much better with same bandwidth would probably be G.726 with one level of
redundancy. Then you would even allow 3% packet loss and still get usable
result. ( 1% errors). But beware! As recently discussed, other disturbing
effects like echo handlers and distorsion tends to come in and destroy the
real result as compared to the theoretical.



And what would be the destination of the audio coded text? I do not see it
realistic to take it all the way to the IP terminal. But possibly to an
intermediate gateway that converts to a text format that the terminal
supports. Do you want to propose double text codecs in all IP terminals
interested in TTY compatibility? One for IP to IP and one for IP ? PSTN?



Some efforts to support TTY transport should be maintained, but the users
have asked us to not focus all energy on that problem, so that the
functional enhancements within reach in IP networks are lost. I understand
that as a preparedness to discuss compromises, like using some added
procedures in order to be routed through text capable gateways.

Can we expect Emergency services and relay services to open an agreed IP ?
IP real-time text method ( A ) very soon? If not, good TTY interoperability
is at least needed for access to these services.



C. PSTN to IP in residential gateways and ATAs.

We need to have a solution for the case when a terminal behind an ATA calls
a native IP terminal. Should the call be routed to a big VoIP gateway where
proper support would be found for conversion to an IP transport of text that
is supported by the terminal.



D. PSTN to PSTN through IP

Yes, this is a GW to GW case, suitable for V.151 if you want.



Gunnar

-------------------------------------------------------------------

Gunnar Hellström

Omnitor

= EMAIL ADDRESS REMOVED =

Tel: +46708204288

www.omnitor.se

_____

From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Paul E. Jones
Sent: Thursday, June 07, 2007 10:09 PM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.



Gunnar,



A. Yeah, I think we can agree on RFC 4103 for IP text-capable devices.
(That does not change my argument for also wanting V.151 support to work
with gateways, though. But direct IP-terminal to IP-terminal should be RFC
4103.)



B. This is the sticky problem. Do we need to demodulate signals and
transport real text from large gateways, or do we just send G.711 audio?
Several years ago, there was a lot of concern expressed with packet loss and
unacceptable character error rate. ATIS held a meeting on this topic. We
initiated work on V.151 and completed that. But now, it seems that there is
a growing consensus that we no longer need to consider legacy TTY support.
So, I?m very confused. Do we need to further consider support for legacy
TTY devices?



C. ATAs ? What this requirement fails to consider is that more ATAs will
have fax devices connected to them than text phones. There will also be
standard modem devices and other devices (e.g., security alarm systems,
point of sale terminals, etc.) that may not use standard modulations. There
is little we can do for non-standard modulations, except to use G.711. But,
for standard modulations, we can to T.38 for fax, V.150 for modem, and V.151
for text. RFC 4103 could be considered, but it must be introduced in such a
way that fax calls and modem calls still work. For this reason, V.151 may
still be the better choice.



D. This sounds like a GW to GW case, which fits precisely within the scope
of V.151.



Paul



From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Gunnar
Hellström
Sent: Tuesday, June 05, 2007 5:52 PM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.



Paul and all,

I want to return to the discussion on 1194.23(b) about real-time text
interoperability.

We left it with too much uncertainty.



A. IP to IP

If we look through the arguments, we easily find that there is quite good
agreement on how to handle real-time text in the pure IP environment.

You, say:

?in spite of the many references to RFC 4103 (which I do favor for native IP
devices), there are concerns with the ability to utilize RFC 4103 on gateway
devices.?

This is also what the statements in 1194.23(b) say.

So, in fact there is an emerging agreement that RFC 4103 is to be favoured
between IP terminals. This agreement can also be seen in the growing number
of references in standards and policy documents.



Based on that agreement we can build a new class of high functionality,
fully interoperable IP Text capable phones and IP Total conversation devices
corresponding to the draft requirement 1194.23(b). Knowing that there is an
agreement on this level will encourage a good new market. Interoperability
is the key to popularity.



Do we have more parties agreeing on this?

----------------------------------------------------------



B. PSTN to IP in large gateways

With that agreement settled we may approach the issue of gateways between
TTY and IP Text capable terminals.

We use RFC 4103 in small scale PSTN/IP gateways without problems. But you
talk about possible concerns in large scale PSTN/IP gateways.



You correctly state:? Placing a requirement on gateway equipment to relay
modulated TTY signals is an uphill battle, and one that simply cannot be met
with many of the tens of thousands of already-deployed gateway devices in
the field.?

Other methods than forcing all ports to support TTY are required to achieve
TTY / IP text interoperability. It is very likely that we need to agree on
some way to route the calls that MAY contain TTY so that they pass gateway
ports with special capability of conversion between TTY and an IP real-time
text format. Such methods are discussed in standards groups, and they should
be encouraged to come to workable solutions.



C. PSTN to IP in residential gateways and ATAs.

Another problem is what to recommend for the analogue terminal adapters.
There you have no choice. If it provides a PSTN device port, it should
behave properly for attached TTY:s.



This is what RFC 4504 ?Sip Telephony devices? says about the ATA or
residential gateway:

-----From RFC 4504------



Req-57: SIP telephony devices MAY provide analog adaptor

functionality through an RJ-11 FXS port to support FXS

devices. If an RJ-11 (FXS) port is provided, then it MAY

support a gateway function from all text-telephone protocols

according to ITU-T Recommendation V.18 to RFC 4103 text

conversation (in fact, this is encouraged in the near term

during the transition to widespread use of SIP telephony

devices). If this gateway function is not included or fails,

the device MUST pass through all text-telephone protocols

according to ITU-T Recommendation V.18, November 2000, in a

transparent fashion.







--------------------------------

D. PSTN to PSTN through IP

This is another, more operator internal area that might need its own
discussion.





With A solved, we can carry on discussing B, C and possibly D.

The current language in



Gunnar

-------------------------------------------------------------------

Gunnar Hellström

Omnitor

= EMAIL ADDRESS REMOVED =

Tel: +46708204288

www.omnitor.se

_____

From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Paul E. Jones
Sent: Thursday, May 24, 2007 12:34 AM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.



Gunnar,



Not to drive the committee into a deep hole on this much-debated issue, but
in spite of the many references to RFC 4103 (which I do favor for native IP
devices), there are concerns with the ability to utilize RFC 4103 on gateway
devices. When developing TIA-1001, we were presented with a laundry list of
requirements that, unfortunately, RFC 4103 could not always satisfy for
gateway devices (or not very well). Thus, TIA-1001 and V.151 prescribe
something different, yet very similar in capability, as a primary means of
relaying text over IP.



Perhaps more important is the loud voices I hear in the industry that are
actually deploying equipment. As much as I?ve pushed to get support for a
text relay mechanism between analog TTY devices over IP, it is very
difficult to even get DSPs in the market that can do proper tone detection,
let alone error-free character extraction. Even if that issue is solved
(which it could be), we?re still faced with other problems:



* RFC 4103 consumes more resources on large gateways, which would
lead to higher port costs and/or lower port density

* The PSTN circuit is a multiplex of voice and TTY signals.
Separating text and voice into separate steams on IP, only to put them back
together again on a remote gateway, is a zero-gain exercise (i.e., it?s a
complete waste)

* It takes time to establish an RFC 4103 stream, especially if there
are H.248 media gateways, two media gateway controllers, and one or more
proxies in the call path (and we have all of this and more in the IMS
architecture), so RFC 4103 might introduce delays in initial communication
which can be avoided with TIA-1001

* For legacy TTY devices, carriers seem to not favor text relay at
all, preferring to use G.711 and simply pass TTY signals over G.711 (much to
my dismay)



So, simply declaring that a gateway device shall support RFC 4103 and citing
standards references is insufficient. The problem is a complicated on a
number of levels, which is why carriers seem to favor treating TTY as voice.
Placing a requirement on gateway equipment to relay modulated TTY signals is
an uphill battle, and one that simply cannot be met with many of the tens of
thousands of already-deployed gateway devices in the field. When we can get
a foot in the door, to then further complicate the problem with multiple RTP
streams, multiplexing issues, and higher per-port costs, increased signaling
overhead, etc., will likely mean we stick with G.711 for legacy TTY support
indefinitely.



So, if I were to place bets on what I think stands the greatest chance of
succeeding on gateway devices in the carrier space, it would be (in order):

* V.152 (Voice Band Data, i.e., use G.711 or better for
pass-through)

* TIA-1001 / V.151 (if we can convince folks to do relay at all)

* RFC 4103



Paul





From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Gunnar
Hellström
Sent: Wednesday, May 23, 2007 5:19 PM
To: Teitac-telecom
Subject: [teitac-telecom] RFC 4103 reference for real-time text.



I want to comment on today?s meeting discussion on 1194.23(b), about the
explicit reference to RFC 4103 for real-time text.

It sounds good with many voices understanding the great benefits that are
within reach by moving to IP and getting a real-time text channel easily
integrated with other media in the calls.



However, Fred Lucas / TIA had some questions and concerns that I can answer
and hopefully resolve.



I will take them in portions.



Concern 1: ?RFC 4103 is not so much known protocol. Any protocol can be
decided now for this purpose.?



Answer: IETF RFC 4103 ?RTP Payload for text conversation? is an open
standard now referenced from at least 20 other standards from IETF, ITU-T,
3GPP and ETSI. It has for example been included as one of the three media
together with video and audio in IMS Multimedia Telephony. IMS is the next
environment we will see grow for establishing IP based telecom services.



These standards comprise:

-Transmission

-Service specification

-Terminal functionality

-Gateways

-Emergency services

-Relay services



No other standard for real-time text has the ambition to have this wide
coverage. It has taken some years to reach this acceptance level.



Here are a few excerpts:



1. >From RFC 4305, SIP telephony device requirements:

?Req-55: SIP telephony devices that include a display, or have a

facility for connecting an external display, MUST include

protocol support as described in RFC 4103 [23] for real-time

interactive text.?



2. >From ietf-draft-ecrit-requirements: ?Requirements for Emergency Context
Resolution with Internet Technologies?

?Emergency calling must support a variety of

media. Such media should include voice, conversational text
([RFC4103]), instant messaging and video.?



3. >From ITU-T V.151 ?Procedures for the end-to-end connection of analogue
PSTN text telephones over an IP network utilizing text relay?

?In general, ITDs transmit text characters when communicating with other
ITDs using RFC 4103, which specifies the establishment of a separate RTP
stream specifically for transmitting text characters.? ( ITDs are IP text
devices )



Etc.



Conclusion: Well covered in standards, ready for wider deployment.



Regards



Gunnar Hellström

-------------------------------------------------------------------

Gunnar Hellström

Omnitor

= EMAIL ADDRESS REMOVED =

Tel: +46708204288

www.omnitor.se





__________ NOD32 2285 (20070522) Information __________

Detta meddelande är genomsökt av NOD32 Antivirus.
http://www.nod32.com



__________ NOD32 2313 (20070606) Information __________

Detta meddelande är genomsökt av NOD32 Antivirus.
http://www.nod32.com

From: Gregg Vanderheiden
Date: Thu, Jun 07 2007 5:05 PM
Subject: Re: RFC 4103 reference for real-time text.

RFC 4103 and RFC-4351 (the part of V.151 that is being referred to) are
very similar (almost identical except that 4103 ships text and audio data
on different channels where 4351 ships them on the same channel. They
both use T.140 for text encoding and RTP etc. ) Since they are so similar
it isnt that hard to support both if you support 4351 (which is arguably
slightly harder to implement than RFC-4103 since you have to sort out the
audio from the text packets in the audio channel) what about if we just
require the pair of them.



Then we have RFC-4103 for all IP to IP communication

and RFC-4351 for communication between VoIP devinces and PSTN gateways.



(RFC-4103 can communicate with PSTN gateways but would use up two ports
rather than 1)





If we require both 4103 adn 4351 then we provide both the clean 4103 and the
4351 which masquarades text in voice channels but is more efficient for PSTN
gateways where you mix the voice and text together anyway on the Analog
(PSTN) side.



Someday ? when there is no longer a PSTN and as PSTN slowly fades, we can
rely more and more on the 4103.





NOTE: this still allows closed systems like Skype, VoIP company systems,
Vonnage, Cable phone, etc to use whatever they want internally that is
reliable as long as they translate into the standard format when they
connect to other systems. They dont have to use them even then ? but have
to be able to be able to use them ? so that there is always something that
everyone supports so they can communicate/connect with text as they do with
voice.





Thoughts?




Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.






_____


From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Gunnar
Hellström
Sent: Thursday, June 07, 2007 4:15 PM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.

Paul,



A. IP to IP

Fine. This is an important step for good progress in design for all in
telecomms. Are there more parties who can join in this agreement?



B. PSTN to IP in large gateways

Just sending G.711 audio is likely not sufficiently reliable for TIA 825.
Because of its long character time of 165 ms, and its letter shift ? figure
shift technique, it is extremely sensitive to packet loss. The quite high
acceptable limit of 1% character errors require a theoretical packet loss
rate of a maximum of 0.1% when using plain G.711. That is too risky even in
good networks.

Much better with same bandwidth would probably be G.726 with one level of
redundancy. Then you would even allow 3% packet loss and still get usable
result. ( 1% errors). But beware! As recently discussed, other disturbing
effects like echo handlers and distorsion tends to come in and destroy the
real result as compared to the theoretical.



And what would be the destination of the audio coded text? I do not see it
realistic to take it all the way to the IP terminal. But possibly to an
intermediate gateway that converts to a text format that the terminal
supports. Do you want to propose double text codecs in all IP terminals
interested in TTY compatibility? One for IP to IP and one for IP ? PSTN?



Some efforts to support TTY transport should be maintained, but the users
have asked us to not focus all energy on that problem, so that the
functional enhancements within reach in IP networks are lost. I understand
that as a preparedness to discuss compromises, like using some added
procedures in order to be routed through text capable gateways.

Can we expect Emergency services and relay services to open an agreed IP ?
IP real-time text method ( A ) very soon? If not, good TTY interoperability
is at least needed for access to these services.



C. PSTN to IP in residential gateways and ATAs.

We need to have a solution for the case when a terminal behind an ATA calls
a native IP terminal. Should the call be routed to a big VoIP gateway where
proper support would be found for conversion to an IP transport of text that
is supported by the terminal.



D. PSTN to PSTN through IP

Yes, this is a GW to GW case, suitable for V.151 if you want.



Gunnar

-------------------------------------------------------------------

Gunnar Hellström

Omnitor

= EMAIL ADDRESS REMOVED =

Tel: +46708204288

www.omnitor.se


_____


From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Paul E. Jones
Sent: Thursday, June 07, 2007 10:09 PM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.



Gunnar,



A. Yeah, I think we can agree on RFC 4103 for IP text-capable devices.
(That does not change my argument for also wanting V.151 support to work
with gateways, though. But direct IP-terminal to IP-terminal should be RFC
4103.)



B. This is the sticky problem. Do we need to demodulate signals and
transport real text from large gateways, or do we just send G.711 audio?
Several years ago, there was a lot of concern expressed with packet loss and
unacceptable character error rate. ATIS held a meeting on this topic. We
initiated work on V.151 and completed that. But now, it seems that there is
a growing consensus that we no longer need to consider legacy TTY support.
So, I?m very confused. Do we need to further consider support for legacy
TTY devices?



C. ATAs ? What this requirement fails to consider is that more ATAs will
have fax devices connected to them than text phones. There will also be
standard modem devices and other devices (e.g., security alarm systems,
point of sale terminals, etc.) that may not use standard modulations. There
is little we can do for non-standard modulations, except to use G.711. But,
for standard modulations, we can to T.38 for fax, V.150 for modem, and V.151
for text. RFC 4103 could be considered, but it must be introduced in such a
way that fax calls and modem calls still work. For this reason, V.151 may
still be the better choice.



D. This sounds like a GW to GW case, which fits precisely within the scope
of V.151.



Paul



From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Gunnar
Hellström
Sent: Tuesday, June 05, 2007 5:52 PM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.



Paul and all,

I want to return to the discussion on 1194.23(b) about real-time text
interoperability.

We left it with too much uncertainty.



A. IP to IP

If we look through the arguments, we easily find that there is quite good
agreement on how to handle real-time text in the pure IP environment.

You, say:

?in spite of the many references to RFC 4103 (which I do favor for native IP
devices), there are concerns with the ability to utilize RFC 4103 on gateway
devices.?

This is also what the statements in 1194.23(b) say.

So, in fact there is an emerging agreement that RFC 4103 is to be favoured
between IP terminals. This agreement can also be seen in the growing number
of references in standards and policy documents.



Based on that agreement we can build a new class of high functionality,
fully interoperable IP Text capable phones and IP Total conversation devices
corresponding to the draft requirement 1194.23(b). Knowing that there is an
agreement on this level will encourage a good new market. Interoperability
is the key to popularity.



Do we have more parties agreeing on this?

----------------------------------------------------------



B. PSTN to IP in large gateways

With that agreement settled we may approach the issue of gateways between
TTY and IP Text capable terminals.

We use RFC 4103 in small scale PSTN/IP gateways without problems. But you
talk about possible concerns in large scale PSTN/IP gateways.



You correctly state:? Placing a requirement on gateway equipment to relay
modulated TTY signals is an uphill battle, and one that simply cannot be met
with many of the tens of thousands of already-deployed gateway devices in
the field.?

Other methods than forcing all ports to support TTY are required to achieve
TTY / IP text interoperability. It is very likely that we need to agree on
some way to route the calls that MAY contain TTY so that they pass gateway
ports with special capability of conversion between TTY and an IP real-time
text format. Such methods are discussed in standards groups, and they should
be encouraged to come to workable solutions.



C. PSTN to IP in residential gateways and ATAs.

Another problem is what to recommend for the analogue terminal adapters.
There you have no choice. If it provides a PSTN device port, it should
behave properly for attached TTY:s.



This is what RFC 4504 ?Sip Telephony devices? says about the ATA or
residential gateway:

-----From RFC 4504------



Req-57: SIP telephony devices MAY provide analog adaptor

functionality through an RJ-11 FXS port to support FXS

devices. If an RJ-11 (FXS) port is provided, then it MAY

support a gateway function from all text-telephone protocols

according to ITU-T Recommendation V.18 to RFC 4103 text

conversation (in fact, this is encouraged in the near term

during the transition to widespread use of SIP telephony

devices). If this gateway function is not included or fails,

the device MUST pass through all text-telephone protocols

according to ITU-T Recommendation V.18, November 2000, in a

transparent fashion.







--------------------------------

D. PSTN to PSTN through IP

This is another, more operator internal area that might need its own
discussion.





With A solved, we can carry on discussing B, C and possibly D.

The current language in



Gunnar

-------------------------------------------------------------------

Gunnar Hellström

Omnitor

= EMAIL ADDRESS REMOVED =

Tel: +46708204288

www.omnitor.se


_____


From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Paul E. Jones
Sent: Thursday, May 24, 2007 12:34 AM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.



Gunnar,



Not to drive the committee into a deep hole on this much-debated issue, but
in spite of the many references to RFC 4103 (which I do favor for native IP
devices), there are concerns with the ability to utilize RFC 4103 on gateway
devices. When developing TIA-1001, we were presented with a laundry list of
requirements that, unfortunately, RFC 4103 could not always satisfy for
gateway devices (or not very well). Thus, TIA-1001 and V.151 prescribe
something different, yet very similar in capability, as a primary means of
relaying text over IP.



Perhaps more important is the loud voices I hear in the industry that are
actually deploying equipment. As much as I?ve pushed to get support for a
text relay mechanism between analog TTY devices over IP, it is very
difficult to even get DSPs in the market that can do proper tone detection,
let alone error-free character extraction. Even if that issue is solved
(which it could be), we?re still faced with other problems:



* RFC 4103 consumes more resources on large gateways, which would
lead to higher port costs and/or lower port density

* The PSTN circuit is a multiplex of voice and TTY signals.
Separating text and voice into separate steams on IP, only to put them back
together again on a remote gateway, is a zero-gain exercise (i.e., it?s a
complete waste)

* It takes time to establish an RFC 4103 stream, especially if there
are H.248 media gateways, two media gateway controllers, and one or more
proxies in the call path (and we have all of this and more in the IMS
architecture), so RFC 4103 might introduce delays in initial communication
which can be avoided with TIA-1001

* For legacy TTY devices, carriers seem to not favor text relay at
all, preferring to use G.711 and simply pass TTY signals over G.711 (much to
my dismay)



So, simply declaring that a gateway device shall support RFC 4103 and citing
standards references is insufficient. The problem is a complicated on a
number of levels, which is why carriers seem to favor treating TTY as voice.
Placing a requirement on gateway equipment to relay modulated TTY signals is
an uphill battle, and one that simply cannot be met with many of the tens of
thousands of already-deployed gateway devices in the field. When we can get
a foot in the door, to then further complicate the problem with multiple RTP
streams, multiplexing issues, and higher per-port costs, increased signaling
overhead, etc., will likely mean we stick with G.711 for legacy TTY support
indefinitely.



So, if I were to place bets on what I think stands the greatest chance of
succeeding on gateway devices in the carrier space, it would be (in order):

* V.152 (Voice Band Data, i.e., use G.711 or better for
pass-through)

* TIA-1001 / V.151 (if we can convince folks to do relay at all)

* RFC 4103



Paul





From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Gunnar
Hellström
Sent: Wednesday, May 23, 2007 5:19 PM
To: Teitac-telecom
Subject: [teitac-telecom] RFC 4103 reference for real-time text.



I want to comment on today?s meeting discussion on 1194.23(b), about the
explicit reference to RFC 4103 for real-time text.

It sounds good with many voices understanding the great benefits that are
within reach by moving to IP and getting a real-time text channel easily
integrated with other media in the calls.



However, Fred Lucas / TIA had some questions and concerns that I can answer
and hopefully resolve.



I will take them in portions.



Concern 1: ?RFC 4103 is not so much known protocol. Any protocol can be
decided now for this purpose.?



Answer: IETF RFC 4103 ?RTP Payload for text conversation? is an open
standard now referenced from at least 20 other standards from IETF, ITU-T,
3GPP and ETSI. It has for example been included as one of the three media
together with video and audio in IMS Multimedia Telephony. IMS is the next
environment we will see grow for establishing IP based telecom services.



These standards comprise:

-Transmission

-Service specification

-Terminal functionality

-Gateways

-Emergency services

-Relay services



No other standard for real-time text has the ambition to have this wide
coverage. It has taken some years to reach this acceptance level.



Here are a few excerpts:



1. >From RFC 4305, SIP telephony device requirements:

?Req-55: SIP telephony devices that include a display, or have a

facility for connecting an external display, MUST include

protocol support as described in RFC 4103 [23] for real-time

interactive text.?



2. >From ietf-draft-ecrit-requirements: ?Requirements for Emergency Context
Resolution with Internet Technologies?

?Emergency calling must support a variety of

media. Such media should include voice, conversational text
([RFC4103]), instant messaging and video.?



3. >From ITU-T V.151 ?Procedures for the end-to-end connection of analogue
PSTN text telephones over an IP network utilizing text relay?

?In general, ITDs transmit text characters when communicating with other
ITDs using RFC 4103, which specifies the establishment of a separate RTP
stream specifically for transmitting text characters.? ( ITDs are IP text
devices )



Etc.



Conclusion: Well covered in standards, ready for wider deployment.



Regards



Gunnar Hellström

-------------------------------------------------------------------

Gunnar Hellström

Omnitor

= EMAIL ADDRESS REMOVED =

Tel: +46708204288

www.omnitor.se





__________ NOD32 2285 (20070522) Information __________

Detta meddelande är genomsökt av NOD32 Antivirus.
http://www.nod32.com



__________ NOD32 2313 (20070606) Information __________

Detta meddelande är genomsökt av NOD32 Antivirus.
http://www.nod32.com

From: John Combs (jcombs)
Date: Thu, Jun 07 2007 5:10 PM
Subject: Re: RFC 4103 reference for real-time text.

One reason they went with RFC-4351 is that is much more likely to get through a firewall than RFC-4103 (because of the separate text & audio channels in 4103).

From: Gregg Vanderheiden
Date: Thu, Jun 07 2007 5:15 PM
Subject: Re: RFC 4103 reference for real-time text.

See other email. RE 4103 vs V151



RE TTY. It is still the only thing that works on PSTN. But is shouldn?t
be used anywhere else. And hopefully it will fade with PSTN use.




Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.






_____


From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Paul E. Jones
Sent: Thursday, June 07, 2007 3:09 PM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.

Gunnar,



A. Yeah, I think we can agree on RFC 4103 for IP text-capable devices.
(That does not change my argument for also wanting V.151 support to work
with gateways, though. But direct IP-terminal to IP-terminal should be RFC
4103.)



B. This is the sticky problem. Do we need to demodulate signals and
transport real text from large gateways, or do we just send G.711 audio?
Several years ago, there was a lot of concern expressed with packet loss and
unacceptable character error rate. ATIS held a meeting on this topic. We
initiated work on V.151 and completed that. But now, it seems that there is
a growing consensus that we no longer need to consider legacy TTY support.
So, I?m very confused. Do we need to further consider support for legacy
TTY devices?



C. ATAs ? What this requirement fails to consider is that more ATAs will
have fax devices connected to them than text phones. There will also be
standard modem devices and other devices (e.g., security alarm systems,
point of sale terminals, etc.) that may not use standard modulations. There
is little we can do for non-standard modulations, except to use G.711. But,
for standard modulations, we can to T.38 for fax, V.150 for modem, and V.151
for text. RFC 4103 could be considered, but it must be introduced in such a
way that fax calls and modem calls still work. For this reason, V.151 may
still be the better choice.



D. This sounds like a GW to GW case, which fits precisely within the scope
of V.151.



Paul



From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Gunnar
Hellström
Sent: Tuesday, June 05, 2007 5:52 PM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.



Paul and all,

I want to return to the discussion on 1194.23(b) about real-time text
interoperability.

We left it with too much uncertainty.



A. IP to IP

If we look through the arguments, we easily find that there is quite good
agreement on how to handle real-time text in the pure IP environment.

You, say:

?in spite of the many references to RFC 4103 (which I do favor for native IP
devices), there are concerns with the ability to utilize RFC 4103 on gateway
devices.?

This is also what the statements in 1194.23(b) say.

So, in fact there is an emerging agreement that RFC 4103 is to be favoured
between IP terminals. This agreement can also be seen in the growing number
of references in standards and policy documents.



Based on that agreement we can build a new class of high functionality,
fully interoperable IP Text capable phones and IP Total conversation devices
corresponding to the draft requirement 1194.23(b). Knowing that there is an
agreement on this level will encourage a good new market. Interoperability
is the key to popularity.



Do we have more parties agreeing on this?

----------------------------------------------------------



B. PSTN to IP in large gateways

With that agreement settled we may approach the issue of gateways between
TTY and IP Text capable terminals.

We use RFC 4103 in small scale PSTN/IP gateways without problems. But you
talk about possible concerns in large scale PSTN/IP gateways.



You correctly state:? Placing a requirement on gateway equipment to relay
modulated TTY signals is an uphill battle, and one that simply cannot be met
with many of the tens of thousands of already-deployed gateway devices in
the field.?

Other methods than forcing all ports to support TTY are required to achieve
TTY / IP text interoperability. It is very likely that we need to agree on
some way to route the calls that MAY contain TTY so that they pass gateway
ports with special capability of conversion between TTY and an IP real-time
text format. Such methods are discussed in standards groups, and they should
be encouraged to come to workable solutions.



C. PSTN to IP in residential gateways and ATAs.

Another problem is what to recommend for the analogue terminal adapters.
There you have no choice. If it provides a PSTN device port, it should
behave properly for attached TTY:s.



This is what RFC 4504 ?Sip Telephony devices? says about the ATA or
residential gateway:

-----From RFC 4504------



Req-57: SIP telephony devices MAY provide analog adaptor

functionality through an RJ-11 FXS port to support FXS

devices. If an RJ-11 (FXS) port is provided, then it MAY

support a gateway function from all text-telephone protocols

according to ITU-T Recommendation V.18 to RFC 4103 text

conversation (in fact, this is encouraged in the near term

during the transition to widespread use of SIP telephony

devices). If this gateway function is not included or fails,

the device MUST pass through all text-telephone protocols

according to ITU-T Recommendation V.18, November 2000, in a

transparent fashion.







--------------------------------

D. PSTN to PSTN through IP

This is another, more operator internal area that might need its own
discussion.





With A solved, we can carry on discussing B, C and possibly D.

The current language in



Gunnar

-------------------------------------------------------------------

Gunnar Hellström

Omnitor

= EMAIL ADDRESS REMOVED =

Tel: +46708204288

www.omnitor.se


_____


From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Paul E. Jones
Sent: Thursday, May 24, 2007 12:34 AM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.



Gunnar,



Not to drive the committee into a deep hole on this much-debated issue, but
in spite of the many references to RFC 4103 (which I do favor for native IP
devices), there are concerns with the ability to utilize RFC 4103 on gateway
devices. When developing TIA-1001, we were presented with a laundry list of
requirements that, unfortunately, RFC 4103 could not always satisfy for
gateway devices (or not very well). Thus, TIA-1001 and V.151 prescribe
something different, yet very similar in capability, as a primary means of
relaying text over IP.



Perhaps more important is the loud voices I hear in the industry that are
actually deploying equipment. As much as I?ve pushed to get support for a
text relay mechanism between analog TTY devices over IP, it is very
difficult to even get DSPs in the market that can do proper tone detection,
let alone error-free character extraction. Even if that issue is solved
(which it could be), we?re still faced with other problems:



* RFC 4103 consumes more resources on large gateways, which would
lead to higher port costs and/or lower port density

* The PSTN circuit is a multiplex of voice and TTY signals.
Separating text and voice into separate steams on IP, only to put them back
together again on a remote gateway, is a zero-gain exercise (i.e., it?s a
complete waste)

* It takes time to establish an RFC 4103 stream, especially if there
are H.248 media gateways, two media gateway controllers, and one or more
proxies in the call path (and we have all of this and more in the IMS
architecture), so RFC 4103 might introduce delays in initial communication
which can be avoided with TIA-1001

* For legacy TTY devices, carriers seem to not favor text relay at
all, preferring to use G.711 and simply pass TTY signals over G.711 (much to
my dismay)



So, simply declaring that a gateway device shall support RFC 4103 and citing
standards references is insufficient. The problem is a complicated on a
number of levels, which is why carriers seem to favor treating TTY as voice.
Placing a requirement on gateway equipment to relay modulated TTY signals is
an uphill battle, and one that simply cannot be met with many of the tens of
thousands of already-deployed gateway devices in the field. When we can get
a foot in the door, to then further complicate the problem with multiple RTP
streams, multiplexing issues, and higher per-port costs, increased signaling
overhead, etc., will likely mean we stick with G.711 for legacy TTY support
indefinitely.



So, if I were to place bets on what I think stands the greatest chance of
succeeding on gateway devices in the carrier space, it would be (in order):

* V.152 (Voice Band Data, i.e., use G.711 or better for
pass-through)

* TIA-1001 / V.151 (if we can convince folks to do relay at all)

* RFC 4103



Paul





From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Gunnar
Hellström
Sent: Wednesday, May 23, 2007 5:19 PM
To: Teitac-telecom
Subject: [teitac-telecom] RFC 4103 reference for real-time text.



I want to comment on today?s meeting discussion on 1194.23(b), about the
explicit reference to RFC 4103 for real-time text.

It sounds good with many voices understanding the great benefits that are
within reach by moving to IP and getting a real-time text channel easily
integrated with other media in the calls.



However, Fred Lucas / TIA had some questions and concerns that I can answer
and hopefully resolve.



I will take them in portions.



Concern 1: ?RFC 4103 is not so much known protocol. Any protocol can be
decided now for this purpose.?



Answer: IETF RFC 4103 ?RTP Payload for text conversation? is an open
standard now referenced from at least 20 other standards from IETF, ITU-T,
3GPP and ETSI. It has for example been included as one of the three media
together with video and audio in IMS Multimedia Telephony. IMS is the next
environment we will see grow for establishing IP based telecom services.



These standards comprise:

-Transmission

-Service specification

-Terminal functionality

-Gateways

-Emergency services

-Relay services



No other standard for real-time text has the ambition to have this wide
coverage. It has taken some years to reach this acceptance level.



Here are a few excerpts:



1. >From RFC 4305, SIP telephony device requirements:

?Req-55: SIP telephony devices that include a display, or have a

facility for connecting an external display, MUST include

protocol support as described in RFC 4103 [23] for real-time

interactive text.?



2. >From ietf-draft-ecrit-requirements: ?Requirements for Emergency Context
Resolution with Internet Technologies?

?Emergency calling must support a variety of

media. Such media should include voice, conversational text
([RFC4103]), instant messaging and video.?



3. >From ITU-T V.151 ?Procedures for the end-to-end connection of analogue
PSTN text telephones over an IP network utilizing text relay?

?In general, ITDs transmit text characters when communicating with other
ITDs using RFC 4103, which specifies the establishment of a separate RTP
stream specifically for transmitting text characters.? ( ITDs are IP text
devices )



Etc.



Conclusion: Well covered in standards, ready for wider deployment.



Regards



Gunnar Hellström

-------------------------------------------------------------------

Gunnar Hellström

Omnitor

= EMAIL ADDRESS REMOVED =

Tel: +46708204288

www.omnitor.se





__________ NOD32 2285 (20070522) Information __________

Detta meddelande är genomsökt av NOD32 Antivirus.
http://www.nod32.com

From: Gregg Vanderheiden
Date: Thu, Jun 07 2007 5:55 PM
Subject: Re: RFC 4103 reference for real-time text.

Yep. But other security systems don't like finding text masquerading as
audio packet in and audio channel. So having the pair of them meets the
different criteria and needs in different systems.



Your thoughts on just requiring support for both?


Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.






_____


From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of John Combs
(jcombs)
Sent: Thursday, June 07, 2007 6:06 PM
To: TEITAC Telecommunications Subcommittee
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.

One reason they went with RFC-4351 is that is much more likely to get
through a firewall than RFC-4103 (because of the separate text & audio
channels in 4103).






_____


From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Gregg
Vanderheiden
Sent: Thursday, June 07, 2007 4:01 PM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.

RFC 4103 and RFC-4351 (the part of V.151 that is being referred to) are
very similar (almost identical except that 4103 ships text and audio data
on different channels where 4351 ships them on the same channel. They
both use T.140 for text encoding and RTP etc. ) Since they are so similar
it isnt that hard to support both if you support 4351 (which is arguably
slightly harder to implement than RFC-4103 since you have to sort out the
audio from the text packets in the audio channel) what about if we just
require the pair of them.



Then we have RFC-4103 for all IP to IP communication

and RFC-4351 for communication between VoIP devinces and PSTN gateways.



(RFC-4103 can communicate with PSTN gateways but would use up two ports
rather than 1)





If we require both 4103 adn 4351 then we provide both the clean 4103 and the
4351 which masquarades text in voice channels but is more efficient for PSTN
gateways where you mix the voice and text together anyway on the Analog
(PSTN) side.



Someday ? when there is no longer a PSTN and as PSTN slowly fades, we can
rely more and more on the 4103.





NOTE: this still allows closed systems like Skype, VoIP company systems,
Vonnage, Cable phone, etc to use whatever they want internally that is
reliable as long as they translate into the standard format when they
connect to other systems. They dont have to use them even then ? but have
to be able to be able to use them ? so that there is always something that
everyone supports so they can communicate/connect with text as they do with
voice.





Thoughts?




Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.






_____


From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Gunnar
Hellström
Sent: Thursday, June 07, 2007 4:15 PM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.

Paul,



A. IP to IP

Fine. This is an important step for good progress in design for all in
telecomms. Are there more parties who can join in this agreement?



B. PSTN to IP in large gateways

Just sending G.711 audio is likely not sufficiently reliable for TIA 825.
Because of its long character time of 165 ms, and its letter shift ? figure
shift technique, it is extremely sensitive to packet loss. The quite high
acceptable limit of 1% character errors require a theoretical packet loss
rate of a maximum of 0.1% when using plain G.711. That is too risky even in
good networks.

Much better with same bandwidth would probably be G.726 with one level of
redundancy. Then you would even allow 3% packet loss and still get usable
result. ( 1% errors). But beware! As recently discussed, other disturbing
effects like echo handlers and distorsion tends to come in and destroy the
real result as compared to the theoretical.



And what would be the destination of the audio coded text? I do not see it
realistic to take it all the way to the IP terminal. But possibly to an
intermediate gateway that converts to a text format that the terminal
supports. Do you want to propose double text codecs in all IP terminals
interested in TTY compatibility? One for IP to IP and one for IP ? PSTN?



Some efforts to support TTY transport should be maintained, but the users
have asked us to not focus all energy on that problem, so that the
functional enhancements within reach in IP networks are lost. I understand
that as a preparedness to discuss compromises, like using some added
procedures in order to be routed through text capable gateways.

Can we expect Emergency services and relay services to open an agreed IP ?
IP real-time text method ( A ) very soon? If not, good TTY interoperability
is at least needed for access to these services.



C. PSTN to IP in residential gateways and ATAs.

We need to have a solution for the case when a terminal behind an ATA calls
a native IP terminal. Should the call be routed to a big VoIP gateway where
proper support would be found for conversion to an IP transport of text that
is supported by the terminal.



D. PSTN to PSTN through IP

Yes, this is a GW to GW case, suitable for V.151 if you want.



Gunnar

-------------------------------------------------------------------

Gunnar Hellström

Omnitor

= EMAIL ADDRESS REMOVED =

Tel: +46708204288

www.omnitor.se


_____


From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Paul E. Jones
Sent: Thursday, June 07, 2007 10:09 PM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.



Gunnar,



A. Yeah, I think we can agree on RFC 4103 for IP text-capable devices.
(That does not change my argument for also wanting V.151 support to work
with gateways, though. But direct IP-terminal to IP-terminal should be RFC
4103.)



B. This is the sticky problem. Do we need to demodulate signals and
transport real text from large gateways, or do we just send G.711 audio?
Several years ago, there was a lot of concern expressed with packet loss and
unacceptable character error rate. ATIS held a meeting on this topic. We
initiated work on V.151 and completed that. But now, it seems that there is
a growing consensus that we no longer need to consider legacy TTY support.
So, I?m very confused. Do we need to further consider support for legacy
TTY devices?



C. ATAs ? What this requirement fails to consider is that more ATAs will
have fax devices connected to them than text phones. There will also be
standard modem devices and other devices (e.g., security alarm systems,
point of sale terminals, etc.) that may not use standard modulations. There
is little we can do for non-standard modulations, except to use G.711. But,
for standard modulations, we can to T.38 for fax, V.150 for modem, and V.151
for text. RFC 4103 could be considered, but it must be introduced in such a
way that fax calls and modem calls still work. For this reason, V.151 may
still be the better choice.



D. This sounds like a GW to GW case, which fits precisely within the scope
of V.151.



Paul



From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Gunnar
Hellström
Sent: Tuesday, June 05, 2007 5:52 PM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.



Paul and all,

I want to return to the discussion on 1194.23(b) about real-time text
interoperability.

We left it with too much uncertainty.



A. IP to IP

If we look through the arguments, we easily find that there is quite good
agreement on how to handle real-time text in the pure IP environment.

You, say:

?in spite of the many references to RFC 4103 (which I do favor for native IP
devices), there are concerns with the ability to utilize RFC 4103 on gateway
devices.?

This is also what the statements in 1194.23(b) say.

So, in fact there is an emerging agreement that RFC 4103 is to be favoured
between IP terminals. This agreement can also be seen in the growing number
of references in standards and policy documents.



Based on that agreement we can build a new class of high functionality,
fully interoperable IP Text capable phones and IP Total conversation devices
corresponding to the draft requirement 1194.23(b). Knowing that there is an
agreement on this level will encourage a good new market. Interoperability
is the key to popularity.



Do we have more parties agreeing on this?

----------------------------------------------------------



B. PSTN to IP in large gateways

With that agreement settled we may approach the issue of gateways between
TTY and IP Text capable terminals.

We use RFC 4103 in small scale PSTN/IP gateways without problems. But you
talk about possible concerns in large scale PSTN/IP gateways.



You correctly state:? Placing a requirement on gateway equipment to relay
modulated TTY signals is an uphill battle, and one that simply cannot be met
with many of the tens of thousands of already-deployed gateway devices in
the field.?

Other methods than forcing all ports to support TTY are required to achieve
TTY / IP text interoperability. It is very likely that we need to agree on
some way to route the calls that MAY contain TTY so that they pass gateway
ports with special capability of conversion between TTY and an IP real-time
text format. Such methods are discussed in standards groups, and they should
be encouraged to come to workable solutions.



C. PSTN to IP in residential gateways and ATAs.

Another problem is what to recommend for the analogue terminal adapters.
There you have no choice. If it provides a PSTN device port, it should
behave properly for attached TTY:s.



This is what RFC 4504 ?Sip Telephony devices? says about the ATA or
residential gateway:

-----From RFC 4504------



Req-57: SIP telephony devices MAY provide analog adaptor

functionality through an RJ-11 FXS port to support FXS

devices. If an RJ-11 (FXS) port is provided, then it MAY

support a gateway function from all text-telephone protocols

according to ITU-T Recommendation V.18 to RFC 4103 text

conversation (in fact, this is encouraged in the near term

during the transition to widespread use of SIP telephony

devices). If this gateway function is not included or fails,

the device MUST pass through all text-telephone protocols

according to ITU-T Recommendation V.18, November 2000, in a

transparent fashion.







--------------------------------

D. PSTN to PSTN through IP

This is another, more operator internal area that might need its own
discussion.





With A solved, we can carry on discussing B, C and possibly D.

The current language in



Gunnar

-------------------------------------------------------------------

Gunnar Hellström

Omnitor

= EMAIL ADDRESS REMOVED =

Tel: +46708204288

www.omnitor.se


_____


From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Paul E. Jones
Sent: Thursday, May 24, 2007 12:34 AM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.



Gunnar,



Not to drive the committee into a deep hole on this much-debated issue, but
in spite of the many references to RFC 4103 (which I do favor for native IP
devices), there are concerns with the ability to utilize RFC 4103 on gateway
devices. When developing TIA-1001, we were presented with a laundry list of
requirements that, unfortunately, RFC 4103 could not always satisfy for
gateway devices (or not very well). Thus, TIA-1001 and V.151 prescribe
something different, yet very similar in capability, as a primary means of
relaying text over IP.



Perhaps more important is the loud voices I hear in the industry that are
actually deploying equipment. As much as I?ve pushed to get support for a
text relay mechanism between analog TTY devices over IP, it is very
difficult to even get DSPs in the market that can do proper tone detection,
let alone error-free character extraction. Even if that issue is solved
(which it could be), we?re still faced with other problems:



* RFC 4103 consumes more resources on large gateways, which would
lead to higher port costs and/or lower port density

* The PSTN circuit is a multiplex of voice and TTY signals.
Separating text and voice into separate steams on IP, only to put them back
together again on a remote gateway, is a zero-gain exercise (i.e., it?s a
complete waste)

* It takes time to establish an RFC 4103 stream, especially if there
are H.248 media gateways, two media gateway controllers, and one or more
proxies in the call path (and we have all of this and more in the IMS
architecture), so RFC 4103 might introduce delays in initial communication
which can be avoided with TIA-1001

* For legacy TTY devices, carriers seem to not favor text relay at
all, preferring to use G.711 and simply pass TTY signals over G.711 (much to
my dismay)



So, simply declaring that a gateway device shall support RFC 4103 and citing
standards references is insufficient. The problem is a complicated on a
number of levels, which is why carriers seem to favor treating TTY as voice.
Placing a requirement on gateway equipment to relay modulated TTY signals is
an uphill battle, and one that simply cannot be met with many of the tens of
thousands of already-deployed gateway devices in the field. When we can get
a foot in the door, to then further complicate the problem with multiple RTP
streams, multiplexing issues, and higher per-port costs, increased signaling
overhead, etc., will likely mean we stick with G.711 for legacy TTY support
indefinitely.



So, if I were to place bets on what I think stands the greatest chance of
succeeding on gateway devices in the carrier space, it would be (in order):

* V.152 (Voice Band Data, i.e., use G.711 or better for
pass-through)

* TIA-1001 / V.151 (if we can convince folks to do relay at all)

* RFC 4103



Paul





From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Gunnar
Hellström
Sent: Wednesday, May 23, 2007 5:19 PM
To: Teitac-telecom
Subject: [teitac-telecom] RFC 4103 reference for real-time text.



I want to comment on today?s meeting discussion on 1194.23(b), about the
explicit reference to RFC 4103 for real-time text.

It sounds good with many voices understanding the great benefits that are
within reach by moving to IP and getting a real-time text channel easily
integrated with other media in the calls.



However, Fred Lucas / TIA had some questions and concerns that I can answer
and hopefully resolve.



I will take them in portions.



Concern 1: ?RFC 4103 is not so much known protocol. Any protocol can be
decided now for this purpose.?



Answer: IETF RFC 4103 ?RTP Payload for text conversation? is an open
standard now referenced from at least 20 other standards from IETF, ITU-T,
3GPP and ETSI. It has for example been included as one of the three media
together with video and audio in IMS Multimedia Telephony. IMS is the next
environment we will see grow for establishing IP based telecom services.



These standards comprise:

-Transmission

-Service specification

-Terminal functionality

-Gateways

-Emergency services

-Relay services



No other standard for real-time text has the ambition to have this wide
coverage. It has taken some years to reach this acceptance level.



Here are a few excerpts:



1. >From RFC 4305, SIP telephony device requirements:

?Req-55: SIP telephony devices that include a display, or have a

facility for connecting an external display, MUST include

protocol support as described in RFC 4103 [23] for real-time

interactive text.?



2. >From ietf-draft-ecrit-requirements: ?Requirements for Emergency Context
Resolution with Internet Technologies?

?Emergency calling must support a variety of

media. Such media should include voice, conversational text
([RFC4103]), instant messaging and video.?



3. >From ITU-T V.151 ?Procedures for the end-to-end connection of analogue
PSTN text telephones over an IP network utilizing text relay?

?In general, ITDs transmit text characters when communicating with other
ITDs using RFC 4103, which specifies the establishment of a separate RTP
stream specifically for transmitting text characters.? ( ITDs are IP text
devices )



Etc.



Conclusion: Well covered in standards, ready for wider deployment.



Regards



Gunnar Hellström

-------------------------------------------------------------------

Gunnar Hellström

Omnitor

= EMAIL ADDRESS REMOVED =

Tel: +46708204288

www.omnitor.se





__________ NOD32 2285 (20070522) Information __________

Detta meddelande är genomsökt av NOD32 Antivirus.
http://www.nod32.com



__________ NOD32 2313 (20070606) Information __________

Detta meddelande är genomsökt av NOD32 Antivirus.
http://www.nod32.com

From: Gunnar Hellström
Date: Fri, Jun 08 2007 1:05 AM
Subject: Re: RFC 4103 reference for real-time text.

Requiring RFC 4103 for real-time text and RFC 4351 for textphone
compatibility is likely the compromise that is easiest to accept.

This proposal is explained in an Annex to V.151.



It must still be allowed for gateways to go straight to RFC 4103. Gateways
should only be required to implement at least one of them.



What is the proposal for all implemented gateways that today do not support
any TTY compatibility?

- Update them to support the decided textphone compatibility
transport?

- Put some routing mechanism in place so that calls that likely
will contain text are directed to new text capable gateways?

- Put an ?afterburner? close to the gateway, converting between
good audio transport towards the gateway and a good text transport towards
the terminals for calls that may contain text?

( This is likely an operator decision, but it is good to know that it can be
solved )



For relay services and emergency services it would be sufficient with only
RFC 4103 in IP networks, as long as they maintain their PSTN connection for
TTY access.



What does operators and gateway manufacturers say? Would this proposed
compromise make life so much easier for big gateways, so that it would be
worth the extra burden on terminal and network manufacturers to support both
transports?

( For networks, it is for example a matter of letting two types of media
through the Network-to-Network Interfaces; the audio/t140c and the
text/t140. )



Gunnar

-------------------------------------------------------------------

Gunnar Hellström

Omnitor

= EMAIL ADDRESS REMOVED =

Tel: +46708204288

www.omnitor.se

_____

From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Gregg
Vanderheiden
Sent: Friday, June 08, 2007 1:47 AM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.



Yep. But other security systems don't like finding text masquerading as
audio packet in and audio channel. So having the pair of them meets the
different criteria and needs in different systems.



Your thoughts on just requiring support for both?


Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.

From: Paul E. Jones
Date: Fri, Jun 08 2007 1:15 PM
Subject: Re: RFC 4103 reference for real-time text.

Gunnar,



B. This is precisely the issue we really need to tackle. Do we force all
TTY users to have to continue using those devices until the end of time, can
we find a technology that enables us to bridge the old and new, or do we
just make a complete switch to something new? We?ve got three options and
it seems like there is no consensus. Initially, we were told support for
legacy TTY devices was very important, so we created V.151. Then we were
told they?re not. I just saw the document from the FCC, which seems to
strongly encourage (or mandate) support for accessibility capabilities, but
it is open to interpretation (somewhat). You want to enable users to make
calls using RFC 4103. But a VoIP service provider?s ATA device likely
cannot even detect Baudot tones, let alone discriminate between Baudot, EDT,
V.21 textphones, fax machines, and modems. This can be addressed, but
nobody wants to do anything and see it viewed as a wasted effort. We all
need to agree on what to do and then execute, but it?s really annoying that
we cannot reach a consensus. If packet loss is a problem, then having
centralized gateway do conversion from audio to text will not solve the
problem. So, we either have to ensure that we do not have packet loss,
forget about TTY support and move to new technology, or we must add proper
support for TTYs. Can we reach an agreement on this point?



C. So we do need to support the legacy devices? I would suggest that we
consider using V.151 Annex D.



Paul



From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Gunnar
Hellström
Sent: Thursday, June 07, 2007 5:15 PM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.



Paul,



A. IP to IP

Fine. This is an important step for good progress in design for all in
telecomms. Are there more parties who can join in this agreement?



B. PSTN to IP in large gateways

Just sending G.711 audio is likely not sufficiently reliable for TIA 825.
Because of its long character time of 165 ms, and its letter shift ? figure
shift technique, it is extremely sensitive to packet loss. The quite high
acceptable limit of 1% character errors require a theoretical packet loss
rate of a maximum of 0.1% when using plain G.711. That is too risky even in
good networks.

Much better with same bandwidth would probably be G.726 with one level of
redundancy. Then you would even allow 3% packet loss and still get usable
result. ( 1% errors). But beware! As recently discussed, other disturbing
effects like echo handlers and distorsion tends to come in and destroy the
real result as compared to the theoretical.



And what would be the destination of the audio coded text? I do not see it
realistic to take it all the way to the IP terminal. But possibly to an
intermediate gateway that converts to a text format that the terminal
supports. Do you want to propose double text codecs in all IP terminals
interested in TTY compatibility? One for IP to IP and one for IP ? PSTN?



Some efforts to support TTY transport should be maintained, but the users
have asked us to not focus all energy on that problem, so that the
functional enhancements within reach in IP networks are lost. I understand
that as a preparedness to discuss compromises, like using some added
procedures in order to be routed through text capable gateways.

Can we expect Emergency services and relay services to open an agreed IP ?
IP real-time text method ( A ) very soon? If not, good TTY interoperability
is at least needed for access to these services.



C. PSTN to IP in residential gateways and ATAs.

We need to have a solution for the case when a terminal behind an ATA calls
a native IP terminal. Should the call be routed to a big VoIP gateway where
proper support would be found for conversion to an IP transport of text that
is supported by the terminal.



D. PSTN to PSTN through IP

Yes, this is a GW to GW case, suitable for V.151 if you want.



Gunnar

-------------------------------------------------------------------

Gunnar Hellström

Omnitor

= EMAIL ADDRESS REMOVED =

Tel: +46708204288

www.omnitor.se

_____

From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Paul E. Jones
Sent: Thursday, June 07, 2007 10:09 PM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.



Gunnar,



A. Yeah, I think we can agree on RFC 4103 for IP text-capable devices.
(That does not change my argument for also wanting V.151 support to work
with gateways, though. But direct IP-terminal to IP-terminal should be RFC
4103.)



B. This is the sticky problem. Do we need to demodulate signals and
transport real text from large gateways, or do we just send G.711 audio?
Several years ago, there was a lot of concern expressed with packet loss and
unacceptable character error rate. ATIS held a meeting on this topic. We
initiated work on V.151 and completed that. But now, it seems that there is
a growing consensus that we no longer need to consider legacy TTY support.
So, I?m very confused. Do we need to further consider support for legacy
TTY devices?



C. ATAs ? What this requirement fails to consider is that more ATAs will
have fax devices connected to them than text phones. There will also be
standard modem devices and other devices (e.g., security alarm systems,
point of sale terminals, etc.) that may not use standard modulations. There
is little we can do for non-standard modulations, except to use G.711. But,
for standard modulations, we can to T.38 for fax, V.150 for modem, and V.151
for text. RFC 4103 could be considered, but it must be introduced in such a
way that fax calls and modem calls still work. For this reason, V.151 may
still be the better choice.



D. This sounds like a GW to GW case, which fits precisely within the scope
of V.151.



Paul



From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Gunnar
Hellström
Sent: Tuesday, June 05, 2007 5:52 PM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.



Paul and all,

I want to return to the discussion on 1194.23(b) about real-time text
interoperability.

We left it with too much uncertainty.



A. IP to IP

If we look through the arguments, we easily find that there is quite good
agreement on how to handle real-time text in the pure IP environment.

You, say:

?in spite of the many references to RFC 4103 (which I do favor for native IP
devices), there are concerns with the ability to utilize RFC 4103 on gateway
devices.?

This is also what the statements in 1194.23(b) say.

So, in fact there is an emerging agreement that RFC 4103 is to be favoured
between IP terminals. This agreement can also be seen in the growing number
of references in standards and policy documents.



Based on that agreement we can build a new class of high functionality,
fully interoperable IP Text capable phones and IP Total conversation devices
corresponding to the draft requirement 1194.23(b). Knowing that there is an
agreement on this level will encourage a good new market. Interoperability
is the key to popularity.



Do we have more parties agreeing on this?

----------------------------------------------------------



B. PSTN to IP in large gateways

With that agreement settled we may approach the issue of gateways between
TTY and IP Text capable terminals.

We use RFC 4103 in small scale PSTN/IP gateways without problems. But you
talk about possible concerns in large scale PSTN/IP gateways.



You correctly state:? Placing a requirement on gateway equipment to relay
modulated TTY signals is an uphill battle, and one that simply cannot be met
with many of the tens of thousands of already-deployed gateway devices in
the field.?

Other methods than forcing all ports to support TTY are required to achieve
TTY / IP text interoperability. It is very likely that we need to agree on
some way to route the calls that MAY contain TTY so that they pass gateway
ports with special capability of conversion between TTY and an IP real-time
text format. Such methods are discussed in standards groups, and they should
be encouraged to come to workable solutions.



C. PSTN to IP in residential gateways and ATAs.

Another problem is what to recommend for the analogue terminal adapters.
There you have no choice. If it provides a PSTN device port, it should
behave properly for attached TTY:s.



This is what RFC 4504 ?Sip Telephony devices? says about the ATA or
residential gateway:

-----From RFC 4504------



Req-57: SIP telephony devices MAY provide analog adaptor

functionality through an RJ-11 FXS port to support FXS

devices. If an RJ-11 (FXS) port is provided, then it MAY

support a gateway function from all text-telephone protocols

according to ITU-T Recommendation V.18 to RFC 4103 text

conversation (in fact, this is encouraged in the near term

during the transition to widespread use of SIP telephony

devices). If this gateway function is not included or fails,

the device MUST pass through all text-telephone protocols

according to ITU-T Recommendation V.18, November 2000, in a

transparent fashion.







--------------------------------

D. PSTN to PSTN through IP

This is another, more operator internal area that might need its own
discussion.





With A solved, we can carry on discussing B, C and possibly D.

The current language in



Gunnar

-------------------------------------------------------------------

Gunnar Hellström

Omnitor

= EMAIL ADDRESS REMOVED =

Tel: +46708204288

www.omnitor.se

_____

From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Paul E. Jones
Sent: Thursday, May 24, 2007 12:34 AM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.



Gunnar,



Not to drive the committee into a deep hole on this much-debated issue, but
in spite of the many references to RFC 4103 (which I do favor for native IP
devices), there are concerns with the ability to utilize RFC 4103 on gateway
devices. When developing TIA-1001, we were presented with a laundry list of
requirements that, unfortunately, RFC 4103 could not always satisfy for
gateway devices (or not very well). Thus, TIA-1001 and V.151 prescribe
something different, yet very similar in capability, as a primary means of
relaying text over IP.



Perhaps more important is the loud voices I hear in the industry that are
actually deploying equipment. As much as I?ve pushed to get support for a
text relay mechanism between analog TTY devices over IP, it is very
difficult to even get DSPs in the market that can do proper tone detection,
let alone error-free character extraction. Even if that issue is solved
(which it could be), we?re still faced with other problems:



· RFC 4103 consumes more resources on large gateways, which would
lead to higher port costs and/or lower port density

· The PSTN circuit is a multiplex of voice and TTY signals.
Separating text and voice into separate steams on IP, only to put them back
together again on a remote gateway, is a zero-gain exercise (i.e., it?s a
complete waste)

· It takes time to establish an RFC 4103 stream, especially if there
are H.248 media gateways, two media gateway controllers, and one or more
proxies in the call path (and we have all of this and more in the IMS
architecture), so RFC 4103 might introduce delays in initial communication
which can be avoided with TIA-1001

· For legacy TTY devices, carriers seem to not favor text relay at
all, preferring to use G.711 and simply pass TTY signals over G.711 (much to
my dismay)



So, simply declaring that a gateway device shall support RFC 4103 and citing
standards references is insufficient. The problem is a complicated on a
number of levels, which is why carriers seem to favor treating TTY as voice.
Placing a requirement on gateway equipment to relay modulated TTY signals is
an uphill battle, and one that simply cannot be met with many of the tens of
thousands of already-deployed gateway devices in the field. When we can get
a foot in the door, to then further complicate the problem with multiple RTP
streams, multiplexing issues, and higher per-port costs, increased signaling
overhead, etc., will likely mean we stick with G.711 for legacy TTY support
indefinitely.



So, if I were to place bets on what I think stands the greatest chance of
succeeding on gateway devices in the carrier space, it would be (in order):

· V.152 (Voice Band Data, i.e., use G.711 or better for
pass-through)

· TIA-1001 / V.151 (if we can convince folks to do relay at all)

· RFC 4103



Paul





From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Gunnar
Hellström
Sent: Wednesday, May 23, 2007 5:19 PM
To: Teitac-telecom
Subject: [teitac-telecom] RFC 4103 reference for real-time text.



I want to comment on today?s meeting discussion on 1194.23(b), about the
explicit reference to RFC 4103 for real-time text.

It sounds good with many voices understanding the great benefits that are
within reach by moving to IP and getting a real-time text channel easily
integrated with other media in the calls.



However, Fred Lucas / TIA had some questions and concerns that I can answer
and hopefully resolve.



I will take them in portions.



Concern 1: ?RFC 4103 is not so much known protocol. Any protocol can be
decided now for this purpose.?



Answer: IETF RFC 4103 ?RTP Payload for text conversation? is an open
standard now referenced from at least 20 other standards from IETF, ITU-T,
3GPP and ETSI. It has for example been included as one of the three media
together with video and audio in IMS Multimedia Telephony. IMS is the next
environment we will see grow for establishing IP based telecom services.



These standards comprise:

-Transmission

-Service specification

-Terminal functionality

-Gateways

-Emergency services

-Relay services



No other standard for real-time text has the ambition to have this wide
coverage. It has taken some years to reach this acceptance level.



Here are a few excerpts:



1. >From RFC 4305, SIP telephony device requirements:

?Req-55: SIP telephony devices that include a display, or have a

facility for connecting an external display, MUST include

protocol support as described in RFC 4103 [23] for real-time

interactive text.?



2. >From ietf-draft-ecrit-requirements: ?Requirements for Emergency Context
Resolution with Internet Technologies?

?Emergency calling must support a variety of

media. Such media should include voice, conversational text
([RFC4103]), instant messaging and video.?



3. >From ITU-T V.151 ?Procedures for the end-to-end connection of analogue
PSTN text telephones over an IP network utilizing text relay?

?In general, ITDs transmit text characters when communicating with other
ITDs using RFC 4103, which specifies the establishment of a separate RTP
stream specifically for transmitting text characters.? ( ITDs are IP text
devices )



Etc.



Conclusion: Well covered in standards, ready for wider deployment.



Regards



Gunnar Hellström

-------------------------------------------------------------------

Gunnar Hellström

Omnitor

= EMAIL ADDRESS REMOVED =

Tel: +46708204288

www.omnitor.se





__________ NOD32 2285 (20070522) Information __________

Detta meddelande är genomsökt av NOD32 Antivirus.
http://www.nod32.com



__________ NOD32 2313 (20070606) Information __________

Detta meddelande är genomsökt av NOD32 Antivirus.
http://www.nod32.com

From: Paul E. Jones
Date: Fri, Jun 08 2007 1:30 PM
Subject: Re: RFC 4103 reference for real-time text.

Gregg,



Why would firewall block the ?audio?? That?s exactly how DTMF or other
audio ?events? are exchanged in VoIP systems. If a key is pressed on a
keypad, it is translated into an RFC 2833/4733 data packet that indicates
which key is pressed. RFC 4351 (V.151) does the same thing for text,
translating modulated text signals into a data packet indicating ?what key
is pressed?.



Paul





From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Gregg
Vanderheiden
Sent: Thursday, June 07, 2007 7:47 PM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.



Yep. But other security systems don't like finding text masquerading as
audio packet in and audio channel. So having the pair of them meets the
different criteria and needs in different systems.



Your thoughts on just requiring support for both?


Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.






_____


From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of John Combs
(jcombs)
Sent: Thursday, June 07, 2007 6:06 PM
To: TEITAC Telecommunications Subcommittee
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.

One reason they went with RFC-4351 is that is much more likely to get
through a firewall than RFC-4103 (because of the separate text & audio
channels in 4103).






_____


From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Gregg
Vanderheiden
Sent: Thursday, June 07, 2007 4:01 PM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.

RFC 4103 and RFC-4351 (the part of V.151 that is being referred to) are
very similar (almost identical except that 4103 ships text and audio data
on different channels where 4351 ships them on the same channel. They
both use T.140 for text encoding and RTP etc. ) Since they are so similar
it isnt that hard to support both if you support 4351 (which is arguably
slightly harder to implement than RFC-4103 since you have to sort out the
audio from the text packets in the audio channel) what about if we just
require the pair of them.



Then we have RFC-4103 for all IP to IP communication

and RFC-4351 for communication between VoIP devinces and PSTN gateways.



(RFC-4103 can communicate with PSTN gateways but would use up two ports
rather than 1)





If we require both 4103 adn 4351 then we provide both the clean 4103 and the
4351 which masquarades text in voice channels but is more efficient for PSTN
gateways where you mix the voice and text together anyway on the Analog
(PSTN) side.



Someday ? when there is no longer a PSTN and as PSTN slowly fades, we can
rely more and more on the 4103.





NOTE: this still allows closed systems like Skype, VoIP company systems,
Vonnage, Cable phone, etc to use whatever they want internally that is
reliable as long as they translate into the standard format when they
connect to other systems. They dont have to use them even then ? but have
to be able to be able to use them ? so that there is always something that
everyone supports so they can communicate/connect with text as they do with
voice.





Thoughts?




Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.






_____


From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Gunnar
Hellström
Sent: Thursday, June 07, 2007 4:15 PM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.

Paul,



A. IP to IP

Fine. This is an important step for good progress in design for all in
telecomms. Are there more parties who can join in this agreement?



B. PSTN to IP in large gateways

Just sending G.711 audio is likely not sufficiently reliable for TIA 825.
Because of its long character time of 165 ms, and its letter shift ? figure
shift technique, it is extremely sensitive to packet loss. The quite high
acceptable limit of 1% character errors require a theoretical packet loss
rate of a maximum of 0.1% when using plain G.711. That is too risky even in
good networks.

Much better with same bandwidth would probably be G.726 with one level of
redundancy. Then you would even allow 3% packet loss and still get usable
result. ( 1% errors). But beware! As recently discussed, other disturbing
effects like echo handlers and distorsion tends to come in and destroy the
real result as compared to the theoretical.



And what would be the destination of the audio coded text? I do not see it
realistic to take it all the way to the IP terminal. But possibly to an
intermediate gateway that converts to a text format that the terminal
supports. Do you want to propose double text codecs in all IP terminals
interested in TTY compatibility? One for IP to IP and one for IP ? PSTN?



Some efforts to support TTY transport should be maintained, but the users
have asked us to not focus all energy on that problem, so that the
functional enhancements within reach in IP networks are lost. I understand
that as a preparedness to discuss compromises, like using some added
procedures in order to be routed through text capable gateways.

Can we expect Emergency services and relay services to open an agreed IP ?
IP real-time text method ( A ) very soon? If not, good TTY interoperability
is at least needed for access to these services.



C. PSTN to IP in residential gateways and ATAs.

We need to have a solution for the case when a terminal behind an ATA calls
a native IP terminal. Should the call be routed to a big VoIP gateway where
proper support would be found for conversion to an IP transport of text that
is supported by the terminal.



D. PSTN to PSTN through IP

Yes, this is a GW to GW case, suitable for V.151 if you want.



Gunnar

-------------------------------------------------------------------

Gunnar Hellström

Omnitor

= EMAIL ADDRESS REMOVED =

Tel: +46708204288

www.omnitor.se


_____


From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Paul E. Jones
Sent: Thursday, June 07, 2007 10:09 PM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.



Gunnar,



A. Yeah, I think we can agree on RFC 4103 for IP text-capable devices.
(That does not change my argument for also wanting V.151 support to work
with gateways, though. But direct IP-terminal to IP-terminal should be RFC
4103.)



B. This is the sticky problem. Do we need to demodulate signals and
transport real text from large gateways, or do we just send G.711 audio?
Several years ago, there was a lot of concern expressed with packet loss and
unacceptable character error rate. ATIS held a meeting on this topic. We
initiated work on V.151 and completed that. But now, it seems that there is
a growing consensus that we no longer need to consider legacy TTY support.
So, I?m very confused. Do we need to further consider support for legacy
TTY devices?



C. ATAs ? What this requirement fails to consider is that more ATAs will
have fax devices connected to them than text phones. There will also be
standard modem devices and other devices (e.g., security alarm systems,
point of sale terminals, etc.) that may not use standard modulations. There
is little we can do for non-standard modulations, except to use G.711. But,
for standard modulations, we can to T.38 for fax, V.150 for modem, and V.151
for text. RFC 4103 could be considered, but it must be introduced in such a
way that fax calls and modem calls still work. For this reason, V.151 may
still be the better choice.



D. This sounds like a GW to GW case, which fits precisely within the scope
of V.151.



Paul



From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Gunnar
Hellström
Sent: Tuesday, June 05, 2007 5:52 PM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.



Paul and all,

I want to return to the discussion on 1194.23(b) about real-time text
interoperability.

We left it with too much uncertainty.



A. IP to IP

If we look through the arguments, we easily find that there is quite good
agreement on how to handle real-time text in the pure IP environment.

You, say:

?in spite of the many references to RFC 4103 (which I do favor for native IP
devices), there are concerns with the ability to utilize RFC 4103 on gateway
devices.?

This is also what the statements in 1194.23(b) say.

So, in fact there is an emerging agreement that RFC 4103 is to be favoured
between IP terminals. This agreement can also be seen in the growing number
of references in standards and policy documents.



Based on that agreement we can build a new class of high functionality,
fully interoperable IP Text capable phones and IP Total conversation devices
corresponding to the draft requirement 1194.23(b). Knowing that there is an
agreement on this level will encourage a good new market. Interoperability
is the key to popularity.



Do we have more parties agreeing on this?

----------------------------------------------------------



B. PSTN to IP in large gateways

With that agreement settled we may approach the issue of gateways between
TTY and IP Text capable terminals.

We use RFC 4103 in small scale PSTN/IP gateways without problems. But you
talk about possible concerns in large scale PSTN/IP gateways.



You correctly state:? Placing a requirement on gateway equipment to relay
modulated TTY signals is an uphill battle, and one that simply cannot be met
with many of the tens of thousands of already-deployed gateway devices in
the field.?

Other methods than forcing all ports to support TTY are required to achieve
TTY / IP text interoperability. It is very likely that we need to agree on
some way to route the calls that MAY contain TTY so that they pass gateway
ports with special capability of conversion between TTY and an IP real-time
text format. Such methods are discussed in standards groups, and they should
be encouraged to come to workable solutions.



C. PSTN to IP in residential gateways and ATAs.

Another problem is what to recommend for the analogue terminal adapters.
There you have no choice. If it provides a PSTN device port, it should
behave properly for attached TTY:s.



This is what RFC 4504 ?Sip Telephony devices? says about the ATA or
residential gateway:

-----From RFC 4504------



Req-57: SIP telephony devices MAY provide analog adaptor

functionality through an RJ-11 FXS port to support FXS

devices. If an RJ-11 (FXS) port is provided, then it MAY

support a gateway function from all text-telephone protocols

according to ITU-T Recommendation V.18 to RFC 4103 text

conversation (in fact, this is encouraged in the near term

during the transition to widespread use of SIP telephony

devices). If this gateway function is not included or fails,

the device MUST pass through all text-telephone protocols

according to ITU-T Recommendation V.18, November 2000, in a

transparent fashion.







--------------------------------

D. PSTN to PSTN through IP

This is another, more operator internal area that might need its own
discussion.





With A solved, we can carry on discussing B, C and possibly D.

The current language in



Gunnar

-------------------------------------------------------------------

Gunnar Hellström

Omnitor

= EMAIL ADDRESS REMOVED =

Tel: +46708204288

www.omnitor.se


_____


From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Paul E. Jones
Sent: Thursday, May 24, 2007 12:34 AM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.



Gunnar,



Not to drive the committee into a deep hole on this much-debated issue, but
in spite of the many references to RFC 4103 (which I do favor for native IP
devices), there are concerns with the ability to utilize RFC 4103 on gateway
devices. When developing TIA-1001, we were presented with a laundry list of
requirements that, unfortunately, RFC 4103 could not always satisfy for
gateway devices (or not very well). Thus, TIA-1001 and V.151 prescribe
something different, yet very similar in capability, as a primary means of
relaying text over IP.



Perhaps more important is the loud voices I hear in the industry that are
actually deploying equipment. As much as I?ve pushed to get support for a
text relay mechanism between analog TTY devices over IP, it is very
difficult to even get DSPs in the market that can do proper tone detection,
let alone error-free character extraction. Even if that issue is solved
(which it could be), we?re still faced with other problems:



· RFC 4103 consumes more resources on large gateways, which would
lead to higher port costs and/or lower port density

· The PSTN circuit is a multiplex of voice and TTY signals.
Separating text and voice into separate steams on IP, only to put them back
together again on a remote gateway, is a zero-gain exercise (i.e., it?s a
complete waste)

· It takes time to establish an RFC 4103 stream, especially if there
are H.248 media gateways, two media gateway controllers, and one or more
proxies in the call path (and we have all of this and more in the IMS
architecture), so RFC 4103 might introduce delays in initial communication
which can be avoided with TIA-1001

· For legacy TTY devices, carriers seem to not favor text relay at
all, preferring to use G.711 and simply pass TTY signals over G.711 (much to
my dismay)



So, simply declaring that a gateway device shall support RFC 4103 and citing
standards references is insufficient. The problem is a complicated on a
number of levels, which is why carriers seem to favor treating TTY as voice.
Placing a requirement on gateway equipment to relay modulated TTY signals is
an uphill battle, and one that simply cannot be met with many of the tens of
thousands of already-deployed gateway devices in the field. When we can get
a foot in the door, to then further complicate the problem with multiple RTP
streams, multiplexing issues, and higher per-port costs, increased signaling
overhead, etc., will likely mean we stick with G.711 for legacy TTY support
indefinitely.



So, if I were to place bets on what I think stands the greatest chance of
succeeding on gateway devices in the carrier space, it would be (in order):

· V.152 (Voice Band Data, i.e., use G.711 or better for
pass-through)

· TIA-1001 / V.151 (if we can convince folks to do relay at all)

· RFC 4103



Paul





From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Gunnar
Hellström
Sent: Wednesday, May 23, 2007 5:19 PM
To: Teitac-telecom
Subject: [teitac-telecom] RFC 4103 reference for real-time text.



I want to comment on today?s meeting discussion on 1194.23(b), about the
explicit reference to RFC 4103 for real-time text.

It sounds good with many voices understanding the great benefits that are
within reach by moving to IP and getting a real-time text channel easily
integrated with other media in the calls.



However, Fred Lucas / TIA had some questions and concerns that I can answer
and hopefully resolve.



I will take them in portions.



Concern 1: ?RFC 4103 is not so much known protocol. Any protocol can be
decided now for this purpose.?



Answer: IETF RFC 4103 ?RTP Payload for text conversation? is an open
standard now referenced from at least 20 other standards from IETF, ITU-T,
3GPP and ETSI. It has for example been included as one of the three media
together with video and audio in IMS Multimedia Telephony. IMS is the next
environment we will see grow for establishing IP based telecom services.



These standards comprise:

-Transmission

-Service specification

-Terminal functionality

-Gateways

-Emergency services

-Relay services



No other standard for real-time text has the ambition to have this wide
coverage. It has taken some years to reach this acceptance level.



Here are a few excerpts:



1. >From RFC 4305, SIP telephony device requirements:

?Req-55: SIP telephony devices that include a display, or have a

facility for connecting an external display, MUST include

protocol support as described in RFC 4103 [23] for real-time

interactive text.?



2. >From ietf-draft-ecrit-requirements: ?Requirements for Emergency Context
Resolution with Internet Technologies?

?Emergency calling must support a variety of

media. Such media should include voice, conversational text
([RFC4103]), instant messaging and video.?



3. >From ITU-T V.151 ?Procedures for the end-to-end connection of analogue
PSTN text telephones over an IP network utilizing text relay?

?In general, ITDs transmit text characters when communicating with other
ITDs using RFC 4103, which specifies the establishment of a separate RTP
stream specifically for transmitting text characters.? ( ITDs are IP text
devices )



Etc.



Conclusion: Well covered in standards, ready for wider deployment.



Regards



Gunnar Hellström

-------------------------------------------------------------------

Gunnar Hellström

Omnitor

= EMAIL ADDRESS REMOVED =

Tel: +46708204288

www.omnitor.se





__________ NOD32 2285 (20070522) Information __________

Detta meddelande är genomsökt av NOD32 Antivirus.
http://www.nod32.com



__________ NOD32 2313 (20070606) Information __________

Detta meddelande är genomsökt av NOD32 Antivirus.
http://www.nod32.com

From: Pam Ransom
Date: Fri, Jun 08 2007 1:35 PM
Subject: Re: RFC 4103 reference for real-time text.

Just a reminder ... There are approximately 25-27 states that continue to administer TTY Distribution Programs, and thus there is a significant embedded base of this older TTY technology. Pam Ransom
----- Original Message -----
From: Paul E. Jones
To: 'TEITAC Telecommunications Subcommittee'
Sent: Friday, June 08, 2007 2:10 PM
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.


Gunnar,



B. This is precisely the issue we really need to tackle. Do we force all TTY users to have to continue using those devices until the end of time, can we find a technology that enables us to bridge the old and new, or do we just make a complete switch to something new? We've got three options and it seems like there is no consensus. Initially, we were told support for legacy TTY devices was very important, so we created V.151. Then we were told they're not. I just saw the document from the FCC, which seems to strongly encourage (or mandate) support for accessibility capabilities, but it is open to interpretation (somewhat). You want to enable users to make calls using RFC 4103. But a VoIP service provider's ATA device likely cannot even detect Baudot tones, let alone discriminate between Baudot, EDT, V.21 textphones, fax machines, and modems. This can be addressed, but nobody wants to do anything and see it viewed as a wasted effort. We all need to agree on what to do and then execute, but it's really annoying that we cannot reach a consensus. If packet loss is a problem, then having centralized gateway do conversion from audio to text will not solve the problem. So, we either have to ensure that we do not have packet loss, forget about TTY support and move to new technology, or we must add proper support for TTYs. Can we reach an agreement on this point?



C. So we do need to support the legacy devices? I would suggest that we consider using V.151 Annex D.



Paul



From: = EMAIL ADDRESS REMOVED = [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Gunnar Hellström
Sent: Thursday, June 07, 2007 5:15 PM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.



Paul,



A. IP to IP

Fine. This is an important step for good progress in design for all in telecomms. Are there more parties who can join in this agreement?



B. PSTN to IP in large gateways

Just sending G.711 audio is likely not sufficiently reliable for TIA 825. Because of its long character time of 165 ms, and its letter shift - figure shift technique, it is extremely sensitive to packet loss. The quite high acceptable limit of 1% character errors require a theoretical packet loss rate of a maximum of 0.1% when using plain G.711. That is too risky even in good networks.

Much better with same bandwidth would probably be G.726 with one level of redundancy. Then you would even allow 3% packet loss and still get usable result. ( 1% errors). But beware! As recently discussed, other disturbing effects like echo handlers and distorsion tends to come in and destroy the real result as compared to the theoretical.



And what would be the destination of the audio coded text? I do not see it realistic to take it all the way to the IP terminal. But possibly to an intermediate gateway that converts to a text format that the terminal supports. Do you want to propose double text codecs in all IP terminals interested in TTY compatibility? One for IP to IP and one for IP - PSTN?



Some efforts to support TTY transport should be maintained, but the users have asked us to not focus all energy on that problem, so that the functional enhancements within reach in IP networks are lost. I understand that as a preparedness to discuss compromises, like using some added procedures in order to be routed through text capable gateways.

Can we expect Emergency services and relay services to open an agreed IP - IP real-time text method ( A ) very soon? If not, good TTY interoperability is at least needed for access to these services.



C. PSTN to IP in residential gateways and ATAs.

We need to have a solution for the case when a terminal behind an ATA calls a native IP terminal. Should the call be routed to a big VoIP gateway where proper support would be found for conversion to an IP transport of text that is supported by the terminal.



D. PSTN to PSTN through IP

Yes, this is a GW to GW case, suitable for V.151 if you want.



Gunnar

-------------------------------------------------------------------

Gunnar Hellström

Omnitor

= EMAIL ADDRESS REMOVED =

Tel: +46708204288

www.omnitor.se


------------------------------------------------------------------------------

From: = EMAIL ADDRESS REMOVED = [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Paul E. Jones
Sent: Thursday, June 07, 2007 10:09 PM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.



Gunnar,



A. Yeah, I think we can agree on RFC 4103 for IP text-capable devices. (That does not change my argument for also wanting V.151 support to work with gateways, though. But direct IP-terminal to IP-terminal should be RFC 4103.)



B. This is the sticky problem. Do we need to demodulate signals and transport real text from large gateways, or do we just send G.711 audio? Several years ago, there was a lot of concern expressed with packet loss and unacceptable character error rate. ATIS held a meeting on this topic. We initiated work on V.151 and completed that. But now, it seems that there is a growing consensus that we no longer need to consider legacy TTY support. So, I'm very confused. Do we need to further consider support for legacy TTY devices?



C. ATAs - What this requirement fails to consider is that more ATAs will have fax devices connected to them than text phones. There will also be standard modem devices and other devices (e.g., security alarm systems, point of sale terminals, etc.) that may not use standard modulations. There is little we can do for non-standard modulations, except to use G.711. But, for standard modulations, we can to T.38 for fax, V.150 for modem, and V.151 for text. RFC 4103 could be considered, but it must be introduced in such a way that fax calls and modem calls still work. For this reason, V.151 may still be the better choice.



D. This sounds like a GW to GW case, which fits precisely within the scope of V.151.



Paul



From: = EMAIL ADDRESS REMOVED = [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Gunnar Hellström
Sent: Tuesday, June 05, 2007 5:52 PM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.



Paul and all,

I want to return to the discussion on 1194.23(b) about real-time text interoperability.

We left it with too much uncertainty.



A. IP to IP

If we look through the arguments, we easily find that there is quite good agreement on how to handle real-time text in the pure IP environment.

You, say:

"in spite of the many references to RFC 4103 (which I do favor for native IP devices), there are concerns with the ability to utilize RFC 4103 on gateway devices."

This is also what the statements in 1194.23(b) say.

So, in fact there is an emerging agreement that RFC 4103 is to be favoured between IP terminals. This agreement can also be seen in the growing number of references in standards and policy documents.



Based on that agreement we can build a new class of high functionality, fully interoperable IP Text capable phones and IP Total conversation devices corresponding to the draft requirement 1194.23(b). Knowing that there is an agreement on this level will encourage a good new market. Interoperability is the key to popularity.



Do we have more parties agreeing on this?

----------------------------------------------------------



B. PSTN to IP in large gateways

With that agreement settled we may approach the issue of gateways between TTY and IP Text capable terminals.

We use RFC 4103 in small scale PSTN/IP gateways without problems. But you talk about possible concerns in large scale PSTN/IP gateways.



You correctly state:" Placing a requirement on gateway equipment to relay modulated TTY signals is an uphill battle, and one that simply cannot be met with many of the tens of thousands of already-deployed gateway devices in the field."

Other methods than forcing all ports to support TTY are required to achieve TTY / IP text interoperability. It is very likely that we need to agree on some way to route the calls that MAY contain TTY so that they pass gateway ports with special capability of conversion between TTY and an IP real-time text format. Such methods are discussed in standards groups, and they should be encouraged to come to workable solutions.



C. PSTN to IP in residential gateways and ATAs.

Another problem is what to recommend for the analogue terminal adapters. There you have no choice. If it provides a PSTN device port, it should behave properly for attached TTY:s.



This is what RFC 4504 "Sip Telephony devices" says about the ATA or residential gateway:

-----From RFC 4504------



Req-57: SIP telephony devices MAY provide analog adaptor

functionality through an RJ-11 FXS port to support FXS

devices. If an RJ-11 (FXS) port is provided, then it MAY

support a gateway function from all text-telephone protocols

according to ITU-T Recommendation V.18 to RFC 4103 text

conversation (in fact, this is encouraged in the near term

during the transition to widespread use of SIP telephony

devices). If this gateway function is not included or fails,

the device MUST pass through all text-telephone protocols

according to ITU-T Recommendation V.18, November 2000, in a

transparent fashion.







--------------------------------

D. PSTN to PSTN through IP

This is another, more operator internal area that might need its own discussion.





With A solved, we can carry on discussing B, C and possibly D.

The current language in



Gunnar

-------------------------------------------------------------------

Gunnar Hellström

Omnitor

= EMAIL ADDRESS REMOVED =

Tel: +46708204288

www.omnitor.se


------------------------------------------------------------------------------

From: = EMAIL ADDRESS REMOVED = [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Paul E. Jones
Sent: Thursday, May 24, 2007 12:34 AM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.



Gunnar,



Not to drive the committee into a deep hole on this much-debated issue, but in spite of the many references to RFC 4103 (which I do favor for native IP devices), there are concerns with the ability to utilize RFC 4103 on gateway devices. When developing TIA-1001, we were presented with a laundry list of requirements that, unfortunately, RFC 4103 could not always satisfy for gateway devices (or not very well). Thus, TIA-1001 and V.151 prescribe something different, yet very similar in capability, as a primary means of relaying text over IP.



Perhaps more important is the loud voices I hear in the industry that are actually deploying equipment. As much as I've pushed to get support for a text relay mechanism between analog TTY devices over IP, it is very difficult to even get DSPs in the market that can do proper tone detection, let alone error-free character extraction. Even if that issue is solved (which it could be), we're still faced with other problems:



· RFC 4103 consumes more resources on large gateways, which would lead to higher port costs and/or lower port density

· The PSTN circuit is a multiplex of voice and TTY signals. Separating text and voice into separate steams on IP, only to put them back together again on a remote gateway, is a zero-gain exercise (i.e., it's a complete waste)

· It takes time to establish an RFC 4103 stream, especially if there are H.248 media gateways, two media gateway controllers, and one or more proxies in the call path (and we have all of this and more in the IMS architecture), so RFC 4103 might introduce delays in initial communication which can be avoided with TIA-1001

· For legacy TTY devices, carriers seem to not favor text relay at all, preferring to use G.711 and simply pass TTY signals over G.711 (much to my dismay)



So, simply declaring that a gateway device shall support RFC 4103 and citing standards references is insufficient. The problem is a complicated on a number of levels, which is why carriers seem to favor treating TTY as voice. Placing a requirement on gateway equipment to relay modulated TTY signals is an uphill battle, and one that simply cannot be met with many of the tens of thousands of already-deployed gateway devices in the field. When we can get a foot in the door, to then further complicate the problem with multiple RTP streams, multiplexing issues, and higher per-port costs, increased signaling overhead, etc., will likely mean we stick with G.711 for legacy TTY support indefinitely.



So, if I were to place bets on what I think stands the greatest chance of succeeding on gateway devices in the carrier space, it would be (in order):

· V.152 (Voice Band Data, i.e., use G.711 or better for pass-through)

· TIA-1001 / V.151 (if we can convince folks to do relay at all)

· RFC 4103



Paul





From: = EMAIL ADDRESS REMOVED = [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Gunnar Hellström
Sent: Wednesday, May 23, 2007 5:19 PM
To: Teitac-telecom
Subject: [teitac-telecom] RFC 4103 reference for real-time text.



I want to comment on today's meeting discussion on 1194.23(b), about the explicit reference to RFC 4103 for real-time text.

It sounds good with many voices understanding the great benefits that are within reach by moving to IP and getting a real-time text channel easily integrated with other media in the calls.



However, Fred Lucas / TIA had some questions and concerns that I can answer and hopefully resolve.



I will take them in portions.



Concern 1: "RFC 4103 is not so much known protocol. Any protocol can be decided now for this purpose."



Answer: IETF RFC 4103 "RTP Payload for text conversation" is an open standard now referenced from at least 20 other standards from IETF, ITU-T, 3GPP and ETSI. It has for example been included as one of the three media together with video and audio in IMS Multimedia Telephony. IMS is the next environment we will see grow for establishing IP based telecom services.



These standards comprise:

-Transmission

-Service specification

-Terminal functionality

-Gateways

-Emergency services

-Relay services



No other standard for real-time text has the ambition to have this wide coverage. It has taken some years to reach this acceptance level.



Here are a few excerpts:



1. >From RFC 4305, SIP telephony device requirements:

"Req-55: SIP telephony devices that include a display, or have a

facility for connecting an external display, MUST include

protocol support as described in RFC 4103 [23] for real-time

interactive text."



2. >From ietf-draft-ecrit-requirements: "Requirements for Emergency Context Resolution with Internet Technologies"

"Emergency calling must support a variety of

media. Such media should include voice, conversational text
([RFC4103]), instant messaging and video."



3. >From ITU-T V.151 "Procedures for the end-to-end connection of analogue PSTN text telephones over an IP network utilizing text relay"

"In general, ITDs transmit text characters when communicating with other ITDs using RFC 4103, which specifies the establishment of a separate RTP stream specifically for transmitting text characters." ( ITDs are IP text devices )



Etc.



Conclusion: Well covered in standards, ready for wider deployment.



Regards



Gunnar Hellström

-------------------------------------------------------------------

Gunnar Hellström

Omnitor

= EMAIL ADDRESS REMOVED =

Tel: +46708204288

www.omnitor.se





__________ NOD32 2285 (20070522) Information __________

Detta meddelande är genomsökt av NOD32 Antivirus.
http://www.nod32.com



__________ NOD32 2313 (20070606) Information __________

Detta meddelande är genomsökt av NOD32 Antivirus.
http://www.nod32.com



------------------------------------------------------------------------------

From: Diane Golden
Date: Fri, Jun 08 2007 2:15 PM
Subject: Re: RFC 4103 reference for real-time text.

On behalf of one of the state programs that distribute adaptive telephone
equipment, pure TTY's are a very tiny part of the distribution today. The
numbers have steadily decreased year after year as people move to other
equipment options. What we don't have is good data on how many people use
the TTY as their only telecom equipment rather than a secondary or
supplemental option. We do now distribute more VCO phones (including
regular VCO and CapTel) than TTYs and for pretty much all of these people
that is the only telecom option they have. So that group may actually be
our biggest legacy equipment problem.

Diane

Diane Cordry Golden, Ph.D., Director
Missouri Assistive Technology
816/350-5280 (direct voice)
= EMAIL ADDRESS REMOVED =
www.at.mo.gov



-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ]On Behalf Of Pam Ransom
Sent: Friday, June 08, 2007 2:16 PM
To: TEITAC Telecommunications Subcommittee
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.


Just a reminder ... There are approximately 25-27 states that continue to
administer TTY Distribution Programs, and thus there is a significant
embedded base of this older TTY technology. Pam Ransom
----- Original Message -----
From: Paul E. Jones
To: 'TEITAC Telecommunications Subcommittee'
Sent: Friday, June 08, 2007 2:10 PM
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.


Gunnar,



B. This is precisely the issue we really need to tackle. Do we force all
TTY users to have to continue using those devices until the end of time, can
we find a technology that enables us to bridge the old and new, or do we
just make a complete switch to something new? We've got three options and
it seems like there is no consensus. Initially, we were told support for
legacy TTY devices was very important, so we created V.151. Then we were
told they're not. I just saw the document from the FCC, which seems to
strongly encourage (or mandate) support for accessibility capabilities, but
it is open to interpretation (somewhat). You want to enable users to make
calls using RFC 4103. But a VoIP service provider's ATA device likely
cannot even detect Baudot tones, let alone discriminate between Baudot, EDT,
V.21 textphones, fax machines, and modems. This can be addressed, but
nobody wants to do anything and see it viewed as a wasted effort. We all
need to agree on what to do and then execute, but it's really annoying that
we cannot reach a consensus. If packet loss is a problem, then having
centralized gateway do conversion from audio to text will not solve the
problem. So, we either have to ensure that we do not have packet loss,
forget about TTY support and move to new technology, or we must add proper
support for TTYs. Can we reach an agreement on this point?



C. So we do need to support the legacy devices? I would suggest that we
consider using V.151 Annex D.



Paul



From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Gunnar
Hellström
Sent: Thursday, June 07, 2007 5:15 PM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.



Paul,



A. IP to IP

Fine. This is an important step for good progress in design for all in
telecomms. Are there more parties who can join in this agreement?



B. PSTN to IP in large gateways

Just sending G.711 audio is likely not sufficiently reliable for TIA 825.
Because of its long character time of 165 ms, and its letter shift - figure
shift technique, it is extremely sensitive to packet loss. The quite high
acceptable limit of 1% character errors require a theoretical packet loss
rate of a maximum of 0.1% when using plain G.711. That is too risky even in
good networks.

Much better with same bandwidth would probably be G.726 with one level of
redundancy. Then you would even allow 3% packet loss and still get usable
result. ( 1% errors). But beware! As recently discussed, other disturbing
effects like echo handlers and distorsion tends to come in and destroy the
real result as compared to the theoretical.



And what would be the destination of the audio coded text? I do not see it
realistic to take it all the way to the IP terminal. But possibly to an
intermediate gateway that converts to a text format that the terminal
supports. Do you want to propose double text codecs in all IP terminals
interested in TTY compatibility? One for IP to IP and one for IP - PSTN?



Some efforts to support TTY transport should be maintained, but the users
have asked us to not focus all energy on that problem, so that the
functional enhancements within reach in IP networks are lost. I understand
that as a preparedness to discuss compromises, like using some added
procedures in order to be routed through text capable gateways.

Can we expect Emergency services and relay services to open an agreed IP -
IP real-time text method ( A ) very soon? If not, good TTY interoperability
is at least needed for access to these services.



C. PSTN to IP in residential gateways and ATAs.

We need to have a solution for the case when a terminal behind an ATA
calls a native IP terminal. Should the call be routed to a big VoIP gateway
where proper support would be found for conversion to an IP transport of
text that is supported by the terminal.



D. PSTN to PSTN through IP

Yes, this is a GW to GW case, suitable for V.151 if you want.



Gunnar

-------------------------------------------------------------------

Gunnar Hellström

Omnitor

= EMAIL ADDRESS REMOVED =

Tel: +46708204288

www.omnitor.se


----------------------------------------------------------------------------
--

From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Paul E. Jones
Sent: Thursday, June 07, 2007 10:09 PM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.



Gunnar,



A. Yeah, I think we can agree on RFC 4103 for IP text-capable devices.
(That does not change my argument for also wanting V.151 support to work
with gateways, though. But direct IP-terminal to IP-terminal should be RFC
4103.)



B. This is the sticky problem. Do we need to demodulate signals and
transport real text from large gateways, or do we just send G.711 audio?
Several years ago, there was a lot of concern expressed with packet loss and
unacceptable character error rate. ATIS held a meeting on this topic. We
initiated work on V.151 and completed that. But now, it seems that there is
a growing consensus that we no longer need to consider legacy TTY support.
So, I'm very confused. Do we need to further consider support for legacy
TTY devices?



C. ATAs - What this requirement fails to consider is that more ATAs will
have fax devices connected to them than text phones. There will also be
standard modem devices and other devices (e.g., security alarm systems,
point of sale terminals, etc.) that may not use standard modulations. There
is little we can do for non-standard modulations, except to use G.711. But,
for standard modulations, we can to T.38 for fax, V.150 for modem, and V.151
for text. RFC 4103 could be considered, but it must be introduced in such a
way that fax calls and modem calls still work. For this reason, V.151 may
still be the better choice.



D. This sounds like a GW to GW case, which fits precisely within the scope
of V.151.



Paul



From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Gunnar
Hellström
Sent: Tuesday, June 05, 2007 5:52 PM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.



Paul and all,

I want to return to the discussion on 1194.23(b) about real-time text
interoperability.

We left it with too much uncertainty.



A. IP to IP

If we look through the arguments, we easily find that there is quite good
agreement on how to handle real-time text in the pure IP environment.

You, say:

"in spite of the many references to RFC 4103 (which I do favor for native
IP devices), there are concerns with the ability to utilize RFC 4103 on
gateway devices."

This is also what the statements in 1194.23(b) say.

So, in fact there is an emerging agreement that RFC 4103 is to be favoured
between IP terminals. This agreement can also be seen in the growing number
of references in standards and policy documents.



Based on that agreement we can build a new class of high functionality,
fully interoperable IP Text capable phones and IP Total conversation devices
corresponding to the draft requirement 1194.23(b). Knowing that there is an
agreement on this level will encourage a good new market. Interoperability
is the key to popularity.



Do we have more parties agreeing on this?

----------------------------------------------------------



B. PSTN to IP in large gateways

With that agreement settled we may approach the issue of gateways between
TTY and IP Text capable terminals.

We use RFC 4103 in small scale PSTN/IP gateways without problems. But you
talk about possible concerns in large scale PSTN/IP gateways.



You correctly state:" Placing a requirement on gateway equipment to relay
modulated TTY signals is an uphill battle, and one that simply cannot be met
with many of the tens of thousands of already-deployed gateway devices in
the field."

Other methods than forcing all ports to support TTY are required to
achieve TTY / IP text interoperability. It is very likely that we need to
agree on some way to route the calls that MAY contain TTY so that they pass
gateway ports with special capability of conversion between TTY and an IP
real-time text format. Such methods are discussed in standards groups, and
they should be encouraged to come to workable solutions.



C. PSTN to IP in residential gateways and ATAs.

Another problem is what to recommend for the analogue terminal adapters.
There you have no choice. If it provides a PSTN device port, it should
behave properly for attached TTY:s.



This is what RFC 4504 "Sip Telephony devices" says about the ATA or
residential gateway:

-----From RFC 4504------



Req-57: SIP telephony devices MAY provide analog adaptor

functionality through an RJ-11 FXS port to support FXS

devices. If an RJ-11 (FXS) port is provided, then it MAY

support a gateway function from all text-telephone protocols

according to ITU-T Recommendation V.18 to RFC 4103 text

conversation (in fact, this is encouraged in the near term

during the transition to widespread use of SIP telephony

devices). If this gateway function is not included or fails,

the device MUST pass through all text-telephone protocols

according to ITU-T Recommendation V.18, November 2000, in a

transparent fashion.







--------------------------------

D. PSTN to PSTN through IP

This is another, more operator internal area that might need its own
discussion.





With A solved, we can carry on discussing B, C and possibly D.

The current language in



Gunnar

-------------------------------------------------------------------

Gunnar Hellström

Omnitor

= EMAIL ADDRESS REMOVED =

Tel: +46708204288

www.omnitor.se


----------------------------------------------------------------------------
--

From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Paul E. Jones
Sent: Thursday, May 24, 2007 12:34 AM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.



Gunnar,



Not to drive the committee into a deep hole on this much-debated issue,
but in spite of the many references to RFC 4103 (which I do favor for native
IP devices), there are concerns with the ability to utilize RFC 4103 on
gateway devices. When developing TIA-1001, we were presented with a laundry
list of requirements that, unfortunately, RFC 4103 could not always satisfy
for gateway devices (or not very well). Thus, TIA-1001 and V.151 prescribe
something different, yet very similar in capability, as a primary means of
relaying text over IP.



Perhaps more important is the loud voices I hear in the industry that are
actually deploying equipment. As much as I've pushed to get support for a
text relay mechanism between analog TTY devices over IP, it is very
difficult to even get DSPs in the market that can do proper tone detection,
let alone error-free character extraction. Even if that issue is solved
(which it could be), we're still faced with other problems:



· RFC 4103 consumes more resources on large gateways, which would
lead to higher port costs and/or lower port density

· The PSTN circuit is a multiplex of voice and TTY signals.
Separating text and voice into separate steams on IP, only to put them back
together again on a remote gateway, is a zero-gain exercise (i.e., it's a
complete waste)

· It takes time to establish an RFC 4103 stream, especially if
there are H.248 media gateways, two media gateway controllers, and one or
more proxies in the call path (and we have all of this and more in the IMS
architecture), so RFC 4103 might introduce delays in initial communication
which can be avoided with TIA-1001

· For legacy TTY devices, carriers seem to not favor text relay at
all, preferring to use G.711 and simply pass TTY signals over G.711 (much to
my dismay)



So, simply declaring that a gateway device shall support RFC 4103 and
citing standards references is insufficient. The problem is a complicated
on a number of levels, which is why carriers seem to favor treating TTY as
voice. Placing a requirement on gateway equipment to relay modulated TTY
signals is an uphill battle, and one that simply cannot be met with many of
the tens of thousands of already-deployed gateway devices in the field.
When we can get a foot in the door, to then further complicate the problem
with multiple RTP streams, multiplexing issues, and higher per-port costs,
increased signaling overhead, etc., will likely mean we stick with G.711 for
legacy TTY support indefinitely.



So, if I were to place bets on what I think stands the greatest chance of
succeeding on gateway devices in the carrier space, it would be (in order):

· V.152 (Voice Band Data, i.e., use G.711 or better for
pass-through)

· TIA-1001 / V.151 (if we can convince folks to do relay at all)

· RFC 4103



Paul





From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Gunnar
Hellström
Sent: Wednesday, May 23, 2007 5:19 PM
To: Teitac-telecom
Subject: [teitac-telecom] RFC 4103 reference for real-time text.



I want to comment on today's meeting discussion on 1194.23(b), about the
explicit reference to RFC 4103 for real-time text.

It sounds good with many voices understanding the great benefits that are
within reach by moving to IP and getting a real-time text channel easily
integrated with other media in the calls.



However, Fred Lucas / TIA had some questions and concerns that I can
answer and hopefully resolve.



I will take them in portions.



Concern 1: "RFC 4103 is not so much known protocol. Any protocol can be
decided now for this purpose."



Answer: IETF RFC 4103 "RTP Payload for text conversation" is an open
standard now referenced from at least 20 other standards from IETF, ITU-T,
3GPP and ETSI. It has for example been included as one of the three media
together with video and audio in IMS Multimedia Telephony. IMS is the next
environment we will see grow for establishing IP based telecom services.



These standards comprise:

-Transmission

-Service specification

-Terminal functionality

-Gateways

-Emergency services

-Relay services



No other standard for real-time text has the ambition to have this wide
coverage. It has taken some years to reach this acceptance level.



Here are a few excerpts:



1. >From RFC 4305, SIP telephony device requirements:

"Req-55: SIP telephony devices that include a display, or have a

facility for connecting an external display, MUST include

protocol support as described in RFC 4103 [23] for real-time

interactive text."



2. >From ietf-draft-ecrit-requirements: "Requirements for Emergency
Context Resolution with Internet Technologies"

"Emergency calling must support a variety of

media. Such media should include voice, conversational text
([RFC4103]), instant messaging and video."



3. >From ITU-T V.151 "Procedures for the end-to-end connection of
analogue PSTN text telephones over an IP network utilizing text relay"

"In general, ITDs transmit text characters when communicating with other
ITDs using RFC 4103, which specifies the establishment of a separate RTP
stream specifically for transmitting text characters." ( ITDs are IP text
devices )



Etc.



Conclusion: Well covered in standards, ready for wider deployment.



Regards



Gunnar Hellström

-------------------------------------------------------------------

Gunnar Hellström

Omnitor

= EMAIL ADDRESS REMOVED =

Tel: +46708204288

www.omnitor.se





__________ NOD32 2285 (20070522) Information __________

Detta meddelande är genomsökt av NOD32 Antivirus.
http://www.nod32.com



__________ NOD32 2313 (20070606) Information __________

Detta meddelande är genomsökt av NOD32 Antivirus.
http://www.nod32.com



----------------------------------------------------------------------------
--

From: Gregg Vanderheiden
Date: Fri, Jun 08 2007 2:25 PM
Subject: Re: RFC 4103 reference for real-time text.

TTY is critical on PSTN. It is the only thing that works there.



But it does not work well and is very limiting on IP. Like cellular
phones, (that also can't transport TTY tones natively without destroying
them, the strategy is to convert to a data format where there system
connects to the PSTN.



V.151 is a protocol designed to work between gateways. It is great there.







We need protocols between VoIP phones and between VoIP phones and gateways.




The best I can see is a hybrid approach.





1) Require that all VoIP phones, routers etc support both RFC-4103 and
and RFC-4351 - WHERE THEY CONNECT TO PUBLIC IP SIP SYSTEMS ? OR CONNECT TO
OTHER SYSTEMS. (Internally within their own systems where they control
both ends and intermediate routers, they can use anything that meets the
reliability requirements ).

2) PSTN to IP Gateways would also support both but could give
preference to RFC-4351 (offer it first) so that they can save a port for
each call. (if everyone supports both as they should ? then RFC-4351 would
work first time.

3) On non public systems (Skype, Vonnage, Corporations Internal
systems, etc) any text transport that meets the requirements is allowed as
long as it is translated into TTY at any PSTN interface and into RFC04103
and 4351 at any external IP SIP interface.





Would this hit the major issues?




Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.






_____


From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Paul E. Jones
Sent: Friday, June 08, 2007 2:10 PM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.

Gunnar,



B. This is precisely the issue we really need to tackle. Do we force all
TTY users to have to continue using those devices until the end of time, can
we find a technology that enables us to bridge the old and new, or do we
just make a complete switch to something new? We?ve got three options and
it seems like there is no consensus. Initially, we were told support for
legacy TTY devices was very important, so we created V.151. Then we were
told they?re not. I just saw the document from the FCC, which seems to
strongly encourage (or mandate) support for accessibility capabilities, but
it is open to interpretation (somewhat). You want to enable users to make
calls using RFC 4103. But a VoIP service provider?s ATA device likely
cannot even detect Baudot tones, let alone discriminate between Baudot, EDT,
V.21 textphones, fax machines, and modems. This can be addressed, but
nobody wants to do anything and see it viewed as a wasted effort. We all
need to agree on what to do and then execute, but it?s really annoying that
we cannot reach a consensus. If packet loss is a problem, then having
centralized gateway do conversion from audio to text will not solve the
problem. So, we either have to ensure that we do not have packet loss,
forget about TTY support and move to new technology, or we must add proper
support for TTYs. Can we reach an agreement on this point?



C. So we do need to support the legacy devices? I would suggest that we
consider using V.151 Annex D.



Paul



From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Gunnar
Hellström
Sent: Thursday, June 07, 2007 5:15 PM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.



Paul,



A. IP to IP

Fine. This is an important step for good progress in design for all in
telecomms. Are there more parties who can join in this agreement?



B. PSTN to IP in large gateways

Just sending G.711 audio is likely not sufficiently reliable for TIA 825.
Because of its long character time of 165 ms, and its letter shift ? figure
shift technique, it is extremely sensitive to packet loss. The quite high
acceptable limit of 1% character errors require a theoretical packet loss
rate of a maximum of 0.1% when using plain G.711. That is too risky even in
good networks.

Much better with same bandwidth would probably be G.726 with one level of
redundancy. Then you would even allow 3% packet loss and still get usable
result. ( 1% errors). But beware! As recently discussed, other disturbing
effects like echo handlers and distorsion tends to come in and destroy the
real result as compared to the theoretical.



And what would be the destination of the audio coded text? I do not see it
realistic to take it all the way to the IP terminal. But possibly to an
intermediate gateway that converts to a text format that the terminal
supports. Do you want to propose double text codecs in all IP terminals
interested in TTY compatibility? One for IP to IP and one for IP ? PSTN?



Some efforts to support TTY transport should be maintained, but the users
have asked us to not focus all energy on that problem, so that the
functional enhancements within reach in IP networks are lost. I understand
that as a preparedness to discuss compromises, like using some added
procedures in order to be routed through text capable gateways.

Can we expect Emergency services and relay services to open an agreed IP ?
IP real-time text method ( A ) very soon? If not, good TTY interoperability
is at least needed for access to these services.



C. PSTN to IP in residential gateways and ATAs.

We need to have a solution for the case when a terminal behind an ATA calls
a native IP terminal. Should the call be routed to a big VoIP gateway where
proper support would be found for conversion to an IP transport of text that
is supported by the terminal.



D. PSTN to PSTN through IP

Yes, this is a GW to GW case, suitable for V.151 if you want.



Gunnar

-------------------------------------------------------------------

Gunnar Hellström

Omnitor

= EMAIL ADDRESS REMOVED =

Tel: +46708204288

www.omnitor.se


_____


From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Paul E. Jones
Sent: Thursday, June 07, 2007 10:09 PM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.



Gunnar,



A. Yeah, I think we can agree on RFC 4103 for IP text-capable devices.
(That does not change my argument for also wanting V.151 support to work
with gateways, though. But direct IP-terminal to IP-terminal should be RFC
4103.)



B. This is the sticky problem. Do we need to demodulate signals and
transport real text from large gateways, or do we just send G.711 audio?
Several years ago, there was a lot of concern expressed with packet loss and
unacceptable character error rate. ATIS held a meeting on this topic. We
initiated work on V.151 and completed that. But now, it seems that there is
a growing consensus that we no longer need to consider legacy TTY support.
So, I?m very confused. Do we need to further consider support for legacy
TTY devices?



C. ATAs ? What this requirement fails to consider is that more ATAs will
have fax devices connected to them than text phones. There will also be
standard modem devices and other devices (e.g., security alarm systems,
point of sale terminals, etc.) that may not use standard modulations. There
is little we can do for non-standard modulations, except to use G.711. But,
for standard modulations, we can to T.38 for fax, V.150 for modem, and V.151
for text. RFC 4103 could be considered, but it must be introduced in such a
way that fax calls and modem calls still work. For this reason, V.151 may
still be the better choice.



D. This sounds like a GW to GW case, which fits precisely within the scope
of V.151.



Paul



From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Gunnar
Hellström
Sent: Tuesday, June 05, 2007 5:52 PM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.



Paul and all,

I want to return to the discussion on 1194.23(b) about real-time text
interoperability.

We left it with too much uncertainty.



A. IP to IP

If we look through the arguments, we easily find that there is quite good
agreement on how to handle real-time text in the pure IP environment.

You, say:

?in spite of the many references to RFC 4103 (which I do favor for native IP
devices), there are concerns with the ability to utilize RFC 4103 on gateway
devices.?

This is also what the statements in 1194.23(b) say.

So, in fact there is an emerging agreement that RFC 4103 is to be favoured
between IP terminals. This agreement can also be seen in the growing number
of references in standards and policy documents.



Based on that agreement we can build a new class of high functionality,
fully interoperable IP Text capable phones and IP Total conversation devices
corresponding to the draft requirement 1194.23(b). Knowing that there is an
agreement on this level will encourage a good new market. Interoperability
is the key to popularity.



Do we have more parties agreeing on this?

----------------------------------------------------------



B. PSTN to IP in large gateways

With that agreement settled we may approach the issue of gateways between
TTY and IP Text capable terminals.

We use RFC 4103 in small scale PSTN/IP gateways without problems. But you
talk about possible concerns in large scale PSTN/IP gateways.



You correctly state:? Placing a requirement on gateway equipment to relay
modulated TTY signals is an uphill battle, and one that simply cannot be met
with many of the tens of thousands of already-deployed gateway devices in
the field.?

Other methods than forcing all ports to support TTY are required to achieve
TTY / IP text interoperability. It is very likely that we need to agree on
some way to route the calls that MAY contain TTY so that they pass gateway
ports with special capability of conversion between TTY and an IP real-time
text format. Such methods are discussed in standards groups, and they should
be encouraged to come to workable solutions.



C. PSTN to IP in residential gateways and ATAs.

Another problem is what to recommend for the analogue terminal adapters.
There you have no choice. If it provides a PSTN device port, it should
behave properly for attached TTY:s.



This is what RFC 4504 ?Sip Telephony devices? says about the ATA or
residential gateway:

-----From RFC 4504------



Req-57: SIP telephony devices MAY provide analog adaptor

functionality through an RJ-11 FXS port to support FXS

devices. If an RJ-11 (FXS) port is provided, then it MAY

support a gateway function from all text-telephone protocols

according to ITU-T Recommendation V.18 to RFC 4103 text

conversation (in fact, this is encouraged in the near term

during the transition to widespread use of SIP telephony

devices). If this gateway function is not included or fails,

the device MUST pass through all text-telephone protocols

according to ITU-T Recommendation V.18, November 2000, in a

transparent fashion.







--------------------------------

D. PSTN to PSTN through IP

This is another, more operator internal area that might need its own
discussion.





With A solved, we can carry on discussing B, C and possibly D.

The current language in



Gunnar

-------------------------------------------------------------------

Gunnar Hellström

Omnitor

= EMAIL ADDRESS REMOVED =

Tel: +46708204288

www.omnitor.se


_____


From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Paul E. Jones
Sent: Thursday, May 24, 2007 12:34 AM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.



Gunnar,



Not to drive the committee into a deep hole on this much-debated issue, but
in spite of the many references to RFC 4103 (which I do favor for native IP
devices), there are concerns with the ability to utilize RFC 4103 on gateway
devices. When developing TIA-1001, we were presented with a laundry list of
requirements that, unfortunately, RFC 4103 could not always satisfy for
gateway devices (or not very well). Thus, TIA-1001 and V.151 prescribe
something different, yet very similar in capability, as a primary means of
relaying text over IP.



Perhaps more important is the loud voices I hear in the industry that are
actually deploying equipment. As much as I?ve pushed to get support for a
text relay mechanism between analog TTY devices over IP, it is very
difficult to even get DSPs in the market that can do proper tone detection,
let alone error-free character extraction. Even if that issue is solved
(which it could be), we?re still faced with other problems:



* RFC 4103 consumes more resources on large gateways, which would
lead to higher port costs and/or lower port density

* The PSTN circuit is a multiplex of voice and TTY signals.
Separating text and voice into separate steams on IP, only to put them back
together again on a remote gateway, is a zero-gain exercise (i.e., it?s a
complete waste)

* It takes time to establish an RFC 4103 stream, especially if there
are H.248 media gateways, two media gateway controllers, and one or more
proxies in the call path (and we have all of this and more in the IMS
architecture), so RFC 4103 might introduce delays in initial communication
which can be avoided with TIA-1001

* For legacy TTY devices, carriers seem to not favor text relay at
all, preferring to use G.711 and simply pass TTY signals over G.711 (much to
my dismay)



So, simply declaring that a gateway device shall support RFC 4103 and citing
standards references is insufficient. The problem is a complicated on a
number of levels, which is why carriers seem to favor treating TTY as voice.
Placing a requirement on gateway equipment to relay modulated TTY signals is
an uphill battle, and one that simply cannot be met with many of the tens of
thousands of already-deployed gateway devices in the field. When we can get
a foot in the door, to then further complicate the problem with multiple RTP
streams, multiplexing issues, and higher per-port costs, increased signaling
overhead, etc., will likely mean we stick with G.711 for legacy TTY support
indefinitely.



So, if I were to place bets on what I think stands the greatest chance of
succeeding on gateway devices in the carrier space, it would be (in order):

* V.152 (Voice Band Data, i.e., use G.711 or better for
pass-through)

* TIA-1001 / V.151 (if we can convince folks to do relay at all)

* RFC 4103



Paul





From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Gunnar
Hellström
Sent: Wednesday, May 23, 2007 5:19 PM
To: Teitac-telecom
Subject: [teitac-telecom] RFC 4103 reference for real-time text.



I want to comment on today?s meeting discussion on 1194.23(b), about the
explicit reference to RFC 4103 for real-time text.

It sounds good with many voices understanding the great benefits that are
within reach by moving to IP and getting a real-time text channel easily
integrated with other media in the calls.



However, Fred Lucas / TIA had some questions and concerns that I can answer
and hopefully resolve.



I will take them in portions.



Concern 1: ?RFC 4103 is not so much known protocol. Any protocol can be
decided now for this purpose.?



Answer: IETF RFC 4103 ?RTP Payload for text conversation? is an open
standard now referenced from at least 20 other standards from IETF, ITU-T,
3GPP and ETSI. It has for example been included as one of the three media
together with video and audio in IMS Multimedia Telephony. IMS is the next
environment we will see grow for establishing IP based telecom services.



These standards comprise:

-Transmission

-Service specification

-Terminal functionality

-Gateways

-Emergency services

-Relay services



No other standard for real-time text has the ambition to have this wide
coverage. It has taken some years to reach this acceptance level.



Here are a few excerpts:



1. >From RFC 4305, SIP telephony device requirements:

?Req-55: SIP telephony devices that include a display, or have a

facility for connecting an external display, MUST include

protocol support as described in RFC 4103 [23] for real-time

interactive text.?



2. >From ietf-draft-ecrit-requirements: ?Requirements for Emergency Context
Resolution with Internet Technologies?

?Emergency calling must support a variety of

media. Such media should include voice, conversational text
([RFC4103]), instant messaging and video.?



3. >From ITU-T V.151 ?Procedures for the end-to-end connection of analogue
PSTN text telephones over an IP network utilizing text relay?

?In general, ITDs transmit text characters when communicating with other
ITDs using RFC 4103, which specifies the establishment of a separate RTP
stream specifically for transmitting text characters.? ( ITDs are IP text
devices )



Etc.



Conclusion: Well covered in standards, ready for wider deployment.



Regards



Gunnar Hellström

-------------------------------------------------------------------

Gunnar Hellström

Omnitor

= EMAIL ADDRESS REMOVED =

Tel: +46708204288

www.omnitor.se





__________ NOD32 2285 (20070522) Information __________

Detta meddelande är genomsökt av NOD32 Antivirus.
http://www.nod32.com



__________ NOD32 2313 (20070606) Information __________

Detta meddelande är genomsökt av NOD32 Antivirus.
http://www.nod32.com

From: Paul E. Jones
Date: Sat, Jun 09 2007 3:20 PM
Subject: Re: RFC 4103 reference for real-time text.

Diane,



What is a ?VCO phone?? Is this one that still uses Baudot for character
transmission?



Captel, as I understand, does not use Baudot. As such, it will introduce
significantly more hurdles moving forward. Over the past few years as we?ve
been working on new standards to move from a legacy TTY world to an IP
world, several of us in the industry have invited Ultratec to participate
and to share information so that we can integrate the technology into
standards, but they?ve repeatedly declined. So, I really worry about how we
could ever possibly support Captel. The only choice might be to use G.711,
but then the government could not require VoIP service providers like Vonage
or services from AT&T like CallVantage to support it, because there is no
way for either of those carriers to guarantee (or even remotely attempt) to
guarantee the low packet loss rates necessary for those services to work
since they do not own the access lines going into subscriber?s homes.



Perhaps we need to move to distributing IP versions of those same kinds of
technologies well in advance of a complete migration to VoIP.



Paul





From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Diane Golden
Sent: Friday, June 08, 2007 4:18 PM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.



On behalf of one of the state programs that distribute adaptive telephone
equipment, pure TTY's are a very tiny part of the distribution today. The
numbers have steadily decreased year after year as people move to other
equipment options. What we don't have is good data on how many people use
the TTY as their only telecom equipment rather than a secondary or
supplemental option. We do now distribute more VCO phones (including
regular VCO and CapTel) than TTYs and for pretty much all of these people
that is the only telecom option they have. So that group may actually be
our biggest legacy equipment problem.



Diane



Diane Cordry Golden, Ph.D., Director
Missouri Assistive Technology
816/350-5280 (direct voice)
= EMAIL ADDRESS REMOVED =
www.at.mo.gov



-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ]On Behalf Of Pam Ransom
Sent: Friday, June 08, 2007 2:16 PM
To: TEITAC Telecommunications Subcommittee
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.

Just a reminder ... There are approximately 25-27 states that continue to
administer TTY Distribution Programs, and thus there is a significant
embedded base of this older TTY technology. Pam Ransom

----- Original Message -----

From: Paul E. Jones <mailto: = EMAIL ADDRESS REMOVED = >

To: 'TEITAC Telecommunications Subcommittee'
<mailto: = EMAIL ADDRESS REMOVED = >

Sent: Friday, June 08, 2007 2:10 PM

Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.



Gunnar,



B. This is precisely the issue we really need to tackle. Do we force all
TTY users to have to continue using those devices until the end of time, can
we find a technology that enables us to bridge the old and new, or do we
just make a complete switch to something new? We've got three options and
it seems like there is no consensus. Initially, we were told support for
legacy TTY devices was very important, so we created V.151. Then we were
told they're not. I just saw the document from the FCC, which seems to
strongly encourage (or mandate) support for accessibility capabilities, but
it is open to interpretation (somewhat). You want to enable users to make
calls using RFC 4103. But a VoIP service provider's ATA device likely
cannot even detect Baudot tones, let alone discriminate between Baudot, EDT,
V.21 textphones, fax machines, and modems. This can be addressed, but
nobody wants to do anything and see it viewed as a wasted effort. We all
need to agree on what to do and then execute, but it's really annoying that
we cannot reach a consensus. If packet loss is a problem, then having
centralized gateway do conversion from audio to text will not solve the
problem. So, we either have to ensure that we do not have packet loss,
forget about TTY support and move to new technology, or we must add proper
support for TTYs. Can we reach an agreement on this point?



C. So we do need to support the legacy devices? I would suggest that we
consider using V.151 Annex D.



Paul



From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Gunnar
Hellström
Sent: Thursday, June 07, 2007 5:15 PM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.



Paul,



A. IP to IP

Fine. This is an important step for good progress in design for all in
telecomms. Are there more parties who can join in this agreement?



B. PSTN to IP in large gateways

Just sending G.711 audio is likely not sufficiently reliable for TIA 825.
Because of its long character time of 165 ms, and its letter shift - figure
shift technique, it is extremely sensitive to packet loss. The quite high
acceptable limit of 1% character errors require a theoretical packet loss
rate of a maximum of 0.1% when using plain G.711. That is too risky even in
good networks.

Much better with same bandwidth would probably be G.726 with one level of
redundancy. Then you would even allow 3% packet loss and still get usable
result. ( 1% errors). But beware! As recently discussed, other disturbing
effects like echo handlers and distorsion tends to come in and destroy the
real result as compared to the theoretical.



And what would be the destination of the audio coded text? I do not see it
realistic to take it all the way to the IP terminal. But possibly to an
intermediate gateway that converts to a text format that the terminal
supports. Do you want to propose double text codecs in all IP terminals
interested in TTY compatibility? One for IP to IP and one for IP - PSTN?



Some efforts to support TTY transport should be maintained, but the users
have asked us to not focus all energy on that problem, so that the
functional enhancements within reach in IP networks are lost. I understand
that as a preparedness to discuss compromises, like using some added
procedures in order to be routed through text capable gateways.

Can we expect Emergency services and relay services to open an agreed IP -
IP real-time text method ( A ) very soon? If not, good TTY interoperability
is at least needed for access to these services.



C. PSTN to IP in residential gateways and ATAs.

We need to have a solution for the case when a terminal behind an ATA calls
a native IP terminal. Should the call be routed to a big VoIP gateway where
proper support would be found for conversion to an IP transport of text that
is supported by the terminal.



D. PSTN to PSTN through IP

Yes, this is a GW to GW case, suitable for V.151 if you want.



Gunnar

-------------------------------------------------------------------

Gunnar Hellström

Omnitor

= EMAIL ADDRESS REMOVED =

Tel: +46708204288

www.omnitor.se


_____


From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Paul E. Jones
Sent: Thursday, June 07, 2007 10:09 PM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.



Gunnar,



A. Yeah, I think we can agree on RFC 4103 for IP text-capable devices.
(That does not change my argument for also wanting V.151 support to work
with gateways, though. But direct IP-terminal to IP-terminal should be RFC
4103.)



B. This is the sticky problem. Do we need to demodulate signals and
transport real text from large gateways, or do we just send G.711 audio?
Several years ago, there was a lot of concern expressed with packet loss and
unacceptable character error rate. ATIS held a meeting on this topic. We
initiated work on V.151 and completed that. But now, it seems that there is
a growing consensus that we no longer need to consider legacy TTY support.
So, I'm very confused. Do we need to further consider support for legacy
TTY devices?



C. ATAs - What this requirement fails to consider is that more ATAs will
have fax devices connected to them than text phones. There will also be
standard modem devices and other devices (e.g., security alarm systems,
point of sale terminals, etc.) that may not use standard modulations. There
is little we can do for non-standard modulations, except to use G.711. But,
for standard modulations, we can to T.38 for fax, V.150 for modem, and V.151
for text. RFC 4103 could be considered, but it must be introduced in such a
way that fax calls and modem calls still work. For this reason, V.151 may
still be the better choice.



D. This sounds like a GW to GW case, which fits precisely within the scope
of V.151.



Paul



From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Gunnar
Hellström
Sent: Tuesday, June 05, 2007 5:52 PM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.



Paul and all,

I want to return to the discussion on 1194.23(b) about real-time text
interoperability.

We left it with too much uncertainty.



A. IP to IP

If we look through the arguments, we easily find that there is quite good
agreement on how to handle real-time text in the pure IP environment.

You, say:

"in spite of the many references to RFC 4103 (which I do favor for native IP
devices), there are concerns with the ability to utilize RFC 4103 on gateway
devices."

This is also what the statements in 1194.23(b) say.

So, in fact there is an emerging agreement that RFC 4103 is to be favoured
between IP terminals. This agreement can also be seen in the growing number
of references in standards and policy documents.



Based on that agreement we can build a new class of high functionality,
fully interoperable IP Text capable phones and IP Total conversation devices
corresponding to the draft requirement 1194.23(b). Knowing that there is an
agreement on this level will encourage a good new market. Interoperability
is the key to popularity.



Do we have more parties agreeing on this?

----------------------------------------------------------



B. PSTN to IP in large gateways

With that agreement settled we may approach the issue of gateways between
TTY and IP Text capable terminals.

We use RFC 4103 in small scale PSTN/IP gateways without problems. But you
talk about possible concerns in large scale PSTN/IP gateways.



You correctly state:" Placing a requirement on gateway equipment to relay
modulated TTY signals is an uphill battle, and one that simply cannot be met
with many of the tens of thousands of already-deployed gateway devices in
the field."

Other methods than forcing all ports to support TTY are required to achieve
TTY / IP text interoperability. It is very likely that we need to agree on
some way to route the calls that MAY contain TTY so that they pass gateway
ports with special capability of conversion between TTY and an IP real-time
text format. Such methods are discussed in standards groups, and they should
be encouraged to come to workable solutions.



C. PSTN to IP in residential gateways and ATAs.

Another problem is what to recommend for the analogue terminal adapters.
There you have no choice. If it provides a PSTN device port, it should
behave properly for attached TTY:s.



This is what RFC 4504 "Sip Telephony devices" says about the ATA or
residential gateway:

-----From RFC 4504------



Req-57: SIP telephony devices MAY provide analog adaptor

functionality through an RJ-11 FXS port to support FXS

devices. If an RJ-11 (FXS) port is provided, then it MAY

support a gateway function from all text-telephone protocols

according to ITU-T Recommendation V.18 to RFC 4103 text

conversation (in fact, this is encouraged in the near term

during the transition to widespread use of SIP telephony

devices). If this gateway function is not included or fails,

the device MUST pass through all text-telephone protocols

according to ITU-T Recommendation V.18, November 2000, in a

transparent fashion.







--------------------------------

D. PSTN to PSTN through IP

This is another, more operator internal area that might need its own
discussion.





With A solved, we can carry on discussing B, C and possibly D.

The current language in



Gunnar

-------------------------------------------------------------------

Gunnar Hellström

Omnitor

= EMAIL ADDRESS REMOVED =

Tel: +46708204288

www.omnitor.se


_____


From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Paul E. Jones
Sent: Thursday, May 24, 2007 12:34 AM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.



Gunnar,



Not to drive the committee into a deep hole on this much-debated issue, but
in spite of the many references to RFC 4103 (which I do favor for native IP
devices), there are concerns with the ability to utilize RFC 4103 on gateway
devices. When developing TIA-1001, we were presented with a laundry list of
requirements that, unfortunately, RFC 4103 could not always satisfy for
gateway devices (or not very well). Thus, TIA-1001 and V.151 prescribe
something different, yet very similar in capability, as a primary means of
relaying text over IP.



Perhaps more important is the loud voices I hear in the industry that are
actually deploying equipment. As much as I've pushed to get support for a
text relay mechanism between analog TTY devices over IP, it is very
difficult to even get DSPs in the market that can do proper tone detection,
let alone error-free character extraction. Even if that issue is solved
(which it could be), we're still faced with other problems:



· RFC 4103 consumes more resources on large gateways, which would
lead to higher port costs and/or lower port density

· The PSTN circuit is a multiplex of voice and TTY signals.
Separating text and voice into separate steams on IP, only to put them back
together again on a remote gateway, is a zero-gain exercise (i.e., it's a
complete waste)

· It takes time to establish an RFC 4103 stream, especially if there
are H.248 media gateways, two media gateway controllers, and one or more
proxies in the call path (and we have all of this and more in the IMS
architecture), so RFC 4103 might introduce delays in initial communication
which can be avoided with TIA-1001

· For legacy TTY devices, carriers seem to not favor text relay at
all, preferring to use G.711 and simply pass TTY signals over G.711 (much to
my dismay)



So, simply declaring that a gateway device shall support RFC 4103 and citing
standards references is insufficient. The problem is a complicated on a
number of levels, which is why carriers seem to favor treating TTY as voice.
Placing a requirement on gateway equipment to relay modulated TTY signals is
an uphill battle, and one that simply cannot be met with many of the tens of
thousands of already-deployed gateway devices in the field. When we can get
a foot in the door, to then further complicate the problem with multiple RTP
streams, multiplexing issues, and higher per-port costs, increased signaling
overhead, etc., will likely mean we stick with G.711 for legacy TTY support
indefinitely.



So, if I were to place bets on what I think stands the greatest chance of
succeeding on gateway devices in the carrier space, it would be (in order):

· V.152 (Voice Band Data, i.e., use G.711 or better for
pass-through)

· TIA-1001 / V.151 (if we can convince folks to do relay at all)

· RFC 4103



Paul





From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Gunnar
Hellström
Sent: Wednesday, May 23, 2007 5:19 PM
To: Teitac-telecom
Subject: [teitac-telecom] RFC 4103 reference for real-time text.



I want to comment on today's meeting discussion on 1194.23(b), about the
explicit reference to RFC 4103 for real-time text.

It sounds good with many voices understanding the great benefits that are
within reach by moving to IP and getting a real-time text channel easily
integrated with other media in the calls.



However, Fred Lucas / TIA had some questions and concerns that I can answer
and hopefully resolve.



I will take them in portions.



Concern 1: "RFC 4103 is not so much known protocol. Any protocol can be
decided now for this purpose."



Answer: IETF RFC 4103 "RTP Payload for text conversation" is an open
standard now referenced from at least 20 other standards from IETF, ITU-T,
3GPP and ETSI. It has for example been included as one of the three media
together with video and audio in IMS Multimedia Telephony. IMS is the next
environment we will see grow for establishing IP based telecom services.



These standards comprise:

-Transmission

-Service specification

-Terminal functionality

-Gateways

-Emergency services

-Relay services



No other standard for real-time text has the ambition to have this wide
coverage. It has taken some years to reach this acceptance level.



Here are a few excerpts:



1. >From RFC 4305, SIP telephony device requirements:

"Req-55: SIP telephony devices that include a display, or have a

facility for connecting an external display, MUST include

protocol support as described in RFC 4103 [23] for real-time

interactive text."



2. >From ietf-draft-ecrit-requirements: "Requirements for Emergency Context
Resolution with Internet Technologies"

"Emergency calling must support a variety of

media. Such media should include voice, conversational text
([RFC4103]), instant messaging and video."



3. >From ITU-T V.151 "Procedures for the end-to-end connection of analogue
PSTN text telephones over an IP network utilizing text relay"

"In general, ITDs transmit text characters when communicating with other
ITDs using RFC 4103, which specifies the establishment of a separate RTP
stream specifically for transmitting text characters." ( ITDs are IP text
devices )



Etc.



Conclusion: Well covered in standards, ready for wider deployment.



Regards



Gunnar Hellström

-------------------------------------------------------------------

Gunnar Hellström

Omnitor

= EMAIL ADDRESS REMOVED =

Tel: +46708204288

www.omnitor.se





__________ NOD32 2285 (20070522) Information __________

Detta meddelande är genomsökt av NOD32 Antivirus.
http://www.nod32.com



__________ NOD32 2313 (20070606) Information __________

Detta meddelande är genomsökt av NOD32 Antivirus.
http://www.nod32.com


_____

From: Paul E. Jones
Date: Sat, Jun 09 2007 3:35 PM
Subject: Re: RFC 4103 reference for real-time text.

Gregg,



I still do not think it is a good idea to require every phone to support
real-times text. Not every phone today supports text, while they certainly
could. Baudot is trivial, the it could be integrated into my wireless phone
very easily. But, that?s not what I would want to use!



I think we need to ?be careful what we ask for?, otherwise what we might
have is a large number of inferior devices and then people asking, ?what
more do you want??? There might be a resistance to consider making other
options available.



Today, not every phone is accessible. But, what is accessible is the phone
network. A user can use his equipment (or provided equipment) and access
the PSTN to communicate with anybody in the world. They key is ?network
access?, not ?phone access?. If we wanted to mandate public phones have
integrated RFC 4103 capabilities, fine. Those are closed systems that might
offer no other interface. Or will they? It might be possible to use an
external text device that works wirelessly with the public phone as a
?natural extension? of the phone. (Never discount the possibility that
technology might evolve in the future into something quite different than
what we have today. I am working on just such a new kind of system.
Whether it sees the light of day is another matter, but we should at least
consider how technology is ever-changing and more sophisticated.)



What I would personally want to be able to use is a Pocket PC, Ultra Mobile
PC (UMPC) or other device with communication software installed. I would
like to have a means to access the network, such as via an Ethernet
connection or a wireless access point. (It?s not too hard for me to imagine
that a business could establish a VLAN specifically for such purposes: I
have the equipment necessary to do that in my house, so it?s not beyond
reach.)



So, I would encourage you to consider the network, not the phone, as the
focal point for accessibility. This will enable users to have a wider
variety of options, including portable PC devices, dedicated textphones,
PCs, or other devices.



Paul





From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Gregg
Vanderheiden
Sent: Friday, June 08, 2007 4:24 PM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.



TTY is critical on PSTN. It is the only thing that works there.



But it does not work well and is very limiting on IP. Like cellular
phones, (that also can't transport TTY tones natively without destroying
them, the strategy is to convert to a data format where there system
connects to the PSTN.



V.151 is a protocol designed to work between gateways. It is great there.







We need protocols between VoIP phones and between VoIP phones and gateways.




The best I can see is a hybrid approach.





1) Require that all VoIP phones, routers etc support both RFC-4103 and and
RFC-4351 - WHERE THEY CONNECT TO PUBLIC IP SIP SYSTEMS ? OR CONNECT TO
OTHER SYSTEMS. (Internally within their own systems where they control
both ends and intermediate routers, they can use anything that meets the
reliability requirements ).

2) PSTN to IP Gateways would also support both but could give preference to
RFC-4351 (offer it first) so that they can save a port for each call. (if
everyone supports both as they should ? then RFC-4351 would work first time.


3) On non public systems (Skype, Vonnage, Corporations Internal systems,
etc) any text transport that meets the requirements is allowed as long as it
is translated into TTY at any PSTN interface and into RFC04103 and 4351 at
any external IP SIP interface.





Would this hit the major issues?




Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.






_____


From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Paul E. Jones
Sent: Friday, June 08, 2007 2:10 PM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.

Gunnar,



B. This is precisely the issue we really need to tackle. Do we force all
TTY users to have to continue using those devices until the end of time, can
we find a technology that enables us to bridge the old and new, or do we
just make a complete switch to something new? We?ve got three options and
it seems like there is no consensus. Initially, we were told support for
legacy TTY devices was very important, so we created V.151. Then we were
told they?re not. I just saw the document from the FCC, which seems to
strongly encourage (or mandate) support for accessibility capabilities, but
it is open to interpretation (somewhat). You want to enable users to make
calls using RFC 4103. But a VoIP service provider?s ATA device likely
cannot even detect Baudot tones, let alone discriminate between Baudot, EDT,
V.21 textphones, fax machines, and modems. This can be addressed, but
nobody wants to do anything and see it viewed as a wasted effort. We all
need to agree on what to do and then execute, but it?s really annoying that
we cannot reach a consensus. If packet loss is a problem, then having
centralized gateway do conversion from audio to text will not solve the
problem. So, we either have to ensure that we do not have packet loss,
forget about TTY support and move to new technology, or we must add proper
support for TTYs. Can we reach an agreement on this point?



C. So we do need to support the legacy devices? I would suggest that we
consider using V.151 Annex D.



Paul



From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Gunnar
Hellström
Sent: Thursday, June 07, 2007 5:15 PM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.



Paul,



A. IP to IP

Fine. This is an important step for good progress in design for all in
telecomms. Are there more parties who can join in this agreement?



B. PSTN to IP in large gateways

Just sending G.711 audio is likely not sufficiently reliable for TIA 825.
Because of its long character time of 165 ms, and its letter shift ? figure
shift technique, it is extremely sensitive to packet loss. The quite high
acceptable limit of 1% character errors require a theoretical packet loss
rate of a maximum of 0.1% when using plain G.711. That is too risky even in
good networks.

Much better with same bandwidth would probably be G.726 with one level of
redundancy. Then you would even allow 3% packet loss and still get usable
result. ( 1% errors). But beware! As recently discussed, other disturbing
effects like echo handlers and distorsion tends to come in and destroy the
real result as compared to the theoretical.



And what would be the destination of the audio coded text? I do not see it
realistic to take it all the way to the IP terminal. But possibly to an
intermediate gateway that converts to a text format that the terminal
supports. Do you want to propose double text codecs in all IP terminals
interested in TTY compatibility? One for IP to IP and one for IP ? PSTN?



Some efforts to support TTY transport should be maintained, but the users
have asked us to not focus all energy on that problem, so that the
functional enhancements within reach in IP networks are lost. I understand
that as a preparedness to discuss compromises, like using some added
procedures in order to be routed through text capable gateways.

Can we expect Emergency services and relay services to open an agreed IP ?
IP real-time text method ( A ) very soon? If not, good TTY interoperability
is at least needed for access to these services.



C. PSTN to IP in residential gateways and ATAs.

We need to have a solution for the case when a terminal behind an ATA calls
a native IP terminal. Should the call be routed to a big VoIP gateway where
proper support would be found for conversion to an IP transport of text that
is supported by the terminal.



D. PSTN to PSTN through IP

Yes, this is a GW to GW case, suitable for V.151 if you want.



Gunnar

-------------------------------------------------------------------

Gunnar Hellström

Omnitor

= EMAIL ADDRESS REMOVED =

Tel: +46708204288

www.omnitor.se


_____


From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Paul E. Jones
Sent: Thursday, June 07, 2007 10:09 PM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.



Gunnar,



A. Yeah, I think we can agree on RFC 4103 for IP text-capable devices.
(That does not change my argument for also wanting V.151 support to work
with gateways, though. But direct IP-terminal to IP-terminal should be RFC
4103.)



B. This is the sticky problem. Do we need to demodulate signals and
transport real text from large gateways, or do we just send G.711 audio?
Several years ago, there was a lot of concern expressed with packet loss and
unacceptable character error rate. ATIS held a meeting on this topic. We
initiated work on V.151 and completed that. But now, it seems that there is
a growing consensus that we no longer need to consider legacy TTY support.
So, I?m very confused. Do we need to further consider support for legacy
TTY devices?



C. ATAs ? What this requirement fails to consider is that more ATAs will
have fax devices connected to them than text phones. There will also be
standard modem devices and other devices (e.g., security alarm systems,
point of sale terminals, etc.) that may not use standard modulations. There
is little we can do for non-standard modulations, except to use G.711. But,
for standard modulations, we can to T.38 for fax, V.150 for modem, and V.151
for text. RFC 4103 could be considered, but it must be introduced in such a
way that fax calls and modem calls still work. For this reason, V.151 may
still be the better choice.



D. This sounds like a GW to GW case, which fits precisely within the scope
of V.151.



Paul



From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Gunnar
Hellström
Sent: Tuesday, June 05, 2007 5:52 PM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.



Paul and all,

I want to return to the discussion on 1194.23(b) about real-time text
interoperability.

We left it with too much uncertainty.



A. IP to IP

If we look through the arguments, we easily find that there is quite good
agreement on how to handle real-time text in the pure IP environment.

You, say:

?in spite of the many references to RFC 4103 (which I do favor for native IP
devices), there are concerns with the ability to utilize RFC 4103 on gateway
devices.?

This is also what the statements in 1194.23(b) say.

So, in fact there is an emerging agreement that RFC 4103 is to be favoured
between IP terminals. This agreement can also be seen in the growing number
of references in standards and policy documents.



Based on that agreement we can build a new class of high functionality,
fully interoperable IP Text capable phones and IP Total conversation devices
corresponding to the draft requirement 1194.23(b). Knowing that there is an
agreement on this level will encourage a good new market. Interoperability
is the key to popularity.



Do we have more parties agreeing on this?

----------------------------------------------------------



B. PSTN to IP in large gateways

With that agreement settled we may approach the issue of gateways between
TTY and IP Text capable terminals.

We use RFC 4103 in small scale PSTN/IP gateways without problems. But you
talk about possible concerns in large scale PSTN/IP gateways.



You correctly state:? Placing a requirement on gateway equipment to relay
modulated TTY signals is an uphill battle, and one that simply cannot be met
with many of the tens of thousands of already-deployed gateway devices in
the field.?

Other methods than forcing all ports to support TTY are required to achieve
TTY / IP text interoperability. It is very likely that we need to agree on
some way to route the calls that MAY contain TTY so that they pass gateway
ports with special capability of conversion between TTY and an IP real-time
text format. Such methods are discussed in standards groups, and they should
be encouraged to come to workable solutions.



C. PSTN to IP in residential gateways and ATAs.

Another problem is what to recommend for the analogue terminal adapters.
There you have no choice. If it provides a PSTN device port, it should
behave properly for attached TTY:s.



This is what RFC 4504 ?Sip Telephony devices? says about the ATA or
residential gateway:

-----From RFC 4504------



Req-57: SIP telephony devices MAY provide analog adaptor

functionality through an RJ-11 FXS port to support FXS

devices. If an RJ-11 (FXS) port is provided, then it MAY

support a gateway function from all text-telephone protocols

according to ITU-T Recommendation V.18 to RFC 4103 text

conversation (in fact, this is encouraged in the near term

during the transition to widespread use of SIP telephony

devices). If this gateway function is not included or fails,

the device MUST pass through all text-telephone protocols

according to ITU-T Recommendation V.18, November 2000, in a

transparent fashion.







--------------------------------

D. PSTN to PSTN through IP

This is another, more operator internal area that might need its own
discussion.





With A solved, we can carry on discussing B, C and possibly D.

The current language in



Gunnar

-------------------------------------------------------------------

Gunnar Hellström

Omnitor

= EMAIL ADDRESS REMOVED =

Tel: +46708204288

www.omnitor.se


_____


From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Paul E. Jones
Sent: Thursday, May 24, 2007 12:34 AM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.



Gunnar,



Not to drive the committee into a deep hole on this much-debated issue, but
in spite of the many references to RFC 4103 (which I do favor for native IP
devices), there are concerns with the ability to utilize RFC 4103 on gateway
devices. When developing TIA-1001, we were presented with a laundry list of
requirements that, unfortunately, RFC 4103 could not always satisfy for
gateway devices (or not very well). Thus, TIA-1001 and V.151 prescribe
something different, yet very similar in capability, as a primary means of
relaying text over IP.



Perhaps more important is the loud voices I hear in the industry that are
actually deploying equipment. As much as I?ve pushed to get support for a
text relay mechanism between analog TTY devices over IP, it is very
difficult to even get DSPs in the market that can do proper tone detection,
let alone error-free character extraction. Even if that issue is solved
(which it could be), we?re still faced with other problems:



· RFC 4103 consumes more resources on large gateways, which would
lead to higher port costs and/or lower port density

· The PSTN circuit is a multiplex of voice and TTY signals.
Separating text and voice into separate steams on IP, only to put them back
together again on a remote gateway, is a zero-gain exercise (i.e., it?s a
complete waste)

· It takes time to establish an RFC 4103 stream, especially if there
are H.248 media gateways, two media gateway controllers, and one or more
proxies in the call path (and we have all of this and more in the IMS
architecture), so RFC 4103 might introduce delays in initial communication
which can be avoided with TIA-1001

· For legacy TTY devices, carriers seem to not favor text relay at
all, preferring to use G.711 and simply pass TTY signals over G.711 (much to
my dismay)



So, simply declaring that a gateway device shall support RFC 4103 and citing
standards references is insufficient. The problem is a complicated on a
number of levels, which is why carriers seem to favor treating TTY as voice.
Placing a requirement on gateway equipment to relay modulated TTY signals is
an uphill battle, and one that simply cannot be met with many of the tens of
thousands of already-deployed gateway devices in the field. When we can get
a foot in the door, to then further complicate the problem with multiple RTP
streams, multiplexing issues, and higher per-port costs, increased signaling
overhead, etc., will likely mean we stick with G.711 for legacy TTY support
indefinitely.



So, if I were to place bets on what I think stands the greatest chance of
succeeding on gateway devices in the carrier space, it would be (in order):

· V.152 (Voice Band Data, i.e., use G.711 or better for
pass-through)

· TIA-1001 / V.151 (if we can convince folks to do relay at all)

· RFC 4103



Paul





From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Gunnar
Hellström
Sent: Wednesday, May 23, 2007 5:19 PM
To: Teitac-telecom
Subject: [teitac-telecom] RFC 4103 reference for real-time text.



I want to comment on today?s meeting discussion on 1194.23(b), about the
explicit reference to RFC 4103 for real-time text.

It sounds good with many voices understanding the great benefits that are
within reach by moving to IP and getting a real-time text channel easily
integrated with other media in the calls.



However, Fred Lucas / TIA had some questions and concerns that I can answer
and hopefully resolve.



I will take them in portions.



Concern 1: ?RFC 4103 is not so much known protocol. Any protocol can be
decided now for this purpose.?



Answer: IETF RFC 4103 ?RTP Payload for text conversation? is an open
standard now referenced from at least 20 other standards from IETF, ITU-T,
3GPP and ETSI. It has for example been included as one of the three media
together with video and audio in IMS Multimedia Telephony. IMS is the next
environment we will see grow for establishing IP based telecom services.



These standards comprise:

-Transmission

-Service specification

-Terminal functionality

-Gateways

-Emergency services

-Relay services



No other standard for real-time text has the ambition to have this wide
coverage. It has taken some years to reach this acceptance level.



Here are a few excerpts:



1. >From RFC 4305, SIP telephony device requirements:

?Req-55: SIP telephony devices that include a display, or have a

facility for connecting an external display, MUST include

protocol support as described in RFC 4103 [23] for real-time

interactive text.?



2. >From ietf-draft-ecrit-requirements: ?Requirements for Emergency Context
Resolution with Internet Technologies?

?Emergency calling must support a variety of

media. Such media should include voice, conversational text
([RFC4103]), instant messaging and video.?



3. >From ITU-T V.151 ?Procedures for the end-to-end connection of analogue
PSTN text telephones over an IP network utilizing text relay?

?In general, ITDs transmit text characters when communicating with other
ITDs using RFC 4103, which specifies the establishment of a separate RTP
stream specifically for transmitting text characters.? ( ITDs are IP text
devices )



Etc.



Conclusion: Well covered in standards, ready for wider deployment.



Regards



Gunnar Hellström

-------------------------------------------------------------------

Gunnar Hellström

Omnitor

= EMAIL ADDRESS REMOVED =

Tel: +46708204288

www.omnitor.se





__________ NOD32 2285 (20070522) Information __________

Detta meddelande är genomsökt av NOD32 Antivirus.
http://www.nod32.com



__________ NOD32 2313 (20070606) Information __________

Detta meddelande är genomsökt av NOD32 Antivirus.
http://www.nod32.com

From: Jim Tobias
Date: Sun, Jun 10 2007 6:20 AM
Subject: Re: RFC 4103 reference for real-time text.

Thanks, Paul and others, for this stimulating technical discussion.

As important as it is to get the technology right, Paul begins to move in an
even more important
direction: what do users want in a replacement for the wireline Baudot TTY?
Luckily, there is no
shortage of consumers ready to answer this question. In fact, the answers
already reside in the
market choices of these consumers, at least the early (if 5-10 years is
"early") adopters of wireless
text, IP relay, and video relay and their growing technological
sophistication.

The problem is not in the technology, but in the lack of a consensus on the
technology policy. If
all the stakeholders -- users, TTY manufacturers, TRS providers, mainstream
carriers and manufacturers,
regulators, etc. -- were brought together in an authoritative process, we
could solve this migration
muddle, improve the user experience, and save tens of millions of dollars a
year. By "authoritative process"
I mean something with carrots and sticks that can drive policy regarding TTY
compatibility requirements,
equipment distribution programs, etc. That's not easy, but it is feasible.



***
Jim Tobias
Inclusive Technologies
+1.732.441.0831 v/tty
+1.908.907.2387 mobile
skype jimtobias




_____

From: Paul E. Jones [mailto: = EMAIL ADDRESS REMOVED = ]
Sent: Saturday, June 09, 2007 5:32 PM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.



Gregg,



I still do not think it is a good idea to require every phone to support
real-times text. Not every phone today supports text, while they certainly
could. Baudot is trivial, the it could be integrated into my wireless phone
very easily. But, that?s not what I would want to use!



I think we need to ?be careful what we ask for?, otherwise what we might
have is a large number of inferior devices and then people asking, ?what
more do you want??? There might be a resistance to consider making other
options available.



Today, not every phone is accessible. But, what is accessible is the phone
network. A user can use his equipment (or provided equipment) and access
the PSTN to communicate with anybody in the world. They key is ?network
access?, not ?phone access?. If we wanted to mandate public phones have
integrated RFC 4103 capabilities, fine. Those are closed systems that might
offer no other interface. Or will they? It might be possible to use an
external text device that works wirelessly with the public phone as a
?natural extension? of the phone. (Never discount the possibility that
technology might evolve in the future into something quite different than
what we have today. I am working on just such a new kind of system.
Whether it sees the light of day is another matter, but we should at least
consider how technology is ever-changing and more sophisticated.)



What I would personally want to be able to use is a Pocket PC, Ultra Mobile
PC (UMPC) or other device with communication software installed. I would
like to have a means to access the network, such as via an Ethernet
connection or a wireless access point. (It?s not too hard for me to imagine
that a business could establish a VLAN specifically for such purposes: I
have the equipment necessary to do that in my house, so it?s not beyond
reach.)



So, I would encourage you to consider the network, not the phone, as the
focal point for accessibility. This will enable users to have a wider
variety of options, including portable PC devices, dedicated textphones,
PCs, or other devices.



Paul





From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Gregg
Vanderheiden
Sent: Friday, June 08, 2007 4:24 PM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.



TTY is critical on PSTN. It is the only thing that works there.



But it does not work well and is very limiting on IP. Like cellular
phones, (that also can't transport TTY tones natively without destroying
them, the strategy is to convert to a data format where there system
connects to the PSTN.



V.151 is a protocol designed to work between gateways. It is great there.







We need protocols between VoIP phones and between VoIP phones and gateways.




The best I can see is a hybrid approach.





1) Require that all VoIP phones, routers etc support both RFC-4103 and and
RFC-4351 - WHERE THEY CONNECT TO PUBLIC IP SIP SYSTEMS ? OR CONNECT TO
OTHER SYSTEMS. (Internally within their own systems where they control
both ends and intermediate routers, they can use anything that meets the
reliability requirements ).

2) PSTN to IP Gateways would also support both but could give preference to
RFC-4351 (offer it first) so that they can save a port for each call. (if
everyone supports both as they should ? then RFC-4351 would work first time.


3) On non public systems (Skype, Vonnage, Corporations Internal systems,
etc) any text transport that meets the requirements is allowed as long as it
is translated into TTY at any PSTN interface and into RFC04103 and 4351 at
any external IP SIP interface.





Would this hit the major issues?




Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.






_____


From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Paul E. Jones
Sent: Friday, June 08, 2007 2:10 PM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.

Gunnar,



B. This is precisely the issue we really need to tackle. Do we force all
TTY users to have to continue using those devices until the end of time, can
we find a technology that enables us to bridge the old and new, or do we
just make a complete switch to something new? We?ve got three options and
it seems like there is no consensus. Initially, we were told support for
legacy TTY devices was very important, so we created V.151. Then we were
told they?re not. I just saw the document from the FCC, which seems to
strongly encourage (or mandate) support for accessibility capabilities, but
it is open to interpretation (somewhat). You want to enable users to make
calls using RFC 4103. But a VoIP service provider?s ATA device likely
cannot even detect Baudot tones, let alone discriminate between Baudot, EDT,
V.21 textphones, fax machines, and modems. This can be addressed, but
nobody wants to do anything and see it viewed as a wasted effort. We all
need to agree on what to do and then execute, but it?s really annoying that
we cannot reach a consensus. If packet loss is a problem, then having
centralized gateway do conversion from audio to text will not solve the
problem. So, we either have to ensure that we do not have packet loss,
forget about TTY support and move to new technology, or we must add proper
support for TTYs. Can we reach an agreement on this point?



C. So we do need to support the legacy devices? I would suggest that we
consider using V.151 Annex D.



Paul



From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Gunnar
Hellström
Sent: Thursday, June 07, 2007 5:15 PM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.



Paul,



A. IP to IP

Fine. This is an important step for good progress in design for all in
telecomms. Are there more parties who can join in this agreement?



B. PSTN to IP in large gateways

Just sending G.711 audio is likely not sufficiently reliable for TIA 825.
Because of its long character time of 165 ms, and its letter shift ? figure
shift technique, it is extremely sensitive to packet loss. The quite high
acceptable limit of 1% character errors require a theoretical packet loss
rate of a maximum of 0.1% when using plain G.711. That is too risky even in
good networks.

Much better with same bandwidth would probably be G.726 with one level of
redundancy. Then you would even allow 3% packet loss and still get usable
result. ( 1% errors). But beware! As recently discussed, other disturbing
effects like echo handlers and distorsion tends to come in and destroy the
real result as compared to the theoretical.



And what would be the destination of the audio coded text? I do not see it
realistic to take it all the way to the IP terminal. But possibly to an
intermediate gateway that converts to a text format that the terminal
supports. Do you want to propose double text codecs in all IP terminals
interested in TTY compatibility? One for IP to IP and one for IP ? PSTN?



Some efforts to support TTY transport should be maintained, but the users
have asked us to not focus all energy on that problem, so that the
functional enhancements within reach in IP networks are lost. I understand
that as a preparedness to discuss compromises, like using some added
procedures in order to be routed through text capable gateways.

Can we expect Emergency services and relay services to open an agreed IP ?
IP real-time text method ( A ) very soon? If not, good TTY interoperability
is at least needed for access to these services.



C. PSTN to IP in residential gateways and ATAs.

We need to have a solution for the case when a terminal behind an ATA calls
a native IP terminal. Should the call be routed to a big VoIP gateway where
proper support would be found for conversion to an IP transport of text that
is supported by the terminal.



D. PSTN to PSTN through IP

Yes, this is a GW to GW case, suitable for V.151 if you want.



Gunnar

-------------------------------------------------------------------

Gunnar Hellström

Omnitor

= EMAIL ADDRESS REMOVED =

Tel: +46708204288

www.omnitor.se


_____


From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Paul E. Jones
Sent: Thursday, June 07, 2007 10:09 PM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.



Gunnar,



A. Yeah, I think we can agree on RFC 4103 for IP text-capable devices.
(That does not change my argument for also wanting V.151 support to work
with gateways, though. But direct IP-terminal to IP-terminal should be RFC
4103.)



B. This is the sticky problem. Do we need to demodulate signals and
transport real text from large gateways, or do we just send G.711 audio?
Several years ago, there was a lot of concern expressed with packet loss and
unacceptable character error rate. ATIS held a meeting on this topic. We
initiated work on V.151 and completed that. But now, it seems that there is
a growing consensus that we no longer need to consider legacy TTY support.
So, I?m very confused. Do we need to further consider support for legacy
TTY devices?



C. ATAs ? What this requirement fails to consider is that more ATAs will
have fax devices connected to them than text phones. There will also be
standard modem devices and other devices (e.g., security alarm systems,
point of sale terminals, etc.) that may not use standard modulations. There
is little we can do for non-standard modulations, except to use G.711. But,
for standard modulations, we can to T.38 for fax, V.150 for modem, and V.151
for text. RFC 4103 could be considered, but it must be introduced in such a
way that fax calls and modem calls still work. For this reason, V.151 may
still be the better choice.



D. This sounds like a GW to GW case, which fits precisely within the scope
of V.151.



Paul



From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Gunnar
Hellström
Sent: Tuesday, June 05, 2007 5:52 PM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.



Paul and all,

I want to return to the discussion on 1194.23(b) about real-time text
interoperability.

We left it with too much uncertainty.



A. IP to IP

If we look through the arguments, we easily find that there is quite good
agreement on how to handle real-time text in the pure IP environment.

You, say:

?in spite of the many references to RFC 4103 (which I do favor for native IP
devices), there are concerns with the ability to utilize RFC 4103 on gateway
devices.?

This is also what the statements in 1194.23(b) say.

So, in fact there is an emerging agreement that RFC 4103 is to be favoured
between IP terminals. This agreement can also be seen in the growing number
of references in standards and policy documents.



Based on that agreement we can build a new class of high functionality,
fully interoperable IP Text capable phones and IP Total conversation devices
corresponding to the draft requirement 1194.23(b). Knowing that there is an
agreement on this level will encourage a good new market. Interoperability
is the key to popularity.



Do we have more parties agreeing on this?

----------------------------------------------------------



B. PSTN to IP in large gateways

With that agreement settled we may approach the issue of gateways between
TTY and IP Text capable terminals.

We use RFC 4103 in small scale PSTN/IP gateways without problems. But you
talk about possible concerns in large scale PSTN/IP gateways.



You correctly state:? Placing a requirement on gateway equipment to relay
modulated TTY signals is an uphill battle, and one that simply cannot be met
with many of the tens of thousands of already-deployed gateway devices in
the field.?

Other methods than forcing all ports to support TTY are required to achieve
TTY / IP text interoperability. It is very likely that we need to agree on
some way to route the calls that MAY contain TTY so that they pass gateway
ports with special capability of conversion between TTY and an IP real-time
text format. Such methods are discussed in standards groups, and they should
be encouraged to come to workable solutions.



C. PSTN to IP in residential gateways and ATAs.

Another problem is what to recommend for the analogue terminal adapters.
There you have no choice. If it provides a PSTN device port, it should
behave properly for attached TTY:s.



This is what RFC 4504 ?Sip Telephony devices? says about the ATA or
residential gateway:

-----From RFC 4504------



Req-57: SIP telephony devices MAY provide analog adaptor

functionality through an RJ-11 FXS port to support FXS

devices. If an RJ-11 (FXS) port is provided, then it MAY

support a gateway function from all text-telephone protocols

according to ITU-T Recommendation V.18 to RFC 4103 text

conversation (in fact, this is encouraged in the near term

during the transition to widespread use of SIP telephony

devices). If this gateway function is not included or fails,

the device MUST pass through all text-telephone protocols

according to ITU-T Recommendation V.18, November 2000, in a

transparent fashion.







--------------------------------

D. PSTN to PSTN through IP

This is another, more operator internal area that might need its own
discussion.





With A solved, we can carry on discussing B, C and possibly D.

The current language in



Gunnar

-------------------------------------------------------------------

Gunnar Hellström

Omnitor

= EMAIL ADDRESS REMOVED =

Tel: +46708204288

www.omnitor.se


_____


From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Paul E. Jones
Sent: Thursday, May 24, 2007 12:34 AM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.



Gunnar,



Not to drive the committee into a deep hole on this much-debated issue, but
in spite of the many references to RFC 4103 (which I do favor for native IP
devices), there are concerns with the ability to utilize RFC 4103 on gateway
devices. When developing TIA-1001, we were presented with a laundry list of
requirements that, unfortunately, RFC 4103 could not always satisfy for
gateway devices (or not very well). Thus, TIA-1001 and V.151 prescribe
something different, yet very similar in capability, as a primary means of
relaying text over IP.



Perhaps more important is the loud voices I hear in the industry that are
actually deploying equipment. As much as I?ve pushed to get support for a
text relay mechanism between analog TTY devices over IP, it is very
difficult to even get DSPs in the market that can do proper tone detection,
let alone error-free character extraction. Even if that issue is solved
(which it could be), we?re still faced with other problems:



· RFC 4103 consumes more resources on large gateways, which would
lead to higher port costs and/or lower port density

· The PSTN circuit is a multiplex of voice and TTY signals.
Separating text and voice into separate steams on IP, only to put them back
together again on a remote gateway, is a zero-gain exercise (i.e., it?s a
complete waste)

· It takes time to establish an RFC 4103 stream, especially if there
are H.248 media gateways, two media gateway controllers, and one or more
proxies in the call path (and we have all of this and more in the IMS
architecture), so RFC 4103 might introduce delays in initial communication
which can be avoided with TIA-1001

· For legacy TTY devices, carriers seem to not favor text relay at
all, preferring to use G.711 and simply pass TTY signals over G.711 (much to
my dismay)



So, simply declaring that a gateway device shall support RFC 4103 and citing
standards references is insufficient. The problem is a complicated on a
number of levels, which is why carriers seem to favor treating TTY as voice.
Placing a requirement on gateway equipment to relay modulated TTY signals is
an uphill battle, and one that simply cannot be met with many of the tens of
thousands of already-deployed gateway devices in the field. When we can get
a foot in the door, to then further complicate the problem with multiple RTP
streams, multiplexing issues, and higher per-port costs, increased signaling
overhead, etc., will likely mean we stick with G.711 for legacy TTY support
indefinitely.



So, if I were to place bets on what I think stands the greatest chance of
succeeding on gateway devices in the carrier space, it would be (in order):

· V.152 (Voice Band Data, i.e., use G.711 or better for
pass-through)

· TIA-1001 / V.151 (if we can convince folks to do relay at all)

· RFC 4103



Paul





From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Gunnar
Hellström
Sent: Wednesday, May 23, 2007 5:19 PM
To: Teitac-telecom
Subject: [teitac-telecom] RFC 4103 reference for real-time text.



I want to comment on today?s meeting discussion on 1194.23(b), about the
explicit reference to RFC 4103 for real-time text.

It sounds good with many voices understanding the great benefits that are
within reach by moving to IP and getting a real-time text channel easily
integrated with other media in the calls.



However, Fred Lucas / TIA had some questions and concerns that I can answer
and hopefully resolve.



I will take them in portions.



Concern 1: ?RFC 4103 is not so much known protocol. Any protocol can be
decided now for this purpose.?



Answer: IETF RFC 4103 ?RTP Payload for text conversation? is an open
standard now referenced from at least 20 other standards from IETF, ITU-T,
3GPP and ETSI. It has for example been included as one of the three media
together with video and audio in IMS Multimedia Telephony. IMS is the next
environment we will see grow for establishing IP based telecom services.



These standards comprise:

-Transmission

-Service specification

-Terminal functionality

-Gateways

-Emergency services

-Relay services



No other standard for real-time text has the ambition to have this wide
coverage. It has taken some years to reach this acceptance level.



Here are a few excerpts:



1. >From RFC 4305, SIP telephony device requirements:

?Req-55: SIP telephony devices that include a display, or have a

facility for connecting an external display, MUST include

protocol support as described in RFC 4103 [23] for real-time

interactive text.?



2. >From ietf-draft-ecrit-requirements: ?Requirements for Emergency Context
Resolution with Internet Technologies?

?Emergency calling must support a variety of

media. Such media should include voice, conversational text
([RFC4103]), instant messaging and video.?



3. >From ITU-T V.151 ?Procedures for the end-to-end connection of analogue
PSTN text telephones over an IP network utilizing text relay?

?In general, ITDs transmit text characters when communicating with other
ITDs using RFC 4103, which specifies the establishment of a separate RTP
stream specifically for transmitting text characters.? ( ITDs are IP text
devices )



Etc.



Conclusion: Well covered in standards, ready for wider deployment.



Regards



Gunnar Hellström

-------------------------------------------------------------------

Gunnar Hellström

Omnitor

= EMAIL ADDRESS REMOVED =

Tel: +46708204288

www.omnitor.se





__________ NOD32 2285 (20070522) Information __________

Detta meddelande är genomsökt av NOD32 Antivirus.
http://www.nod32.com



__________ NOD32 2313 (20070606) Information __________

Detta meddelande är genomsökt av NOD32 Antivirus.
http://www.nod32.com

From: Diane Golden
Date: Sun, Jun 10 2007 2:50 PM
Subject: Re: RFC 4103 reference for real-time text.

VCO is voice carry over and does use Baudot (unless there's something out
there I'm unaware of.) The person with the VCO phone uses their own voice
to send communication and received by reading text (almost always coming via
relay). Captel does use a different transmission but I believe has a
secondary Baudot capacity to allow users to call 911 directly by making a
"traditional VCO" call. When they switch to "traditional VCO" the CapTel
user no longer has simultaneous voice/text coming in (just text) and the
outgoing call to 911 just goes to the emergency center instead of
automatically connecting to the CapTel relay center.

Not only do we have transmission/code issues with these systems, we also
have a situation in which a proprietary product is the only avenue to obtain
a more effective relay service unless the consumer can go to IP. Right now
consumers who need VCO can use "traditional VCO" with a number of products
on the market but it uses regular relay services which do not provide nearly
the speed of conversion of speech to text as does the CapTel relay service.
So if you want the faster relay, you have to use the CapTel phone which
provides simultaneous voice/text which many consumers can't use (don't have
the residual hearing) and for some it actually disrupts their ability to
communicate effectively (especially elderly). I'm not sure what the answer
is -- but for those of us who work with consumers every day, it is really
frustrating to have to purchase one proprietary phone that has
uneeded/unwanted features just to be able to access a more
efficient/effective relay service. Sorry, my venting for the day.

Diane

Diane Cordry Golden, Ph.D., Director
Missouri Assistive Technology
816/350-5280 (direct voice)
= EMAIL ADDRESS REMOVED =
www.at.mo.gov



-----Original Message-----
From: Paul E. Jones [mailto: = EMAIL ADDRESS REMOVED = ]
Sent: Saturday, June 09, 2007 4:18 PM
To: = EMAIL ADDRESS REMOVED = ; 'TEITAC Telecommunications Subcommittee'
Subject: RE: [teitac-telecom] RFC 4103 reference for real-time text.



Diane,



What is a ?VCO phone?? Is this one that still uses Baudot for character
transmission?



Captel, as I understand, does not use Baudot. As such, it will introduce
significantly more hurdles moving forward. Over the past few years as we?ve
been working on new standards to move from a legacy TTY world to an IP
world, several of us in the industry have invited Ultratec to participate
and to share information so that we can integrate the technology into
standards, but they?ve repeatedly declined. So, I really worry about how we
could ever possibly support Captel. The only choice might be to use G.711,
but then the government could not require VoIP service providers like Vonage
or services from AT&T like CallVantage to support it, because there is no
way for either of those carriers to guarantee (or even remotely attempt) to
guarantee the low packet loss rates necessary for those services to work
since they do not own the access lines going into subscriber?s homes.



Perhaps we need to move to distributing IP versions of those same kinds of
technologies well in advance of a complete migration to VoIP.



Paul





From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Diane Golden
Sent: Friday, June 08, 2007 4:18 PM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.



On behalf of one of the state programs that distribute adaptive telephone
equipment, pure TTY's are a very tiny part of the distribution today. The
numbers have steadily decreased year after year as people move to other
equipment options. What we don't have is good data on how many people use
the TTY as their only telecom equipment rather than a secondary or
supplemental option. We do now distribute more VCO phones (including
regular VCO and CapTel) than TTYs and for pretty much all of these people
that is the only telecom option they have. So that group may actually be
our biggest legacy equipment problem.



Diane



Diane Cordry Golden, Ph.D., Director
Missouri Assistive Technology
816/350-5280 (direct voice)
= EMAIL ADDRESS REMOVED =
www.at.mo.gov



-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ]On Behalf Of Pam Ransom
Sent: Friday, June 08, 2007 2:16 PM
To: TEITAC Telecommunications Subcommittee
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.

Just a reminder ... There are approximately 25-27 states that continue to
administer TTY Distribution Programs, and thus there is a significant
embedded base of this older TTY technology. Pam Ransom

----- Original Message -----

From: Paul E. Jones

To: 'TEITAC Telecommunications Subcommittee'

Sent: Friday, June 08, 2007 2:10 PM

Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.



Gunnar,



B. This is precisely the issue we really need to tackle. Do we force all
TTY users to have to continue using those devices until the end of time, can
we find a technology that enables us to bridge the old and new, or do we
just make a complete switch to something new? We've got three options and
it seems like there is no consensus. Initially, we were told support for
legacy TTY devices was very important, so we created V.151. Then we were
told they're not. I just saw the document from the FCC, which seems to
strongly encourage (or mandate) support for accessibility capabilities, but
it is open to interpretation (somewhat). You want to enable users to make
calls using RFC 4103. But a VoIP service provider's ATA device likely
cannot even detect Baudot tones, let alone discriminate between Baudot, EDT,
V.21 textphones, fax machines, and modems. This can be addressed, but
nobody wants to do anything and see it viewed as a wasted effort. We all
need to agree on what to do and then execute, but it's really annoying that
we cannot reach a consensus. If packet loss is a problem, then having
centralized gateway do conversion from audio to text will not solve the
problem. So, we either have to ensure that we do not have packet loss,
forget about TTY support and move to new technology, or we must add proper
support for TTYs. Can we reach an agreement on this point?



C. So we do need to support the legacy devices? I would suggest that we
consider using V.151 Annex D.



Paul



From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Gunnar
Hellström
Sent: Thursday, June 07, 2007 5:15 PM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.



Paul,



A. IP to IP

Fine. This is an important step for good progress in design for all in
telecomms. Are there more parties who can join in this agreement?



B. PSTN to IP in large gateways

Just sending G.711 audio is likely not sufficiently reliable for TIA 825.
Because of its long character time of 165 ms, and its letter shift - figure
shift technique, it is extremely sensitive to packet loss. The quite high
acceptable limit of 1% character errors require a theoretical packet loss
rate of a maximum of 0.1% when using plain G.711. That is too risky even in
good networks.

Much better with same bandwidth would probably be G.726 with one level of
redundancy. Then you would even allow 3% packet loss and still get usable
result. ( 1% errors). But beware! As recently discussed, other disturbing
effects like echo handlers and distorsion tends to come in and destroy the
real result as compared to the theoretical.



And what would be the destination of the audio coded text? I do not see it
realistic to take it all the way to the IP terminal. But possibly to an
intermediate gateway that converts to a text format that the terminal
supports. Do you want to propose double text codecs in all IP terminals
interested in TTY compatibility? One for IP to IP and one for IP - PSTN?



Some efforts to support TTY transport should be maintained, but the users
have asked us to not focus all energy on that problem, so that the
functional enhancements within reach in IP networks are lost. I understand
that as a preparedness to discuss compromises, like using some added
procedures in order to be routed through text capable gateways.

Can we expect Emergency services and relay services to open an agreed IP -
IP real-time text method ( A ) very soon? If not, good TTY interoperability
is at least needed for access to these services.



C. PSTN to IP in residential gateways and ATAs.

We need to have a solution for the case when a terminal behind an ATA
calls a native IP terminal. Should the call be routed to a big VoIP gateway
where proper support would be found for conversion to an IP transport of
text that is supported by the terminal.



D. PSTN to PSTN through IP

Yes, this is a GW to GW case, suitable for V.151 if you want.



Gunnar

-------------------------------------------------------------------

Gunnar Hellström

Omnitor

= EMAIL ADDRESS REMOVED =

Tel: +46708204288

www.omnitor.se


----------------------------------------------------------------------------
--

From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Paul E. Jones
Sent: Thursday, June 07, 2007 10:09 PM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.



Gunnar,



A. Yeah, I think we can agree on RFC 4103 for IP text-capable devices.
(That does not change my argument for also wanting V.151 support to work
with gateways, though. But direct IP-terminal to IP-terminal should be RFC
4103.)



B. This is the sticky problem. Do we need to demodulate signals and
transport real text from large gateways, or do we just send G.711 audio?
Several years ago, there was a lot of concern expressed with packet loss and
unacceptable character error rate. ATIS held a meeting on this topic. We
initiated work on V.151 and completed that. But now, it seems that there is
a growing consensus that we no longer need to consider legacy TTY support.
So, I'm very confused. Do we need to further consider support for legacy
TTY devices?



C. ATAs - What this requirement fails to consider is that more ATAs will
have fax devices connected to them than text phones. There will also be
standard modem devices and other devices (e.g., security alarm systems,
point of sale terminals, etc.) that may not use standard modulations. There
is little we can do for non-standard modulations, except to use G.711. But,
for standard modulations, we can to T.38 for fax, V.150 for modem, and V.151
for text. RFC 4103 could be considered, but it must be introduced in such a
way that fax calls and modem calls still work. For this reason, V.151 may
still be the better choice.



D. This sounds like a GW to GW case, which fits precisely within the scope
of V.151.



Paul



From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Gunnar
Hellström
Sent: Tuesday, June 05, 2007 5:52 PM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.



Paul and all,

I want to return to the discussion on 1194.23(b) about real-time text
interoperability.

We left it with too much uncertainty.



A. IP to IP

If we look through the arguments, we easily find that there is quite good
agreement on how to handle real-time text in the pure IP environment.

You, say:

"in spite of the many references to RFC 4103 (which I do favor for native
IP devices), there are concerns with the ability to utilize RFC 4103 on
gateway devices."

This is also what the statements in 1194.23(b) say.

So, in fact there is an emerging agreement that RFC 4103 is to be favoured
between IP terminals. This agreement can also be seen in the growing number
of references in standards and policy documents.



Based on that agreement we can build a new class of high functionality,
fully interoperable IP Text capable phones and IP Total conversation devices
corresponding to the draft requirement 1194.23(b). Knowing that there is an
agreement on this level will encourage a good new market. Interoperability
is the key to popularity.



Do we have more parties agreeing on this?

----------------------------------------------------------



B. PSTN to IP in large gateways

With that agreement settled we may approach the issue of gateways between
TTY and IP Text capable terminals.

We use RFC 4103 in small scale PSTN/IP gateways without problems. But you
talk about possible concerns in large scale PSTN/IP gateways.



You correctly state:" Placing a requirement on gateway equipment to relay
modulated TTY signals is an uphill battle, and one that simply cannot be met
with many of the tens of thousands of already-deployed gateway devices in
the field."

Other methods than forcing all ports to support TTY are required to
achieve TTY / IP text interoperability. It is very likely that we need to
agree on some way to route the calls that MAY contain TTY so that they pass
gateway ports with special capability of conversion between TTY and an IP
real-time text format. Such methods are discussed in standards groups, and
they should be encouraged to come to workable solutions.



C. PSTN to IP in residential gateways and ATAs.

Another problem is what to recommend for the analogue terminal adapters.
There you have no choice. If it provides a PSTN device port, it should
behave properly for attached TTY:s.



This is what RFC 4504 "Sip Telephony devices" says about the ATA or
residential gateway:

-----From RFC 4504------



Req-57: SIP telephony devices MAY provide analog adaptor

functionality through an RJ-11 FXS port to support FXS

devices. If an RJ-11 (FXS) port is provided, then it MAY

support a gateway function from all text-telephone protocols

according to ITU-T Recommendation V.18 to RFC 4103 text

conversation (in fact, this is encouraged in the near term

during the transition to widespread use of SIP telephony

devices). If this gateway function is not included or fails,

the device MUST pass through all text-telephone protocols

according to ITU-T Recommendation V.18, November 2000, in a

transparent fashion.







--------------------------------

D. PSTN to PSTN through IP

This is another, more operator internal area that might need its own
discussion.





With A solved, we can carry on discussing B, C and possibly D.

The current language in



Gunnar

-------------------------------------------------------------------

Gunnar Hellström

Omnitor

= EMAIL ADDRESS REMOVED =

Tel: +46708204288

www.omnitor.se


----------------------------------------------------------------------------
--

From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Paul E. Jones
Sent: Thursday, May 24, 2007 12:34 AM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.



Gunnar,



Not to drive the committee into a deep hole on this much-debated issue,
but in spite of the many references to RFC 4103 (which I do favor for native
IP devices), there are concerns with the ability to utilize RFC 4103 on
gateway devices. When developing TIA-1001, we were presented with a laundry
list of requirements that, unfortunately, RFC 4103 could not always satisfy
for gateway devices (or not very well). Thus, TIA-1001 and V.151 prescribe
something different, yet very similar in capability, as a primary means of
relaying text over IP.



Perhaps more important is the loud voices I hear in the industry that are
actually deploying equipment. As much as I've pushed to get support for a
text relay mechanism between analog TTY devices over IP, it is very
difficult to even get DSPs in the market that can do proper tone detection,
let alone error-free character extraction. Even if that issue is solved
(which it could be), we're still faced with other problems:



· RFC 4103 consumes more resources on large gateways, which would
lead to higher port costs and/or lower port density

· The PSTN circuit is a multiplex of voice and TTY signals.
Separating text and voice into separate steams on IP, only to put them back
together again on a remote gateway, is a zero-gain exercise (i.e., it's a
complete waste)

· It takes time to establish an RFC 4103 stream, especially if
there are H.248 media gateways, two media gateway controllers, and one or
more proxies in the call path (and we have all of this and more in the IMS
architecture), so RFC 4103 might introduce delays in initial communication
which can be avoided with TIA-1001

· For legacy TTY devices, carriers seem to not favor text relay at
all, preferring to use G.711 and simply pass TTY signals over G.711 (much to
my dismay)



So, simply declaring that a gateway device shall support RFC 4103 and
citing standards references is insufficient. The problem is a complicated
on a number of levels, which is why carriers seem to favor treating TTY as
voice. Placing a requirement on gateway equipment to relay modulated TTY
signals is an uphill battle, and one that simply cannot be met with many of
the tens of thousands of already-deployed gateway devices in the field.
When we can get a foot in the door, to then further complicate the problem
with multiple RTP streams, multiplexing issues, and higher per-port costs,
increased signaling overhead, etc., will likely mean we stick with G.711 for
legacy TTY support indefinitely.



So, if I were to place bets on what I think stands the greatest chance of
succeeding on gateway devices in the carrier space, it would be (in order):

· V.152 (Voice Band Data, i.e., use G.711 or better for
pass-through)

· TIA-1001 / V.151 (if we can convince folks to do relay at all)

· RFC 4103



Paul





From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Gunnar
Hellström
Sent: Wednesday, May 23, 2007 5:19 PM
To: Teitac-telecom
Subject: [teitac-telecom] RFC 4103 reference for real-time text.



I want to comment on today's meeting discussion on 1194.23(b), about the
explicit reference to RFC 4103 for real-time text.

It sounds good with many voices understanding the great benefits that are
within reach by moving to IP and getting a real-time text channel easily
integrated with other media in the calls.



However, Fred Lucas / TIA had some questions and concerns that I can
answer and hopefully resolve.



I will take them in portions.



Concern 1: "RFC 4103 is not so much known protocol. Any protocol can be
decided now for this purpose."



Answer: IETF RFC 4103 "RTP Payload for text conversation" is an open
standard now referenced from at least 20 other standards from IETF, ITU-T,
3GPP and ETSI. It has for example been included as one of the three media
together with video and audio in IMS Multimedia Telephony. IMS is the next
environment we will see grow for establishing IP based telecom services.



These standards comprise:

-Transmission

-Service specification

-Terminal functionality

-Gateways

-Emergency services

-Relay services



No other standard for real-time text has the ambition to have this wide
coverage. It has taken some years to reach this acceptance level.



Here are a few excerpts:



1. >From RFC 4305, SIP telephony device requirements:

"Req-55: SIP telephony devices that include a display, or have a

facility for connecting an external display, MUST include

protocol support as described in RFC 4103 [23] for real-time

interactive text."



2. >From ietf-draft-ecrit-requirements: "Requirements for Emergency
Context Resolution with Internet Technologies"

"Emergency calling must support a variety of

media. Such media should include voice, conversational text
([RFC4103]), instant messaging and video."



3. >From ITU-T V.151 "Procedures for the end-to-end connection of
analogue PSTN text telephones over an IP network utilizing text relay"

"In general, ITDs transmit text characters when communicating with other
ITDs using RFC 4103, which specifies the establishment of a separate RTP
stream specifically for transmitting text characters." ( ITDs are IP text
devices )



Etc.



Conclusion: Well covered in standards, ready for wider deployment.



Regards



Gunnar Hellström

-------------------------------------------------------------------

Gunnar Hellström

Omnitor

= EMAIL ADDRESS REMOVED =

Tel: +46708204288

www.omnitor.se





__________ NOD32 2285 (20070522) Information __________

Detta meddelande är genomsökt av NOD32 Antivirus.
http://www.nod32.com



__________ NOD32 2313 (20070606) Information __________

Detta meddelande är genomsökt av NOD32 Antivirus.
http://www.nod32.com


----------------------------------------------------------------------------
--

From: Paul E. Jones
Date: Sun, Jun 10 2007 5:55 PM
Subject: Re: RFC 4103 reference for real-time text.

Diane,



OK, my understand of VCO was in line with yours. The way it was worded
("VCO phone"), I thought it was a phone like Captel that I just had not
heard about before.



Your venting is well-justified. Since I started working in this area
several years ago, I've co-authored several standards, been given several
conflicting requirements, been accused of doing an injustice to the deaf
community, and had countless debates that were far less than fruitful. All
the while, I am genuinely trying to find a solution that is acceptable to
everybody. I'm almost at a point of thinking there is no way.



One of the problems that I've observed (at least, this is my personal
opinion) is that people try to take the old technology and apply it to the
new technology. New technology opens the door for changes. IP, in general,
really opens the door for significant changes in the way deaf people can
communicate. What I hope is that we recognize the possibilities and do not
rush to forcing something into the market that limits those possibilities.



Initially, I would think (as was originally posited to me) that "bridging
the old with the new" was the first important step. We created the
standards to do that. We then need to ask, "what do we want next?" I have
an idea and I'm working on that. I do not personally view anything we have
today (in terms of standards) as the best and final step: I think we've only
scratched the surface and much more potential exists.



We need something for the moment, but we also need to ensure the door is
wide open for better technologies. It's definitely hard to codify that
desire into law.



Paul





From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Diane Golden
Sent: Sunday, June 10, 2007 4:54 PM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.



VCO is voice carry over and does use Baudot (unless there's something out
there I'm unaware of.) The person with the VCO phone uses their own voice
to send communication and received by reading text (almost always coming via
relay). Captel does use a different transmission but I believe has a
secondary Baudot capacity to allow users to call 911 directly by making a
"traditional VCO" call. When they switch to "traditional VCO" the CapTel
user no longer has simultaneous voice/text coming in (just text) and the
outgoing call to 911 just goes to the emergency center instead of
automatically connecting to the CapTel relay center.



Not only do we have transmission/code issues with these systems, we also
have a situation in which a proprietary product is the only avenue to obtain
a more effective relay service unless the consumer can go to IP. Right now
consumers who need VCO can use "traditional VCO" with a number of products
on the market but it uses regular relay services which do not provide nearly
the speed of conversion of speech to text as does the CapTel relay service.
So if you want the faster relay, you have to use the CapTel phone which
provides simultaneous voice/text which many consumers can't use (don't have
the residual hearing) and for some it actually disrupts their ability to
communicate effectively (especially elderly). I'm not sure what the answer
is -- but for those of us who work with consumers every day, it is really
frustrating to have to purchase one proprietary phone that has
uneeded/unwanted features just to be able to access a more
efficient/effective relay service. Sorry, my venting for the day.



Diane



Diane Cordry Golden, Ph.D., Director
Missouri Assistive Technology
816/350-5280 (direct voice)
= EMAIL ADDRESS REMOVED =
www.at.mo.gov



-----Original Message-----
From: Paul E. Jones [mailto: = EMAIL ADDRESS REMOVED = ]
Sent: Saturday, June 09, 2007 4:18 PM
To: = EMAIL ADDRESS REMOVED = ; 'TEITAC Telecommunications Subcommittee'
Subject: RE: [teitac-telecom] RFC 4103 reference for real-time text.

Diane,



What is a "VCO phone"? Is this one that still uses Baudot for character
transmission?



Captel, as I understand, does not use Baudot. As such, it will introduce
significantly more hurdles moving forward. Over the past few years as we've
been working on new standards to move from a legacy TTY world to an IP
world, several of us in the industry have invited Ultratec to participate
and to share information so that we can integrate the technology into
standards, but they've repeatedly declined. So, I really worry about how we
could ever possibly support Captel. The only choice might be to use G.711,
but then the government could not require VoIP service providers like Vonage
or services from AT&T like CallVantage to support it, because there is no
way for either of those carriers to guarantee (or even remotely attempt) to
guarantee the low packet loss rates necessary for those services to work
since they do not own the access lines going into subscriber's homes.



Perhaps we need to move to distributing IP versions of those same kinds of
technologies well in advance of a complete migration to VoIP.



Paul





From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Diane Golden
Sent: Friday, June 08, 2007 4:18 PM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.



On behalf of one of the state programs that distribute adaptive telephone
equipment, pure TTY's are a very tiny part of the distribution today. The
numbers have steadily decreased year after year as people move to other
equipment options. What we don't have is good data on how many people use
the TTY as their only telecom equipment rather than a secondary or
supplemental option. We do now distribute more VCO phones (including
regular VCO and CapTel) than TTYs and for pretty much all of these people
that is the only telecom option they have. So that group may actually be
our biggest legacy equipment problem.



Diane



Diane Cordry Golden, Ph.D., Director
Missouri Assistive Technology
816/350-5280 (direct voice)
= EMAIL ADDRESS REMOVED =
www.at.mo.gov



[SNIP]

From: Gregg Vanderheiden
Date: Tue, Jun 12 2007 11:15 PM
Subject: Re: RFC 4103 reference for real-time text.

Hmm



There is a bit of confusing discussion here. A few notes.





- VCO is a technique. It can be used with TTY or with other
technologies that do not support simultaneous text and speech. It is
commonly used with relays. It can also be used without using a relay.
The VCO capability on one cell phone for example can be used with an HCO
feature on another phone.



- CapTel uses industry standards for communicating in PSTN. It uses
them differently than in the past because no one offered CapTel in the past.
CapTel isn't TTY because TTY doesn't support simultaneous voice and text
which is of course required.



- IP captioned telephone can be done using RFC-4103. (It can also
be done with RFC-4351). It cannot be done with VBD or TTY tones on IP.





Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.






_____


From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Paul E. Jones
Sent: Sunday, June 10, 2007 6:49 PM
To: = EMAIL ADDRESS REMOVED = ; 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.

Diane,



OK, my understand of VCO was in line with yours. The way it was worded
("VCO phone"), I thought it was a phone like Captel that I just had not
heard about before.



Your venting is well-justified. Since I started working in this area
several years ago, I've co-authored several standards, been given several
conflicting requirements, been accused of doing an injustice to the deaf
community, and had countless debates that were far less than fruitful. All
the while, I am genuinely trying to find a solution that is acceptable to
everybody. I'm almost at a point of thinking there is no way.



One of the problems that I've observed (at least, this is my personal
opinion) is that people try to take the old technology and apply it to the
new technology. New technology opens the door for changes. IP, in general,
really opens the door for significant changes in the way deaf people can
communicate. What I hope is that we recognize the possibilities and do not
rush to forcing something into the market that limits those possibilities.



Initially, I would think (as was originally posited to me) that "bridging
the old with the new" was the first important step. We created the
standards to do that. We then need to ask, "what do we want next?" I have
an idea and I'm working on that. I do not personally view anything we have
today (in terms of standards) as the best and final step: I think we've only
scratched the surface and much more potential exists.



We need something for the moment, but we also need to ensure the door is
wide open for better technologies. It's definitely hard to codify that
desire into law.



Paul





From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Diane Golden
Sent: Sunday, June 10, 2007 4:54 PM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.



VCO is voice carry over and does use Baudot (unless there's something out
there I'm unaware of.) The person with the VCO phone uses their own voice
to send communication and received by reading text (almost always coming via
relay). Captel does use a different transmission but I believe has a
secondary Baudot capacity to allow users to call 911 directly by making a
"traditional VCO" call. When they switch to "traditional VCO" the CapTel
user no longer has simultaneous voice/text coming in (just text) and the
outgoing call to 911 just goes to the emergency center instead of
automatically connecting to the CapTel relay center.



Not only do we have transmission/code issues with these systems, we also
have a situation in which a proprietary product is the only avenue to obtain
a more effective relay service unless the consumer can go to IP. Right now
consumers who need VCO can use "traditional VCO" with a number of products
on the market but it uses regular relay services which do not provide nearly
the speed of conversion of speech to text as does the CapTel relay service.
So if you want the faster relay, you have to use the CapTel phone which
provides simultaneous voice/text which many consumers can't use (don't have
the residual hearing) and for some it actually disrupts their ability to
communicate effectively (especially elderly). I'm not sure what the answer
is -- but for those of us who work with consumers every day, it is really
frustrating to have to purchase one proprietary phone that has
uneeded/unwanted features just to be able to access a more
efficient/effective relay service. Sorry, my venting for the day.



Diane



Diane Cordry Golden, Ph.D., Director
Missouri Assistive Technology
816/350-5280 (direct voice)
= EMAIL ADDRESS REMOVED =
www.at.mo.gov



-----Original Message-----
From: Paul E. Jones [mailto: = EMAIL ADDRESS REMOVED = ]
Sent: Saturday, June 09, 2007 4:18 PM
To: = EMAIL ADDRESS REMOVED = ; 'TEITAC Telecommunications Subcommittee'
Subject: RE: [teitac-telecom] RFC 4103 reference for real-time text.

Diane,



What is a "VCO phone"? Is this one that still uses Baudot for character
transmission?



Captel, as I understand, does not use Baudot. As such, it will introduce
significantly more hurdles moving forward. Over the past few years as we've
been working on new standards to move from a legacy TTY world to an IP
world, several of us in the industry have invited Ultratec to participate
and to share information so that we can integrate the technology into
standards, but they've repeatedly declined. So, I really worry about how we
could ever possibly support Captel. The only choice might be to use G.711,
but then the government could not require VoIP service providers like Vonage
or services from AT&T like CallVantage to support it, because there is no
way for either of those carriers to guarantee (or even remotely attempt) to
guarantee the low packet loss rates necessary for those services to work
since they do not own the access lines going into subscriber's homes.



Perhaps we need to move to distributing IP versions of those same kinds of
technologies well in advance of a complete migration to VoIP.



Paul





From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Diane Golden
Sent: Friday, June 08, 2007 4:18 PM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.



On behalf of one of the state programs that distribute adaptive telephone
equipment, pure TTY's are a very tiny part of the distribution today. The
numbers have steadily decreased year after year as people move to other
equipment options. What we don't have is good data on how many people use
the TTY as their only telecom equipment rather than a secondary or
supplemental option. We do now distribute more VCO phones (including
regular VCO and CapTel) than TTYs and for pretty much all of these people
that is the only telecom option they have. So that group may actually be
our biggest legacy equipment problem.



Diane



Diane Cordry Golden, Ph.D., Director
Missouri Assistive Technology
816/350-5280 (direct voice)
= EMAIL ADDRESS REMOVED =
www.at.mo.gov



[SNIP]

From: Gregg Vanderheiden
Date: Tue, Jun 12 2007 11:20 PM
Subject: Re: RFC 4103 reference for real-time text.

Hi Paul,



Thanks.



Just so people aren't confused - let me state the current language in the
telecom proposal



The current language does no propose that all phones be made into text
phones.



Availability: What is proposed is

1) EITHER support real time text OR provide a way to connect a phone
that does support text in parallel. (This is basically the same as today
with TTY)

2) IF an IP PHONE *already* has a multi-line display - THEN display IP
text that you receive (this is software only)

3) IF an IP PHONE *already* has a keyboard or allows a keyboard
interface - THEN allow the phone to send IP text. (this is software only
again)



Reliability: That all telecom systems support some type of reliable IP text
format. (Standard within the system but different closed systems can use
different technologies)



Interoperability: That all systems and devices that connect to the public
phone system support the standard format for the system to ensure
interoperability.

- for PSTN that is TIA 825

- for IP SIP it would be RFC 4103 (though there is also a proposal
on the list so support BOTH RFC-4103 and RFC-4351)










Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.






_____


From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Paul E. Jones
Sent: Saturday, June 09, 2007 4:32 PM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.

Gregg,



I still do not think it is a good idea to require every phone to support
real-times text. Not every phone today supports text, while they certainly
could. Baudot is trivial, the it could be integrated into my wireless phone
very easily. But, that's not what I would want to use!



I think we need to "be careful what we ask for", otherwise what we might
have is a large number of inferior devices and then people asking, "what
more do you want?"" There might be a resistance to consider making other
options available.



Today, not every phone is accessible. But, what is accessible is the phone
network. A user can use his equipment (or provided equipment) and access
the PSTN to communicate with anybody in the world. They key is "network
access", not "phone access". If we wanted to mandate public phones have
integrated RFC 4103 capabilities, fine. Those are closed systems that might
offer no other interface. Or will they? It might be possible to use an
external text device that works wirelessly with the public phone as a
"natural extension" of the phone. (Never discount the possibility that
technology might evolve in the future into something quite different than
what we have today. I am working on just such a new kind of system.
Whether it sees the light of day is another matter, but we should at least
consider how technology is ever-changing and more sophisticated.)



What I would personally want to be able to use is a Pocket PC, Ultra Mobile
PC (UMPC) or other device with communication software installed. I would
like to have a means to access the network, such as via an Ethernet
connection or a wireless access point. (It's not too hard for me to imagine
that a business could establish a VLAN specifically for such purposes: I
have the equipment necessary to do that in my house, so it's not beyond
reach.)



So, I would encourage you to consider the network, not the phone, as the
focal point for accessibility. This will enable users to have a wider
variety of options, including portable PC devices, dedicated textphones,
PCs, or other devices.



Paul





From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Gregg
Vanderheiden
Sent: Friday, June 08, 2007 4:24 PM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.



TTY is critical on PSTN. It is the only thing that works there.



But it does not work well and is very limiting on IP. Like cellular
phones, (that also can't transport TTY tones natively without destroying
them, the strategy is to convert to a data format where there system
connects to the PSTN.



V.151 is a protocol designed to work between gateways. It is great there.







We need protocols between VoIP phones and between VoIP phones and gateways.




The best I can see is a hybrid approach.





1) Require that all VoIP phones, routers etc support both RFC-4103 and
and RFC-4351 - WHERE THEY CONNECT TO PUBLIC IP SIP SYSTEMS - OR CONNECT TO
OTHER SYSTEMS. (Internally within their own systems where they control
both ends and intermediate routers, they can use anything that meets the
reliability requirements ).

2) PSTN to IP Gateways would also support both but could give
preference to RFC-4351 (offer it first) so that they can save a port for
each call. (if everyone supports both as they should - then RFC-4351 would
work first time.

3) On non public systems (Skype, Vonnage, Corporations Internal
systems, etc) any text transport that meets the requirements is allowed as
long as it is translated into TTY at any PSTN interface and into RFC04103
and 4351 at any external IP SIP interface.





Would this hit the major issues?




Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.

From: Gregg Vanderheiden
Date: Wed, Jun 13 2007 7:05 AM
Subject: Re: RFC 4103 reference for real-time text.

Good edit. That was intent.




Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.






_____


From: Gunnar Hellström [mailto: = EMAIL ADDRESS REMOVED = ]
Sent: Wednesday, June 13, 2007 2:06 AM
To: Gregg Vanderheiden
Subject: RE: [teitac-telecom] RFC 4103 reference for real-time text.

I want to respond, or you to bring up:ge





--------------------------------------------------------------



This is essentially good.



It is in line with RFC 4504 SIP Telephony device requirements.



I would like to see another word for *already*, so that it also covers the
case when you design a new phone.

Proposal, either delete *already* or replace it with *is designed with*.
That would apply also to actions during the design process.



1) EITHER support real time text OR provide a way to connect a phone
that does support text in parallel. (This is basically the same as today
with TTY)

2) IF an IP PHONE *is designed with* a multi-line display ? THEN
display IP text that you receive (this is software only)

3) IF an IP PHONE *is designed with* a keyboard or allows a keyboard
interface - THEN allow the phone to send IP text. (this is software only
again)



Gunnar

-------------------------------------------------------------------

Gunnar Hellström

Omnitor

= EMAIL ADDRESS REMOVED =

Tel: +46708204288

www.omnitor.se <http://www.omnitor.se/>






_____


From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Gregg
Vanderheiden
Sent: Wednesday, June 13, 2007 7:17 AM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.



Hi Paul,



Thanks.



Just so people aren't confused ? let me state the current language in the
telecom proposal



The current language does no propose that all phones be made into text
phones.



Availability: What is proposed is

1) EITHER support real time text OR provide a way to connect a phone
that does support text in parallel. (This is basically the same as today
with TTY)

2) IF an IP PHONE *already* has a multi-line display ? THEN display IP
text that you receive (this is software only)

3) IF an IP PHONE *already* has a keyboard or allows a keyboard
interface - THEN allow the phone to send IP text. (this is software only
again)



Reliability: That all telecom systems support some type of reliable IP text
format. (Standard within the system but different closed systems can use
different technologies)



Interoperability: That all systems and devices that connect to the public
phone system support the standard format for the system to ensure
interoperability.

- for PSTN that is TIA 825

- for IP SIP it would be RFC 4103 (though there is also a proposal
on the list so support BOTH RFC-4103 and RFC-4351)










Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.






_____


From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Paul E. Jones
Sent: Saturday, June 09, 2007 4:32 PM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.

Gregg,



I still do not think it is a good idea to require every phone to support
real-times text. Not every phone today supports text, while they certainly
could. Baudot is trivial, the it could be integrated into my wireless phone
very easily. But, that?s not what I would want to use!



I think we need to ?be careful what we ask for?, otherwise what we might
have is a large number of inferior devices and then people asking, ?what
more do you want??? There might be a resistance to consider making other
options available.



Today, not every phone is accessible. But, what is accessible is the phone
network. A user can use his equipment (or provided equipment) and access
the PSTN to communicate with anybody in the world. They key is ?network
access?, not ?phone access?. If we wanted to mandate public phones have
integrated RFC 4103 capabilities, fine. Those are closed systems that might
offer no other interface. Or will they? It might be possible to use an
external text device that works wirelessly with the public phone as a
?natural extension? of the phone. (Never discount the possibility that
technology might evolve in the future into something quite different than
what we have today. I am working on just such a new kind of system.
Whether it sees the light of day is another matter, but we should at least
consider how technology is ever-changing and more sophisticated.)



What I would personally want to be able to use is a Pocket PC, Ultra Mobile
PC (UMPC) or other device with communication software installed. I would
like to have a means to access the network, such as via an Ethernet
connection or a wireless access point. (It?s not too hard for me to imagine
that a business could establish a VLAN specifically for such purposes: I
have the equipment necessary to do that in my house, so it?s not beyond
reach.)



So, I would encourage you to consider the network, not the phone, as the
focal point for accessibility. This will enable users to have a wider
variety of options, including portable PC devices, dedicated textphones,
PCs, or other devices.



Paul





From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Gregg
Vanderheiden
Sent: Friday, June 08, 2007 4:24 PM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.



TTY is critical on PSTN. It is the only thing that works there.



But it does not work well and is very limiting on IP. Like cellular
phones, (that also can't transport TTY tones natively without destroying
them, the strategy is to convert to a data format where there system
connects to the PSTN.



V.151 is a protocol designed to work between gateways. It is great there.







We need protocols between VoIP phones and between VoIP phones and gateways.




The best I can see is a hybrid approach.





1) Require that all VoIP phones, routers etc support both RFC-4103 and
and RFC-4351 - WHERE THEY CONNECT TO PUBLIC IP SIP SYSTEMS ? OR CONNECT TO
OTHER SYSTEMS. (Internally within their own systems where they control
both ends and intermediate routers, they can use anything that meets the
reliability requirements ).

2) PSTN to IP Gateways would also support both but could give
preference to RFC-4351 (offer it first) so that they can save a port for
each call. (if everyone supports both as they should ? then RFC-4351 would
work first time.

3) On non public systems (Skype, Vonnage, Corporations Internal
systems, etc) any text transport that meets the requirements is allowed as
long as it is translated into TTY at any PSTN interface and into RFC04103
and 4351 at any external IP SIP interface.





Would this hit the major issues?




Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.







__________ NOD32 2325 (20070612) Information __________

Detta meddelande dr genomsvkt av NOD32 Antivirus.
http://www.nod32.com

From: Paul E. Jones
Date: Sun, Jun 17 2007 9:20 PM
Subject: Re: RFC 4103 reference for real-time text.

Gregg,



What industry standards does CapTel use? As far as I know, there is no way
for us to support that in an IP world.



Paul





From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Gregg
Vanderheiden
Sent: Wednesday, June 13, 2007 1:13 AM
To: 'TEITAC Telecommunications Subcommittee'; = EMAIL ADDRESS REMOVED =
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.



Hmm



There is a bit of confusing discussion here. A few notes.





- VCO is a technique. It can be used with TTY or with other
technologies that do not support simultaneous text and speech. It is
commonly used with relays. It can also be used without using a relay.
The VCO capability on one cell phone for example can be used with an HCO
feature on another phone.

- CapTel uses industry standards for communicating in PSTN. It uses
them differently than in the past because no one offered CapTel in the past.
CapTel isn't TTY because TTY doesn't support simultaneous voice and text
which is of course required.

- IP captioned telephone can be done using RFC-4103. (It can also be
done with RFC-4351). It cannot be done with VBD or TTY tones on IP.





Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.






_____


From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Paul E. Jones
Sent: Sunday, June 10, 2007 6:49 PM
To: = EMAIL ADDRESS REMOVED = ; 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.

Diane,



OK, my understand of VCO was in line with yours. The way it was worded
("VCO phone"), I thought it was a phone like Captel that I just had not
heard about before.



Your venting is well-justified. Since I started working in this area
several years ago, I've co-authored several standards, been given several
conflicting requirements, been accused of doing an injustice to the deaf
community, and had countless debates that were far less than fruitful. All
the while, I am genuinely trying to find a solution that is acceptable to
everybody. I'm almost at a point of thinking there is no way.



One of the problems that I've observed (at least, this is my personal
opinion) is that people try to take the old technology and apply it to the
new technology. New technology opens the door for changes. IP, in general,
really opens the door for significant changes in the way deaf people can
communicate. What I hope is that we recognize the possibilities and do not
rush to forcing something into the market that limits those possibilities.



Initially, I would think (as was originally posited to me) that "bridging
the old with the new" was the first important step. We created the
standards to do that. We then need to ask, "what do we want next?" I have
an idea and I'm working on that. I do not personally view anything we have
today (in terms of standards) as the best and final step: I think we've only
scratched the surface and much more potential exists.



We need something for the moment, but we also need to ensure the door is
wide open for better technologies. It's definitely hard to codify that
desire into law.



Paul





From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Diane Golden
Sent: Sunday, June 10, 2007 4:54 PM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.



VCO is voice carry over and does use Baudot (unless there's something out
there I'm unaware of.) The person with the VCO phone uses their own voice
to send communication and received by reading text (almost always coming via
relay). Captel does use a different transmission but I believe has a
secondary Baudot capacity to allow users to call 911 directly by making a
"traditional VCO" call. When they switch to "traditional VCO" the CapTel
user no longer has simultaneous voice/text coming in (just text) and the
outgoing call to 911 just goes to the emergency center instead of
automatically connecting to the CapTel relay center.



Not only do we have transmission/code issues with these systems, we also
have a situation in which a proprietary product is the only avenue to obtain
a more effective relay service unless the consumer can go to IP. Right now
consumers who need VCO can use "traditional VCO" with a number of products
on the market but it uses regular relay services which do not provide nearly
the speed of conversion of speech to text as does the CapTel relay service.
So if you want the faster relay, you have to use the CapTel phone which
provides simultaneous voice/text which many consumers can't use (don't have
the residual hearing) and for some it actually disrupts their ability to
communicate effectively (especially elderly). I'm not sure what the answer
is -- but for those of us who work with consumers every day, it is really
frustrating to have to purchase one proprietary phone that has
uneeded/unwanted features just to be able to access a more
efficient/effective relay service. Sorry, my venting for the day.



Diane



Diane Cordry Golden, Ph.D., Director
Missouri Assistive Technology
816/350-5280 (direct voice)
= EMAIL ADDRESS REMOVED =
www.at.mo.gov



-----Original Message-----
From: Paul E. Jones [mailto: = EMAIL ADDRESS REMOVED = ]
Sent: Saturday, June 09, 2007 4:18 PM
To: = EMAIL ADDRESS REMOVED = ; 'TEITAC Telecommunications Subcommittee'
Subject: RE: [teitac-telecom] RFC 4103 reference for real-time text.

Diane,



What is a "VCO phone"? Is this one that still uses Baudot for character
transmission?



Captel, as I understand, does not use Baudot. As such, it will introduce
significantly more hurdles moving forward. Over the past few years as we've
been working on new standards to move from a legacy TTY world to an IP
world, several of us in the industry have invited Ultratec to participate
and to share information so that we can integrate the technology into
standards, but they've repeatedly declined. So, I really worry about how we
could ever possibly support Captel. The only choice might be to use G.711,
but then the government could not require VoIP service providers like Vonage
or services from AT&T like CallVantage to support it, because there is no
way for either of those carriers to guarantee (or even remotely attempt) to
guarantee the low packet loss rates necessary for those services to work
since they do not own the access lines going into subscriber's homes.



Perhaps we need to move to distributing IP versions of those same kinds of
technologies well in advance of a complete migration to VoIP.



Paul





From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Diane Golden
Sent: Friday, June 08, 2007 4:18 PM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.



On behalf of one of the state programs that distribute adaptive telephone
equipment, pure TTY's are a very tiny part of the distribution today. The
numbers have steadily decreased year after year as people move to other
equipment options. What we don't have is good data on how many people use
the TTY as their only telecom equipment rather than a secondary or
supplemental option. We do now distribute more VCO phones (including
regular VCO and CapTel) than TTYs and for pretty much all of these people
that is the only telecom option they have. So that group may actually be
our biggest legacy equipment problem.



Diane



Diane Cordry Golden, Ph.D., Director
Missouri Assistive Technology
816/350-5280 (direct voice)
= EMAIL ADDRESS REMOVED =
www.at.mo.gov



[SNIP]

From: Gregg Vanderheiden
Date: Sun, Jun 17 2007 11:30 PM
Subject: Re: RFC 4103 reference for real-time text.

Oh, you said "we can't support that in IP world" so that confused me.



Dual line CapTel uses two standard lines. For single line I know they use
a modem standard but will have to look up which.

But that is all irrelevant for IP. They aren't using the PSTN standards for
IP. They are using IP standards.




Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.






_____


From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Paul E. Jones
Sent: Monday, June 18, 2007 12:11 AM
To: 'TEITAC Telecommunications Subcommittee'; = EMAIL ADDRESS REMOVED =
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.

Gregg,



You mentioned that CapTel used industry standards on the PSTN: that is what
I was asking about.



Paul





From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Gregg
Vanderheiden
Sent: Monday, June 18, 2007 1:09 AM
To: 'TEITAC Telecommunications Subcommittee'; = EMAIL ADDRESS REMOVED =
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.



I am not going to pre-announce the formats that Ultratec will be supporting
on IP but IP CapTel is now authorized and they are implementing it now.



It is easy to support captioned telephony in IP. Much easier than in PSTN.





Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.






_____


From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Paul E. Jones
Sent: Sunday, June 17, 2007 10:15 PM
To: 'TEITAC Telecommunications Subcommittee'; = EMAIL ADDRESS REMOVED =
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.

Gregg,



What industry standards does CapTel use? As far as I know, there is no way
for us to support that in an IP world.



Paul





From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Gregg
Vanderheiden
Sent: Wednesday, June 13, 2007 1:13 AM
To: 'TEITAC Telecommunications Subcommittee'; = EMAIL ADDRESS REMOVED =
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.



Hmm



There is a bit of confusing discussion here. A few notes.





- VCO is a technique. It can be used with TTY or with other technologies
that do not support simultaneous text and speech. It is commonly used with
relays. It can also be used without using a relay. The VCO capability on
one cell phone for example can be used with an HCO feature on another phone.


- CapTel uses industry standards for communicating in PSTN. It uses them
differently than in the past because no one offered CapTel in the past.
CapTel isn't TTY because TTY doesn't support simultaneous voice and text
which is of course required.

- IP captioned telephone can be done using RFC-4103. (It can also be done
with RFC-4351). It cannot be done with VBD or TTY tones on IP.





Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.






_____


From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Paul E. Jones
Sent: Sunday, June 10, 2007 6:49 PM
To: = EMAIL ADDRESS REMOVED = ; 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.

Diane,



OK, my understand of VCO was in line with yours. The way it was worded
("VCO phone"), I thought it was a phone like Captel that I just had not
heard about before.



Your venting is well-justified. Since I started working in this area
several years ago, I've co-authored several standards, been given several
conflicting requirements, been accused of doing an injustice to the deaf
community, and had countless debates that were far less than fruitful. All
the while, I am genuinely trying to find a solution that is acceptable to
everybody. I'm almost at a point of thinking there is no way.



One of the problems that I've observed (at least, this is my personal
opinion) is that people try to take the old technology and apply it to the
new technology. New technology opens the door for changes. IP, in general,
really opens the door for significant changes in the way deaf people can
communicate. What I hope is that we recognize the possibilities and do not
rush to forcing something into the market that limits those possibilities.



Initially, I would think (as was originally posited to me) that "bridging
the old with the new" was the first important step. We created the
standards to do that. We then need to ask, "what do we want next?" I have
an idea and I'm working on that. I do not personally view anything we have
today (in terms of standards) as the best and final step: I think we've only
scratched the surface and much more potential exists.



We need something for the moment, but we also need to ensure the door is
wide open for better technologies. It's definitely hard to codify that
desire into law.



Paul





From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Diane Golden
Sent: Sunday, June 10, 2007 4:54 PM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.



VCO is voice carry over and does use Baudot (unless there's something out
there I'm unaware of.) The person with the VCO phone uses their own voice
to send communication and received by reading text (almost always coming via
relay). Captel does use a different transmission but I believe has a
secondary Baudot capacity to allow users to call 911 directly by making a
"traditional VCO" call. When they switch to "traditional VCO" the CapTel
user no longer has simultaneous voice/text coming in (just text) and the
outgoing call to 911 just goes to the emergency center instead of
automatically connecting to the CapTel relay center.



Not only do we have transmission/code issues with these systems, we also
have a situation in which a proprietary product is the only avenue to obtain
a more effective relay service unless the consumer can go to IP. Right now
consumers who need VCO can use "traditional VCO" with a number of products
on the market but it uses regular relay services which do not provide nearly
the speed of conversion of speech to text as does the CapTel relay service.
So if you want the faster relay, you have to use the CapTel phone which
provides simultaneous voice/text which many consumers can't use (don't have
the residual hearing) and for some it actually disrupts their ability to
communicate effectively (especially elderly). I'm not sure what the answer
is -- but for those of us who work with consumers every day, it is really
frustrating to have to purchase one proprietary phone that has
uneeded/unwanted features just to be able to access a more
efficient/effective relay service. Sorry, my venting for the day.



Diane



Diane Cordry Golden, Ph.D., Director
Missouri Assistive Technology
816/350-5280 (direct voice)
= EMAIL ADDRESS REMOVED =
www.at.mo.gov



-----Original Message-----
From: Paul E. Jones [mailto: = EMAIL ADDRESS REMOVED = ]
Sent: Saturday, June 09, 2007 4:18 PM
To: = EMAIL ADDRESS REMOVED = ; 'TEITAC Telecommunications Subcommittee'
Subject: RE: [teitac-telecom] RFC 4103 reference for real-time text.

Diane,



What is a "VCO phone"? Is this one that still uses Baudot for character
transmission?



Captel, as I understand, does not use Baudot. As such, it will introduce
significantly more hurdles moving forward. Over the past few years as we've
been working on new standards to move from a legacy TTY world to an IP
world, several of us in the industry have invited Ultratec to participate
and to share information so that we can integrate the technology into
standards, but they've repeatedly declined. So, I really worry about how we
could ever possibly support Captel. The only choice might be to use G.711,
but then the government could not require VoIP service providers like Vonage
or services from AT&T like CallVantage to support it, because there is no
way for either of those carriers to guarantee (or even remotely attempt) to
guarantee the low packet loss rates necessary for those services to work
since they do not own the access lines going into subscriber's homes.



Perhaps we need to move to distributing IP versions of those same kinds of
technologies well in advance of a complete migration to VoIP.



Paul





From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Diane Golden
Sent: Friday, June 08, 2007 4:18 PM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.



On behalf of one of the state programs that distribute adaptive telephone
equipment, pure TTY's are a very tiny part of the distribution today. The
numbers have steadily decreased year after year as people move to other
equipment options. What we don't have is good data on how many people use
the TTY as their only telecom equipment rather than a secondary or
supplemental option. We do now distribute more VCO phones (including
regular VCO and CapTel) than TTYs and for pretty much all of these people
that is the only telecom option they have. So that group may actually be
our biggest legacy equipment problem.



Diane



Diane Cordry Golden, Ph.D., Director
Missouri Assistive Technology
816/350-5280 (direct voice)
= EMAIL ADDRESS REMOVED =
www.at.mo.gov



[SNIP]

From: Paul E. Jones
Date: Mon, Jun 18 2007 2:25 AM
Subject: Re: RFC 4103 reference for real-time text.

Gregg,



But, there's nothing in the proposed law that would encourage or require
such a network enablement. The only provisions that I see are ones that
require some change to a phone. In any case, I will not push it since I
know that there is a lot of work required to enable devices that just
"appear" on the network.



Still, I feel like something is missing. An enterprise could text-enable
those phones with multi-line displays, do nothing else, and claim
compliance. How would end users feel about that? It would be a worse
interface than what users have today with TTY devices. TTY devices at least
have a keyboard, but the proposed law will not require that a keyboard be
provided for any deaf user, will it?



Paul





From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Gregg
Vanderheiden
Sent: Monday, June 18, 2007 1:04 AM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.



Either would seem to be sufficient to meet this. as long as 'hooking up to
the network' would give the same privileges as using the phone.




Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.






_____


From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Paul E. Jones
Sent: Sunday, June 17, 2007 10:30 PM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.

Gregg,



What do you mean by "provide a way to connect a phone that does support text
in parallel"? Does this allow me to bring an IP text device into an office
and be able to use it for communication, or am I going to be forced to
interface my text device with a voice phone? I am not opposed if people
want to interconnect a text device with a phone, but I don't want to be
forced to do that when I have a perfectly good working portable device that
has text and voice capability, my address book, and settings that are
suitable for me. So, what's missing is the ability for me to interface in
some way to the network. Do we want to enable IP text devices to interact
with the system without a voice telephone?



Paul





From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Gregg
Vanderheiden
Sent: Wednesday, June 13, 2007 1:17 AM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.





Hi Paul,



Thanks.



Just so people aren't confused - let me state the current language in the
telecom proposal



The current language does no propose that all phones be made into text
phones.



Availability: What is proposed is

1) EITHER support real time text OR provide a way to connect a phone
that does support text in parallel. (This is basically the same as today
with TTY)

2) IF an IP PHONE *already* has a multi-line display - THEN display IP
text that you receive (this is software only)

3) IF an IP PHONE *already* has a keyboard or allows a keyboard
interface - THEN allow the phone to send IP text. (this is software only
again)



Reliability: That all telecom systems support some type of reliable IP text
format. (Standard within the system but different closed systems can use
different technologies)



Interoperability: That all systems and devices that connect to the public
phone system support the standard format for the system to ensure
interoperability.

- for PSTN that is TIA 825

- for IP SIP it would be RFC 4103 (though there is also a proposal
on the list so support BOTH RFC-4103 and RFC-4351)










Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.






_____


From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Paul E. Jones
Sent: Saturday, June 09, 2007 4:32 PM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.

Gregg,



I still do not think it is a good idea to require every phone to support
real-times text. Not every phone today supports text, while they certainly
could. Baudot is trivial, the it could be integrated into my wireless phone
very easily. But, that's not what I would want to use!



I think we need to "be careful what we ask for", otherwise what we might
have is a large number of inferior devices and then people asking, "what
more do you want?"" There might be a resistance to consider making other
options available.



Today, not every phone is accessible. But, what is accessible is the phone
network. A user can use his equipment (or provided equipment) and access
the PSTN to communicate with anybody in the world. They key is "network
access", not "phone access". If we wanted to mandate public phones have
integrated RFC 4103 capabilities, fine. Those are closed systems that might
offer no other interface. Or will they? It might be possible to use an
external text device that works wirelessly with the public phone as a
"natural extension" of the phone. (Never discount the possibility that
technology might evolve in the future into something quite different than
what we have today. I am working on just such a new kind of system.
Whether it sees the light of day is another matter, but we should at least
consider how technology is ever-changing and more sophisticated.)



What I would personally want to be able to use is a Pocket PC, Ultra Mobile
PC (UMPC) or other device with communication software installed. I would
like to have a means to access the network, such as via an Ethernet
connection or a wireless access point. (It's not too hard for me to imagine
that a business could establish a VLAN specifically for such purposes: I
have the equipment necessary to do that in my house, so it's not beyond
reach.)



So, I would encourage you to consider the network, not the phone, as the
focal point for accessibility. This will enable users to have a wider
variety of options, including portable PC devices, dedicated textphones,
PCs, or other devices.



Paul





From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Gregg
Vanderheiden
Sent: Friday, June 08, 2007 4:24 PM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.



TTY is critical on PSTN. It is the only thing that works there.



But it does not work well and is very limiting on IP. Like cellular
phones, (that also can't transport TTY tones natively without destroying
them, the strategy is to convert to a data format where there system
connects to the PSTN.



V.151 is a protocol designed to work between gateways. It is great there.







We need protocols between VoIP phones and between VoIP phones and gateways.




The best I can see is a hybrid approach.





1) Require that all VoIP phones, routers etc support both RFC-4103 and
and RFC-4351 - WHERE THEY CONNECT TO PUBLIC IP SIP SYSTEMS - OR CONNECT TO
OTHER SYSTEMS. (Internally within their own systems where they control
both ends and intermediate routers, they can use anything that meets the
reliability requirements ).

2) PSTN to IP Gateways would also support both but could give
preference to RFC-4351 (offer it first) so that they can save a port for
each call. (if everyone supports both as they should - then RFC-4351 would
work first time.

3) On non public systems (Skype, Vonnage, Corporations Internal
systems, etc) any text transport that meets the requirements is allowed as
long as it is translated into TTY at any PSTN interface and into RFC04103
and 4351 at any external IP SIP interface.





Would this hit the major issues?




Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.

From: Paul E. Jones
Date: Mon, Jun 18 2007 2:40 AM
Subject: Re: RFC 4103 reference for real-time text.

Gregg,



So, CapTel on the PSTN today still presents a problem converting from PSTN
to IP, since the text is on the PSTN as who-knows-what and uses a separate
phone line for voice. I would not be able to use such a system with my VoIP
service provider and I assume we could not require them to support it,
either. (One cannot engineer a network to proprietary technology.)



In the IP world, there is no need for a special "CapTel" phone, per se,
since any text-enabled IP phone (hardware or software) would be able to
provide the same capabilities (e.g., G.711 for audio and RFC 4103 for text).
So, why call this "IP CapTel"? The objective of these legal changes is to
make an effort to make this kind of technology ubiquitous and open, right?
In any case, Ultratec certainly has the right to use that name, but I would
hope we do not devise another network with proprietary elements that do not
benefit the public at large.



Paul





From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Gregg
Vanderheiden
Sent: Monday, June 18, 2007 1:25 AM
To: 'TEITAC Telecommunications Subcommittee'; = EMAIL ADDRESS REMOVED =
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.



Oh, you said "we can't support that in IP world" so that confused me.



Dual line CapTel uses two standard lines. For single line I know they use
a modem standard but will have to look up which.

But that is all irrelevant for IP. They aren't using the PSTN standards for
IP. They are using IP standards.




Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.






_____


From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Paul E. Jones
Sent: Monday, June 18, 2007 12:11 AM
To: 'TEITAC Telecommunications Subcommittee'; = EMAIL ADDRESS REMOVED =
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.

Gregg,



You mentioned that CapTel used industry standards on the PSTN: that is what
I was asking about.



Paul





From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Gregg
Vanderheiden
Sent: Monday, June 18, 2007 1:09 AM
To: 'TEITAC Telecommunications Subcommittee'; = EMAIL ADDRESS REMOVED =
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.



I am not going to pre-announce the formats that Ultratec will be supporting
on IP but IP CapTel is now authorized and they are implementing it now.



It is easy to support captioned telephony in IP. Much easier than in PSTN.





Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.






_____


From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Paul E. Jones
Sent: Sunday, June 17, 2007 10:15 PM
To: 'TEITAC Telecommunications Subcommittee'; = EMAIL ADDRESS REMOVED =
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.

Gregg,



What industry standards does CapTel use? As far as I know, there is no way
for us to support that in an IP world.



Paul





From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Gregg
Vanderheiden
Sent: Wednesday, June 13, 2007 1:13 AM
To: 'TEITAC Telecommunications Subcommittee'; = EMAIL ADDRESS REMOVED =
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.



Hmm



There is a bit of confusing discussion here. A few notes.





- VCO is a technique. It can be used with TTY or with other
technologies that do not support simultaneous text and speech. It is
commonly used with relays. It can also be used without using a relay.
The VCO capability on one cell phone for example can be used with an HCO
feature on another phone.

- CapTel uses industry standards for communicating in PSTN. It uses
them differently than in the past because no one offered CapTel in the past.
CapTel isn't TTY because TTY doesn't support simultaneous voice and text
which is of course required.

- IP captioned telephone can be done using RFC-4103. (It can also
be done with RFC-4351). It cannot be done with VBD or TTY tones on IP.





Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.






_____


From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Paul E. Jones
Sent: Sunday, June 10, 2007 6:49 PM
To: = EMAIL ADDRESS REMOVED = ; 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.

Diane,



OK, my understand of VCO was in line with yours. The way it was worded
("VCO phone"), I thought it was a phone like Captel that I just had not
heard about before.



Your venting is well-justified. Since I started working in this area
several years ago, I've co-authored several standards, been given several
conflicting requirements, been accused of doing an injustice to the deaf
community, and had countless debates that were far less than fruitful. All
the while, I am genuinely trying to find a solution that is acceptable to
everybody. I'm almost at a point of thinking there is no way.



One of the problems that I've observed (at least, this is my personal
opinion) is that people try to take the old technology and apply it to the
new technology. New technology opens the door for changes. IP, in general,
really opens the door for significant changes in the way deaf people can
communicate. What I hope is that we recognize the possibilities and do not
rush to forcing something into the market that limits those possibilities.



Initially, I would think (as was originally posited to me) that "bridging
the old with the new" was the first important step. We created the
standards to do that. We then need to ask, "what do we want next?" I have
an idea and I'm working on that. I do not personally view anything we have
today (in terms of standards) as the best and final step: I think we've only
scratched the surface and much more potential exists.



We need something for the moment, but we also need to ensure the door is
wide open for better technologies. It's definitely hard to codify that
desire into law.



Paul





From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Diane Golden
Sent: Sunday, June 10, 2007 4:54 PM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.



VCO is voice carry over and does use Baudot (unless there's something out
there I'm unaware of.) The person with the VCO phone uses their own voice
to send communication and received by reading text (almost always coming via
relay). Captel does use a different transmission but I believe has a
secondary Baudot capacity to allow users to call 911 directly by making a
"traditional VCO" call. When they switch to "traditional VCO" the CapTel
user no longer has simultaneous voice/text coming in (just text) and the
outgoing call to 911 just goes to the emergency center instead of
automatically connecting to the CapTel relay center.



Not only do we have transmission/code issues with these systems, we also
have a situation in which a proprietary product is the only avenue to obtain
a more effective relay service unless the consumer can go to IP. Right now
consumers who need VCO can use "traditional VCO" with a number of products
on the market but it uses regular relay services which do not provide nearly
the speed of conversion of speech to text as does the CapTel relay service.
So if you want the faster relay, you have to use the CapTel phone which
provides simultaneous voice/text which many consumers can't use (don't have
the residual hearing) and for some it actually disrupts their ability to
communicate effectively (especially elderly). I'm not sure what the answer
is -- but for those of us who work with consumers every day, it is really
frustrating to have to purchase one proprietary phone that has
uneeded/unwanted features just to be able to access a more
efficient/effective relay service. Sorry, my venting for the day.



Diane



Diane Cordry Golden, Ph.D., Director
Missouri Assistive Technology
816/350-5280 (direct voice)
= EMAIL ADDRESS REMOVED =
www.at.mo.gov



-----Original Message-----
From: Paul E. Jones [mailto: = EMAIL ADDRESS REMOVED = ]
Sent: Saturday, June 09, 2007 4:18 PM
To: = EMAIL ADDRESS REMOVED = ; 'TEITAC Telecommunications Subcommittee'
Subject: RE: [teitac-telecom] RFC 4103 reference for real-time text.

Diane,



What is a "VCO phone"? Is this one that still uses Baudot for character
transmission?



Captel, as I understand, does not use Baudot. As such, it will introduce
significantly more hurdles moving forward. Over the past few years as we've
been working on new standards to move from a legacy TTY world to an IP
world, several of us in the industry have invited Ultratec to participate
and to share information so that we can integrate the technology into
standards, but they've repeatedly declined. So, I really worry about how we
could ever possibly support Captel. The only choice might be to use G.711,
but then the government could not require VoIP service providers like Vonage
or services from AT&T like CallVantage to support it, because there is no
way for either of those carriers to guarantee (or even remotely attempt) to
guarantee the low packet loss rates necessary for those services to work
since they do not own the access lines going into subscriber's homes.



Perhaps we need to move to distributing IP versions of those same kinds of
technologies well in advance of a complete migration to VoIP.



Paul





From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Diane Golden
Sent: Friday, June 08, 2007 4:18 PM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.



On behalf of one of the state programs that distribute adaptive telephone
equipment, pure TTY's are a very tiny part of the distribution today. The
numbers have steadily decreased year after year as people move to other
equipment options. What we don't have is good data on how many people use
the TTY as their only telecom equipment rather than a secondary or
supplemental option. We do now distribute more VCO phones (including
regular VCO and CapTel) than TTYs and for pretty much all of these people
that is the only telecom option they have. So that group may actually be
our biggest legacy equipment problem.



Diane



Diane Cordry Golden, Ph.D., Director
Missouri Assistive Technology
816/350-5280 (direct voice)
= EMAIL ADDRESS REMOVED =
www.at.mo.gov



[SNIP]

From: Paul E. Jones
Date: Mon, Jun 18 2007 1:51 PM
Subject: Re: RFC 4103 reference for real-time text.

Gregg,



What do you mean by "provide a way to connect a phone that does support text
in parallel"? Does this allow me to bring an IP text device into an office
and be able to use it for communication, or am I going to be forced to
interface my text device with a voice phone? I am not opposed if people
want to interconnect a text device with a phone, but I don't want to be
forced to do that when I have a perfectly good working portable device that
has text and voice capability, my address book, and settings that are
suitable for me. So, what's missing is the ability for me to interface in
some way to the network. Do we want to enable IP text devices to interact
with the system without a voice telephone?



Paul





From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Gregg
Vanderheiden
Sent: Wednesday, June 13, 2007 1:17 AM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.





Hi Paul,



Thanks.



Just so people aren't confused - let me state the current language in the
telecom proposal



The current language does no propose that all phones be made into text
phones.



Availability: What is proposed is

1) EITHER support real time text OR provide a way to connect a phone
that does support text in parallel. (This is basically the same as today
with TTY)

2) IF an IP PHONE *already* has a multi-line display - THEN display IP text
that you receive (this is software only)

3) IF an IP PHONE *already* has a keyboard or allows a keyboard interface
- THEN allow the phone to send IP text. (this is software only again)



Reliability: That all telecom systems support some type of reliable IP text
format. (Standard within the system but different closed systems can use
different technologies)



Interoperability: That all systems and devices that connect to the public
phone system support the standard format for the system to ensure
interoperability.

- for PSTN that is TIA 825

- for IP SIP it would be RFC 4103 (though there is also a proposal on
the list so support BOTH RFC-4103 and RFC-4351)










Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.






_____


From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Paul E. Jones
Sent: Saturday, June 09, 2007 4:32 PM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.

Gregg,



I still do not think it is a good idea to require every phone to support
real-times text. Not every phone today supports text, while they certainly
could. Baudot is trivial, the it could be integrated into my wireless phone
very easily. But, that's not what I would want to use!



I think we need to "be careful what we ask for", otherwise what we might
have is a large number of inferior devices and then people asking, "what
more do you want?"" There might be a resistance to consider making other
options available.



Today, not every phone is accessible. But, what is accessible is the phone
network. A user can use his equipment (or provided equipment) and access
the PSTN to communicate with anybody in the world. They key is "network
access", not "phone access". If we wanted to mandate public phones have
integrated RFC 4103 capabilities, fine. Those are closed systems that might
offer no other interface. Or will they? It might be possible to use an
external text device that works wirelessly with the public phone as a
"natural extension" of the phone. (Never discount the possibility that
technology might evolve in the future into something quite different than
what we have today. I am working on just such a new kind of system.
Whether it sees the light of day is another matter, but we should at least
consider how technology is ever-changing and more sophisticated.)



What I would personally want to be able to use is a Pocket PC, Ultra Mobile
PC (UMPC) or other device with communication software installed. I would
like to have a means to access the network, such as via an Ethernet
connection or a wireless access point. (It's not too hard for me to imagine
that a business could establish a VLAN specifically for such purposes: I
have the equipment necessary to do that in my house, so it's not beyond
reach.)



So, I would encourage you to consider the network, not the phone, as the
focal point for accessibility. This will enable users to have a wider
variety of options, including portable PC devices, dedicated textphones,
PCs, or other devices.



Paul





From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Gregg
Vanderheiden
Sent: Friday, June 08, 2007 4:24 PM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.



TTY is critical on PSTN. It is the only thing that works there.



But it does not work well and is very limiting on IP. Like cellular
phones, (that also can't transport TTY tones natively without destroying
them, the strategy is to convert to a data format where there system
connects to the PSTN.



V.151 is a protocol designed to work between gateways. It is great there.







We need protocols between VoIP phones and between VoIP phones and gateways.




The best I can see is a hybrid approach.





1) Require that all VoIP phones, routers etc support both RFC-4103 and
and RFC-4351 - WHERE THEY CONNECT TO PUBLIC IP SIP SYSTEMS - OR CONNECT TO
OTHER SYSTEMS. (Internally within their own systems where they control
both ends and intermediate routers, they can use anything that meets the
reliability requirements ).

2) PSTN to IP Gateways would also support both but could give
preference to RFC-4351 (offer it first) so that they can save a port for
each call. (if everyone supports both as they should - then RFC-4351 would
work first time.

3) On non public systems (Skype, Vonnage, Corporations Internal
systems, etc) any text transport that meets the requirements is allowed as
long as it is translated into TTY at any PSTN interface and into RFC04103
and 4351 at any external IP SIP interface.





Would this hit the major issues?




Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.

From: Gregg Vanderheiden
Date: Mon, Jun 18 2007 1:51 PM
Subject: Re: RFC 4103 reference for real-time text.

Either would seem to be sufficient to meet this. as long as 'hooking up to
the network' would give the same privileges as using the phone.




Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.






_____


From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Paul E. Jones
Sent: Sunday, June 17, 2007 10:30 PM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.

Gregg,



What do you mean by "provide a way to connect a phone that does support text
in parallel"? Does this allow me to bring an IP text device into an office
and be able to use it for communication, or am I going to be forced to
interface my text device with a voice phone? I am not opposed if people
want to interconnect a text device with a phone, but I don't want to be
forced to do that when I have a perfectly good working portable device that
has text and voice capability, my address book, and settings that are
suitable for me. So, what's missing is the ability for me to interface in
some way to the network. Do we want to enable IP text devices to interact
with the system without a voice telephone?



Paul





From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Gregg
Vanderheiden
Sent: Wednesday, June 13, 2007 1:17 AM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.





Hi Paul,



Thanks.



Just so people aren't confused - let me state the current language in the
telecom proposal



The current language does no propose that all phones be made into text
phones.



Availability: What is proposed is

1) EITHER support real time text OR provide a way to connect a phone
that does support text in parallel. (This is basically the same as today
with TTY)

2) IF an IP PHONE *already* has a multi-line display - THEN display IP
text that you receive (this is software only)

3) IF an IP PHONE *already* has a keyboard or allows a keyboard
interface - THEN allow the phone to send IP text. (this is software only
again)



Reliability: That all telecom systems support some type of reliable IP text
format. (Standard within the system but different closed systems can use
different technologies)



Interoperability: That all systems and devices that connect to the public
phone system support the standard format for the system to ensure
interoperability.

-for PSTN that is TIA 825

-for IP SIP it would be RFC 4103 (though there is also a proposal on the
list so support BOTH RFC-4103 and RFC-4351)










Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.






_____


From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Paul E. Jones
Sent: Saturday, June 09, 2007 4:32 PM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.

Gregg,



I still do not think it is a good idea to require every phone to support
real-times text. Not every phone today supports text, while they certainly
could. Baudot is trivial, the it could be integrated into my wireless phone
very easily. But, that's not what I would want to use!



I think we need to "be careful what we ask for", otherwise what we might
have is a large number of inferior devices and then people asking, "what
more do you want?"" There might be a resistance to consider making other
options available.



Today, not every phone is accessible. But, what is accessible is the phone
network. A user can use his equipment (or provided equipment) and access
the PSTN to communicate with anybody in the world. They key is "network
access", not "phone access". If we wanted to mandate public phones have
integrated RFC 4103 capabilities, fine. Those are closed systems that might
offer no other interface. Or will they? It might be possible to use an
external text device that works wirelessly with the public phone as a
"natural extension" of the phone. (Never discount the possibility that
technology might evolve in the future into something quite different than
what we have today. I am working on just such a new kind of system.
Whether it sees the light of day is another matter, but we should at least
consider how technology is ever-changing and more sophisticated.)



What I would personally want to be able to use is a Pocket PC, Ultra Mobile
PC (UMPC) or other device with communication software installed. I would
like to have a means to access the network, such as via an Ethernet
connection or a wireless access point. (It's not too hard for me to imagine
that a business could establish a VLAN specifically for such purposes: I
have the equipment necessary to do that in my house, so it's not beyond
reach.)



So, I would encourage you to consider the network, not the phone, as the
focal point for accessibility. This will enable users to have a wider
variety of options, including portable PC devices, dedicated textphones,
PCs, or other devices.



Paul





From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Gregg
Vanderheiden
Sent: Friday, June 08, 2007 4:24 PM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.



TTY is critical on PSTN. It is the only thing that works there.



But it does not work well and is very limiting on IP. Like cellular
phones, (that also can't transport TTY tones natively without destroying
them, the strategy is to convert to a data format where there system
connects to the PSTN.



V.151 is a protocol designed to work between gateways. It is great there.







We need protocols between VoIP phones and between VoIP phones and gateways.




The best I can see is a hybrid approach.





1) Require that all VoIP phones, routers etc support both RFC-4103 and
and RFC-4351 - WHERE THEY CONNECT TO PUBLIC IP SIP SYSTEMS - OR CONNECT TO
OTHER SYSTEMS. (Internally within their own systems where they control
both ends and intermediate routers, they can use anything that meets the
reliability requirements ).

2) PSTN to IP Gateways would also support both but could give
preference to RFC-4351 (offer it first) so that they can save a port for
each call. (if everyone supports both as they should - then RFC-4351 would
work first time.

3) On non public systems (Skype, Vonnage, Corporations Internal
systems, etc) any text transport that meets the requirements is allowed as
long as it is translated into TTY at any PSTN interface and into RFC04103
and 4351 at any external IP SIP interface.





Would this hit the major issues?




Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.

From: Gregg Vanderheiden
Date: Mon, Jun 18 2007 1:51 PM
Subject: Re: RFC 4103 reference for real-time text.

I am not going to pre-announce the formats that Ultratec will be supporting
on IP but IP CapTel is now authorized and they are implementing it now.



It is easy to support captioned telephony in IP. Much easier than in PSTN.





Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.






_____


From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Paul E. Jones
Sent: Sunday, June 17, 2007 10:15 PM
To: 'TEITAC Telecommunications Subcommittee'; = EMAIL ADDRESS REMOVED =
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.

Gregg,



What industry standards does CapTel use? As far as I know, there is no way
for us to support that in an IP world.



Paul





From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Gregg
Vanderheiden
Sent: Wednesday, June 13, 2007 1:13 AM
To: 'TEITAC Telecommunications Subcommittee'; = EMAIL ADDRESS REMOVED =
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.



Hmm



There is a bit of confusing discussion here. A few notes.





-VCO is a technique. It can be used with TTY or with other technologies that
do not support simultaneous text and speech. It is commonly used with
relays. It can also be used without using a relay. The VCO capability on
one cell phone for example can be used with an HCO feature on another phone.


-CapTel uses industry standards for communicating in PSTN. It uses them
differently than in the past because no one offered CapTel in the past.
CapTel isn't TTY because TTY doesn't support simultaneous voice and text
which is of course required.

-IP captioned telephone can be done using RFC-4103. (It can also be done
with RFC-4351). It cannot be done with VBD or TTY tones on IP.





Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.






_____


From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Paul E. Jones
Sent: Sunday, June 10, 2007 6:49 PM
To: = EMAIL ADDRESS REMOVED = ; 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.

Diane,



OK, my understand of VCO was in line with yours. The way it was worded
("VCO phone"), I thought it was a phone like Captel that I just had not
heard about before.



Your venting is well-justified. Since I started working in this area
several years ago, I've co-authored several standards, been given several
conflicting requirements, been accused of doing an injustice to the deaf
community, and had countless debates that were far less than fruitful. All
the while, I am genuinely trying to find a solution that is acceptable to
everybody. I'm almost at a point of thinking there is no way.



One of the problems that I've observed (at least, this is my personal
opinion) is that people try to take the old technology and apply it to the
new technology. New technology opens the door for changes. IP, in general,
really opens the door for significant changes in the way deaf people can
communicate. What I hope is that we recognize the possibilities and do not
rush to forcing something into the market that limits those possibilities.



Initially, I would think (as was originally posited to me) that "bridging
the old with the new" was the first important step. We created the
standards to do that. We then need to ask, "what do we want next?" I have
an idea and I'm working on that. I do not personally view anything we have
today (in terms of standards) as the best and final step: I think we've only
scratched the surface and much more potential exists.



We need something for the moment, but we also need to ensure the door is
wide open for better technologies. It's definitely hard to codify that
desire into law.



Paul





From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Diane Golden
Sent: Sunday, June 10, 2007 4:54 PM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.



VCO is voice carry over and does use Baudot (unless there's something out
there I'm unaware of.) The person with the VCO phone uses their own voice
to send communication and received by reading text (almost always coming via
relay). Captel does use a different transmission but I believe has a
secondary Baudot capacity to allow users to call 911 directly by making a
"traditional VCO" call. When they switch to "traditional VCO" the CapTel
user no longer has simultaneous voice/text coming in (just text) and the
outgoing call to 911 just goes to the emergency center instead of
automatically connecting to the CapTel relay center.



Not only do we have transmission/code issues with these systems, we also
have a situation in which a proprietary product is the only avenue to obtain
a more effective relay service unless the consumer can go to IP. Right now
consumers who need VCO can use "traditional VCO" with a number of products
on the market but it uses regular relay services which do not provide nearly
the speed of conversion of speech to text as does the CapTel relay service.
So if you want the faster relay, you have to use the CapTel phone which
provides simultaneous voice/text which many consumers can't use (don't have
the residual hearing) and for some it actually disrupts their ability to
communicate effectively (especially elderly). I'm not sure what the answer
is -- but for those of us who work with consumers every day, it is really
frustrating to have to purchase one proprietary phone that has
uneeded/unwanted features just to be able to access a more
efficient/effective relay service. Sorry, my venting for the day.



Diane



Diane Cordry Golden, Ph.D., Director
Missouri Assistive Technology
816/350-5280 (direct voice)
= EMAIL ADDRESS REMOVED =
www.at.mo.gov



-----Original Message-----
From: Paul E. Jones [mailto: = EMAIL ADDRESS REMOVED = ]
Sent: Saturday, June 09, 2007 4:18 PM
To: = EMAIL ADDRESS REMOVED = ; 'TEITAC Telecommunications Subcommittee'
Subject: RE: [teitac-telecom] RFC 4103 reference for real-time text.

Diane,



What is a "VCO phone"? Is this one that still uses Baudot for character
transmission?



Captel, as I understand, does not use Baudot. As such, it will introduce
significantly more hurdles moving forward. Over the past few years as we've
been working on new standards to move from a legacy TTY world to an IP
world, several of us in the industry have invited Ultratec to participate
and to share information so that we can integrate the technology into
standards, but they've repeatedly declined. So, I really worry about how we
could ever possibly support Captel. The only choice might be to use G.711,
but then the government could not require VoIP service providers like Vonage
or services from AT&T like CallVantage to support it, because there is no
way for either of those carriers to guarantee (or even remotely attempt) to
guarantee the low packet loss rates necessary for those services to work
since they do not own the access lines going into subscriber's homes.



Perhaps we need to move to distributing IP versions of those same kinds of
technologies well in advance of a complete migration to VoIP.



Paul





From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Diane Golden
Sent: Friday, June 08, 2007 4:18 PM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.



On behalf of one of the state programs that distribute adaptive telephone
equipment, pure TTY's are a very tiny part of the distribution today. The
numbers have steadily decreased year after year as people move to other
equipment options. What we don't have is good data on how many people use
the TTY as their only telecom equipment rather than a secondary or
supplemental option. We do now distribute more VCO phones (including
regular VCO and CapTel) than TTYs and for pretty much all of these people
that is the only telecom option they have. So that group may actually be
our biggest legacy equipment problem.



Diane



Diane Cordry Golden, Ph.D., Director
Missouri Assistive Technology
816/350-5280 (direct voice)
= EMAIL ADDRESS REMOVED =
www.at.mo.gov



[SNIP]

From: Paul E. Jones
Date: Mon, Jun 18 2007 1:51 PM
Subject: Re: RFC 4103 reference for real-time text.

Gregg,



You mentioned that CapTel used industry standards on the PSTN: that is what
I was asking about.



Paul





From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Gregg
Vanderheiden
Sent: Monday, June 18, 2007 1:09 AM
To: 'TEITAC Telecommunications Subcommittee'; = EMAIL ADDRESS REMOVED =
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.



I am not going to pre-announce the formats that Ultratec will be supporting
on IP but IP CapTel is now authorized and they are implementing it now.



It is easy to support captioned telephony in IP. Much easier than in PSTN.





Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.






_____


From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Paul E. Jones
Sent: Sunday, June 17, 2007 10:15 PM
To: 'TEITAC Telecommunications Subcommittee'; = EMAIL ADDRESS REMOVED =
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.

Gregg,



What industry standards does CapTel use? As far as I know, there is no way
for us to support that in an IP world.



Paul





From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Gregg
Vanderheiden
Sent: Wednesday, June 13, 2007 1:13 AM
To: 'TEITAC Telecommunications Subcommittee'; = EMAIL ADDRESS REMOVED =
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.



Hmm



There is a bit of confusing discussion here. A few notes.





- VCO is a technique. It can be used with TTY or with other
technologies that do not support simultaneous text and speech. It is
commonly used with relays. It can also be used without using a relay.
The VCO capability on one cell phone for example can be used with an HCO
feature on another phone.

- CapTel uses industry standards for communicating in PSTN. It uses
them differently than in the past because no one offered CapTel in the past.
CapTel isn't TTY because TTY doesn't support simultaneous voice and text
which is of course required.

- IP captioned telephone can be done using RFC-4103. (It can also
be done with RFC-4351). It cannot be done with VBD or TTY tones on IP.





Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.






_____


From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Paul E. Jones
Sent: Sunday, June 10, 2007 6:49 PM
To: = EMAIL ADDRESS REMOVED = ; 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.

Diane,



OK, my understand of VCO was in line with yours. The way it was worded
("VCO phone"), I thought it was a phone like Captel that I just had not
heard about before.



Your venting is well-justified. Since I started working in this area
several years ago, I've co-authored several standards, been given several
conflicting requirements, been accused of doing an injustice to the deaf
community, and had countless debates that were far less than fruitful. All
the while, I am genuinely trying to find a solution that is acceptable to
everybody. I'm almost at a point of thinking there is no way.



One of the problems that I've observed (at least, this is my personal
opinion) is that people try to take the old technology and apply it to the
new technology. New technology opens the door for changes. IP, in general,
really opens the door for significant changes in the way deaf people can
communicate. What I hope is that we recognize the possibilities and do not
rush to forcing something into the market that limits those possibilities.



Initially, I would think (as was originally posited to me) that "bridging
the old with the new" was the first important step. We created the
standards to do that. We then need to ask, "what do we want next?" I have
an idea and I'm working on that. I do not personally view anything we have
today (in terms of standards) as the best and final step: I think we've only
scratched the surface and much more potential exists.



We need something for the moment, but we also need to ensure the door is
wide open for better technologies. It's definitely hard to codify that
desire into law.



Paul





From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Diane Golden
Sent: Sunday, June 10, 2007 4:54 PM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.



VCO is voice carry over and does use Baudot (unless there's something out
there I'm unaware of.) The person with the VCO phone uses their own voice
to send communication and received by reading text (almost always coming via
relay). Captel does use a different transmission but I believe has a
secondary Baudot capacity to allow users to call 911 directly by making a
"traditional VCO" call. When they switch to "traditional VCO" the CapTel
user no longer has simultaneous voice/text coming in (just text) and the
outgoing call to 911 just goes to the emergency center instead of
automatically connecting to the CapTel relay center.



Not only do we have transmission/code issues with these systems, we also
have a situation in which a proprietary product is the only avenue to obtain
a more effective relay service unless the consumer can go to IP. Right now
consumers who need VCO can use "traditional VCO" with a number of products
on the market but it uses regular relay services which do not provide nearly
the speed of conversion of speech to text as does the CapTel relay service.
So if you want the faster relay, you have to use the CapTel phone which
provides simultaneous voice/text which many consumers can't use (don't have
the residual hearing) and for some it actually disrupts their ability to
communicate effectively (especially elderly). I'm not sure what the answer
is -- but for those of us who work with consumers every day, it is really
frustrating to have to purchase one proprietary phone that has
uneeded/unwanted features just to be able to access a more
efficient/effective relay service. Sorry, my venting for the day.



Diane



Diane Cordry Golden, Ph.D., Director
Missouri Assistive Technology
816/350-5280 (direct voice)
= EMAIL ADDRESS REMOVED =
www.at.mo.gov



-----Original Message-----
From: Paul E. Jones [mailto: = EMAIL ADDRESS REMOVED = ]
Sent: Saturday, June 09, 2007 4:18 PM
To: = EMAIL ADDRESS REMOVED = ; 'TEITAC Telecommunications Subcommittee'
Subject: RE: [teitac-telecom] RFC 4103 reference for real-time text.

Diane,



What is a "VCO phone"? Is this one that still uses Baudot for character
transmission?



Captel, as I understand, does not use Baudot. As such, it will introduce
significantly more hurdles moving forward. Over the past few years as we've
been working on new standards to move from a legacy TTY world to an IP
world, several of us in the industry have invited Ultratec to participate
and to share information so that we can integrate the technology into
standards, but they've repeatedly declined. So, I really worry about how we
could ever possibly support Captel. The only choice might be to use G.711,
but then the government could not require VoIP service providers like Vonage
or services from AT&T like CallVantage to support it, because there is no
way for either of those carriers to guarantee (or even remotely attempt) to
guarantee the low packet loss rates necessary for those services to work
since they do not own the access lines going into subscriber's homes.



Perhaps we need to move to distributing IP versions of those same kinds of
technologies well in advance of a complete migration to VoIP.



Paul





From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Diane Golden
Sent: Friday, June 08, 2007 4:18 PM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.



On behalf of one of the state programs that distribute adaptive telephone
equipment, pure TTY's are a very tiny part of the distribution today. The
numbers have steadily decreased year after year as people move to other
equipment options. What we don't have is good data on how many people use
the TTY as their only telecom equipment rather than a secondary or
supplemental option. We do now distribute more VCO phones (including
regular VCO and CapTel) than TTYs and for pretty much all of these people
that is the only telecom option they have. So that group may actually be
our biggest legacy equipment problem.



Diane



Diane Cordry Golden, Ph.D., Director
Missouri Assistive Technology
816/350-5280 (direct voice)
= EMAIL ADDRESS REMOVED =
www.at.mo.gov



[SNIP]

From: Gregg Vanderheiden
Date: Mon, Jun 18 2007 11:30 PM
Subject: Re: RFC 4103 reference for real-time text.

You are correct. The CapTel for analog would not work well on IP - which
is why they are releasing IP version.



You are also correct that you don't need a CapTel phone on IP side as long
as everyone is using the same standard.



IP CapTel is the name of the service from Ultratec. The generic name is
"captioned telephony" and yes the goal is to have everyone using the same
standard for text so that this would be ubiquitous and possible on all
phones with text viewing capability.



G.711 and RFC 4103 that you cite is the target for VoIP via SIP.




Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.






_____


From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Paul E. Jones
Sent: Monday, June 18, 2007 3:38 AM
To: 'TEITAC Telecommunications Subcommittee'; = EMAIL ADDRESS REMOVED =
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.

Gregg,



So, CapTel on the PSTN today still presents a problem converting from PSTN
to IP, since the text is on the PSTN as who-knows-what and uses a separate
phone line for voice. I would not be able to use such a system with my VoIP
service provider and I assume we could not require them to support it,
either. (One cannot engineer a network to proprietary technology.)



In the IP world, there is no need for a special "CapTel" phone, per se,
since any text-enabled IP phone (hardware or software) would be able to
provide the same capabilities (e.g., G.711 for audio and RFC 4103 for text).
So, why call this "IP CapTel"? The objective of these legal changes is to
make an effort to make this kind of technology ubiquitous and open, right?
In any case, Ultratec certainly has the right to use that name, but I would
hope we do not devise another network with proprietary elements that do not
benefit the public at large.



Paul





From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Gregg
Vanderheiden
Sent: Monday, June 18, 2007 1:25 AM
To: 'TEITAC Telecommunications Subcommittee'; = EMAIL ADDRESS REMOVED =
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.



Oh, you said "we can't support that in IP world" so that confused me.



Dual line CapTel uses two standard lines. For single line I know they use
a modem standard but will have to look up which.

But that is all irrelevant for IP. They aren't using the PSTN standards for
IP. They are using IP standards.




Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.






_____


From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Paul E. Jones
Sent: Monday, June 18, 2007 12:11 AM
To: 'TEITAC Telecommunications Subcommittee'; = EMAIL ADDRESS REMOVED =
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.

Gregg,



You mentioned that CapTel used industry standards on the PSTN: that is what
I was asking about.



Paul





From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Gregg
Vanderheiden
Sent: Monday, June 18, 2007 1:09 AM
To: 'TEITAC Telecommunications Subcommittee'; = EMAIL ADDRESS REMOVED =
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.



I am not going to pre-announce the formats that Ultratec will be supporting
on IP but IP CapTel is now authorized and they are implementing it now.



It is easy to support captioned telephony in IP. Much easier than in PSTN.





Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.






_____


From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Paul E. Jones
Sent: Sunday, June 17, 2007 10:15 PM
To: 'TEITAC Telecommunications Subcommittee'; = EMAIL ADDRESS REMOVED =
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.

Gregg,



What industry standards does CapTel use? As far as I know, there is no way
for us to support that in an IP world.



Paul





From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Gregg
Vanderheiden
Sent: Wednesday, June 13, 2007 1:13 AM
To: 'TEITAC Telecommunications Subcommittee'; = EMAIL ADDRESS REMOVED =
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.



Hmm



There is a bit of confusing discussion here. A few notes.





- VCO is a technique. It can be used with TTY or with other
technologies that do not support simultaneous text and speech. It is
commonly used with relays. It can also be used without using a relay.
The VCO capability on one cell phone for example can be used with an HCO
feature on another phone.

- CapTel uses industry standards for communicating in PSTN. It uses
them differently than in the past because no one offered CapTel in the past.
CapTel isn't TTY because TTY doesn't support simultaneous voice and text
which is of course required.

- IP captioned telephone can be done using RFC-4103. (It can also
be done with RFC-4351). It cannot be done with VBD or TTY tones on IP.





Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.






_____


From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Paul E. Jones
Sent: Sunday, June 10, 2007 6:49 PM
To: = EMAIL ADDRESS REMOVED = ; 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.

Diane,



OK, my understand of VCO was in line with yours. The way it was worded
("VCO phone"), I thought it was a phone like Captel that I just had not
heard about before.



Your venting is well-justified. Since I started working in this area
several years ago, I've co-authored several standards, been given several
conflicting requirements, been accused of doing an injustice to the deaf
community, and had countless debates that were far less than fruitful. All
the while, I am genuinely trying to find a solution that is acceptable to
everybody. I'm almost at a point of thinking there is no way.



One of the problems that I've observed (at least, this is my personal
opinion) is that people try to take the old technology and apply it to the
new technology. New technology opens the door for changes. IP, in general,
really opens the door for significant changes in the way deaf people can
communicate. What I hope is that we recognize the possibilities and do not
rush to forcing something into the market that limits those possibilities.



Initially, I would think (as was originally posited to me) that "bridging
the old with the new" was the first important step. We created the
standards to do that. We then need to ask, "what do we want next?" I have
an idea and I'm working on that. I do not personally view anything we have
today (in terms of standards) as the best and final step: I think we've only
scratched the surface and much more potential exists.



We need something for the moment, but we also need to ensure the door is
wide open for better technologies. It's definitely hard to codify that
desire into law.



Paul





From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Diane Golden
Sent: Sunday, June 10, 2007 4:54 PM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.



VCO is voice carry over and does use Baudot (unless there's something out
there I'm unaware of.) The person with the VCO phone uses their own voice
to send communication and received by reading text (almost always coming via
relay). Captel does use a different transmission but I believe has a
secondary Baudot capacity to allow users to call 911 directly by making a
"traditional VCO" call. When they switch to "traditional VCO" the CapTel
user no longer has simultaneous voice/text coming in (just text) and the
outgoing call to 911 just goes to the emergency center instead of
automatically connecting to the CapTel relay center.



Not only do we have transmission/code issues with these systems, we also
have a situation in which a proprietary product is the only avenue to obtain
a more effective relay service unless the consumer can go to IP. Right now
consumers who need VCO can use "traditional VCO" with a number of products
on the market but it uses regular relay services which do not provide nearly
the speed of conversion of speech to text as does the CapTel relay service.
So if you want the faster relay, you have to use the CapTel phone which
provides simultaneous voice/text which many consumers can't use (don't have
the residual hearing) and for some it actually disrupts their ability to
communicate effectively (especially elderly). I'm not sure what the answer
is -- but for those of us who work with consumers every day, it is really
frustrating to have to purchase one proprietary phone that has
uneeded/unwanted features just to be able to access a more
efficient/effective relay service. Sorry, my venting for the day.



Diane



Diane Cordry Golden, Ph.D., Director
Missouri Assistive Technology
816/350-5280 (direct voice)
= EMAIL ADDRESS REMOVED =
www.at.mo.gov



-----Original Message-----
From: Paul E. Jones [mailto: = EMAIL ADDRESS REMOVED = ]
Sent: Saturday, June 09, 2007 4:18 PM
To: = EMAIL ADDRESS REMOVED = ; 'TEITAC Telecommunications Subcommittee'
Subject: RE: [teitac-telecom] RFC 4103 reference for real-time text.

Diane,



What is a "VCO phone"? Is this one that still uses Baudot for character
transmission?



Captel, as I understand, does not use Baudot. As such, it will introduce
significantly more hurdles moving forward. Over the past few years as we've
been working on new standards to move from a legacy TTY world to an IP
world, several of us in the industry have invited Ultratec to participate
and to share information so that we can integrate the technology into
standards, but they've repeatedly declined. So, I really worry about how we
could ever possibly support Captel. The only choice might be to use G.711,
but then the government could not require VoIP service providers like Vonage
or services from AT&T like CallVantage to support it, because there is no
way for either of those carriers to guarantee (or even remotely attempt) to
guarantee the low packet loss rates necessary for those services to work
since they do not own the access lines going into subscriber's homes.



Perhaps we need to move to distributing IP versions of those same kinds of
technologies well in advance of a complete migration to VoIP.



Paul





From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Diane Golden
Sent: Friday, June 08, 2007 4:18 PM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.



On behalf of one of the state programs that distribute adaptive telephone
equipment, pure TTY's are a very tiny part of the distribution today. The
numbers have steadily decreased year after year as people move to other
equipment options. What we don't have is good data on how many people use
the TTY as their only telecom equipment rather than a secondary or
supplemental option. We do now distribute more VCO phones (including
regular VCO and CapTel) than TTYs and for pretty much all of these people
that is the only telecom option they have. So that group may actually be
our biggest legacy equipment problem.



Diane



Diane Cordry Golden, Ph.D., Director
Missouri Assistive Technology
816/350-5280 (direct voice)
= EMAIL ADDRESS REMOVED =
www.at.mo.gov



[SNIP]

From: Gregg Vanderheiden
Date: Mon, Jun 18 2007 11:35 PM
Subject: Re: RFC 4103 reference for real-time text.

You concern is a good one.



I thought it was captured though by provision #2 in this text.





(a) Telecommunications terminals and other terminals capable of providing
real-time voice communications which do not themselves provide TTY or other
real-time text conversation functionality shall comply with the following:

1. All analog and TDM-digital wired terminals shall support the
connection of a TTY in the same location and with the permissions for use as
the telephone. This shall be accomplished by providing an RJ-11 jack on the
telephone, or, in the case of an analog telephone, by the use of a Y-adapter
that allows both the analog telephone and the TTY to be plugged into the
same line outlet, or have built in capability to support an RJ11 module that
can provide a connection point for TTYs;
2. Other types of terminals covered by this section shall support the
connection of real-time text capable devices in conjunction with the voice
call capability in the same location and the same permissions for use as the
terminal.
3. Shall be capable of allowing simultaneous speech and text
conversation without interference or its microphone shall be capable of
being turned on and off to allow the user to intermix speech with text use.






Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.

_____

From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Paul E. Jones
Sent: Monday, June 18, 2007 3:21 AM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.



Gregg,



But, there's nothing in the proposed law that would encourage or require
such a network enablement. The only provisions that I see are ones that
require some change to a phone. In any case, I will not push it since I
know that there is a lot of work required to enable devices that just
"appear" on the network.



Still, I feel like something is missing. An enterprise could text-enable
those phones with multi-line displays, do nothing else, and claim
compliance. How would end users feel about that? It would be a worse
interface than what users have today with TTY devices. TTY devices at least
have a keyboard, but the proposed law will not require that a keyboard be
provided for any deaf user, will it?



Paul





From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Gregg
Vanderheiden
Sent: Monday, June 18, 2007 1:04 AM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.



Either would seem to be sufficient to meet this. as long as 'hooking up to
the network' would give the same privileges as using the phone.




Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.






_____


From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Paul E. Jones
Sent: Sunday, June 17, 2007 10:30 PM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.

Gregg,



What do you mean by "provide a way to connect a phone that does support text
in parallel"? Does this allow me to bring an IP text device into an office
and be able to use it for communication, or am I going to be forced to
interface my text device with a voice phone? I am not opposed if people
want to interconnect a text device with a phone, but I don't want to be
forced to do that when I have a perfectly good working portable device that
has text and voice capability, my address book, and settings that are
suitable for me. So, what's missing is the ability for me to interface in
some way to the network. Do we want to enable IP text devices to interact
with the system without a voice telephone?



Paul





From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Gregg
Vanderheiden
Sent: Wednesday, June 13, 2007 1:17 AM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.





Hi Paul,



Thanks.



Just so people aren't confused - let me state the current language in the
telecom proposal



The current language does no propose that all phones be made into text
phones.



Availability: What is proposed is

1) EITHER support real time text OR provide a way to connect a phone
that does support text in parallel. (This is basically the same as today
with TTY)

2) IF an IP PHONE *already* has a multi-line display - THEN display IP
text that you receive (this is software only)

3) IF an IP PHONE *already* has a keyboard or allows a keyboard
interface - THEN allow the phone to send IP text. (this is software only
again)



Reliability: That all telecom systems support some type of reliable IP text
format. (Standard within the system but different closed systems can use
different technologies)



Interoperability: That all systems and devices that connect to the public
phone system support the standard format for the system to ensure
interoperability.

- for PSTN that is TIA 825

- for IP SIP it would be RFC 4103 (though there is also a proposal on
the list so support BOTH RFC-4103 and RFC-4351)










Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.






_____


From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Paul E. Jones
Sent: Saturday, June 09, 2007 4:32 PM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.

Gregg,



I still do not think it is a good idea to require every phone to support
real-times text. Not every phone today supports text, while they certainly
could. Baudot is trivial, the it could be integrated into my wireless phone
very easily. But, that's not what I would want to use!



I think we need to "be careful what we ask for", otherwise what we might
have is a large number of inferior devices and then people asking, "what
more do you want?"" There might be a resistance to consider making other
options available.



Today, not every phone is accessible. But, what is accessible is the phone
network. A user can use his equipment (or provided equipment) and access
the PSTN to communicate with anybody in the world. They key is "network
access", not "phone access". If we wanted to mandate public phones have
integrated RFC 4103 capabilities, fine. Those are closed systems that might
offer no other interface. Or will they? It might be possible to use an
external text device that works wirelessly with the public phone as a
"natural extension" of the phone. (Never discount the possibility that
technology might evolve in the future into something quite different than
what we have today. I am working on just such a new kind of system.
Whether it sees the light of day is another matter, but we should at least
consider how technology is ever-changing and more sophisticated.)



What I would personally want to be able to use is a Pocket PC, Ultra Mobile
PC (UMPC) or other device with communication software installed. I would
like to have a means to access the network, such as via an Ethernet
connection or a wireless access point. (It's not too hard for me to imagine
that a business could establish a VLAN specifically for such purposes: I
have the equipment necessary to do that in my house, so it's not beyond
reach.)



So, I would encourage you to consider the network, not the phone, as the
focal point for accessibility. This will enable users to have a wider
variety of options, including portable PC devices, dedicated textphones,
PCs, or other devices.



Paul





From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Gregg
Vanderheiden
Sent: Friday, June 08, 2007 4:24 PM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.



TTY is critical on PSTN. It is the only thing that works there.



But it does not work well and is very limiting on IP. Like cellular
phones, (that also can't transport TTY tones natively without destroying
them, the strategy is to convert to a data format where there system
connects to the PSTN.



V.151 is a protocol designed to work between gateways. It is great there.







We need protocols between VoIP phones and between VoIP phones and gateways.




The best I can see is a hybrid approach.





1) Require that all VoIP phones, routers etc support both RFC-4103 and
and RFC-4351 - WHERE THEY CONNECT TO PUBLIC IP SIP SYSTEMS - OR CONNECT TO
OTHER SYSTEMS. (Internally within their own systems where they control
both ends and intermediate routers, they can use anything that meets the
reliability requirements ).

2) PSTN to IP Gateways would also support both but could give preference
to RFC-4351 (offer it first) so that they can save a port for each call.
(if everyone supports both as they should - then RFC-4351 would work first
time.

3) On non public systems (Skype, Vonnage, Corporations Internal systems,
etc) any text transport that meets the requirements is allowed as long as it
is translated into TTY at any PSTN interface and into RFC04103 and 4351 at
any external IP SIP interface.





Would this hit the major issues?




Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.

From: Paul E. Jones
Date: Tue, Jun 19 2007 2:20 AM
Subject: Re: RFC 4103 reference for real-time text.

Gregg,



Possibly-as long as (2) does not mandate interfacing some text-capable
"add-on" device to an IP phone using some undefined interface. I can't see
a sustainable market for such a device for many reasons.



Still, I can't walk into a facility and use my own text phone, which is
something I'd love to the privilege to be able to do.



In my view, the most important thing is to not break what we have today and
then to also introduce radically new technologies. Based on what I've been
told, this is what people want. So, to that end, I still get the feeling
that there's too much emphasis on a voice phone. Do users care? Do users
really want to have text display on any phone? Would they use it? Would
they prefer to have alternative capabilities (e.g., soft phones, etc)? My
point is that manufacturers, enterprise IT staff, and carriers have limited
bandwidth to implement, test, and support various options. We ought to only
mandate those things users demand and it surprises me that users would
demand the ability to see text on any phone (even when there is no
keyboard), when new kinds of text devices would likely be a significantly
higher priority.



Paul





From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Gregg
Vanderheiden
Sent: Tuesday, June 19, 2007 1:32 AM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.



You concern is a good one.



I thought it was captured though by provision #2 in this text.





(a) Telecommunications terminals and other terminals capable of providing
real-time voice communications which do not themselves provide TTY or other
real-time text conversation functionality shall comply with the following:

1. All analog and TDM-digital wired terminals shall support the
connection of a TTY in the same location and with the permissions for use as
the telephone. This shall be accomplished by providing an RJ-11 jack on the
telephone, or, in the case of an analog telephone, by the use of a Y-adapter
that allows both the analog telephone and the TTY to be plugged into the
same line outlet, or have built in capability to support an RJ11 module that
can provide a connection point for TTYs;
2. Other types of terminals covered by this section shall support the
connection of real-time text capable devices in conjunction with the voice
call capability in the same location and the same permissions for use as the
terminal.
3. Shall be capable of allowing simultaneous speech and text
conversation without interference or its microphone shall be capable of
being turned on and off to allow the user to intermix speech with text use.






Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.

_____

From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Paul E. Jones
Sent: Monday, June 18, 2007 3:21 AM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.



Gregg,



But, there's nothing in the proposed law that would encourage or require
such a network enablement. The only provisions that I see are ones that
require some change to a phone. In any case, I will not push it since I
know that there is a lot of work required to enable devices that just
"appear" on the network.



Still, I feel like something is missing. An enterprise could text-enable
those phones with multi-line displays, do nothing else, and claim
compliance. How would end users feel about that? It would be a worse
interface than what users have today with TTY devices. TTY devices at least
have a keyboard, but the proposed law will not require that a keyboard be
provided for any deaf user, will it?



Paul





From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Gregg
Vanderheiden
Sent: Monday, June 18, 2007 1:04 AM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.



Either would seem to be sufficient to meet this. as long as 'hooking up to
the network' would give the same privileges as using the phone.




Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.






_____


From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Paul E. Jones
Sent: Sunday, June 17, 2007 10:30 PM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.

Gregg,



What do you mean by "provide a way to connect a phone that does support text
in parallel"? Does this allow me to bring an IP text device into an office
and be able to use it for communication, or am I going to be forced to
interface my text device with a voice phone? I am not opposed if people
want to interconnect a text device with a phone, but I don't want to be
forced to do that when I have a perfectly good working portable device that
has text and voice capability, my address book, and settings that are
suitable for me. So, what's missing is the ability for me to interface in
some way to the network. Do we want to enable IP text devices to interact
with the system without a voice telephone?



Paul





From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Gregg
Vanderheiden
Sent: Wednesday, June 13, 2007 1:17 AM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.





Hi Paul,



Thanks.



Just so people aren't confused - let me state the current language in the
telecom proposal



The current language does no propose that all phones be made into text
phones.



Availability: What is proposed is

1) EITHER support real time text OR provide a way to connect a phone
that does support text in parallel. (This is basically the same as today
with TTY)

2) IF an IP PHONE *already* has a multi-line display - THEN display IP
text that you receive (this is software only)

3) IF an IP PHONE *already* has a keyboard or allows a keyboard
interface - THEN allow the phone to send IP text. (this is software only
again)



Reliability: That all telecom systems support some type of reliable IP text
format. (Standard within the system but different closed systems can use
different technologies)



Interoperability: That all systems and devices that connect to the public
phone system support the standard format for the system to ensure
interoperability.

- for PSTN that is TIA 825

- for IP SIP it would be RFC 4103 (though there is also a proposal
on the list so support BOTH RFC-4103 and RFC-4351)










Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.






_____


From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Paul E. Jones
Sent: Saturday, June 09, 2007 4:32 PM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.

Gregg,



I still do not think it is a good idea to require every phone to support
real-times text. Not every phone today supports text, while they certainly
could. Baudot is trivial, the it could be integrated into my wireless phone
very easily. But, that's not what I would want to use!



I think we need to "be careful what we ask for", otherwise what we might
have is a large number of inferior devices and then people asking, "what
more do you want?"" There might be a resistance to consider making other
options available.



Today, not every phone is accessible. But, what is accessible is the phone
network. A user can use his equipment (or provided equipment) and access
the PSTN to communicate with anybody in the world. They key is "network
access", not "phone access". If we wanted to mandate public phones have
integrated RFC 4103 capabilities, fine. Those are closed systems that might
offer no other interface. Or will they? It might be possible to use an
external text device that works wirelessly with the public phone as a
"natural extension" of the phone. (Never discount the possibility that
technology might evolve in the future into something quite different than
what we have today. I am working on just such a new kind of system.
Whether it sees the light of day is another matter, but we should at least
consider how technology is ever-changing and more sophisticated.)



What I would personally want to be able to use is a Pocket PC, Ultra Mobile
PC (UMPC) or other device with communication software installed. I would
like to have a means to access the network, such as via an Ethernet
connection or a wireless access point. (It's not too hard for me to imagine
that a business could establish a VLAN specifically for such purposes: I
have the equipment necessary to do that in my house, so it's not beyond
reach.)



So, I would encourage you to consider the network, not the phone, as the
focal point for accessibility. This will enable users to have a wider
variety of options, including portable PC devices, dedicated textphones,
PCs, or other devices.



Paul





From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Gregg
Vanderheiden
Sent: Friday, June 08, 2007 4:24 PM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.



TTY is critical on PSTN. It is the only thing that works there.



But it does not work well and is very limiting on IP. Like cellular
phones, (that also can't transport TTY tones natively without destroying
them, the strategy is to convert to a data format where there system
connects to the PSTN.



V.151 is a protocol designed to work between gateways. It is great there.







We need protocols between VoIP phones and between VoIP phones and gateways.




The best I can see is a hybrid approach.





1) Require that all VoIP phones, routers etc support both RFC-4103 and
and RFC-4351 - WHERE THEY CONNECT TO PUBLIC IP SIP SYSTEMS - OR CONNECT TO
OTHER SYSTEMS. (Internally within their own systems where they control
both ends and intermediate routers, they can use anything that meets the
reliability requirements ).

2) PSTN to IP Gateways would also support both but could give
preference to RFC-4351 (offer it first) so that they can save a port for
each call. (if everyone supports both as they should - then RFC-4351 would
work first time.

3) On non public systems (Skype, Vonnage, Corporations Internal
systems, etc) any text transport that meets the requirements is allowed as
long as it is translated into TTY at any PSTN interface and into RFC04103
and 4351 at any external IP SIP interface.





Would this hit the major issues?




Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.

From: Jim Tobias
Date: Wed, Jun 20 2007 6:25 AM
Subject: real-time text

Hi All,

As drafted on our call monday, the definition of real-time text is:

"Communications that employ the transmission of text wherein the characters
are transmitted by a terminal w/in a maximum of 1 sec. of character input."

I think there are a few problems here:

1. Although the characters are to be transmitted quickly, there is no
reference to how they are handled once they're transmitted. That is, a
server in the middle somewhere could add significant delays by design or
congestion. If we want to make text conversation real-time, we have to make
it clear what the permissable end-to-end delay is.

2. If the intention in this definition was to distinguish TTY-style
(characters are transmitted as soon as they are keyed in) from IM and chat,
where you type a bunch of characters and then press "Enter" to transmit, we
should say so explicitly, somewhere.

3. Most importantly, I don't understand why we would want to exclude the
huge mainstream advantages of chat and IM. I have not heard anything from
the many deaf users of these systems that the "Enter" key imposes a
conversational barrier. Moreover, it is unlikely that mainstream chat/IM
program vendors will modify their programs to transmit character by
character. This leaves deaf and other users still in a communication
ghetto, instead of being able to use the same tools everyone else is using.

******
Jim Tobias
Inclusive Technologies
= EMAIL ADDRESS REMOVED =
+1 732.441.0831 voice/tty
skype jimtobias
+1 908.907.2387 mobile

From: Tom Brett
Date: Wed, Jun 20 2007 6:40 AM
Subject: Re: real-time text

>> 1. Although the characters are to be transmitted quickly, there is no
reference to how they are handled once they're transmitted. That is, a
server in the middle somewhere could add significant delays by design or
congestion. If we want to make text conversation real-time, we have to make
it clear what the permissible end-to-end delay is.

>From my understanding of the real time text definition I thought that it
applied only to the device that was doing the output. There can be
significant delay in the receipt of the characters depending upon receiving
device or traffic on the transmission lines. The end to end delay is, I
think, beyond the control of the subcommittee because the transmission is
either via the internet or telephone lines.

>>3. Most importantly, I don't understand why we would want to exclude the
huge mainstream advantages of chat and IM. I have not heard anything from
the many deaf users of these systems that the "Enter" key imposes a
conversational barrier. Moreover, it is unlikely that mainstream chat/IM
program vendors will modify their programs to transmit character by
character. This leaves deaf and other users still in a communication
ghetto, instead of being able to use the same tools everyone else is using.

As a user of text communication tools that include chat/im I do not find
this to be a barrier. In many respects I find this to be superior to
character by character transmission....we all make typos...imagine receiving
a character by character message:

"Gaood xxx good mraning, I qaxxx am wriging you today..."

This becomes very confusing. I find it better to receive a complete message
with fewer typos that I can then decipher easier.

Tom Brett

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Jim Tobias
Sent: Wednesday, June 20, 2007 8:21 AM
To: 'TEITAC Telecommunications Subcommittee'
Subject: [teitac-telecom] real-time text

Hi All,

As drafted on our call monday, the definition of real-time text is:

"Communications that employ the transmission of text wherein the characters
are transmitted by a terminal w/in a maximum of 1 sec. of character input."

I think there are a few problems here:

1. Although the characters are to be transmitted quickly, there is no
reference to how they are handled once they're transmitted. That is, a
server in the middle somewhere could add significant delays by design or
congestion. If we want to make text conversation real-time, we have to make
it clear what the permissable end-to-end delay is.

2. If the intention in this definition was to distinguish TTY-style
(characters are transmitted as soon as they are keyed in) from IM and chat,
where you type a bunch of characters and then press "Enter" to transmit, we
should say so explicitly, somewhere.

3. Most importantly, I don't understand why we would want to exclude the
huge mainstream advantages of chat and IM. I have not heard anything from
the many deaf users of these systems that the "Enter" key imposes a
conversational barrier. Moreover, it is unlikely that mainstream chat/IM
program vendors will modify their programs to transmit character by
character. This leaves deaf and other users still in a communication
ghetto, instead of being able to use the same tools everyone else is using.

******
Jim Tobias
Inclusive Technologies
= EMAIL ADDRESS REMOVED =
+1 732.441.0831 voice/tty
skype jimtobias
+1 908.907.2387 mobile

From: Gregg Vanderheiden
Date: Wed, Jun 20 2007 11:35 AM
Subject: Re: real-time text

Hi Tom

T140 includes backspaces so you still get a corrected message at the far
end.

And you can always have an option to hold back text if you wish. That is,
a system with real-time text could ALSO have a mode that was message like.


Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.


> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED = [mailto:teitac-telecom-
> = EMAIL ADDRESS REMOVED = ] On Behalf Of Tom Brett
> Sent: Wednesday, June 20, 2007 7:38 AM
> To: 'TEITAC Telecommunications Subcommittee'
> Subject: Re: [teitac-telecom] real-time text
>
> >> 1. Although the characters are to be transmitted quickly, there is no
> reference to how they are handled once they're transmitted. That is, a
> server in the middle somewhere could add significant delays by design or
> congestion. If we want to make text conversation real-time, we have to
> make
> it clear what the permissible end-to-end delay is.
>
> >From my understanding of the real time text definition I thought that it
> applied only to the device that was doing the output. There can be
> significant delay in the receipt of the characters depending upon
> receiving
> device or traffic on the transmission lines. The end to end delay is, I
> think, beyond the control of the subcommittee because the transmission is
> either via the internet or telephone lines.
>
> >>3. Most importantly, I don't understand why we would want to exclude the
> huge mainstream advantages of chat and IM. I have not heard anything from
> the many deaf users of these systems that the "Enter" key imposes a
> conversational barrier. Moreover, it is unlikely that mainstream chat/IM
> program vendors will modify their programs to transmit character by
> character. This leaves deaf and other users still in a communication
> ghetto, instead of being able to use the same tools everyone else is
using.
>
> As a user of text communication tools that include chat/im I do not find
> this to be a barrier. In many respects I find this to be superior to
> character by character transmission....we all make typos...imagine
> receiving
> a character by character message:
>
> "Gaood xxx good mraning, I qaxxx am wriging you today..."
>
> This becomes very confusing. I find it better to receive a complete
> message
> with fewer typos that I can then decipher easier.
>
> Tom Brett
>
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Jim Tobias
> Sent: Wednesday, June 20, 2007 8:21 AM
> To: 'TEITAC Telecommunications Subcommittee'
> Subject: [teitac-telecom] real-time text
>
> Hi All,
>
> As drafted on our call monday, the definition of real-time text is:
>
> "Communications that employ the transmission of text wherein the
> characters
> are transmitted by a terminal w/in a maximum of 1 sec. of character
> input."
>
> I think there are a few problems here:
>
> 1. Although the characters are to be transmitted quickly, there is no
> reference to how they are handled once they're transmitted. That is, a
> server in the middle somewhere could add significant delays by design or
> congestion. If we want to make text conversation real-time, we have to
> make
> it clear what the permissable end-to-end delay is.
>
> 2. If the intention in this definition was to distinguish TTY-style
> (characters are transmitted as soon as they are keyed in) from IM and
chat,
> where you type a bunch of characters and then press "Enter" to transmit,
> we
> should say so explicitly, somewhere.
>
> 3. Most importantly, I don't understand why we would want to exclude the
> huge mainstream advantages of chat and IM. I have not heard anything from
> the many deaf users of these systems that the "Enter" key imposes a
> conversational barrier. Moreover, it is unlikely that mainstream chat/IM
> program vendors will modify their programs to transmit character by
> character. This leaves deaf and other users still in a communication
> ghetto, instead of being able to use the same tools everyone else is
using.
>
> ******
> Jim Tobias
> Inclusive Technologies
> = EMAIL ADDRESS REMOVED =
> +1 732.441.0831 voice/tty
> skype jimtobias
> +1 908.907.2387 mobile
>
>

From: Tom Brett
Date: Wed, Jun 20 2007 12:10 PM
Subject: Re: real-time text

The t140 includes this option but I what I receive is

Ga ood morning, I s am wrting writing you....



Tom Brett


-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Gregg
Vanderheiden
Sent: Wednesday, June 20, 2007 1:27 PM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] real-time text

Hi Tom

T140 includes backspaces so you still get a corrected message at the far
end.

And you can always have an option to hold back text if you wish. That is,
a system with real-time text could ALSO have a mode that was message like.


Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.


> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED = [mailto:teitac-telecom-
> = EMAIL ADDRESS REMOVED = ] On Behalf Of Tom Brett
> Sent: Wednesday, June 20, 2007 7:38 AM
> To: 'TEITAC Telecommunications Subcommittee'
> Subject: Re: [teitac-telecom] real-time text
>
> >> 1. Although the characters are to be transmitted quickly, there is no
> reference to how they are handled once they're transmitted. That is, a
> server in the middle somewhere could add significant delays by design or
> congestion. If we want to make text conversation real-time, we have to
> make
> it clear what the permissible end-to-end delay is.
>
> >From my understanding of the real time text definition I thought that it
> applied only to the device that was doing the output. There can be
> significant delay in the receipt of the characters depending upon
> receiving
> device or traffic on the transmission lines. The end to end delay is, I
> think, beyond the control of the subcommittee because the transmission is
> either via the internet or telephone lines.
>
> >>3. Most importantly, I don't understand why we would want to exclude the
> huge mainstream advantages of chat and IM. I have not heard anything from
> the many deaf users of these systems that the "Enter" key imposes a
> conversational barrier. Moreover, it is unlikely that mainstream chat/IM
> program vendors will modify their programs to transmit character by
> character. This leaves deaf and other users still in a communication
> ghetto, instead of being able to use the same tools everyone else is
using.
>
> As a user of text communication tools that include chat/im I do not find
> this to be a barrier. In many respects I find this to be superior to
> character by character transmission....we all make typos...imagine
> receiving
> a character by character message:
>
> "Gaood xxx good mraning, I qaxxx am wriging you today..."
>
> This becomes very confusing. I find it better to receive a complete
> message
> with fewer typos that I can then decipher easier.
>
> Tom Brett
>
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Jim Tobias
> Sent: Wednesday, June 20, 2007 8:21 AM
> To: 'TEITAC Telecommunications Subcommittee'
> Subject: [teitac-telecom] real-time text
>
> Hi All,
>
> As drafted on our call monday, the definition of real-time text is:
>
> "Communications that employ the transmission of text wherein the
> characters
> are transmitted by a terminal w/in a maximum of 1 sec. of character
> input."
>
> I think there are a few problems here:
>
> 1. Although the characters are to be transmitted quickly, there is no
> reference to how they are handled once they're transmitted. That is, a
> server in the middle somewhere could add significant delays by design or
> congestion. If we want to make text conversation real-time, we have to
> make
> it clear what the permissable end-to-end delay is.
>
> 2. If the intention in this definition was to distinguish TTY-style
> (characters are transmitted as soon as they are keyed in) from IM and
chat,
> where you type a bunch of characters and then press "Enter" to transmit,
> we
> should say so explicitly, somewhere.
>
> 3. Most importantly, I don't understand why we would want to exclude the
> huge mainstream advantages of chat and IM. I have not heard anything from
> the many deaf users of these systems that the "Enter" key imposes a
> conversational barrier. Moreover, it is unlikely that mainstream chat/IM
> program vendors will modify their programs to transmit character by
> character. This leaves deaf and other users still in a communication
> ghetto, instead of being able to use the same tools everyone else is
using.
>
> ******
> Jim Tobias
> Inclusive Technologies
> = EMAIL ADDRESS REMOVED =
> +1 732.441.0831 voice/tty
> skype jimtobias
> +1 908.907.2387 mobile
>
>

From: Gregg Vanderheiden
Date: Wed, Jun 20 2007 12:40 PM
Subject: Re: real-time text

What you would receive is exactly the same as what you receive on TTYs
today.

All corrections are in place. You can see people backspace - that is true.
But only if person sending wants to. That person has the option of holding
text back if they wish. It wouldn't be real-time text in that case. but
the requirement is only that devices be capable of real-time text. it does
not require people to use real-time text.

As Jim pointed out - they may wish to operate in IM mode, in message mode.
Or send email. Just as all of us with real-time voice also use all of
these other modes sometimes and want real-time communication at other times.



Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.



> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Tom Brett
> Sent: Wednesday, June 20, 2007 1:08 PM
> To: 'TEITAC Telecommunications Subcommittee'
> Subject: Re: [teitac-telecom] real-time text
>
> The t140 includes this option but I what I receive is
>
> Ga ood morning, I s am wrting writing you....
>
>
>
> Tom Brett
>
>
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
> Gregg Vanderheiden
> Sent: Wednesday, June 20, 2007 1:27 PM
> To: 'TEITAC Telecommunications Subcommittee'
> Subject: Re: [teitac-telecom] real-time text
>
> Hi Tom
>
> T140 includes backspaces so you still get a corrected message
> at the far end.
>
> And you can always have an option to hold back text if you
> wish. That is,
> a system with real-time text could ALSO have a mode that was
> message like.
>
>
> Gregg
> -- ------------------------------
> Gregg C Vanderheiden Ph.D.
>
>
> > -----Original Message-----
> > From: = EMAIL ADDRESS REMOVED =
> [mailto:teitac-telecom-
> > = EMAIL ADDRESS REMOVED = ] On Behalf Of Tom Brett
> > Sent: Wednesday, June 20, 2007 7:38 AM
> > To: 'TEITAC Telecommunications Subcommittee'
> > Subject: Re: [teitac-telecom] real-time text
> >
> > >> 1. Although the characters are to be transmitted
> quickly, there is
> > >> no
> > reference to how they are handled once they're transmitted.
> That is,
> > a server in the middle somewhere could add significant delays by
> > design or congestion. If we want to make text conversation
> real-time,
> > we have to make it clear what the permissible end-to-end delay is.
> >
> > >From my understanding of the real time text definition I
> thought that
> > >it
> > applied only to the device that was doing the output.
> There can be
> > significant delay in the receipt of the characters depending upon
> > receiving device or traffic on the transmission lines. The
> end to end
> > delay is, I think, beyond the control of the subcommittee
> because the
> > transmission is either via the internet or telephone lines.
> >
> > >>3. Most importantly, I don't understand why we would want
> to exclude
> > >>the
> > huge mainstream advantages of chat and IM. I have not
> heard anything
> > from the many deaf users of these systems that the "Enter"
> key imposes
> > a conversational barrier. Moreover, it is unlikely that mainstream
> > chat/IM program vendors will modify their programs to transmit
> > character by character. This leaves deaf and other users
> still in a
> > communication ghetto, instead of being able to use the same tools
> > everyone else is
> using.
> >
> > As a user of text communication tools that include chat/im I do not
> > find this to be a barrier. In many respects I find this to be
> > superior to character by character transmission....we all make
> > typos...imagine receiving a character by character message:
> >
> > "Gaood xxx good mraning, I qaxxx am wriging you today..."
> >
> > This becomes very confusing. I find it better to receive a
> complete
> > message with fewer typos that I can then decipher easier.
> >
> > Tom Brett
> >
> > -----Original Message-----
> > From: = EMAIL ADDRESS REMOVED =
> > [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Jim
> > Tobias
> > Sent: Wednesday, June 20, 2007 8:21 AM
> > To: 'TEITAC Telecommunications Subcommittee'
> > Subject: [teitac-telecom] real-time text
> >
> > Hi All,
> >
> > As drafted on our call monday, the definition of real-time text is:
> >
> > "Communications that employ the transmission of text wherein the
> > characters are transmitted by a terminal w/in a maximum of
> 1 sec. of
> > character input."
> >
> > I think there are a few problems here:
> >
> > 1. Although the characters are to be transmitted quickly,
> there is no
> > reference to how they are handled once they're transmitted.
> That is,
> > a server in the middle somewhere could add significant delays by
> > design or congestion. If we want to make text conversation
> real-time,
> > we have to make it clear what the permissable end-to-end delay is.
> >
> > 2. If the intention in this definition was to distinguish TTY-style
> > (characters are transmitted as soon as they are keyed in)
> from IM and
> chat,
> > where you type a bunch of characters and then press "Enter" to
> > transmit, we should say so explicitly, somewhere.
> >
> > 3. Most importantly, I don't understand why we would want
> to exclude
> > the huge mainstream advantages of chat and IM. I have not heard
> > anything from the many deaf users of these systems that the "Enter"
> > key imposes a conversational barrier. Moreover, it is
> unlikely that
> > mainstream chat/IM program vendors will modify their programs to
> > transmit character by character. This leaves deaf and other users
> > still in a communication ghetto, instead of being able to
> use the same
> > tools everyone else is
> using.
> >
> > ******
> > Jim Tobias
> > Inclusive Technologies
> > = EMAIL ADDRESS REMOVED =
> > +1 732.441.0831 voice/tty
> > skype jimtobias
> > +1 908.907.2387 mobile
> >
> >

From: jagbell
Date: Wed, Jun 20 2007 4:15 PM
Subject: Re: real-time text

Please note my new address is = EMAIL ADDRESS REMOVED = .

Thanks,

Janice

On Jun 20, 2007, at 2:38 PM, Gregg Vanderheiden wrote:

> What you would receive is exactly the same as what you receive on TTYs
> today.
>
> All corrections are in place. You can see people backspace - that
> is true.
> But only if person sending wants to. That person has the option of
> holding
> text back if they wish. It wouldn't be real-time text in that
> case. but
> the requirement is only that devices be capable of real-time text.
> it does
> not require people to use real-time text.
>
> As Jim pointed out - they may wish to operate in IM mode, in
> message mode.
> Or send email. Just as all of us with real-time voice also use
> all of
> these other modes sometimes and want real-time communication at
> other times.
>
>
>
> Gregg
> -- ------------------------------
> Gregg C Vanderheiden Ph.D.
>
>
>
>> -----Original Message-----
>> From: = EMAIL ADDRESS REMOVED =
>> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Tom
>> Brett
>> Sent: Wednesday, June 20, 2007 1:08 PM
>> To: 'TEITAC Telecommunications Subcommittee'
>> Subject: Re: [teitac-telecom] real-time text
>>
>> The t140 includes this option but I what I receive is
>>
>> Ga ood morning, I s am wrting writing you....
>>
>>
>>
>> Tom Brett
>>
>>
>> -----Original Message-----
>> From: = EMAIL ADDRESS REMOVED =
>> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
>> Gregg Vanderheiden
>> Sent: Wednesday, June 20, 2007 1:27 PM
>> To: 'TEITAC Telecommunications Subcommittee'
>> Subject: Re: [teitac-telecom] real-time text
>>
>> Hi Tom
>>
>> T140 includes backspaces so you still get a corrected message
>> at the far end.
>>
>> And you can always have an option to hold back text if you
>> wish. That is,
>> a system with real-time text could ALSO have a mode that was
>> message like.
>>
>>
>> Gregg
>> -- ------------------------------
>> Gregg C Vanderheiden Ph.D.
>>
>>
>>> -----Original Message-----
>>> From: = EMAIL ADDRESS REMOVED =
>> [mailto:teitac-telecom-
>>> = EMAIL ADDRESS REMOVED = ] On Behalf Of Tom Brett
>>> Sent: Wednesday, June 20, 2007 7:38 AM
>>> To: 'TEITAC Telecommunications Subcommittee'
>>> Subject: Re: [teitac-telecom] real-time text
>>>
>>>>> 1. Although the characters are to be transmitted
>> quickly, there is
>>>>> no
>>> reference to how they are handled once they're transmitted.
>> That is,
>>> a server in the middle somewhere could add significant delays by
>>> design or congestion. If we want to make text conversation
>> real-time,
>>> we have to make it clear what the permissible end-to-end delay is.
>>>
>>>> From my understanding of the real time text definition I
>> thought that
>>>> it
>>> applied only to the device that was doing the output.
>> There can be
>>> significant delay in the receipt of the characters depending upon
>>> receiving device or traffic on the transmission lines. The
>> end to end
>>> delay is, I think, beyond the control of the subcommittee
>> because the
>>> transmission is either via the internet or telephone lines.
>>>
>>>>> 3. Most importantly, I don't understand why we would want
>> to exclude
>>>>> the
>>> huge mainstream advantages of chat and IM. I have not
>> heard anything
>>> from the many deaf users of these systems that the "Enter"
>> key imposes
>>> a conversational barrier. Moreover, it is unlikely that mainstream
>>> chat/IM program vendors will modify their programs to transmit
>>> character by character. This leaves deaf and other users
>> still in a
>>> communication ghetto, instead of being able to use the same tools
>>> everyone else is
>> using.
>>>
>>> As a user of text communication tools that include chat/im I do not
>>> find this to be a barrier. In many respects I find this to be
>>> superior to character by character transmission....we all make
>>> typos...imagine receiving a character by character message:
>>>
>>> "Gaood xxx good mraning, I qaxxx am wriging you today..."
>>>
>>> This becomes very confusing. I find it better to receive a
>> complete
>>> message with fewer typos that I can then decipher easier.
>>>
>>> Tom Brett
>>>
>>> -----Original Message-----
>>> From: = EMAIL ADDRESS REMOVED =
>>> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Jim
>>> Tobias
>>> Sent: Wednesday, June 20, 2007 8:21 AM
>>> To: 'TEITAC Telecommunications Subcommittee'
>>> Subject: [teitac-telecom] real-time text
>>>
>>> Hi All,
>>>
>>> As drafted on our call monday, the definition of real-time text is:
>>>
>>> "Communications that employ the transmission of text wherein the
>>> characters are transmitted by a terminal w/in a maximum of
>> 1 sec. of
>>> character input."
>>>
>>> I think there are a few problems here:
>>>
>>> 1. Although the characters are to be transmitted quickly,
>> there is no
>>> reference to how they are handled once they're transmitted.
>> That is,
>>> a server in the middle somewhere could add significant delays by
>>> design or congestion. If we want to make text conversation
>> real-time,
>>> we have to make it clear what the permissable end-to-end delay is.
>>>
>>> 2. If the intention in this definition was to distinguish TTY-style
>>> (characters are transmitted as soon as they are keyed in)
>> from IM and
>> chat,
>>> where you type a bunch of characters and then press "Enter" to
>>> transmit, we should say so explicitly, somewhere.
>>>
>>> 3. Most importantly, I don't understand why we would want
>> to exclude
>>> the huge mainstream advantages of chat and IM. I have not heard
>>> anything from the many deaf users of these systems that the "Enter"
>>> key imposes a conversational barrier. Moreover, it is
>> unlikely that
>>> mainstream chat/IM program vendors will modify their programs to
>>> transmit character by character. This leaves deaf and other users
>>> still in a communication ghetto, instead of being able to
>> use the same
>>> tools everyone else is
>> using.
>>>
>>> ******
>>> Jim Tobias
>>> Inclusive Technologies
>>> = EMAIL ADDRESS REMOVED =
>>> +1 732.441.0831 voice/tty
>>> skype jimtobias
>>> +1 908.907.2387 mobile
>>>
>>>

From: Gregg Vanderheiden
Date: Wed, Jun 20 2007 4:30 PM
Subject: Re: real-time text

There is nothing here about not using IM because we don't want to discourage
their use at all.

But it is a separate topic from real-time conversation on VoIP.

IM is wonderful - and we all use it. But it doesn't replace our ability or
desire to use the phone - or our voice when we can on calls.

Some people live on IM instead of calls. But others don't.

And older people who are deaf but can talk (or who are hard of hearing) will
want to talk and have what comes back be realtime text (straight or as
captioned speech).

But YES - IM is also important as another way of communicating and we should
do nothing that speaks against its use for those purposes. And I didn't
think we did. Do we?


Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.



> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
> Jim Tobias
> Sent: Wednesday, June 20, 2007 7:21 AM
> To: 'TEITAC Telecommunications Subcommittee'
> Subject: [teitac-telecom] real-time text
>
> Hi All,
>
> As drafted on our call monday, the definition of real-time text is:
>
> "Communications that employ the transmission of text wherein
> the characters are transmitted by a terminal w/in a maximum
> of 1 sec. of character input."
>
> I think there are a few problems here:
>
> 1. Although the characters are to be transmitted quickly,
> there is no reference to how they are handled once they're
> transmitted. That is, a server in the middle somewhere could
> add significant delays by design or congestion. If we want
> to make text conversation real-time, we have to make it clear
> what the permissable end-to-end delay is.
>
> 2. If the intention in this definition was to distinguish
> TTY-style (characters are transmitted as soon as they are
> keyed in) from IM and chat, where you type a bunch of
> characters and then press "Enter" to transmit, we should say
> so explicitly, somewhere.
>
> 3. Most importantly, I don't understand why we would want to
> exclude the huge mainstream advantages of chat and IM. I
> have not heard anything from the many deaf users of these
> systems that the "Enter" key imposes a conversational
> barrier. Moreover, it is unlikely that mainstream chat/IM
> program vendors will modify their programs to transmit
> character by character. This leaves deaf and other users
> still in a communication ghetto, instead of being able to use
> the same tools everyone else is using.
>
> ******
> Jim Tobias
> Inclusive Technologies
> = EMAIL ADDRESS REMOVED =
> +1 732.441.0831 voice/tty
> skype jimtobias
> +1 908.907.2387 mobile
>
>

From: Gregg Vanderheiden
Date: Wed, Jun 20 2007 5:00 PM
Subject: Re: RFC 4103 reference for real-time text.

COMMENTS IN CONTEXT BELOW




Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.

_____

From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Paul E. Jones
Sent: Tuesday, June 19, 2007 1:18 AM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.



Gregg,



Possibly-as long as (2) does not mandate interfacing some text-capable
"add-on" device to an IP phone using some undefined interface. I can't see
a sustainable market for such a device for many reasons.



Still, I can't walk into a facility and use my own text phone, which is
something I'd love to the privilege to be able to do.



GV: if you want to use yours - wouldn't you need some standard way to
connect it? We don't have that now. We are ambiguous about it. But you
are right - we should look at that.



In my view, the most important thing is to not break what we have today and
then to also introduce radically new technologies.

GV: Not sure what you mean here. Can you elaborate on what you don't want
to break? Also - what is the radically new technology you are referring
to?



Based on what I've been told, this is what people want. So, to that end, I
still get the feeling that there's too much emphasis on a voice phone. Do
users care?

GV: Don't understand. I use mine all the time. As does everyone I know
of that can talk. Some have lost their hearing or hear so poorly that they
no longer can - but give them the ability to again and they will be back on
it. And I don't want to lose the ability to talk to people when my
hearing goes.



Do users really want to have text display on any phone? Would they use it?

GV: The text displays are already appearing on the phones. Do you mean
who would like to be able to use the phones they find around them as they
lose their hearing?



Would they prefer to have alternative capabilities (e.g., soft phones,
etc)?

GV: I don't think a soft phone will work with my mom.

I think the large number of regular phones that are sold - speaks to their
prevelance over softphones. Even Skype makes them.

-



My point is that manufacturers, enterprise IT staff, and carriers have
limited bandwidth to implement, test, and support various options. We ought
to only mandate those things users demand and it surprises me that users
would demand the ability to see text on any phone (even when there is no
keyboard), when new kinds of text devices would likely be a significantly
higher priority.

GV: the reasons for wanting to use any phone rather than have to carry
your own with you are many and varied.

- I don't have it with me and I need to call my wife (I talk so I have
no use for a keyboard)

- I am in a place where my cell doesn't work and they don't allow me
to connect foreign phones to their network.

- I am older and can't afford monthly payments for a cell phone or
text service. I just use the phone that is here for everyone.

- I am older and don't understand computers. I just want to call my
kids and be able to see what they are saying.

- If I use my phone I pay for the call - If I use the office phone (at
home office or any office I am in) they pay for it

- My phone doesn't support conf calling - the office one does

- I don't use a computer except when at my desk ( I don't carry one
with me) so softphone won't help

- I use services that charge the phone calling. Don't want those
bills myself.



Basically, all the reasons that everyone likes to use regular phones - and
the reason there are more regular phones than softphones - and usually a
regular phone sitting on the desk next to every soft phone.



For people who cannot speak and need to use a keyboard - I understand your
approach. But the for larger number who can speak - but can't hear well
enough they would like to be able to see what they other people are saying
but be able to speak back.



And if the phone already has a display on it - why would you not display
the text coming in as captions or as supplement? Not sure I follow.

None of the provisions talk about requiring a display. Just allowing text
to display if it is there.



Remember there are many people who do not have the money to afford the
special text communication devices and who also don't have computers. For
government employees at their desks - cost is not a factor. But for phones
in public places, in VA and other government - non-work locations, and
people away from their desks who don't want to use their own phones (because
it would run up charges nationally or internationally) - this is important.




And remembering that we are harmonizing with 255 as well - so it isn't just
government.



So lots of reasons for allowing text to appear on phones (that already have
a display) so that the phones are usable without having to buy an extra
device when not needed.



Thanks



Gregg





Paul





From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Gregg
Vanderheiden
Sent: Tuesday, June 19, 2007 1:32 AM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.



You concern is a good one.



I thought it was captured though by provision #2 in this text.





(a) Telecommunications terminals and other terminals capable of providing
real-time voice communications which do not themselves provide TTY or other
real-time text conversation functionality shall comply with the following:

1. All analog and TDM-digital wired terminals shall support the
connection of a TTY in the same location and with the permissions for use as
the telephone. This shall be accomplished by providing an RJ-11 jack on the
telephone, or, in the case of an analog telephone, by the use of a Y-adapter
that allows both the analog telephone and the TTY to be plugged into the
same line outlet, or have built in capability to support an RJ11 module that
can provide a connection point for TTYs;
2. Other types of terminals covered by this section shall support the
connection of real-time text capable devices in conjunction with the voice
call capability in the same location and the same permissions for use as the
terminal.
3. Shall be capable of allowing simultaneous speech and text
conversation without interference or its microphone shall be capable of
being turned on and off to allow the user to intermix speech with text use.






Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.

_____

From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Paul E. Jones
Sent: Monday, June 18, 2007 3:21 AM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.



Gregg,



But, there's nothing in the proposed law that would encourage or require
such a network enablement. The only provisions that I see are ones that
require some change to a phone. In any case, I will not push it since I
know that there is a lot of work required to enable devices that just
"appear" on the network.



Still, I feel like something is missing. An enterprise could text-enable
those phones with multi-line displays, do nothing else, and claim
compliance. How would end users feel about that? It would be a worse
interface than what users have today with TTY devices. TTY devices at least
have a keyboard, but the proposed law will not require that a keyboard be
provided for any deaf user, will it?



Paul





From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Gregg
Vanderheiden
Sent: Monday, June 18, 2007 1:04 AM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.



Either would seem to be sufficient to meet this. as long as 'hooking up to
the network' would give the same privileges as using the phone.




Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.






_____


From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Paul E. Jones
Sent: Sunday, June 17, 2007 10:30 PM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.

Gregg,



What do you mean by "provide a way to connect a phone that does support text
in parallel"? Does this allow me to bring an IP text device into an office
and be able to use it for communication, or am I going to be forced to
interface my text device with a voice phone? I am not opposed if people
want to interconnect a text device with a phone, but I don't want to be
forced to do that when I have a perfectly good working portable device that
has text and voice capability, my address book, and settings that are
suitable for me. So, what's missing is the ability for me to interface in
some way to the network. Do we want to enable IP text devices to interact
with the system without a voice telephone?



Paul





From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Gregg
Vanderheiden
Sent: Wednesday, June 13, 2007 1:17 AM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.





Hi Paul,



Thanks.



Just so people aren't confused - let me state the current language in the
telecom proposal



The current language does no propose that all phones be made into text
phones.



Availability: What is proposed is

1) EITHER support real time text OR provide a way to connect a phone
that does support text in parallel. (This is basically the same as today
with TTY)

2) IF an IP PHONE *already* has a multi-line display - THEN display IP
text that you receive (this is software only)

3) IF an IP PHONE *already* has a keyboard or allows a keyboard
interface - THEN allow the phone to send IP text. (this is software only
again)



Reliability: That all telecom systems support some type of reliable IP text
format. (Standard within the system but different closed systems can use
different technologies)



Interoperability: That all systems and devices that connect to the public
phone system support the standard format for the system to ensure
interoperability.

- for PSTN that is TIA 825

- for IP SIP it would be RFC 4103 (though there is also a proposal
on the list so support BOTH RFC-4103 and RFC-4351)










Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.






_____


From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Paul E. Jones
Sent: Saturday, June 09, 2007 4:32 PM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.

Gregg,



I still do not think it is a good idea to require every phone to support
real-times text. Not every phone today supports text, while they certainly
could. Baudot is trivial, the it could be integrated into my wireless phone
very easily. But, that's not what I would want to use!



I think we need to "be careful what we ask for", otherwise what we might
have is a large number of inferior devices and then people asking, "what
more do you want?"" There might be a resistance to consider making other
options available.



Today, not every phone is accessible. But, what is accessible is the phone
network. A user can use his equipment (or provided equipment) and access
the PSTN to communicate with anybody in the world. They key is "network
access", not "phone access". If we wanted to mandate public phones have
integrated RFC 4103 capabilities, fine. Those are closed systems that might
offer no other interface. Or will they? It might be possible to use an
external text device that works wirelessly with the public phone as a
"natural extension" of the phone. (Never discount the possibility that
technology might evolve in the future into something quite different than
what we have today. I am working on just such a new kind of system.
Whether it sees the light of day is another matter, but we should at least
consider how technology is ever-changing and more sophisticated.)



What I would personally want to be able to use is a Pocket PC, Ultra Mobile
PC (UMPC) or other device with communication software installed. I would
like to have a means to access the network, such as via an Ethernet
connection or a wireless access point. (It's not too hard for me to imagine
that a business could establish a VLAN specifically for such purposes: I
have the equipment necessary to do that in my house, so it's not beyond
reach.)



So, I would encourage you to consider the network, not the phone, as the
focal point for accessibility. This will enable users to have a wider
variety of options, including portable PC devices, dedicated textphones,
PCs, or other devices.



Paul





From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Gregg
Vanderheiden
Sent: Friday, June 08, 2007 4:24 PM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.



TTY is critical on PSTN. It is the only thing that works there.



But it does not work well and is very limiting on IP. Like cellular
phones, (that also can't transport TTY tones natively without destroying
them, the strategy is to convert to a data format where there system
connects to the PSTN.



V.151 is a protocol designed to work between gateways. It is great there.







We need protocols between VoIP phones and between VoIP phones and gateways.




The best I can see is a hybrid approach.





1) Require that all VoIP phones, routers etc support both RFC-4103 and
and RFC-4351 - WHERE THEY CONNECT TO PUBLIC IP SIP SYSTEMS - OR CONNECT TO
OTHER SYSTEMS. (Internally within their own systems where they control
both ends and intermediate routers, they can use anything that meets the
reliability requirements ).

2) PSTN to IP Gateways would also support both but could give
preference to RFC-4351 (offer it first) so that they can save a port for
each call. (if everyone supports both as they should - then RFC-4351 would
work first time.

3) On non public systems (Skype, Vonnage, Corporations Internal
systems, etc) any text transport that meets the requirements is allowed as
long as it is translated into TTY at any PSTN interface and into RFC04103
and 4351 at any external IP SIP interface.





Would this hit the major issues?




Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.

From: Gunnar Hellström
Date: Wed, Jun 20 2007 10:05 PM
Subject: Re: real-time text

The existing IM services are just as available and good as before. No one
will block anyone from using them.

The goal is to have a proper real-time text medium that can be used in
telecommunications services on equal terms as the other real time
conversational media voice and video.

Why should text users be forced to wait for sentences to be completed when
voice users and sign users get a chance to keep synchronised in their minds
while the thoughts get expressed in spoken words or signing? It is logical
to provide all three media in all timing relations: Real time conversation
with all three media, Instant messaging with all three media, and email and
stored and retrieved conents in all three media.

This question was of course up for discussion also in the European TCAM eWGD
effort working on very similiar topics as Teitac-telecom. During that work,
we at Omnitor made a very brief comparison study with real users in an
intensive co-operation task over distance using modern real-time text versus
IM-style communication.
We tried it with hearing, deaf and hearing impaired users. There was a
preference towards using real-time text. There was no specific difference in
opinion between the different user groups. It was a very brief study that
can only be used as an indication.

There are a number of situations when it is especially valuable to have
real-time transmission of text.
-With text relay services
-With emergency services
-With IP captioned telephony
-In voice or video conferences with deaf or hard-of-hearing participants.
-In detailed explanations when you are in a hurry
-In communication with people who have a TTY. If they do not see text
flowing they think something is wrong and hang up.
But in fact good for all situations when you want to have an efficient
communication.

The IM style is from a time when bandwidth and computer power were scarse
resources. We live now in the real-time era. In IP multimedia, audio is
transmitted 50 times per second, video is transmitted 30 times per second,
so we can afford to transmit text three times per second, giving the users a
good user experience in all media.

Gunnar
-------------------------------------------------------------------
Gunnar Hellström
Omnitor
= EMAIL ADDRESS REMOVED =
Tel: +46708204288
www.omnitor.se

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Gregg
Vanderheiden
Sent: Wednesday, June 20, 2007 8:39 PM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] real-time text

What you would receive is exactly the same as what you receive on TTYs
today.

All corrections are in place. You can see people backspace - that is true.
But only if person sending wants to. That person has the option of holding
text back if they wish. It wouldn't be real-time text in that case. but
the requirement is only that devices be capable of real-time text. it does
not require people to use real-time text.

As Jim pointed out - they may wish to operate in IM mode, in message mode.
Or send email. Just as all of us with real-time voice also use all of
these other modes sometimes and want real-time communication at other times.



Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.



> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Tom Brett
> Sent: Wednesday, June 20, 2007 1:08 PM
> To: 'TEITAC Telecommunications Subcommittee'
> Subject: Re: [teitac-telecom] real-time text
>
> The t140 includes this option but I what I receive is
>
> Ga ood morning, I s am wrting writing you....
>
>
>
> Tom Brett
>
>
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Gregg
> Vanderheiden
> Sent: Wednesday, June 20, 2007 1:27 PM
> To: 'TEITAC Telecommunications Subcommittee'
> Subject: Re: [teitac-telecom] real-time text
>
> Hi Tom
>
> T140 includes backspaces so you still get a corrected message at the
> far end.
>
> And you can always have an option to hold back text if you
> wish. That is,
> a system with real-time text could ALSO have a mode that was message
> like.
>
>
> Gregg
> -- ------------------------------
> Gregg C Vanderheiden Ph.D.
>
>
> > -----Original Message-----
> > From: = EMAIL ADDRESS REMOVED =
> [mailto:teitac-telecom-
> > = EMAIL ADDRESS REMOVED = ] On Behalf Of Tom Brett
> > Sent: Wednesday, June 20, 2007 7:38 AM
> > To: 'TEITAC Telecommunications Subcommittee'
> > Subject: Re: [teitac-telecom] real-time text
> >
> > >> 1. Although the characters are to be transmitted
> quickly, there is
> > >> no
> > reference to how they are handled once they're transmitted.
> That is,
> > a server in the middle somewhere could add significant delays by
> > design or congestion. If we want to make text conversation
> real-time,
> > we have to make it clear what the permissible end-to-end delay is.
> >
> > >From my understanding of the real time text definition I
> thought that
> > >it
> > applied only to the device that was doing the output.
> There can be
> > significant delay in the receipt of the characters depending upon
> > receiving device or traffic on the transmission lines. The
> end to end
> > delay is, I think, beyond the control of the subcommittee
> because the
> > transmission is either via the internet or telephone lines.
> >
> > >>3. Most importantly, I don't understand why we would want
> to exclude
> > >>the
> > huge mainstream advantages of chat and IM. I have not
> heard anything
> > from the many deaf users of these systems that the "Enter"
> key imposes
> > a conversational barrier. Moreover, it is unlikely that mainstream
> > chat/IM program vendors will modify their programs to transmit
> > character by character. This leaves deaf and other users
> still in a
> > communication ghetto, instead of being able to use the same tools
> > everyone else is
> using.
> >
> > As a user of text communication tools that include chat/im I do not
> > find this to be a barrier. In many respects I find this to be
> > superior to character by character transmission....we all make
> > typos...imagine receiving a character by character message:
> >
> > "Gaood xxx good mraning, I qaxxx am wriging you today..."
> >
> > This becomes very confusing. I find it better to receive a
> complete
> > message with fewer typos that I can then decipher easier.
> >
> > Tom Brett
> >
> > -----Original Message-----
> > From: = EMAIL ADDRESS REMOVED =
> > [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Jim
> > Tobias
> > Sent: Wednesday, June 20, 2007 8:21 AM
> > To: 'TEITAC Telecommunications Subcommittee'
> > Subject: [teitac-telecom] real-time text
> >
> > Hi All,
> >
> > As drafted on our call monday, the definition of real-time text is:
> >
> > "Communications that employ the transmission of text wherein the
> > characters are transmitted by a terminal w/in a maximum of
> 1 sec. of
> > character input."
> >
> > I think there are a few problems here:
> >
> > 1. Although the characters are to be transmitted quickly,
> there is no
> > reference to how they are handled once they're transmitted.
> That is,
> > a server in the middle somewhere could add significant delays by
> > design or congestion. If we want to make text conversation
> real-time,
> > we have to make it clear what the permissable end-to-end delay is.
> >
> > 2. If the intention in this definition was to distinguish TTY-style
> > (characters are transmitted as soon as they are keyed in)
> from IM and
> chat,
> > where you type a bunch of characters and then press "Enter" to
> > transmit, we should say so explicitly, somewhere.
> >
> > 3. Most importantly, I don't understand why we would want
> to exclude
> > the huge mainstream advantages of chat and IM. I have not heard
> > anything from the many deaf users of these systems that the "Enter"
> > key imposes a conversational barrier. Moreover, it is
> unlikely that
> > mainstream chat/IM program vendors will modify their programs to
> > transmit character by character. This leaves deaf and other users
> > still in a communication ghetto, instead of being able to
> use the same
> > tools everyone else is
> using.
> >
> > ******
> > Jim Tobias
> > Inclusive Technologies
> > = EMAIL ADDRESS REMOVED =
> > +1 732.441.0831 voice/tty
> > skype jimtobias
> > +1 908.907.2387 mobile
> >
> >

From: Gunnar Hellström
Date: Wed, Jun 20 2007 10:35 PM
Subject: Re: real-time text

Tere was a formatting mistake in the list of situations in my posting. Here
it is again, corrected, Sorry about the repetition.
----------------------------------------------------------------------------
---------------------------------
The existing IM services are just as available and good as before. No one
will block anyone from using them.

The goal is to have a proper real-time text medium that can be used in
telecommunications services on equal terms as the other real time
conversational media voice and video.

Why should text users be forced to wait for sentences to be completed when
voice users and sign users get a chance to keep synchronised in their minds
while the thoughts get expressed in spoken words or signing? It is logical
to provide all three media in all timing relations: Real time conversation
with all three media, Instant messaging with all three media, and email and
stored and retrieved contents in all three media.

This question was of course up for discussion also in the European TCAM eWGD
effort working on very similiar topics as Teitac-telecom. During that work,
we at Omnitor made a very brief comparison study with real users in an
intensive co-operation task over distance using modern real-time text versus
IM-style communication.
We tried it with hearing, deaf and hearing impaired users. There was a
preference towards using real-time text. There was no specific difference in
opinion between the different user groups. It was a very brief study that
can only be used as an indication.

There are a number of situations when it is especially valuable to have
real-time transmission of text.
-With text relay services
-With emergency services
-With IP captioned telephony
-In voice or video conferences with deaf or hard-of-hearing participants.
-In detailed explanations when you are in a hurry.
-In communication with people who have a TTY. If they do not see text
flowing they think something is wrong and hang up.
But in fact good for all situations when you want to have an efficient
communication.

The IM style is from a time when bandwidth and computer power were scarse
resources. We live now in the real-time era. In IP multimedia, audio is
transmitted 50 times per second, video is transmitted 30 times per second,
so we can afford to transmit text three times per second, giving the users a
good user experience in all media.

Gunnar
-------------------------------------------------------------------
Gunnar Hellström
Omnitor
= EMAIL ADDRESS REMOVED =
Tel: +46708204288
www.omnitor.se

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Gregg
Vanderheiden
Sent: Wednesday, June 20, 2007 8:39 PM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] real-time text

What you would receive is exactly the same as what you receive on TTYs
today.

All corrections are in place. You can see people backspace - that is true.
But only if person sending wants to. That person has the option of holding
text back if they wish. It wouldn't be real-time text in that case. but
the requirement is only that devices be capable of real-time text. it does
not require people to use real-time text.

As Jim pointed out - they may wish to operate in IM mode, in message mode.
Or send email. Just as all of us with real-time voice also use all of
these other modes sometimes and want real-time communication at other times.



Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.



> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Tom Brett
> Sent: Wednesday, June 20, 2007 1:08 PM
> To: 'TEITAC Telecommunications Subcommittee'
> Subject: Re: [teitac-telecom] real-time text
>
> The t140 includes this option but I what I receive is
>
> Ga ood morning, I s am wrting writing you....
>
>
>
> Tom Brett
>
>
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Gregg
> Vanderheiden
> Sent: Wednesday, June 20, 2007 1:27 PM
> To: 'TEITAC Telecommunications Subcommittee'
> Subject: Re: [teitac-telecom] real-time text
>
> Hi Tom
>
> T140 includes backspaces so you still get a corrected message at the
> far end.
>
> And you can always have an option to hold back text if you
> wish. That is,
> a system with real-time text could ALSO have a mode that was message
> like.
>
>
> Gregg
> -- ------------------------------
> Gregg C Vanderheiden Ph.D.
>
>
> > -----Original Message-----
> > From: = EMAIL ADDRESS REMOVED =
> [mailto:teitac-telecom-
> > = EMAIL ADDRESS REMOVED = ] On Behalf Of Tom Brett
> > Sent: Wednesday, June 20, 2007 7:38 AM
> > To: 'TEITAC Telecommunications Subcommittee'
> > Subject: Re: [teitac-telecom] real-time text
> >
> > >> 1. Although the characters are to be transmitted
> quickly, there is
> > >> no
> > reference to how they are handled once they're transmitted.
> That is,
> > a server in the middle somewhere could add significant delays by
> > design or congestion. If we want to make text conversation
> real-time,
> > we have to make it clear what the permissible end-to-end delay is.
> >
> > >From my understanding of the real time text definition I
> thought that
> > >it
> > applied only to the device that was doing the output.
> There can be
> > significant delay in the receipt of the characters depending upon
> > receiving device or traffic on the transmission lines. The
> end to end
> > delay is, I think, beyond the control of the subcommittee
> because the
> > transmission is either via the internet or telephone lines.
> >
> > >>3. Most importantly, I don't understand why we would want
> to exclude
> > >>the
> > huge mainstream advantages of chat and IM. I have not
> heard anything
> > from the many deaf users of these systems that the "Enter"
> key imposes
> > a conversational barrier. Moreover, it is unlikely that mainstream
> > chat/IM program vendors will modify their programs to transmit
> > character by character. This leaves deaf and other users
> still in a
> > communication ghetto, instead of being able to use the same tools
> > everyone else is
> using.
> >
> > As a user of text communication tools that include chat/im I do not
> > find this to be a barrier. In many respects I find this to be
> > superior to character by character transmission....we all make
> > typos...imagine receiving a character by character message:
> >
> > "Gaood xxx good mraning, I qaxxx am wriging you today..."
> >
> > This becomes very confusing. I find it better to receive a
> complete
> > message with fewer typos that I can then decipher easier.
> >
> > Tom Brett
> >
> > -----Original Message-----
> > From: = EMAIL ADDRESS REMOVED =
> > [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Jim
> > Tobias
> > Sent: Wednesday, June 20, 2007 8:21 AM
> > To: 'TEITAC Telecommunications Subcommittee'
> > Subject: [teitac-telecom] real-time text
> >
> > Hi All,
> >
> > As drafted on our call monday, the definition of real-time text is:
> >
> > "Communications that employ the transmission of text wherein the
> > characters are transmitted by a terminal w/in a maximum of
> 1 sec. of
> > character input."
> >
> > I think there are a few problems here:
> >
> > 1. Although the characters are to be transmitted quickly,
> there is no
> > reference to how they are handled once they're transmitted.
> That is,
> > a server in the middle somewhere could add significant delays by
> > design or congestion. If we want to make text conversation
> real-time,
> > we have to make it clear what the permissable end-to-end delay is.
> >
> > 2. If the intention in this definition was to distinguish TTY-style
> > (characters are transmitted as soon as they are keyed in)
> from IM and
> chat,
> > where you type a bunch of characters and then press "Enter" to
> > transmit, we should say so explicitly, somewhere.
> >
> > 3. Most importantly, I don't understand why we would want
> to exclude
> > the huge mainstream advantages of chat and IM. I have not heard
> > anything from the many deaf users of these systems that the "Enter"
> > key imposes a conversational barrier. Moreover, it is
> unlikely that
> > mainstream chat/IM program vendors will modify their programs to
> > transmit character by character. This leaves deaf and other users
> > still in a communication ghetto, instead of being able to
> use the same
> > tools everyone else is
> using.
> >
> > ******
> > Jim Tobias
> > Inclusive Technologies
> > = EMAIL ADDRESS REMOVED =
> > +1 732.441.0831 voice/tty
> > skype jimtobias
> > +1 908.907.2387 mobile
> >
> >

From: Paul E. Jones
Date: Wed, Jun 20 2007 11:15 PM
Subject: Re: RFC 4103 reference for real-time text.

Gregg,



See below.



Interfacing an IP text device to a phone certainly needs careful study.
But, we can't require it if we don't have a standard for it, which seems to
be what we're doing here.



Regarding breaking what we have: we must be sure that TTYs that are in the
market still work. We don't want to see those suddenly stop working, which
is a danger. We should also try to interconnect the old TTYs with the
"radically new" (i.e., RFC 4103) devices.



Emphasis on phone:







From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Gregg
Vanderheiden
Sent: Wednesday, June 20, 2007 6:55 PM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.



COMMENTS IN CONTEXT BELOW




Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.

_____

From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Paul E. Jones
Sent: Tuesday, June 19, 2007 1:18 AM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.



Gregg,



Possibly-as long as (2) does not mandate interfacing some text-capable
"add-on" device to an IP phone using some undefined interface. I can't see
a sustainable market for such a device for many reasons.



Still, I can't walk into a facility and use my own text phone, which is
something I'd love to the privilege to be able to do.



GV: if you want to use yours - wouldn't you need some standard way to
connect it? We don't have that now. We are ambiguous about it. But you
are right - we should look at that.

PJ: Interfacing an IP text device to a phone certainly needs careful study.
We can do this well or we can create a mess. ;-)





In my view, the most important thing is to not break what we have today and
then to also introduce radically new technologies.

GV: Not sure what you mean here. Can you elaborate on what you don't want
to break? Also - what is the radically new technology you are referring
to?

PJ: We must ensure that TTY devices in the field work and continue to work
without disruption while we introduce RFC 4103-type devices, IM clients, or
other technologies in parallel. Bridging these still needs discussion, it
seems. There are a number of different tools in use today and will that
change? Do we expect RFC 4103 to be the common protocol and, if so, how do
we bridge that with TTYs?



Based on what I've been told, this is what people want. So, to that end, I
still get the feeling that there's too much emphasis on a voice phone. Do
users care?

GV: Don't understand. I use mine all the time. As does everyone I know
of that can talk. Some have lost their hearing or hear so poorly that they
no longer can - but give them the ability to again and they will be back on
it. And I don't want to lose the ability to talk to people when my
hearing goes.

PJ: If you are completely deaf, do you want a voice phone or to be required
to interface with one? I would not. What I do want is the ability to use
some kind of communication device that isn't a "phone", but still allows me
to reach the world.



Do users really want to have text display on any phone? Would they use it?

GV: The text displays are already appearing on the phones. Do you mean
who would like to be able to use the phones they find around them as they
lose their hearing?

PJ: Having text display on a phone is nice to have, but not sufficient for
deaf users. My concern is that this will be the interface provided to a
deaf employee and they're given nothing else.





Would they prefer to have alternative capabilities (e.g., soft phones,
etc)?

GV: I don't think a soft phone will work with my mom.

I think the large number of regular phones that are sold - speaks to their
prevelance over softphones. Even Skype makes them.

PJ: Understood, but it would work for me. Presently, support for this is
not mandated by my service provider or my employer. What would I be
provided? A voice phone with a small display? Or, perhaps a similar device
with a screen and, if I'm lucky, a keyboard? Since I started working in
this area, I've heard one thing said repeatedly: users want a choice of
devices and do not want to be constrained to the horrible TTY devices
produced in the past. TTY is great when you have nothing else, but a good
PC application could be far better. The reason I focus on PC applications
here is that, more likely than not, that's what I would use. The cost to
make a PC is not so expensive, considering the relative cost of a good
quality (yet unacceptable) TTY device.



-



My point is that manufacturers, enterprise IT staff, and carriers have
limited bandwidth to implement, test, and support various options. We ought
to only mandate those things users demand and it surprises me that users
would demand the ability to see text on any phone (even when there is no
keyboard), when new kinds of text devices would likely be a significantly
higher priority.

GV: the reasons for wanting to use any phone rather than have to carry
your own with you are many and varied.

- I don't have it with me and I need to call my wife (I talk so I have no
use for a keyboard)

- I am in a place where my cell doesn't work and they don't allow me to
connect foreign phones to their network.

- I am older and can't afford monthly payments for a cell phone or text
service. I just use the phone that is here for everyone.

- I am older and don't understand computers. I just want to call my kids
and be able to see what they are saying.

- If I use my phone I pay for the call - If I use the office phone (at home
office or any office I am in) they pay for it

- My phone doesn't support conf calling - the office one does

- I don't use a computer except when at my desk ( I don't carry one with
me) so softphone won't help

- I use services that charge the phone calling. Don't want those bills
myself.

PJ: For nearly all of those reasons, a standard phone with a keyboard and
limited display would be horrible to use for a deaf person. Granted, it's
better than nothing, but I liken it to being forced to picking food out of a
trash can when your homeless: you'll take what you can get. My concern is
that this less-than-acceptable interface could become the only requirement
and users device choices reduced.



Basically, all the reasons that everyone likes to use regular phones - and
the reason there are more regular phones than softphones - and usually a
regular phone sitting on the desk next to every soft phone.



For people who cannot speak and need to use a keyboard - I understand your
approach. But the for larger number who can speak - but can't hear well
enough they would like to be able to see what they other people are saying
but be able to speak back.



And if the phone already has a display on it - why would you not display
the text coming in as captions or as supplement? Not sure I follow.

None of the provisions talk about requiring a display. Just allowing text
to display if it is there.

PJ: It's a matter of balancing requirements against resources. If we were
to go to any service provider in the US and demand that they do any one of 5
things, they will take the easiest solution possible. In this case, a phone
with no keyboard and a screen. Do we then demand that we require support
for that and a different kind of device that is more functional? Do we then
demand those two things and the ability to enable any kind of text-capable
communication tool (like a soft phone running on my Ultra Mobile PC)?
Somewhere, the line has to be drawn, because they cannot be expected to do
everything. Deploying, managing, testing, and supporting service can be
complicated. For this reason, service providers are quick to say that
devices are not supported-I got that "reminder" from Cingular when I called
them today while not using a phone not sold by them.



Remember there are many people who do not have the money to afford the
special text communication devices and who also don't have computers. For
government employees at their desks - cost is not a factor. But for phones
in public places, in VA and other government - non-work locations, and
people away from their desks who don't want to use their own phones (because
it would run up charges nationally or internationally) - this is important.

PJ: I understand. Public phones are largely disappearing it seems.
Companies could provide a more accessible device in lobbies or users desks
(i.e., a computer or more fully-functional text device), service providers
could be required to support soft phone products (perhaps interworking
issues on the shoulders of manufacturers), and public network access points
could be mandated for roaming users who would carry their communication
devices with them. So, I'm all for providing a means of gaining access, but
I think we need to raise the bar over "text on a phone". I personally do
not care if I cannot use every phone. Today, I cannot user every computer,
either, and I don't feel disadvantaged when I go into the office. There are
guest computers and, luckily, a network point of attachment so I can use
mine. I'm just afraid that by putting emphasis on "put text on every phone"
then we're going to miss the opportunity to make the workplace and public
places accessible in the best possible way.





And remembering that we are harmonizing with 255 as well - so it isn't just
government.



So lots of reasons for allowing text to appear on phones (that already have
a display) so that the phones are usable without having to buy an extra
device when not needed.

PJ: So, what would my service provider or employer be required to provide
me? A simple phone that displays text and has 12 keys?



Paul





Thanks



Gregg





Paul





From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Gregg
Vanderheiden
Sent: Tuesday, June 19, 2007 1:32 AM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.



You concern is a good one.



I thought it was captured though by provision #2 in this text.





(a) Telecommunications terminals and other terminals capable of providing
real-time voice communications which do not themselves provide TTY or other
real-time text conversation functionality shall comply with the following:

1. All analog and TDM-digital wired terminals shall support the
connection of a TTY in the same location and with the permissions for use as
the telephone. This shall be accomplished by providing an RJ-11 jack on the
telephone, or, in the case of an analog telephone, by the use of a Y-adapter
that allows both the analog telephone and the TTY to be plugged into the
same line outlet, or have built in capability to support an RJ11 module that
can provide a connection point for TTYs;
2. Other types of terminals covered by this section shall support the
connection of real-time text capable devices in conjunction with the voice
call capability in the same location and the same permissions for use as the
terminal.
3. Shall be capable of allowing simultaneous speech and text
conversation without interference or its microphone shall be capable of
being turned on and off to allow the user to intermix speech with text use.






Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.

_____

From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Paul E. Jones
Sent: Monday, June 18, 2007 3:21 AM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.



Gregg,



But, there's nothing in the proposed law that would encourage or require
such a network enablement. The only provisions that I see are ones that
require some change to a phone. In any case, I will not push it since I
know that there is a lot of work required to enable devices that just
"appear" on the network.



Still, I feel like something is missing. An enterprise could text-enable
those phones with multi-line displays, do nothing else, and claim
compliance. How would end users feel about that? It would be a worse
interface than what users have today with TTY devices. TTY devices at least
have a keyboard, but the proposed law will not require that a keyboard be
provided for any deaf user, will it?



Paul





From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Gregg
Vanderheiden
Sent: Monday, June 18, 2007 1:04 AM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.



Either would seem to be sufficient to meet this. as long as 'hooking up to
the network' would give the same privileges as using the phone.




Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.






_____


From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Paul E. Jones
Sent: Sunday, June 17, 2007 10:30 PM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.

Gregg,



What do you mean by "provide a way to connect a phone that does support text
in parallel"? Does this allow me to bring an IP text device into an office
and be able to use it for communication, or am I going to be forced to
interface my text device with a voice phone? I am not opposed if people
want to interconnect a text device with a phone, but I don't want to be
forced to do that when I have a perfectly good working portable device that
has text and voice capability, my address book, and settings that are
suitable for me. So, what's missing is the ability for me to interface in
some way to the network. Do we want to enable IP text devices to interact
with the system without a voice telephone?



Paul





From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Gregg
Vanderheiden
Sent: Wednesday, June 13, 2007 1:17 AM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.





Hi Paul,



Thanks.



Just so people aren't confused - let me state the current language in the
telecom proposal



The current language does no propose that all phones be made into text
phones.



Availability: What is proposed is

1) EITHER support real time text OR provide a way to connect a phone
that does support text in parallel. (This is basically the same as today
with TTY)

2) IF an IP PHONE *already* has a multi-line display - THEN display IP
text that you receive (this is software only)

3) IF an IP PHONE *already* has a keyboard or allows a keyboard
interface - THEN allow the phone to send IP text. (this is software only
again)



Reliability: That all telecom systems support some type of reliable IP text
format. (Standard within the system but different closed systems can use
different technologies)



Interoperability: That all systems and devices that connect to the public
phone system support the standard format for the system to ensure
interoperability.

- for PSTN that is TIA 825

- for IP SIP it would be RFC 4103 (though there is also a proposal
on the list so support BOTH RFC-4103 and RFC-4351)










Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.






_____


From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Paul E. Jones
Sent: Saturday, June 09, 2007 4:32 PM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.

Gregg,



I still do not think it is a good idea to require every phone to support
real-times text. Not every phone today supports text, while they certainly
could. Baudot is trivial, the it could be integrated into my wireless phone
very easily. But, that's not what I would want to use!



I think we need to "be careful what we ask for", otherwise what we might
have is a large number of inferior devices and then people asking, "what
more do you want?"" There might be a resistance to consider making other
options available.



Today, not every phone is accessible. But, what is accessible is the phone
network. A user can use his equipment (or provided equipment) and access
the PSTN to communicate with anybody in the world. They key is "network
access", not "phone access". If we wanted to mandate public phones have
integrated RFC 4103 capabilities, fine. Those are closed systems that might
offer no other interface. Or will they? It might be possible to use an
external text device that works wirelessly with the public phone as a
"natural extension" of the phone. (Never discount the possibility that
technology might evolve in the future into something quite different than
what we have today. I am working on just such a new kind of system.
Whether it sees the light of day is another matter, but we should at least
consider how technology is ever-changing and more sophisticated.)



What I would personally want to be able to use is a Pocket PC, Ultra Mobile
PC (UMPC) or other device with communication software installed. I would
like to have a means to access the network, such as via an Ethernet
connection or a wireless access point. (It's not too hard for me to imagine
that a business could establish a VLAN specifically for such purposes: I
have the equipment necessary to do that in my house, so it's not beyond
reach.)



So, I would encourage you to consider the network, not the phone, as the
focal point for accessibility. This will enable users to have a wider
variety of options, including portable PC devices, dedicated textphones,
PCs, or other devices.



Paul





From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Gregg
Vanderheiden
Sent: Friday, June 08, 2007 4:24 PM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] RFC 4103 reference for real-time text.



TTY is critical on PSTN. It is the only thing that works there.



But it does not work well and is very limiting on IP. Like cellular
phones, (that also can't transport TTY tones natively without destroying
them, the strategy is to convert to a data format where there system
connects to the PSTN.



V.151 is a protocol designed to work between gateways. It is great there.







We need protocols between VoIP phones and between VoIP phones and gateways.




The best I can see is a hybrid approach.





1) Require that all VoIP phones, routers etc support both RFC-4103 and
and RFC-4351 - WHERE THEY CONNECT TO PUBLIC IP SIP SYSTEMS - OR CONNECT TO
OTHER SYSTEMS. (Internally within their own systems where they control
both ends and intermediate routers, they can use anything that meets the
reliability requirements ).

2) PSTN to IP Gateways would also support both but could give
preference to RFC-4351 (offer it first) so that they can save a port for
each call. (if everyone supports both as they should - then RFC-4351 would
work first time.

3) On non public systems (Skype, Vonnage, Corporations Internal
systems, etc) any text transport that meets the requirements is allowed as
long as it is translated into TTY at any PSTN interface and into RFC04103
and 4351 at any external IP SIP interface.





Would this hit the major issues?




Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.

From: Jim Tobias
Date: Thu, Jun 21 2007 7:45 AM
Subject: Re: real-time text

The problem is using the phrase "real-time text" to mean only character by
character. Line-by-line is also real-time, and both are distinct from store
and forward technologies like email and SMS. That's the important
distinction: whether the end-to-end system is making a good faith effort to
send text as it is received, or whether the system assumes that the text
will remain in a server until retrieved somehow by the recipient. The
latter is not a conversation. The goal is to require a capability for text
conversation, not require how many characters are processed at a time.

******
Jim Tobias
Inclusive Technologies
= EMAIL ADDRESS REMOVED =
+1 732.441.0831 voice/tty
skype jimtobias
+1 908.907.2387 mobile

> -----Original Message-----
> From: Gregg Vanderheiden [mailto: = EMAIL ADDRESS REMOVED = ]
> Sent: Wednesday, June 20, 2007 2:39 PM
> To: 'TEITAC Telecommunications Subcommittee'
> Subject: Re: [teitac-telecom] real-time text
>
> What you would receive is exactly the same as what you
> receive on TTYs today.
>
> All corrections are in place. You can see people backspace
> - that is true.
> But only if person sending wants to. That person has the
> option of holding
> text back if they wish. It wouldn't be real-time text in
> that case. but
> the requirement is only that devices be capable of real-time
> text. it does not require people to use real-time text.
>
> As Jim pointed out - they may wish to operate in IM mode, in
> message mode.
> Or send email. Just as all of us with real-time voice also
> use all of
> these other modes sometimes and want real-time communication
> at other times.
>
>
>
> Gregg
> -- ------------------------------
> Gregg C Vanderheiden Ph.D.
>
>
>
> > -----Original Message-----
> > From: = EMAIL ADDRESS REMOVED =
> > [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of Tom Brett
> > Sent: Wednesday, June 20, 2007 1:08 PM
> > To: 'TEITAC Telecommunications Subcommittee'
> > Subject: Re: [teitac-telecom] real-time text
> >
> > The t140 includes this option but I what I receive is
> >
> > Ga ood morning, I s am wrting writing you....
> >
> >
> >
> > Tom Brett
> >
> >
> > -----Original Message-----
> > From: = EMAIL ADDRESS REMOVED =
> > [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Gregg
> > Vanderheiden
> > Sent: Wednesday, June 20, 2007 1:27 PM
> > To: 'TEITAC Telecommunications Subcommittee'
> > Subject: Re: [teitac-telecom] real-time text
> >
> > Hi Tom
> >
> > T140 includes backspaces so you still get a corrected
> message at the
> > far end.
> >
> > And you can always have an option to hold back text if you
> > wish. That is,
> > a system with real-time text could ALSO have a mode that
> was message
> > like.
> >
> >
> > Gregg
> > -- ------------------------------
> > Gregg C Vanderheiden Ph.D.
> >
> >
> > > -----Original Message-----
> > > From: = EMAIL ADDRESS REMOVED =
> > [mailto:teitac-telecom-
> > > = EMAIL ADDRESS REMOVED = ] On Behalf Of Tom Brett
> > > Sent: Wednesday, June 20, 2007 7:38 AM
> > > To: 'TEITAC Telecommunications Subcommittee'
> > > Subject: Re: [teitac-telecom] real-time text
> > >
> > > >> 1. Although the characters are to be transmitted
> > quickly, there is
> > > >> no
> > > reference to how they are handled once they're transmitted.
> > That is,
> > > a server in the middle somewhere could add significant delays by
> > > design or congestion. If we want to make text conversation
> > real-time,
> > > we have to make it clear what the permissible end-to-end delay is.
> > >
> > > >From my understanding of the real time text definition I
> > thought that
> > > >it
> > > applied only to the device that was doing the output.
> > There can be
> > > significant delay in the receipt of the characters depending upon
> > > receiving device or traffic on the transmission lines. The
> > end to end
> > > delay is, I think, beyond the control of the subcommittee
> > because the
> > > transmission is either via the internet or telephone lines.
> > >
> > > >>3. Most importantly, I don't understand why we would want
> > to exclude
> > > >>the
> > > huge mainstream advantages of chat and IM. I have not
> > heard anything
> > > from the many deaf users of these systems that the "Enter"
> > key imposes
> > > a conversational barrier. Moreover, it is unlikely that
> mainstream
> > > chat/IM program vendors will modify their programs to transmit
> > > character by character. This leaves deaf and other users
> > still in a
> > > communication ghetto, instead of being able to use the same tools
> > > everyone else is
> > using.
> > >
> > > As a user of text communication tools that include
> chat/im I do not
> > > find this to be a barrier. In many respects I find this to be
> > > superior to character by character transmission....we all make
> > > typos...imagine receiving a character by character message:
> > >
> > > "Gaood xxx good mraning, I qaxxx am wriging you today..."
> > >
> > > This becomes very confusing. I find it better to receive a
> > complete
> > > message with fewer typos that I can then decipher easier.
> > >
> > > Tom Brett
> > >
> > > -----Original Message-----
> > > From: = EMAIL ADDRESS REMOVED =
> > > [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Jim
> > > Tobias
> > > Sent: Wednesday, June 20, 2007 8:21 AM
> > > To: 'TEITAC Telecommunications Subcommittee'
> > > Subject: [teitac-telecom] real-time text
> > >
> > > Hi All,
> > >
> > > As drafted on our call monday, the definition of
> real-time text is:
> > >
> > > "Communications that employ the transmission of text wherein the
> > > characters are transmitted by a terminal w/in a maximum of
> > 1 sec. of
> > > character input."
> > >
> > > I think there are a few problems here:
> > >
> > > 1. Although the characters are to be transmitted quickly,
> > there is no
> > > reference to how they are handled once they're transmitted.
> > That is,
> > > a server in the middle somewhere could add significant delays by
> > > design or congestion. If we want to make text conversation
> > real-time,
> > > we have to make it clear what the permissable end-to-end delay is.
> > >
> > > 2. If the intention in this definition was to distinguish
> TTY-style
> > > (characters are transmitted as soon as they are keyed in)
> > from IM and
> > chat,
> > > where you type a bunch of characters and then press "Enter" to
> > > transmit, we should say so explicitly, somewhere.
> > >
> > > 3. Most importantly, I don't understand why we would want
> > to exclude
> > > the huge mainstream advantages of chat and IM. I have not heard
> > > anything from the many deaf users of these systems that
> the "Enter"
> > > key imposes a conversational barrier. Moreover, it is
> > unlikely that
> > > mainstream chat/IM program vendors will modify their programs to
> > > transmit character by character. This leaves deaf and
> other users
> > > still in a communication ghetto, instead of being able to
> > use the same
> > > tools everyone else is
> > using.
> > >
> > > ******
> > > Jim Tobias
> > > Inclusive Technologies
> > > = EMAIL ADDRESS REMOVED =
> > > +1 732.441.0831 voice/tty
> > > skype jimtobias
> > > +1 908.907.2387 mobile
> > >
> > >

From: Gunnar Hellström
Date: Thu, Jun 21 2007 8:45 AM
Subject: Re: real-time text

The goal is to get a good conversational flow without stressfull waiting.
Stressful and confusion-creating waitng appears if you do not send regularly
with a good conversational flow.

Regularly means originally not more than a half second between
transmissions, but in our discussion here it is stretched to one second,
that takes us into the border area of risk for conversational collissions.

Line-by-line is not good conversational flow, even if the line is
transmitted rapidly once sent.
Have you not noticed how you get a desire to shorten off sentences in IM, so
that you keep the other party informed on your thoughts. That forces change
in behaviour for you that is not needed if text was sent regularly without
any specific action from you.

Gunnar
-------------------------------------------------------------------
Gunnar Hellström
Omnitor
= EMAIL ADDRESS REMOVED =
Tel: +46708204288
www.omnitor.se

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Jim Tobias
Sent: Thursday, June 21, 2007 3:40 PM
To: 'TEITAC Telecommunications Subcommittee'
Subject: Re: [teitac-telecom] real-time text

The problem is using the phrase "real-time text" to mean only character by
character. Line-by-line is also real-time, and both are distinct from store
and forward technologies like email and SMS. That's the important
distinction: whether the end-to-end system is making a good faith effort to
send text as it is received, or whether the system assumes that the text
will remain in a server until retrieved somehow by the recipient. The
latter is not a conversation. The goal is to require a capability for text
conversation, not require how many characters are processed at a time.

******
Jim Tobias
Inclusive Technologies
= EMAIL ADDRESS REMOVED =
+1 732.441.0831 voice/tty
skype jimtobias
+1 908.907.2387 mobile

> -----Original Message-----
> From: Gregg Vanderheiden [mailto: = EMAIL ADDRESS REMOVED = ]
> Sent: Wednesday, June 20, 2007 2:39 PM
> To: 'TEITAC Telecommunications Subcommittee'
> Subject: Re: [teitac-telecom] real-time text
>
> What you would receive is exactly the same as what you receive on TTYs
> today.
>
> All corrections are in place. You can see people backspace
> - that is true.
> But only if person sending wants to. That person has the option of
> holding text back if they wish. It wouldn't be real-time text in
> that case. but
> the requirement is only that devices be capable of real-time text. it
> does not require people to use real-time text.
>
> As Jim pointed out - they may wish to operate in IM mode, in message
> mode.
> Or send email. Just as all of us with real-time voice also
> use all of
> these other modes sometimes and want real-time communication at other
> times.
>
>
>
> Gregg
> -- ------------------------------
> Gregg C Vanderheiden Ph.D.
>
>
>
> > -----Original Message-----
> > From: = EMAIL ADDRESS REMOVED =
> > [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of Tom Brett
> > Sent: Wednesday, June 20, 2007 1:08 PM
> > To: 'TEITAC Telecommunications Subcommittee'
> > Subject: Re: [teitac-telecom] real-time text
> >
> > The t140 includes this option but I what I receive is
> >
> > Ga ood morning, I s am wrting writing you....
> >
> >
> >
> > Tom Brett
> >
> >
> > -----Original Message-----
> > From: = EMAIL ADDRESS REMOVED =
> > [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Gregg
> > Vanderheiden
> > Sent: Wednesday, June 20, 2007 1:27 PM
> > To: 'TEITAC Telecommunications Subcommittee'
> > Subject: Re: [teitac-telecom] real-time text
> >
> > Hi Tom
> >
> > T140 includes backspaces so you still get a corrected
> message at the
> > far end.
> >
> > And you can always have an option to hold back text if you
> > wish. That is,
> > a system with real-time text could ALSO have a mode that
> was message
> > like.
> >
> >
> > Gregg
> > -- ------------------------------
> > Gregg C Vanderheiden Ph.D.
> >
> >
> > > -----Original Message-----
> > > From: = EMAIL ADDRESS REMOVED =
> > [mailto:teitac-telecom-
> > > = EMAIL ADDRESS REMOVED = ] On Behalf Of Tom Brett
> > > Sent: Wednesday, June 20, 2007 7:38 AM
> > > To: 'TEITAC Telecommunications Subcommittee'
> > > Subject: Re: [teitac-telecom] real-time text
> > >
> > > >> 1. Although the characters are to be transmitted
> > quickly, there is
> > > >> no
> > > reference to how they are handled once they're transmitted.
> > That is,
> > > a server in the middle somewhere could add significant delays by
> > > design or congestion. If we want to make text conversation
> > real-time,
> > > we have to make it clear what the permissible end-to-end delay is.
> > >
> > > >From my understanding of the real time text definition I
> > thought that
> > > >it
> > > applied only to the device that was doing the output.
> > There can be
> > > significant delay in the receipt of the characters depending upon
> > > receiving device or traffic on the transmission lines. The
> > end to end
> > > delay is, I think, beyond the control of the subcommittee
> > because the
> > > transmission is either via the internet or telephone lines.
> > >
> > > >>3. Most importantly, I don't understand why we would want
> > to exclude
> > > >>the
> > > huge mainstream advantages of chat and IM. I have not
> > heard anything
> > > from the many deaf users of these systems that the "Enter"
> > key imposes
> > > a conversational barrier. Moreover, it is unlikely that
> mainstream
> > > chat/IM program vendors will modify their programs to transmit
> > > character by character. This leaves deaf and other users
> > still in a
> > > communication ghetto, instead of being able to use the same tools
> > > everyone else is
> > using.
> > >
> > > As a user of text communication tools that include
> chat/im I do not
> > > find this to be a barrier. In many respects I find this to be
> > > superior to character by character transmission....we all make
> > > typos...imagine receiving a character by character message:
> > >
> > > "Gaood xxx good mraning, I qaxxx am wriging you today..."
> > >
> > > This becomes very confusing. I find it better to receive a
> > complete
> > > message with fewer typos that I can then decipher easier.
> > >
> > > Tom Brett
> > >
> > > -----Original Message-----
> > > From: = EMAIL ADDRESS REMOVED =
> > > [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Jim
> > > Tobias
> > > Sent: Wednesday, June 20, 2007 8:21 AM
> > > To: 'TEITAC Telecommunications Subcommittee'
> > > Subject: [teitac-telecom] real-time text
> > >
> > > Hi All,
> > >
> > > As drafted on our call monday, the definition of
> real-time text is:
> > >
> > > "Communications that employ the transmission of text wherein the
> > > characters are transmitted by a terminal w/in a maximum of
> > 1 sec. of
> > > character input."
> > >
> > > I think there are a few problems here:
> > >
> > > 1. Although the characters are to be transmitted quickly,
> > there is no
> > > reference to how they are handled once they're transmitted.
> > That is,
> > > a server in the middle somewhere could add significant delays by
> > > design or congestion. If we want to make text conversation
> > real-time,
> > > we have to make it clear what the permissable end-to-end delay is.
> > >
> > > 2. If the intention in this definition was to distinguish
> TTY-style
> > > (characters are transmitted as soon as they are keyed in)
> > from IM and
> > chat,
> > > where you type a bunch of characters and then press "Enter" to
> > > transmit, we should say so explicitly, somewhere.
> > >
> > > 3. Most importantly, I don't understand why we would want
> > to exclude
> > > the huge mainstream advantages of chat and IM. I have not heard
> > > anything from the many deaf users of these systems that
> the "Enter"
> > > key imposes a conversational barrier. Moreover, it is
> > unlikely that
> > > mainstream chat/IM program vendors will modify their programs to
> > > transmit character by character. This leaves deaf and
> other users
> > > still in a communication ghetto, instead of being able to
> > use the same
> > > tools everyone else is
> > using.
> > >
> > > ******
> > > Jim Tobias
> > > Inclusive Technologies
> > > = EMAIL ADDRESS REMOVED =
> > > +1 732.441.0831 voice/tty
> > > skype jimtobias
> > > +1 908.907.2387 mobile
> > >
> > >

From: Gregg Vanderheiden
Date: Thu, Jun 21 2007 1:00 PM
Subject: Re: real-time text

Line by line isn't real-time. Some people contend that it is but it is
near-real-time or pseudo real time at best.

Most IM for example does flow through a server and is stored and forwarded.
Did you ever notice that sometimes the message doesn't appear right away? I
was on Skype call just last week and it took 9 minutes for a message I sent
to someone when I was talking to them - to arrive (and for theirs to get
back to me). They did arrive but only later. Usually (but not always) it
isn't stored for more than a moment.

The fact that IM is stored on servers was also a surprise and embarrassment
to a certain senator who found all his IM on a server backup.

Real-time text by comparison is point to point and happens in real time as
it is generated. It is not a message (as IM is) and it is not stored
somewhere.

People do say that they converse by email, and by SMS and by IM. I even
have heard people talk about conversing by mail. So the word 'converse' is
quite loosely used.

The goal is to allow real-time conversation where the person can track what
you are saying it as you are saying it.

Do demonstrate the difference I think we should create a demo where you talk
back and forth but the person cannot begin to hear what you say until you
are done saying it. (Push to record and it gets sent when you get to the end
of what you are saying). It is faster than typing but you will quickly see
how much slower it is and how it breaks communication conventions.

To try this for yourself - try saying everything to yourself silently
before you say it aloud on a phone call. Do it for a day. It is MUCH
better than not being able to talk but - not the same as talking in
real-time.



Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.



> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
> Jim Tobias
> Sent: Thursday, June 21, 2007 8:40 AM
> To: 'TEITAC Telecommunications Subcommittee'
> Subject: Re: [teitac-telecom] real-time text
>
> The problem is using the phrase "real-time text" to mean only
> character by character. Line-by-line is also real-time, and
> both are distinct from store and forward technologies like
> email and SMS. That's the important
> distinction: whether the end-to-end system is making a good
> faith effort to send text as it is received, or whether the
> system assumes that the text will remain in a server until
> retrieved somehow by the recipient. The latter is not a
> conversation. The goal is to require a capability for text
> conversation, not require how many characters are processed at a time.
>
> ******
> Jim Tobias
> Inclusive Technologies
> = EMAIL ADDRESS REMOVED =
> +1 732.441.0831 voice/tty
> skype jimtobias
> +1 908.907.2387 mobile
>
> > -----Original Message-----
> > From: Gregg Vanderheiden [mailto: = EMAIL ADDRESS REMOVED = ]
> > Sent: Wednesday, June 20, 2007 2:39 PM
> > To: 'TEITAC Telecommunications Subcommittee'
> > Subject: Re: [teitac-telecom] real-time text
> >
> > What you would receive is exactly the same as what you
> receive on TTYs
> > today.
> >
> > All corrections are in place. You can see people backspace
> > - that is true.
> > But only if person sending wants to. That person has the option of
> > holding text back if they wish. It wouldn't be real-time text in
> > that case. but
> > the requirement is only that devices be capable of
> real-time text. it
> > does not require people to use real-time text.
> >
> > As Jim pointed out - they may wish to operate in IM mode,
> in message
> > mode.
> > Or send email. Just as all of us with real-time voice also
> > use all of
> > these other modes sometimes and want real-time
> communication at other
> > times.
> >
> >
> >
> > Gregg
> > -- ------------------------------
> > Gregg C Vanderheiden Ph.D.
> >
> >
> >
> > > -----Original Message-----
> > > From: = EMAIL ADDRESS REMOVED =
> > > [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> > Of Tom Brett
> > > Sent: Wednesday, June 20, 2007 1:08 PM
> > > To: 'TEITAC Telecommunications Subcommittee'
> > > Subject: Re: [teitac-telecom] real-time text
> > >
> > > The t140 includes this option but I what I receive is
> > >
> > > Ga ood morning, I s am wrting writing you....
> > >
> > >
> > >
> > > Tom Brett
> > >
> > >
> > > -----Original Message-----
> > > From: = EMAIL ADDRESS REMOVED =
> > > [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of Gregg
> > > Vanderheiden
> > > Sent: Wednesday, June 20, 2007 1:27 PM
> > > To: 'TEITAC Telecommunications Subcommittee'
> > > Subject: Re: [teitac-telecom] real-time text
> > >
> > > Hi Tom
> > >
> > > T140 includes backspaces so you still get a corrected
> > message at the
> > > far end.
> > >
> > > And you can always have an option to hold back text if you
> > > wish. That is,
> > > a system with real-time text could ALSO have a mode that
> > was message
> > > like.
> > >
> > >
> > > Gregg
> > > -- ------------------------------
> > > Gregg C Vanderheiden Ph.D.
> > >
> > >
> > > > -----Original Message-----
> > > > From: = EMAIL ADDRESS REMOVED =
> > > [mailto:teitac-telecom-
> > > > = EMAIL ADDRESS REMOVED = ] On Behalf Of Tom Brett
> > > > Sent: Wednesday, June 20, 2007 7:38 AM
> > > > To: 'TEITAC Telecommunications Subcommittee'
> > > > Subject: Re: [teitac-telecom] real-time text
> > > >
> > > > >> 1. Although the characters are to be transmitted
> > > quickly, there is
> > > > >> no
> > > > reference to how they are handled once they're transmitted.
> > > That is,
> > > > a server in the middle somewhere could add significant
> delays by
> > > > design or congestion. If we want to make text conversation
> > > real-time,
> > > > we have to make it clear what the permissible
> end-to-end delay is.
> > > >
> > > > >From my understanding of the real time text definition I
> > > thought that
> > > > >it
> > > > applied only to the device that was doing the output.
> > > There can be
> > > > significant delay in the receipt of the characters
> depending upon
> > > > receiving device or traffic on the transmission lines. The
> > > end to end
> > > > delay is, I think, beyond the control of the subcommittee
> > > because the
> > > > transmission is either via the internet or telephone lines.
> > > >
> > > > >>3. Most importantly, I don't understand why we would want
> > > to exclude
> > > > >>the
> > > > huge mainstream advantages of chat and IM. I have not
> > > heard anything
> > > > from the many deaf users of these systems that the "Enter"
> > > key imposes
> > > > a conversational barrier. Moreover, it is unlikely that
> > mainstream
> > > > chat/IM program vendors will modify their programs to transmit
> > > > character by character. This leaves deaf and other users
> > > still in a
> > > > communication ghetto, instead of being able to use the
> same tools
> > > > everyone else is
> > > using.
> > > >
> > > > As a user of text communication tools that include
> > chat/im I do not
> > > > find this to be a barrier. In many respects I find this to be
> > > > superior to character by character transmission....we all make
> > > > typos...imagine receiving a character by character message:
> > > >
> > > > "Gaood xxx good mraning, I qaxxx am wriging you today..."
> > > >
> > > > This becomes very confusing. I find it better to receive a
> > > complete
> > > > message with fewer typos that I can then decipher easier.
> > > >
> > > > Tom Brett
> > > >
> > > > -----Original Message-----
> > > > From: = EMAIL ADDRESS REMOVED =
> > > > [mailto: = EMAIL ADDRESS REMOVED = ] On
> Behalf Of Jim
> > > > Tobias
> > > > Sent: Wednesday, June 20, 2007 8:21 AM
> > > > To: 'TEITAC Telecommunications Subcommittee'
> > > > Subject: [teitac-telecom] real-time text
> > > >
> > > > Hi All,
> > > >
> > > > As drafted on our call monday, the definition of
> > real-time text is:
> > > >
> > > > "Communications that employ the transmission of text
> wherein the
> > > > characters are transmitted by a terminal w/in a maximum of
> > > 1 sec. of
> > > > character input."
> > > >
> > > > I think there are a few problems here:
> > > >
> > > > 1. Although the characters are to be transmitted quickly,
> > > there is no
> > > > reference to how they are handled once they're transmitted.
> > > That is,
> > > > a server in the middle somewhere could add significant
> delays by
> > > > design or congestion. If we want to make text conversation
> > > real-time,
> > > > we have to make it clear what the permissable
> end-to-end delay is.
> > > >
> > > > 2. If the intention in this definition was to distinguish
> > TTY-style
> > > > (characters are transmitted as soon as they are keyed in)
> > > from IM and
> > > chat,
> > > > where you type a bunch of characters and then press "Enter" to
> > > > transmit, we should say so explicitly, somewhere.
> > > >
> > > > 3. Most importantly, I don't understand why we would want
> > > to exclude
> > > > the huge mainstream advantages of chat and IM. I have
> not heard
> > > > anything from the many deaf users of these systems that
> > the "Enter"
> > > > key imposes a conversational barrier. Moreover, it is
> > > unlikely that
> > > > mainstream chat/IM program vendors will modify their
> programs to
> > > > transmit character by character. This leaves deaf and
> > other users
> > > > still in a communication ghetto, instead of being able to
> > > use the same
> > > > tools everyone else is
> > > using.
> > > >
> > > > ******
> > > > Jim Tobias
> > > > Inclusive Technologies
> > > > = EMAIL ADDRESS REMOVED =
> > > > +1 732.441.0831 voice/tty
> > > > skype jimtobias
> > > > +1 908.907.2387 mobile
> > > >
> > > >

From: Jim Tobias
Date: Thu, Jun 21 2007 1:30 PM
Subject: Re: real-time text

>
> Line by line isn't real-time. Some people contend that it
> is but it is near-real-time or pseudo real time at best.

You say it isn't; I say it is. The distinction is whether it is
server intermediated or "pure peer-to-peer".

> Most IM for example does flow through a server and is stored
> and forwarded.
> Did you ever notice that sometimes the message doesn't appear
> right away? I was on Skype call just last week and it took 9
> minutes for a message I sent to someone when I was talking to
> them - to arrive (and for theirs to get back to me). They
> did arrive but only later. Usually (but not always) it isn't
> stored for more than a moment.

You can point to a Skype server? This is news.

> The fact that IM is stored on servers was also a surprise and
> embarrassment to a certain senator who found all his IM on a
> server backup.
>
> Real-time text by comparison is point to point and happens in
> real time as it is generated. It is not a message (as IM is)
> and it is not stored somewhere.
>
> People do say that they converse by email, and by SMS and by
> IM. I even have heard people talk about conversing by mail.
> So the word 'converse' is quite loosely used.

But I'm suggesting we define it. Saying character mode is and line mode
isn't is not the right way to do this.

> The goal is to allow real-time conversation where the person
> can track what you are saying it as you are saying it.
>
> Do demonstrate the difference I think we should create a demo
> where you talk back and forth but the person cannot begin to
> hear what you say until you are done saying it. (Push to
> record and it gets sent when you get to the end of what you
> are saying). It is faster than typing but you will quickly
> see how much slower it is and how it breaks communication conventions.
>
> To try this for yourself - try saying everything to yourself silently
> before you say it aloud on a phone call. Do it for a day.
> It is MUCH
> better than not being able to talk but - not the same as
> talking in real-time.

Let's not focus on the technology platform, but thr underlying function. In
a conversation the user expects to get responses quickly; in a messaging
mode, there is no such expectation.

Although you and Gunnar are right that nothing prevents people from using
line-oriented text, adding the character mode requirement effectively
eliminates line mode technologies from compliance, and I think this is a big
problem.

From: Jim Tobias
Date: Fri, Jun 22 2007 7:40 AM
Subject: Re: real-time text

Hi Gunnar,

Thanks again for your contribution here.

Please understand that my position is not based on any
technological issues. I only note the following,
which you may also agree with:

1. Deaf users have adopted line-by-line text conversation
and SMS with great enthusiasm because the options open
to them are mobile, easy to use, and accepted by many
non-deaf people. This last point allows for direct
communication rather than relay.

2. It is likely that if we require character-by-character
conversation in 255/508 that vendors will either not
provide it or support it as well as they do line-by-line,
and non-deaf users may not adopt it either. This would
perpetuate the communication ghetto we had with wireline
TTY.

******
Jim Tobias
Inclusive Technologies
= EMAIL ADDRESS REMOVED =
+1 732.441.0831 voice/tty
skype jimtobias
+1 908.907.2387 mobile

> -----Original Message-----
> From: Gunnar Hellström [mailto: = EMAIL ADDRESS REMOVED = ]
> Sent: Thursday, June 21, 2007 10:23 AM
> To: 'TEITAC Telecommunications Subcommittee'
> Subject: Re: [teitac-telecom] real-time text
>
> The goal is to get a good conversational flow without
> stressfull waiting.
> Stressful and confusion-creating waitng appears if you do not
> send regularly with a good conversational flow.
>
> Regularly means originally not more than a half second
> between transmissions, but in our discussion here it is
> stretched to one second, that takes us into the border area
> of risk for conversational collissions.
>
> Line-by-line is not good conversational flow, even if the
> line is transmitted rapidly once sent.
> Have you not noticed how you get a desire to shorten off
> sentences in IM, so that you keep the other party informed on
> your thoughts. That forces change in behaviour for you that
> is not needed if text was sent regularly without any specific
> action from you.
>
> Gunnar
> -------------------------------------------------------------------
> Gunnar Hellström
> Omnitor
> = EMAIL ADDRESS REMOVED =
> Tel: +46708204288
> www.omnitor.se
>
> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of
> Jim Tobias
> Sent: Thursday, June 21, 2007 3:40 PM
> To: 'TEITAC Telecommunications Subcommittee'
> Subject: Re: [teitac-telecom] real-time text
>
> The problem is using the phrase "real-time text" to mean only
> character by character. Line-by-line is also real-time, and
> both are distinct from store and forward technologies like
> email and SMS. That's the important
> distinction: whether the end-to-end system is making a good
> faith effort to send text as it is received, or whether the
> system assumes that the text will remain in a server until
> retrieved somehow by the recipient. The latter is not a
> conversation. The goal is to require a capability for text
> conversation, not require how many characters are processed at a time.
>
> ******
> Jim Tobias
> Inclusive Technologies
> = EMAIL ADDRESS REMOVED =
> +1 732.441.0831 voice/tty
> skype jimtobias
> +1 908.907.2387 mobile
>
> > -----Original Message-----
> > From: Gregg Vanderheiden [mailto: = EMAIL ADDRESS REMOVED = ]
> > Sent: Wednesday, June 20, 2007 2:39 PM
> > To: 'TEITAC Telecommunications Subcommittee'
> > Subject: Re: [teitac-telecom] real-time text
> >
> > What you would receive is exactly the same as what you
> receive on TTYs
> > today.
> >
> > All corrections are in place. You can see people backspace
> > - that is true.
> > But only if person sending wants to. That person has the option of
> > holding text back if they wish. It wouldn't be real-time text in
> > that case. but
> > the requirement is only that devices be capable of
> real-time text. it
> > does not require people to use real-time text.
> >
> > As Jim pointed out - they may wish to operate in IM mode,
> in message
> > mode.
> > Or send email. Just as all of us with real-time voice also
> > use all of
> > these other modes sometimes and want real-time
> communication at other
> > times.
> >
> >
> >
> > Gregg
> > -- ------------------------------
> > Gregg C Vanderheiden Ph.D.
> >
> >
> >
> > > -----Original Message-----
> > > From: = EMAIL ADDRESS REMOVED =
> > > [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> > Of Tom Brett
> > > Sent: Wednesday, June 20, 2007 1:08 PM
> > > To: 'TEITAC Telecommunications Subcommittee'
> > > Subject: Re: [teitac-telecom] real-time text
> > >
> > > The t140 includes this option but I what I receive is
> > >
> > > Ga ood morning, I s am wrting writing you....
> > >
> > >
> > >
> > > Tom Brett
> > >
> > >
> > > -----Original Message-----
> > > From: = EMAIL ADDRESS REMOVED =
> > > [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf
> Of Gregg
> > > Vanderheiden
> > > Sent: Wednesday, June 20, 2007 1:27 PM
> > > To: 'TEITAC Telecommunications Subcommittee'
> > > Subject: Re: [teitac-telecom] real-time text
> > >
> > > Hi Tom
> > >
> > > T140 includes backspaces so you still get a corrected
> > message at the
> > > far end.
> > >
> > > And you can always have an option to hold back text if you
> > > wish. That is,
> > > a system with real-time text could ALSO have a mode that
> > was message
> > > like.
> > >
> > >
> > > Gregg
> > > -- ------------------------------
> > > Gregg C Vanderheiden Ph.D.
> > >
> > >
> > > > -----Original Message-----
> > > > From: = EMAIL ADDRESS REMOVED =
> > > [mailto:teitac-telecom-
> > > > = EMAIL ADDRESS REMOVED = ] On Behalf Of Tom Brett
> > > > Sent: Wednesday, June 20, 2007 7:38 AM
> > > > To: 'TEITAC Telecommunications Subcommittee'
> > > > Subject: Re: [teitac-telecom] real-time text
> > > >
> > > > >> 1. Although the characters are to be transmitted
> > > quickly, there is
> > > > >> no
> > > > reference to how they are handled once they're transmitted.
> > > That is,
> > > > a server in the middle somewhere could add significant
> delays by
> > > > design or congestion. If we want to make text conversation
> > > real-time,
> > > > we have to make it clear what the permissible
> end-to-end delay is.
> > > >
> > > > >From my understanding of the real time text definition I
> > > thought that
> > > > >it
> > > > applied only to the device that was doing the output.
> > > There can be
> > > > significant delay in the receipt of the characters
> depending upon
> > > > receiving device or traffic on the transmission lines. The
> > > end to end
> > > > delay is, I think, beyond the control of the subcommittee
> > > because the
> > > > transmission is either via the internet or telephone lines.
> > > >
> > > > >>3. Most importantly, I don't understand why we would want
> > > to exclude
> > > > >>the
> > > > huge mainstream advantages of chat and IM. I have not
> > > heard anything
> > > > from the many deaf users of these systems that the "Enter"
> > > key imposes
> > > > a conversational barrier. Moreover, it is unlikely that
> > mainstream
> > > > chat/IM program vendors will modify their programs to transmit
> > > > character by character. This leaves deaf and other users
> > > still in a
> > > > communication ghetto, instead of being able to use the
> same tools
> > > > everyone else is
> > > using.
> > > >
> > > > As a user of text communication tools that include
> > chat/im I do not
> > > > find this to be a barrier. In many respects I find this to be
> > > > superior to character by character transmission....we all make
> > > > typos...imagine receiving a character by character message:
> > > >
> > > > "Gaood xxx good mraning, I qaxxx am wriging you today..."
> > > >
> > > > This becomes very confusing. I find it better to receive a
> > > complete
> > > > message with fewer typos that I can then decipher easier.
> > > >
> > > > Tom Brett
> > > >
> > > > -----Original Message-----
> > > > From: = EMAIL ADDRESS REMOVED =
> > > > [mailto: = EMAIL ADDRESS REMOVED = ] On
> Behalf Of Jim
> > > > Tobias
> > > > Sent: Wednesday, June 20, 2007 8:21 AM
> > > > To: 'TEITAC Telecommunications Subcommittee'
> > > > Subject: [teitac-telecom] real-time text
> > > >
> > > > Hi All,
> > > >
> > > > As drafted on our call monday, the definition of
> > real-time text is:
> > > >
> > > > "Communications that employ the transmission of text
> wherein the
> > > > characters are transmitted by a terminal w/in a maximum of
> > > 1 sec. of
> > > > character input."
> > > >
> > > > I think there are a few problems here:
> > > >
> > > > 1. Although the characters are to be transmitted quickly,
> > > there is no
> > > > reference to how they are handled once they're transmitted.
> > > That is,
> > > > a server in the middle somewhere could add significant
> delays by
> > > > design or congestion. If we want to make text conversation
> > > real-time,
> > > > we have to make it clear what the permissable
> end-to-end delay is.
> > > >
> > > > 2. If the intention in this definition was to distinguish
> > TTY-style
> > > > (characters are transmitted as soon as they are keyed in)
> > > from IM and
> > > chat,
> > > > where you type a bunch of characters and then press "Enter" to
> > > > transmit, we should say so explicitly, somewhere.
> > > >
> > > > 3. Most importantly, I don't understand why we would want
> > > to exclude
> > > > the huge mainstream advantages of chat and IM. I have
> not heard
> > > > anything from the many deaf users of these systems that
> > the "Enter"
> > > > key imposes a conversational barrier. Moreover, it is
> > > unlikely that
> > > > mainstream chat/IM program vendors will modify their
> programs to
> > > > transmit character by character. This leaves deaf and
> > other users
> > > > still in a communication ghetto, instead of being able to
> > > use the same
> > > > tools everyone else is
> > > using.
> > > >
> > > > ******
> > > > Jim Tobias
> > > > Inclusive Technologies
> > > > = EMAIL ADDRESS REMOVED =
> > > > +1 732.441.0831 voice/tty
> > > > skype jimtobias
> > > > +1 908.907.2387 mobile
> > > >
> > > >