Re: [Slim] Modality preference

[Gunnar Hellström <[e-mail]>]

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.

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.

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

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.

Regards
Gunnar
>
> Brian
>
>> On Jun 19, 2017, at 7:43 AM, Filip Asplund <[e-mail]> wrote:
>>
>> In development of emergency services the need of modality preference has been identified.
>>
>> It seems to me that the functions specified in draft-hellstrom-language-grouping is what we need for emergency services.
>>
>> -- 
>> Best regards
>>
>> Filip Asplund
>> Developer
>> [e-mail]
>> Omnitor AB
>>
>> _______________________________________________
>> SLIM mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/slim
> _______________________________________________
> SLIM mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/slim

-- 
-----------------------------------------
Gunnar Hellström
Omnitor
[e-mail]
[phone]