Subject: Betr.: RE: Betr.: [Sipping] ToIP Requirements

From: "A vWijk" <[email-masked]>
Date: Mon, 01 Mar 2004 05:47:16 +0100

And that is why those 2 solutions would be best IMHO:
1. using a prefix number when using a textphone.
This prefix is for every textphone call you place! Thus not emergency only but any call made by the textphone.
600-911, 600-555-123456, 600-800-cheapshoe.

2. Label the phone number you use for the textphone as text telephone user.

In both cases the PSTN will immediately invoke the text gateway. Which then sends the V.18 reception/boudot reception signalling.

I know that it is not perfect, but the analogue textphones will disappear quickly. 2-3 years for most users and up to 10-15 years for the last few users.

I and many deaf people I know will throw the analogue textphone out of the window as soon as possible.
We will use mobile textphones via the textgateway and SIP phones with RFC2793 (and our pcs with an interactive text client).

greetz

Arnoud

<<< "Gunnar Hellstrom" <[email-masked]> 01-03 03:27  >>>
1. How it is in PSTN:
A calling V.18 sends a specific data pattern for text telephony in the V.8
signal CI.
It is sent in the connected voice channel.
So, as with all calls from PSTN, there is no indication before the call is
set up about what kind of media will be used.

But it is far more easy to identify it as a textphone call than it is for
some of the old systems. E.G the US system "Baudot" is silent when calling,
and the answering side must guess that it is a textphone.

There is not yet any really clear trend to move to V.18 for users in USA.
Therefore I agree that the mechanisms for emergency calls must for a long
time accomplish for the tedious task to try to respond in text on PSTN to
all incoming silent calls to discriminate the text callers. That response
should be done with V.18 signals, so that it at least is prepared for more
convenient handling when people have moved to using V.18 textphones.

2. In SIP.
In SIP, we have text in a separate media stream in the call. An emergency
centre should have capability to use both voice and text simultaneously.
There are mechanisms in discussion about indicating preference for handling
the call with text as the main medium. I am not sure that we can require
that preference to be set in a SIP terminal used for an emergency call by a
text depending person.
So, the safe handling would be for the emergency centre to offer text
capability, and if text connection is achieved, an automatic text greeting
is sent in that channel, while the emergency agent responds in voice. If the
caller then starts using the text channel, it is evident enough that text is
preferred.

Gunnar

-------------------------------------------
Gunnar Hellström
Omnitor AB
Renathvägen 2
SE 121 37 Johanneshov
SWEDEN
+46 8 556 002 03
Mob: +46 708 204 288
www.omnitor.se
[email-masked]
--------------------------------------------

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Rosen, Brian
Sent: Monday, March 01, 2004 1:16 AM
To: Barry Dingle; 'Arnoud van Wijk'; 'Gunnar Hellstrom';
[email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]; Len Bytheway
Subject: RE: Betr.: [Sipping] ToIP Requirements

While we can, and have, specified a single worldwide URI
for emergency calls, I believe it is not even technically
possible to find a single 3 digit number that is not
already in use somewhere.  Thus, I suspect anyone
dreaming that such a thing will happen probably is
going to be disappointed.

Since existing TDD devices do not provide an indication
that they are present until after the call is completed,
I think that we should not even consider use of any
kind of gateway for emergency calls.  This is true of
V.18 devices also, correct?

Having a special number for text emergency calls does
have

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP