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.Rosen@xxxxxxxxxxx> 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@xxxxxxxxxxxxxxxx> 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@xxxxxxxx >>>> To: new-work@xxxxxxxx >>>> 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@xxxxxxxxxxxx> >>>> >>>> Mailing list >>>> Address: slim@xxxxxxxx >>>> 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@xxxxxxxx >>>> 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) >