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

["Gunnar Hellstrom" <[e-mail]>]

Len,

That was a good explanation of some of the
problems and solutions with text emergency call
handling.

You said:
> The originating IP
> address offers no guidance as to where
> the call originate nor where it
> should be answered.
>
> The solution, therefore will need to
> reflect local needs. In countries where
> a national answering approach is taken
> it is a lot easier.

That is where the discussion started, with
comments on
http://www.ietf.org/internet-drafts/draft-ietf-sip
ping-sos-00.txt
where addressing is discussed and we discussed the
opportunities to route calls where the user want
to rely on the text component to centra with text
proficiency.

We have recently established an opportunity for
SIP phones to register that their user has a
preference for text.
See
http://www.ietf.org/internet-drafts/draft-ietf-sip
-callee-caps-03.txt

It would be possible to route the calls with
expressed text preference to text capable
centres. - If wanted -
In the SIP world, I would hope that every phone
has text capability and that text is used by all
in the calls intermixed with voice ( and video ).
Then ESOs would take text based calls naturally.
Interactive character by character text is
extremely valuable in any emergency call for easy
transfer of names, addresses, numbers etc.
The sipdev requirements expressed in
http://www.ietf.org/internet-drafts/draft-sinnreic
h-sipdev-req-03.txt
say that all SIP phones shall have compatible real
time text capabilities based on RFC2793.


For this vision to come true, a lot of
coordination must take place, making the best out
of the excellent opportunities defined in SIP to
establish a telephone system with new and
convenient functionality.

And the toughest part is to achieve reasonable
level of support for the PSTN users in this
system.

Gunnar
-------------------------------------------
Gunnar Hellström
Omnitor AB
Renathvägen 2
SE 121 37 Johanneshov
SWEDEN
[phone]
Mob: [phone]
www.omnitor.se
[e-mail]
--------------------------------------------


> -----Original Message-----
> From: Len [mailto:[e-mail]]
> Sent: Tuesday, March 09, 2004 12:29 AM
> To: Rosen, Brian; 'A vWijk'; Barry Dingle;
> [e-mail];
> [e-mail];
> [e-mail]
> Cc: [e-mail];
> [e-mail]; [e-mail];
> [e-mail]; Toni Dunne;
> [e-mail]
> 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).
>
> 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>
>
> 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. 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 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. 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 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.
>
> =>Len
>
>
> Len Bytheway
> Chief Executive Officer
> Australian Communication Exchange
>
> [phone] (mobile SMS)
> [phone] (voice TTY)
> [phone] (facsimile)
>
> [e-mail]
> http://www.aceinfo.net.au
>
> ......................................On
>  1/3/04 4:51 PM, "Rosen, Brian"
> <[e-mail]> wrote:
>
> > I don't think we are communicating.
> >
> > There are existing systems deployed
> in the PSTN.  We are unlikely
> > to change how they work, how they are
> addressed, and what they do.
> > Specifically, most countries have
> text support for emergency calls.
> > I don't think there is anything we
> can do in SIPPING to change
> > how text emergency calls happen in the PSTN.
> >
> > Specifically, I don't believe it will
> be acceptable to insert
> > a text gateway between a text-capable
> PSTN user and an emergency
> > response center.  It MIGHT be
> possible to implement an emergency
> > response center with SIP technology.
> In such a case, there
> > would be a gateway from the PSTN to
> the emergency response
> > center, and that gateway could
> recognize V.18 tones and handle
> > the call as a text media stream from
> the gateway.  That does
> > not take any new mechanism, and is
> not really germane to the
> > basic discussion of text support, or
> for that matter, emergency
> > calling.
> >
> > Brian
> >
> >> -----Original Message-----
> >> From: A vWijk [mailto:[e-mail]]
> >> Sent: Monday, March 01, 2004 1:00 AM
> >> To: [e-mail];
> [e-mail];
> >> [e-mail];
> [e-mail];
> [e-mail]
> >> Cc: [e-mail];
> [e-mail];
> >> [e-mail];
> >> [e-mail]; [e-mail]
> >> Subject: Betr.: RE: Betr.: RE:
> Betr.: [Sipping] ToIP Requirements
> >>
> >>
> >> Hi Brian,
> >> I am only talking to analogue text
> telephony to IP telephony
> >> on the PSTN.
> >> In the PSTN, you do not use a SIP
> URI for placing a call. You
> >> would dial 911 if it was a voice
> phone or perhaps prefix 600-911.
> >>
> >> The text gateway will send the Text
> media announcement in the
> >> SDP. And send it to the
> sos@localdomain URI. I agree with you
> >> on the sip side. The text gateway
> acts then as the "virtual"
> >> SIP version of the analogue text
> telephone, using RFC2793 text.
> >>
> >> Perhaps we are miscommunicating what
> we are talking about. :-)
> >>
> >> greetz
> >>
> >> Arnoud
> >>
> >>
> >> <<< "Rosen, Brian"
> <[e-mail]> 01-03 06:03  >>>
> >> Arnoud
> >>
> >> With respect to prefixes:
> >> In SIP calls, there are no numbers,
> and thus no prefixes.
> >> You send the Text media announcement
> in the SDP.
> >> You send it to the sos@localdomain
> URI.  We don't need, nor want
> >> prefixes
> >>
> >> In the existing dial plan, some
> jurisdictions have special
> >> numbers for text, some don't.  We
> can't change that.
> >> We have to work with both ways, but
> we don't advocate,
> >> support or discourage them; we
> simple deal with the
> >> possibility that a user might use
> those numbers.
> >>
> >> If you want prefixes for every call,
> speak to your
> >> local number adminstration agency;
> it has nothing
> >> to do with SIP.
> >>
> >> Brian
> >>
> >>> -----Original Message-----
> >>> From: A vWijk [mailto:[e-mail]]
> >>> Sent: Sunday, February 29, 2004 11:47 PM
> >>> To: [e-mail];
> [e-mail];
> >>> [e-mail]; [e-mail];
> >> [e-mail]
> >>> Cc: [e-mail];
> [e-mail];
> >>> [e-mail];
> >>> [e-mail]; [e-mail]
> >>> Subject: Betr.: RE: Betr.:
> [Sipping] ToIP Requirements
> >>>
> >>>
> >>> 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"
> <[e-mail]> 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
> >>> simultane
> >>
> >>
> _______________________________________________
> >> Sipping mailing list
https://www1.ietf.org/mailman/listinfo/sipping
>> This list is for NEW development of the
application of SIP
>> Use [e-mail] for
questions on current sip
>> Use [e-mail] for new developments of core
SIP
>>
>





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