Re: [Slim] Modality preference

[Brian Rosen <[e-mail]>]

> On Jun 19, 2017, at 3:54 PM, Gunnar Hellström <[e-mail]> wrote:
> 
> Brian,
> 
> You are right, that neither the hlang negotiation, nor the language grouping negotiation should influence decisions to enable a media stream or not. 
> The draft-hellstrom-language-grouping specification says: "
> The grouping semantics defined in this document are only informing
>    about language contents disposition in media and SHOULD not be taken
>    as reasons to enable or reject media streams.
> "
> So, let us avoid discussion on the influence on enabling media of the specified mechanisms. 
> 
Okay, my mistake.

> Den 2017-06-19 kl. 15:31, skrev Brian Rosen:
>> We’ve been working on supporting emergency services with multiple media for some time in the NENA Next Generation 9-1-1 project.
>> 
>> At least in the U.S., all media offered should be accepted.  The language preference will be negotiated, and based on the result, an interpreting service may be bridged into the call.
>> As such, a modality preference is not seen as valuable, and in fact, could be considered harmful, as the call taker should be trained to provide an initial answer in all media negotiated and react to the user’s actions thereafter.  An important characteristic of emergency services when viewed from the lens of the slim work is that the mechanisms have to work for the small percentage of cases where the normal mechanisms fail.  In this case, it would be use of a device with language and media preferences labeled by a user who isn’t the usual user of the device when an emergency call is placed.  You do NOT want to assume that the labeled preferences are actually the real preferences.  You bias your responses by the preferences, but you have to allow for variation when the call is actually answered.  So, answering in all offered media is something we would do, regardless of what the highest media preference was.
> [GH]That sounds good as a theory, but may turn out to be equally harmful as you think that obeying modality
> preference would be. 
> Answering in all modalities may cause an uncertainty of the caller for which modality to best continue the conversation. 
> And it can cause delays and resource waste if you want to answer with sign language in all calls indicating sign language competence. The indication of sign language competence can be for the case I have repeated many times: A hearing person competent in sign language but preferring spoken language. In order to not get everyday calls with deaf signing persons to invoke a video relay service, it is of value to specify sign laguage competence, but on a lower preference level that spoken language for this person.
> Having that sign language competence indication cause a PSAP to answer with sign language will cause delays and resource usage if not the first sign language answer is only a recording.
You put English first and ASL second on the video stream.   The right thing happens.  

> 
> If you had the opportunity to use modality preference I would think that you got better success rate and satisfied users if you first answered in the most preferred modality, and be prepared to retry     with less favoured modalities a few seconds later in order to cater for the few cases with a borrowed phone.
I don’t think so.  Please try to find a better example.  I can’t think of one.
>>  
>> 
>> Another reason why media preference is not really wanted is that emergency services can use other media even when the user doesn’t prefer to use them.  An audio feed for a deaf caller can be helpful to identify what is happening around the caller.  A video feed for a blind caller (if the device really made the offer) could similarly be useful.
> [GH]This is not a reason to not want modality preference.
> As said initially, we are not discussing negotiating the enabling of media. We are only specifying guidance for which language and modality to use initially in the call.
> (we have a good parallell in RFC 4796, the SDP Content attribute, where it is said: "
> 'content' values are just informative at the offer/answer model [8 <https://tools.ietf.org/html/rfc4796#ref-8>] level." Maybe we should include a clear
>  statement like that in the SLIM real-time drafts.
>> 
>> So, I think this is not a useful capability for emergency services and if it was in the offer, I’d tend to want to ignore it and accept all media, with an initial greeting in the preferred language.
> Even if that would be feasible for the emergency service case, you need to consider that the communicationn device needs also be useful in the everyday call situation. In that situation, the answering part will not normally have the capability to answer in three modalities in parallell. A modality preference indication is essential for the call to start smoothly with an answer in a modality and language that the caller is willing to receive, and a modality preference indication to the caller is essential for the caller to start using the most suitable modality. 
First of all, this thread is specifically about emergency services.  I’m not objecting to the follow on work you are proposing.  I just don’t think it’s useful or even desirable for emergency services.
I also think that if you offer 3 modalities, you can handle all 3 simultaneously.  That is the way real systems actually work,  My video conference systems are now all 3 modality systems,  They offer video, audio and text at answering time.  It’s normal to start with audio, but some people actually announce themselves with text if they join late.  Everything seems to work fine,  If an ASL caller joins, they might be initially be greeted via audio but the response in ASL would happen immediately, with smooth transitions by all parties.
> 
> So, please accept that there are good motivations for a modality preference indication. You promised me a review of a separate draft for this functionality. 
> As you may have seen, I first created two drafts for indications integrated with draft-ietf-slim-negotiating-human-language, and then an alternative more self-sustained, based on the SDP grouping     framework. I would also appreciate your assessment of which alternative to prefer and proceed with. I prefer 
> draft-hellstrom-language-grouping; it is more consistent and has no known interop problems.
I will review the drafts soon.