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