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

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 9 Mar 2004 14:18:37 -0500

Arnoud

At this point, I don't think there is anything we can do, or need to do,
with respect to PSTN gateways in any IETF working group, do you?

Brian

> -----Original Message-----
> From: Arnoud van Wijk [mailto:[email-masked]]
> Sent: Tuesday, March 09, 2004 10:59 AM
> To: 'Rosen, Brian'; 'Len'; 'Barry Dingle';
> [email-masked]; [email-masked];
> [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]; 'Toni Dunne'; [email-masked]
> Subject: RE: Betr.: RE: Betr.: RE: Betr.: [Sipping] ToIP Requirements
> 
> 
> Brian,
> 
> Hmmm there are strategies to determine that a call is a text 
> call or a voice
> call on the PSTN side.
> Ranging from 
> 1. prefix, eg. 600-then called number (note that is for ALL 
> text telephone
> calls and not only 112 or 911)
> 2. PSTN can listen whether it is text or voice. With an 
> incoming V.18/V21
> call it is possible. Boudot and DTMF phones are silent and 
> need to receive a
> query tone.
> 3. marking the phone number as text telephone user. When that 
> happens, the
> PSTN will firstly asume that the call is text and then voice. 
> It is even
> possible that it will send a query tone (Boudot and DTMF). 
> And when the text
> telephone does no kick in, it will just asume voice. This 
> means that as a
> voice user, that you will always hear a query tone when 
> placing a phonecall.
> But that is fine, since you live in the same house as the 
> deaf person. If
> you then hate it, get 2 phone lines or use the prefix method.
> 
> The bottomline is that there are possibilities at the PSTN to 
> detect that
> the incoming call is a textphone user.
> 
> Maybe it is a good idea if we investigate this and see if the above
> described solutions and other possible solutions are fine and 
> do work in a
> reliable way. 
> And we can then focus on implementing the text gateway for 
> emergencies.
> 
> So that energency centers will be able to receive any call in 
> voice, video
> and interactive text. Total conversation.
> 
> And yes, I do NOT want a separate dedicated setup for analog 
> text telephones
> for emergency calls. It will not work and it complicates 
> matters. It never
> worked well.
> 
> I appreciate your putting RFC 2793 in the specs. And I am 
> writing those
> mails from the perspective of a text telephone user. I want 
> to be sure that
> when I call 911 or 112 (depending where I am ofcourse), that 
> I do get the
> emergency operator. And that they can find me in case I 
> become unconsious.
> 
> But that also means that I do not want a panicked emergency 
> operator because
> he or she almost never recieves a textphone call and has more or less
> forgotten how to use the text telephone.
> 
> Greetz
> 
> Arnoud
> 
> Drs. Arnoud A. T. van Wijk
> Viataal
> Research & Development
> Afdeling RDS
> Theerestraat 42
> 5271 GD Sint-Michielsgestel
> The Netherlands. 
> Mobile: +31651921948
> International text telephone: +31735588408
> 
> -----Original Message-----
> From: Rosen, Brian [mailto:[email-masked]] 
> Sent: dinsdag 9 maart 2004 16:09
> To: 'Arnoud van Wijk'; 'Len'; 'Barry Dingle';
> [email-masked]; [email-masked];
> [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]; 'Toni Dunne'; [email-masked]
> Subject: RE: Betr.: RE: Betr.: RE: Betr.: [Sipping] ToIP Requirements
> 
> Arnoud
> 
> We'll put 2793 in the specs.  I'll also get it into the NENA 
> specs, which
> are North America specific.  I don't think we can do a whole lot with
> gateways; they are stuck with the same problems we have today 
> -- you don't
> know you have a text call until you answer it.  I'm not 
> inclined to work
> very hard to mitigate any of that; I'd rather make sure that 
> we don't lose
> anything as we make technology transitions, but make it more and more
> attractive for people to convert to SIP phones where we can 
> make a lot of
> difference.
> 
> Brian
> 
> > -----Original Message-----
> > From: Arnoud van Wijk [mailto:[email-masked]]
> > Sent: Tuesday, March 09, 2004 10:01 AM
> > To: 'Rosen, Brian'; 'Len'; 'Barry Dingle';
> > [email-masked]; [email-masked];
> > [email-masked]
> > Cc: [email-masked]; [email-masked]; [email-masked];
> > [email-masked]; 'Toni Dunne'; [email-masked]
> > Subject: RE: Betr.: RE: Betr.: RE: Betr.: [Sipping] ToIP 
> Requirements
> > 
> > 
> > And I hear the same problem in the Netherlands that the 112 
> > operators are
> > clueless when they receive an incoming text telephone call.
> > The biggest problem is that they have to transfer the call to a text
> > telephone.
> > And those things are not as easy to deal with as a computer.
> > 
> > That is also why I just want to see all emergency calls 
> > coming in using RFC
> > 2793 Interactive texting.
> > Why? Better integration with the 112/911 center's computer 
> > systems, the
> > operator can just use the same computer, and there is then a text
> > conversation instead of voice.
> > Or maybe simultaneously, where the deaf caller talks to the 
> > operator and the
> > replies are sent back in text.
> > 
> > That is what I like to see. And thus the PSTN text gateways 
> > MUST be able to
> > deal properly with emergency calls. Location is not a 
> > problem, since the
> > text gateways can pass along the address/location.
> > 
> > Native IP calls using interactive text are indeed a problem 
> > with location.
> > But that is just the same with VoIP calls.
> > 
> > Greetz
> > 
> > Arnoud
> > 
> > Drs. Arnoud A. T. van Wijk
> > Viataal
> > Research & Development
> > Afdeling RDS
> > Theerestraat 42
> > 5271 GD Sint-Michielsgestel
> > The Netherlands. 
> > Mobile: +31651921948
> > International text telephone: +31735588408
> > 
> > -----Original Message-----
> > From: Rosen, Brian [mailto:[email-masked]] 
> > Sent: dinsdag 9 maart 2004 14:52
> > To: 'Len'; 'A vWijk'; Barry Dingle; [email-masked];
> > [email-masked]; [email-masked]
> > Cc: [email-masked]; [email-masked]; [email-masked];
> > [email-masked]; Toni Dunne; [email-masked]
> > Subject: RE: Betr.: RE: Betr.: RE: Betr.: [Sipping] ToIP 
> Requirements
> > 
> > Len
> > 
> > Thanks for a thorough explanation of how text is done today.
> > 
> > Lots of comments in-line:
> > 
> > > -----Original Message-----
> > > From: Len [mailto:[email-masked]]
> > > Sent: Monday, March 08, 2004 6:29 PM
> > > To: Rosen, Brian; 'A vWijk'; Barry Dingle;
> > > [email-masked]; [email-masked];
> > > [email-masked]
> > > Cc: [email-masked]; [email-masked]; [email-masked];
> > > [email-masked]; Toni Dunne; [email-masked]
> > > Subject: Re: Betr.: RE: Betr.: RE: Betr.: [Sipping] ToIP 
> > Requirements
> > > 
> > > 
> > > The text emergency call number is a tricky issue.
> > > 
> > > The problem stems from the fact that emergency call routing 
> > > is done in a
> > > number of different ways:
> > > 
> > > One:
> > > The USA model whereby a local agency is the Public Safety 
> > > Answering Point,
> > > they take calls directly and usually dispatch an emergency 
> > > response from the
> > > PSAP. There are around 5,500 PSAPs in the USA. In the USA 
> > each PSAP is
> > > required to have a TTY capability and maintain staff skills 
> > > in dealing with
> > > callers using textphones. I recently met with the American 
> > > President of APCO
> > > (Association of Public Safety Communications Officials) who 
> > > admitted the
> > > system used in the USA is not working! The small number of 
> > > TTY calls means
> > > that most staff are not up to speed with their ³Deaf phone² 
> > > and panic when a
> > > call comes in. Further the systems used are not friendly to 
> > > VCO, HCO and
> > > certainly not to any system that has a carrier signal (eg 
> > > v.21 or v.18).
> > I think this experience is somewhat variable.  I can ask more 
> > about it next
> > week at the NENA meeting.  Certainly, the current system is 
> > really only
> > useful with BAUDOT.
> > 
> > > 
> > > Two:
> > > Australia, New Zealand and the UK have a national emergency 
> > > call taking
> > > facility (000, 111 and 999). In these cases a call is taken 
> > > by the call
> > > answering point then passed to the appropriate agency (Police 
> > > Fire Ambulance
> > > etc). For this system to work for textphones, it requires the 
> > > initial call
> > > taker must have text detection capability, then the ability 
> > > to set up a 3
> > > way conference call, then transfer that call to an 
> emergency service
> > > organisation (ESO), who in turn must also have text 
> > > capability. There are
> > > problems with TTY due to its half duplex nature, and even 
> > > greater problems
> > > with modes that require a carrier signal. The types of 
> > > equipment usually
> > > provided to interface with ESO CAD (computer aided despatch) 
> > > systems offer
> > > TTY 50 and no VCO, HCO or v.21 etc None have v.18 to my 
> > > knowledge. There are
> > > many thousands of ESO answering points around Australia and 
> > > to provide full
> > > v.18 capability and training for all would be expensive and 
> > > problematic.
> > > 
> > > Both Australia and the UK have opted for similar solutions.
> > > 
> > > BT in the UK offers 0800 as a text emergency number. This 
> > > routes through the
> > > TextDirect text server, then engages the TypeTalk relay 
> service and
> > > establishes a relay call directly with 999. The 999 agent 
> > > gets an incoming
> > > call via voice and can conference, transfer etc the call as 
> > > it does for any
> > > incoming voice call. The 999 operator can then hand over the 
> > > relayed call to
> > > the appropriate ESO. This will work with any textphone that 
> > > is recognised by
> > > the text server and supports VCO, HCO etc. The call 
> > sequence is: text
> > > caller>
> > I believe most relay services can, and will do this.  I don't 
> > know how often
> > it happens in the U.S.  I believe that when this mechanism is 
> > used, location
> > and call-back numbers are lost.  That is a large problem.  I 
> > know emergency
> > centers that would rather get location and deal with 
> > inexperienced operators
> > than not have location and work with a relay operator, but YMMV.
> > 
> > > 
> > > In Australia we have taken the UK model a step further. 106 
> > > is the dedicated
> > > text emergency call service. It is offered on the same 
> > > priority routes as
> > > 000 and brings the full national emergency answering 
> > > capability into the
> > > relay service.
> > > 
> > > As for facilities within a text server whether it be PSTN or 
> > > IP based the
> > > matter is particularly confusing.
> > > 
> > > Firstly whatever solution is put in place MUST be locality 
> > > specific. 
> > Not in the IETF.  We don't do that.  We can accommodate a 
> > range of options,
> > but we don't do national variants.  That is a very good 
> > thing.  Since the
> > emergency system has to change in some way to accommodate 
> > VoIP, its probably
> > not a problem to make VoIP call handling universal world wide.  
> > 
> > > If
> > > there were a ³universal² emergency access number code, the 
> > > fact that the
> > > public internet does not understand location would bring 
> > > about a disaster.
> > The current proposal in the sos draft is that there is a 
> > universal uri.
> > There will be local emergency phone numbers, which will be 
> > translated into
> > the universal uri for routing.  This is clearly not a good 
> > situation, but
> > its the best we can do.  The usual example of how bad it is 
> > would be when a
> > user in one country is using a VoIP system in their home 
> > country over a VPN.
> > If an emergency occurs, should the user call their home 
> > emergency number or
> > the local emergency number?  How should the VoIP system in 
> > the home country
> > react?
> > 
> > The current answer is that you use the local emergency 
> > number, and there is
> > a mechanism to learn what that local number is, so that the 
> > call will in
> > fact be interpreted by the network correctly, and routed correctly.
> > 
> > We will route emergency calls correctly.  Location will be 
> > provided,  and we
> > will use the location to route.  Please see the emergency 
> > arch document.
> > 
> > > The calls must be routed to the appropriate emergency 
> > > answering point. In
> > > Australia, NZ the UK etc calls would need to be routed to 
> > > their national
> > > emergency answering point. That could be 000, 111 or 999 on 
> > > the PSTN via a
> > > gateway, or by an equivalent direct access to a SIP service 
> > within the
> > > answering point. 
> > We plan to make this work correctly.  It will be possible to 
> > build gateways
> > that provide a subset of possible services to a answering 
> point using
> > current mobile location technology, but the services provided 
> > will be much
> > better if the answering point is SIP capable.  This will 
> > especially be true
> > for text users.
> > 
> > >In the USA, Canada etc the solution is much 
> > > more complex as
> > > there are literally thousands of answering points each 
> > > serving a particular
> > > geographic region. A text caller with an emergency in LA does 
> > > not want their
> > > call answered in by PSAP in Kansas City  they have no 
> > > dispatch facilities
> > > nor the capability to seamlessly transfer the call. The 
> > originating IP
> > > address offers no guidance as to where the call originate 
> > nor where it
> > > should be answered.
> > The drafts address this problem, and I believe will route the 
> > call correctly
> > in all cases.  It depends on a database, which I propose to 
> > be in the DNS
> > (see draft-rosen-dns-sos-00). 
> > 
> > I should know this, but is it not the case that there are in 
> > fact regional
> > answering points in the UK and AU?  There are fewer than in 
> > the US, but its
> > not just one big center.  I understand that dispatch is 
> > handled at a local
> > level.  That is sometimes true in the US also.  It really 
> > doesn't matter,
> > the proposals work in both cases, or even hybrids where there 
> > are some local
> > answering points and other areas not covered by the local 
> > ones are handled
> > by national (or regional) centers.
> > 
> > The largest problem is in countries that have no universal 
> > emergency centers
> > at all, where you call the local fire/police/ambulance 
> > service directly.
> > The sos draft provides universal uris for this case also, but 
> > the user has
> > to know to use these instead of the single universal sos uri. 
> >  Perhaps with
> > the evolution to VoIP, emergency services in those countries 
> > could evolve.
> > We won't plan on it :(
> > 
> > > 
> > > The solution, therefore will need to reflect local needs. In 
> > > countries where
> > > a natuional answering approach is taken it is a lot easier, 
> > I have no
> > > constructive suggestions for those where a PSAP type system 
> > operates.
> > When a real SIP text capable end point makes an emergency 
> > call, it will use
> > the universal sos URI.  A local emergency number can be used, 
> > which will
> > translate to the universal uri.  That call will be routed to 
> > the correct
> > answering point.  The call will have caller preferences, 
> and media SDP
> > offers that indicate it is a text call.  Calls can be routed 
> > to operators
> > who can handle text.  VoIP capable answering points should be 
> > capable of
> > patching
> > in relay services, and transferring calls, with location 
> > intact, to dispatch
> > points.  Thus I believe there will be strong incentives for 
> > hearing impaired
> > citizens to deploy SIP text phones as soon as the 
> > capabilities for handling
> > such calls are deployed in the answering centers.  Since VoIP 
> > is ALREADY
> > becoming a problem for the centers, I believe you can expect 
> > that there will
> > be VoIP capable answering points reasonably soon.
> > 
> > Brian 
> >  
> > 
> 

_______________________________________________
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

---

From: "Gunnar Hellstrom" <[email-masked]>
Date: Thu, 11 Mar 2004 11:09:13 +0100

Brian,

I think there are things that can be done in IETF
for gateways.

In RFC2805, gateway control requirements, it is
said:

d.   Allow the MGC to specify whether text
telephony/FAX/data modem
        traffic is to be terminated at the MG,
modulated/demodulated,
        and converted to packets or forwarded by
the MG in the media
        flow as voice band traffic.

and later:

11.2.4.  Trunking/Access Gateway with text
telephone access ports

   An access gateway with ports capable of text
telephone communication,
   must provide communication between text
telephones in the SCN and
   text conversation channels in the packet
network.

   Text telephone capability of ports is assumed
to be possible to
   combine with other options for calls as
described in section 11.2.6
   (e.) on "Adaptable NASes".

   The port is assumed to adjust for the
differences in the supported
   text telephone protocols, so that the text
media stream can be
   communicated T.140 coded in the packet network
without further
   transcoding [7].

   The protocol must be capable of reporting the
type of text telephone
   that is connected to the SCN port. The foreseen
types are the same as
   the ones supported by ITU-T V.18:  DTMF, EDT,
Baudot-45, Baudot-50,
   Bell, V.21, Minitel and V.18. It should be
possible to control which
   protocols are supported. The SCN port is
assumed to contain ITU-T
   V.18 functionality [8].

   The protocol must be able to control the
following functionality
   levels of text telephone support:

   a.   Simple text-only support: The call is set
into text mode from
        the beginning of the call, in order to
conduct a text-only
        conversation.

   b.   Alternating text-voice support: The call
may begin in voice mode
        or text mode and, at any moment during the
call, change mode on
        request by the SCN user. On the packet
side, the two media
        streams for voice and text must be opened,
and it must be
        possible to control the feeding of each
stream by the protocol.

   c.   Simultaneous text and voice support: The
call is performed in a
        mode when simultaneous text and voice
streams are supported. The
        call may start in voice mode and during
the call change state to
        a text-and-voice call.

   A port may implement only level a, or any level
combination of a, b
   and c, always including level a.

   The protocol must support:

   d.   A text based alternative to the
interactive voice response, or
        audio resource functionality of the
gateway when the port is
        used in text telephone mode.

   e.   Selection of what national translation
table to be used between
        the Unicode based T.140 and the 5-7 bit
based text telephone
        protocols.

   f.   Control of the V.18 probe message to be
used on incoming calls.

--------------------------------------------------
---------------------------------------
There are more references to text telephony in
that requirement spec.

The fulfillment of most of these requirements are
only specified in ITU-t H.248.2, and no IETF spec.
We should not duplicate efforts, but recognition
of that these requirements are met in H.248.2
might be good, so that further specification of
higher level interoperability between PSTN text
telephony and text in SIP can be done.

Similar specifications should possibly be entered
in MGCP.

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]
--------------------------------------------

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of
> Rosen, Brian
> Sent: Tuesday, March 09, 2004 8:19 PM
> Cc: [email-masked];
> [email-masked]; [email-masked];
> > Cc: [email-masked];
> [email-masked]; [email-masked];
> > Cc: [email-masked];
> [email-masked]; [email-masked];
> > > Cc: [email-masked];
> [email-masked]; [email-masked];
> > > Cc: [email-masked];
> [email-masked]; [email-masked];
> > > > Cc: [email-masked];
> [email-masked]; [email-masked];
> Sipping mailing list
> https://www1.ietf.org/mailman/listinfo/sipping