Re: [Slim] Eric Rescorla's No Objection on draft-ietf-slim-negotiating-human-language-19: (with COMMENT)

It hasn't been my understanding that language would be sprung on users; if video is requested in an offer to carry ASL, that would be in the offer, and if the answerer can support ASL, the answer includes video with ASL. In North America, callers needing sign language interpretation or text translation usually initiate calls via the interpreter/relay service, but this might not be true elsewhere. In North America, PSAPs have the ability to handle text calls (legacy PSAPs support TTY; next-gen PSAPs support RTT). Calls needing language translation might internally be handled by staff who speak the language or an external language translation service might be bridged in, (e.g., an emergency call routed to a PSAP in San Diego might have call takers who speak Spanish but might need a third-party translator for French, the opposite for a PSAP in Montreal). 

Sent from my iPad

> On Jan 6, 2018, at 7:31 PM, Bernard Aboba <bernard.aboba@gmail.com> wrote:
> 
> On Jan 6, 2018, at 6:55 PM, Eric Rescorla <ekr@rtfm.com> wrote:
> 
>>> For disabled users, the capabilities may not be symmetric. 
>> 
>> But this is true for ordinary SDP as well. I might be able to receive H.264 but not send it.
> 
> [BA] Thanks. The draft should explain the reasoning. IMHO the argument goes sonething like this:
> 
> A pure recv/recv negotiation will not necessarily disclose beforehand what special services are needed for the call - services (e.g. ASL interpretation or RTT handling) that could take time to acquire. 
> 
> Since the actual video media sent is not labelled as ASL even if the answerer has ASL interpreters it can pull in and therefore advertises in SDP ASL reception capability in video, a recv/recv negotiation doesn’t tell the Answerer that the Offerer will need them, so the Answerer may need to (frantically) arrange for ASL interpretation after initial receipt of media. In an emergency, that can chew up valuable time.
> 
> 
> _______________________________________________
> SLIM mailing list
> SLIM@ietf.org
> https://www.ietf.org/mailman/listinfo/slim
> 