Re: [Ecrit] [new-work] WG Review: Selection of Language for Internet Med


On Jul 7, 2015, at 8:00 AM, Gunnar Hellström 
<gunnar(_dot_)hellstrom(_at_)omnitor(_dot_)se> wrote:


I deleted ietf and iesg from the addresses and added slim. But you are right 
that this is a general sip topic as well.
Just tell where we shall continue the discussion.


[BA] Since much of the required discussion will need to be about topics such as 
routing and not language preferences it seems to me that there is a need for 
another venue other than SLIM.

About work items: I think slim can continue to create its planned media and 
modality indications.
But work is needed on the routing mechanisms using SLIM and other indications 
to decide on connection of users and optionally assisting services (such as 
relay).


[BA] I agree.

It is better if the mechanisms are general, and not emergency service 
specific.


[BA] I also agree with this - which is why I am concerned about focussing 
solely on emergency scenarios. The same issue arose with location routing - SIP 
conveyance was not only about emergency uses although that was certainly a key 
use case.

Another reason is that large parts of the mechanisms will be used and 
verified to work.


[BA] Indeed - a call center use case is plausible as well - and might be more 
likely to motivate addition of the required routing functionality to components 
such as SIP proxies.


That means that we end up with recommendations to have bridges in various 
places to be able to handle the different call scenarios optimally. Do you 
agree?


[BA] Yes, I agree - and it seems important to document these problems and 
potential solutions so that these problems do not slip through the cracks.

relay service users of speech-to-speech and captioned telephony services 
cannot describe their needs with the current proposed coding of slim, and 
would likely be better off to have a possibility to just request an assisting 
service by a URI and a sip operation.


[BA] Indeed. If the IETF is going to take on these kind of problems, it needs 
to take actions that will contribute to solving them in their entirety. That 
means chartering the work in the right places with the right expertise. While 
the proposed SLIM WG Charter does address one aspect of the problem, it leaves 
most of it unresolved and the proposed WG is not the right venue to close on 
the remainder.


Thus slim is only part of the solution. It would be good to have somewhere to 
discuss the whole picture and set slim and the other mechanisms in their 
context.
Where?

Gunnar

Rosen, Brian skrev den 2015-07-07 14:51:

But the draft doesn’t suggest that the direct model should replace the
current emergency call routing, it merely allows new capability.  If there
is any language you find that makes it seem like direct routing should be
preferred over the current location based routing, we can address that.

On your specific point about not being able to deal with non-video
equipped PSAPs, we have plenty of mechanisms available to readily
accommodate that situation.  Devices are required to follow existing
practice of forwarding calls to their normal outbound proxy, and this
draft doesn’t change that at all.  What happens after that is confined to
what the services that provide routing for VRS, and we can handle location
sensitive handling of such calls.  All 9-1-1 calls are “direct” routed, in
that they route to the outbound proxy, which routes based on the LoST
query result, and that is not media sensitive.  That delivers the call to
the right inbound proxy server, which then is able to route based on
media, if desired.

The way we handle VRS, and still get calls routed by the location of the
caller is to have the VRS service route the call like any other 9-1-1 call
would be routed, but they add a header that informs the PSAP that a CA is
available.  The PSAP then creates a 3 way video/audio call among the PSAP,
the caller and the CA.  If the PSAP wishes to use its own CA, it can do
so, but it needs to know this is a VRS call.  The PSAP doesn’t need to
handle video, since if it’s not sending/receiving video, it’s a 2 way
video, 3 way audio call, and even its bridge doesn’t really need to be in
the video path.

We certainly can have ecrit review drafts coming out of this work.  NENA
and EENA will also review.

I don’t believe there is a need to have an entirely separate document to
handle the emergency call flows.  We just need appropriate review, which
I’m sure we can arrange.

Brian

On 7/6/15, 11:30 PM, "Bernard Aboba" <bernard_aboba(_at_)hotmail(_dot_)com> 
wrote:

I agree that the "direct" model described in the draft is very
problematic.  One of the guiding principles of accessibility is that
services need to be available as widely as possible given PSAP
capabilities. Attempting to route VRS emergency calls directly will
actually dramatically reduce the ability of disabled users to reach
emergency services since video could not be accepted until the PSAP is
equipped to handle it, even if the interpretation service were able to do
so, and a call routed via the interpreting service could succeed with
full functionality.

These are exactly the kinds of issues that would be debated and addressed
within a WG with appropriate RAI focus, but which are likely to be
neglected in a WG whose Charter covers both emergency service
accessibility issues and email language selection.

At a minimum, I would like to see another work item relating to use of
the proposed language specification, including call flows, within a group
with emergency services or SIP expertise (such as ECRIT).

On Jul 6, 2015, at 7:13 PM, Rosen, Brian 
<Brian(_dot_)Rosen(_at_)neustar(_dot_)biz>
wrote:

While I think the “direct model” is actually very problematic, I think
that draft is quite appropriate for the basic purpose of making sure a
trained call taker gets the call.  And, of course, it’s also very useful
for generic routing of calls for which a VRS as a “transcoder” would be
a
much better way to make a generic video call look differently from a VRS
video call, and invoke proper treatment.

It’s also a better way to announce a VRS call to the call taker.  Today,
we don’t know it from any other 3rd party initiated video call.

As Randy says, we’ve discussed these issues with the NENA Accessibility
groups as well as the FCC accessibility committee folks.  We’ve also
been
discussing the issues with PSAPs who have some multi-lingual call
takers,
and would very much appreciate being able to route to the right queue.
And, of course, improving how PSAPs handle “Language Line” services is
one
of the basic goals of this work.  The direct model would make VRS look
exactly like Language Line.

Brian

On 7/6/15, 8:35 PM, "Randall Gellens" 
<randy(_at_)qti(_dot_)qualcomm(_dot_)com> wrote:

Hi Bernard,

I'd like to discuss your concerns a bit.  I've added Brian Rosen to
the email as he is chair of the NG (i3) architecture group in NENA.

I'm trying to understand why you believe that the call flow in 4.5
would result in rejection of the video stream, rather than the PSAP
engaging an interpretation service.  As you say, we are trying to
move from today's model in which the caller first calls the relay
service, and then the relay service bridges in the PSAP, to a direct
model where the caller calls 911 directly, and the PSAP bridges in
the relay service.  Obviously, there are funding issues that would
need to be handled in order for PSAPs to be able to invoke relay
services, but both the next-gen and accessibility groups in NENA want
a direct model (which offers many advantages, including priority
treatment and location delivery).  The NENA Policy-Based Routing
(PBR) functionality within an ESInet has the ability to use the SDP
when making routing decisions (in case PSAPs have cooperation
agreements where some PSAPs handle some types of calls or some
languages or media).

The draft and the issues have been discussed with the co-chairs of
the NENA accessibility WG, and they are strongly in favor of a direct
model for next-gen.

In the U.S., emergency call routing is first by location, and then by
local rules (if any).  For example, if a call requires text, there
might be some PSAPs in a cooperating group that take text calls on
behalf of others.  Likewise if the call requests audio or textual
Spanish.  In Europe, various models are under discussion, including
some in which a call might be routed to a PSAP in a country where the
caller's language is native.  The draft allows this flexibility: the
call can be routed to a specific PSAP (and even call taker) or the
PSAP can bridge in translation or relay services at the start of the
call.

At 5:15 PM -0700 7/1/15, Bernard Aboba wrote:

I believe that this Charter is poorly suited to developing
solutions to the problem faced by disabled users of realtime
emergency services.

In the case of access to emergency services by the disabled, the
goal is not "selection of the best-fit language", but rather,
routing of the call and media so as to pull together the services
best fitting the emergency situation and the disabilities of the
caller, as well as the capabilities of the device and
intermediaries which may sit between the caller and the PSAP.  Not
only are media and language intrinsically linked, but also, the
ways in which calls are routed is influenced and in some cases
prescribed by regulation and national standards.

Simply put, draft-gellens-slim-negotiating-human-language lacks
appropriate consideration of the problem context.  Specifying it as
the starting point is therefore inappropriate. As an example, today
the call flow described in Section 4.5 would most likely result in
rejection of the video portion of the call by the PSAP, leaving the
dispatcher with no means of communicating with the hearing-impaired
caller, thus leaving the caller worse off than they are today
attempting to make an emergency call within the (cumbersome and
error/delay-prone) Video Relay Service.   A fuller consideration of
the problem context would involve consideration of current
operation of relay services and proposals for their evolution.
Attempting to develop this problem context within a WG that is
also attempting to deal with language-selection in email would be
frustrating at best.

A sensible Charter would also probably include liaisons with
disability rights organizations, groups specifying the operation of
relay services, and groups considering next steps for access to
emergency services.

From: iesg(_at_)ietf(_dot_)org
To: new-work(_at_)ietf(_dot_)org
Date: Fri, 26 Jun 2015 08:36:05 -0700
Subject: [new-work] WG Review: Selection of Language for Internet
Media (slim)

A new IETF working group has been proposed in the Applications and
Real-Time Area. The IESG has not made any determination yet. The
following draft charter was submitted, and is provided for
informational
purposes only. Please send your comments to the IESG mailing list
(iesg
at ietf.org) by 2015-07-06.

Selection of Language for Internet Media (slim)
------------------------------------------------
Current Status: Proposed WG

Assigned Area Director:
Barry Leiba <barryleiba(_at_)computer(_dot_)org>

Mailing list
Address: slim(_at_)ietf(_dot_)org
To Subscribe: https://www.ietf.org/mailman/listinfo/slim
Archive: https://mailarchive.ietf.org/arch/browse/slim/

Charter:

Description of Working Group:

A mutually comprehensible language is helpful for human
communication.
This is true across a range of circumstances and environments. In
general, the problem is most acute in situations where there is not a
clear choice for a single language, such as environments lacking
contextual or out-of-band information regarding the identity of the
parties and the language to be used.

The group will address two specific cases that most urgently need a
technical solution: One problem space is non-real-time communication,
specifically email for one-to-many or where the set of recipients is
dynamic or different recipients require different languages; the
other is
real-time communication, specifically emergency calling, preferably
also
useful for other cases where the parties may not know each other
personally or where one party wishes to accommodate people with
varying
language and media needs.

In the real-time communication case, language and media are
intrinsically
linked, for example, signed languages require a video media.

While the two use cases are in different contexts (real time and
non-real-time), the fundamental goal is the same: to enable selection
of
the best-fit language(s) for a specific situation. Some of the
details
will also be in common across the cases, e.g., the language tags.
Having
a single WG address both cases makes it clear that these are two
aspects
of the same basic problem. A single WG also makes it easier to
maximize
similarities and avoid unnecessary fragmentation of the solutions,
and
facilitates broader review.

The group will produce two documents, one for email, and one for
real-time communications.

In the email case, the group will determine a MIME based solution
that
enables a single email message to contain multiple language versions
of
the content, with provisions to help clients select a best fit
version.

In the real-time communication case, the group will produce a
specification based on draft-gellens-slim-negotiating-human-language,
enabling negotiation of a human language per media stream. The
specification must be suitable for use in emergency communications as
specified in RFC 6443 and RFC 6881 (which use SIP and SDP to
negotiate
media); it is desirable to also be suitable for use in non-emergency
real-time communications that share the same call set-up and media
negotiation protocols. The mechanism will permit the caller's media
and
language needs and preferences to be matched against what the called
party is able to provide. The mechanism will permit resources (e.g.,
translation, relay, media) to be allocated or engaged as early as
possible in the call set-up or for the call to be routed or handled
specially (e.g., routed to a resource able to provide a needed
language
and/or media). Alternatives such as doing the negotiation in SIP have
been thoroughly explored in the past and are out of scope (although
the
scope might be extended after the SDP mechanism has been advanced).

By adding language to the existing media negotiation mechanism as
used in
RFC 6443 and RFC 6881, the group can meet the basic use cases with
minimal added complexity and be able to enhance later for additional
use
cases as needed.

Milestones:
Oct 2015 - Submit "Multiple Language Content Type" to the IESG (based
on draft-tomkinson-slim-multilangcontent)
Feb 2016 - Submit "Negotiating Human Language in Real-Time
Communications" to the IESG (based on
draft-gellens-slim-negotiating-human-language)

_______________________________________________
new-work mailing list
new-work(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/new-work



-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Just because you do not take an interest in politics doesn't mean
politics won't take and interest in you.  --Pericles (495-425 BC)

_______________________________________________
Ecrit mailing list
Ecrit(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ecrit


-- 
-----------------------------------------
Gunnar Hellström
Omnitor
gunnar(_dot_)hellstrom(_at_)omnitor(_dot_)se
+46 708 204 288

Re: [Ecrit] [new-work] WG Review: Selection of Language for Internet Media (slim)