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

From: Bernard Aboba <[email-masked]>
Date: Mon, 6 Jul 2015 20:30:44 -0700

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 <[email-masked]> 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" <[email-masked]> 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: [email-masked]
>>>> To: [email-masked]
>>>> 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 <[email-masked]>
>>>> 
>>>> Mailing list
>>>> Address: [email-masked]
>>>> 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
>>>> [email-masked]
>>>> 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)
>

---

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 7 Jul 2015 12:51:51 +0000

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" <[email-masked]> 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).
>
>
>
>
>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 07 Jul 2015 10:06:04 -0400

> 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 EC…

+1

(But did you mean to sent this to ecrit, or slim?)

	Thanks,
	Paul

> Ecrit mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ecrit
>

---

From: Gunnar Hellström <[email-masked]>
Date: Tue, 07 Jul 2015 16:59:57 +0200

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.

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).

It is better if the mechanisms are general, and not emergency service 
specific. One reason is that users will then have much higher tendency 
to keep their preference settings in order. Another reason is that large 
parts of the mechanisms will be used and verified to work. The emergency 
service specific mechanisms have the risk of not being thoroughly tested 
for every kind of terminal/service provider/modality combination.

IN ETSI STF 489 we are right now intensively discussing the topics in 
this thread, and have a need to come to conclusions on realistic 
mechanisms that optimise user benefits in the emergency call scenarios.

One risk we have seen is what Brian also describes. A call with e.g. 
total conversation being routed to an ESInet entry of a country at the 
moment only supporting speech in the PSAPs. If it is a call requiring 
sign language translation, it is true that the ESInet or PSAP bridge 
could support video and real-time text even if no PSAP in that network 
does so. Then we can get a proper video relay invoked and accept to have 
the communication with the PSAP in speech with the interpreter.

But how can we handle the situation that there is a gap in NG112 
implementation. The user is in a country still on PSTN for 112. The 
search for an ESInet entry for that country will fail and the SIP 
service provider need to convert to PSTN emergency calling. Then it can 
not be expected that the 112 network can bridge the multimedia call.  It 
seems to me that for that case, the user terminal or sip service 
provider needs to have the bridge for that case.

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?

I just sent to SLIM also the view that SIP media and language tags as 
they are defined today can be used to detect need for sign language 
support ( as indicated in RFC 6443), while the asymmetric needs of 
deaf-blind communication or hard-of hearing communication will require 
slim-style indications and yet relay service users of speech-to-speech 
and captioned telephony services cannot describe their needs with the 
current proposed coding of slim, and woulld likely be better off to have 
a possibility to just request an assisting service by a URI and a sip 
operation.

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

-- 
-----------------------------------------
Gunnar Hellström
Omnitor
[email-masked]
+46 708 204 288

---

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 7 Jul 2015 15:31:22 +0000

See inline
> On Jul 7, 2015, at 10:59 AM, Gunnar Hellström <[email-masked]> 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.
I think this discussion should be held on the slim, but I left ecrit in.

> 
> 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).
IETF has no work group that handles relay or any other assisted service.  We’ll have to do it in dispatch I think, or sipcore.
> 
> It is better if the mechanisms are general, and not emergency service specific. One reason is that users will then have much higher tendency to keep their preference settings in order. Another reason is that large parts of the mechanisms will be used and verified to work. The emergency service specific mechanisms have the risk of not being thoroughly tested for every kind of terminal/service provider/modality combination.
I agree completely.  We really want the slim mechanism to be THE way we handle a request for relay, just like we want it to be the way we request language routing or translation for any other language
> 
> IN ETSI STF 489 we are right now intensively discussing the topics in this thread, and have a need to come to conclusions on realistic mechanisms that optimise user benefits in the emergency call scenarios.
We can work on the emergency call scenario in slim with ecrit participation.  I don’t think there is enough text to justify a separate document.
> 
> One risk we have seen is what Brian also describes. A call with e.g. total conversation being routed to an ESInet entry of a country at the moment only supporting speech in the PSAPs. If it is a call requiring sign language translation, it is true that the ESInet or PSAP bridge could support video and real-time text even if no PSAP in that network does so. Then we can get a proper video relay invoked and accept to have the communication with the PSAP in speech with the interpreter.
Right
> 
> But how can we handle the situation that there is a gap in NG112 implementation. The user is in a country still on PSTN for 112. The search for an ESInet entry for that country will fail and the SIP service provider need to convert to PSTN emergency calling. Then it can not be expected that the 112 network can bridge the multimedia call.  It seems to me that for that case, the user terminal or sip service provider needs to have the bridge for that case.
We’ve discussed the general problem of how does an origination carrier know that a call from a particular location is destined for a converted (i.e. NG9-1-1/RFC6881) PSAP, or not.  We’re heading towards having some LoST response that indicated that fact.   That could be used by the sip service provider to decide what to do.  
> 
> 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?
Yes, but I think there are exactly two places - the relay provider and the PSAP.
> 
> I just sent to SLIM also the view that SIP media and language tags as they are defined today can be used to detect need for sign language support ( as indicated in RFC 6443), while the asymmetric needs of deaf-blind communication or hard-of hearing communication will require slim-style indications and yet relay service users of speech-to-speech and captioned telephony services cannot describe their needs with the current proposed coding of slim, and woulld likely be better off to have a possibility to just request an assisting service by a URI and a sip operation.
I would think we add language tags for these cases.  

> 
> 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?
Dispatch to start.  Then we can decide where to do any work we think we need.

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 7 Jul 2015 10:31:55 -0700

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

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