Re: [Ecrit] URN: for people with hearing loss

[Henning Schulzrinne <[e-mail]>]

Inline.

On Wed, Jul 19, 2017 at 7:56 PM, Drage, Keith (Nokia - GB) <
[e-mail]> wrote:

Replying to the thread as a whole, rather than just to the last message.
Firstly I think we should ignore SMS from a solution based on service URN
for a number of reasons.
It has been specified by the regulator as an emergency service in the UK,
but imposes no requirements on the mobile operators to treat it any
different to a normal SMS, therefore it is formally still a store and
forward service. My understanding is that this is regarded as a means to an
end, rather than an ideal solution, and ultimately real time text would be
the preferred solution.
3GPP does not define an emergency form of SMS, and SMS does not meet the
service requirements for emergency call, primarily the need for an
interactive communication.


This illustrates the problem of trying to define emergency too narrowly. By
US regulation (47 CFR 20.18), text-to-911 (currently, SMS) is indeed
mandatory to provide as an emergency service for US cellular carriers. (It
is naturally not a "call", but it is emergency communication.) However,
this may not matter unless such SMS gets converted to MSRP (say) and then
needs to be routed to a different location than service:sos voice or
multimedia calls. This does not currently appear to be the case, but could
be.



In regard to obtaining a real time text service, surely there are two
issues here – do I require routeing to a specialist endpoint, and how do I
indicate to the remote endpoint that real time text is required. Surely we
only require routeing to a specialist endpoint if either the technology at
a normal endpoint cannot handle the service, or a specialist user is
required. My understanding of the UK perspective on this is that when a
move is made to IP PSAPs, the intention is that all 1st level PSAPs will be
capable of handling real time text (in my understanding not a particularly
expensive requirement), and that all PSAP attendants will be trained to
handle such calls. If that is the case, then there is no special routeing
requirement. In terms of indicating the need to the endpoint, then SDP is
sufficient. Thus from the UK perspective, I am not understanding the need
for anything beyond the existing SOS URN.




I would add that in adding .msg as a subtype, there would be considerable
confusion as to its precedence with other subtypes, such as fire. Is
sos.msg.fire the same as sos.fire.msg? Assuming those combinations are
defined as legal in the first place. Note that if sos.fire.msg was used,
and the responder did not understand .fire, then the result would only be
understood as sos, and not as sos.msg. Therefore I see major issues of
reuse of the URN to indicate this requirement.

I did not suggest a message (.msg) suffix, for the reasons you mention and
since this seems unnecessary based on the services actually deployed. As a
stopgap, while there are mixed TDM-IP networks (with legacy customer
networks) that use special-purpose numbers, such as sos.message URN may be
needed to reach the right gateway (e.g., a TTY-to-RTT gateway). If a user
dials the special TTY (or fax) number, the network can't distinguish this
from a regular voice call, as you know, so either all PSAPs have to be able
to handle fax and TTY, or the call has to be initially directed to the
special-purpose gateway.

Naturally, if

Henning