Subject: [Slim] Expected use - relative to SIP and specific service requests in draft-gellens-slim-negotiating-human-language-02

From: Gunnar Hellström <[email-masked]>
Date: Mon, 06 Jul 2015 12:28:32 +0200

I saw that -02 is out. Good!

A couple of comments:

1. Expected use relative to SIP.

It seems decided now that the mechanism will be adapted to use in SDP.

The use of the Accept-Language media tag is already described for 
negotiation of language in emergency calls in RFC 6443, e.g. in section 9.2:
"

    SIP caller preferences [RFC3841  <https://tools.ietf.org/html/rfc3841>] can be used to signal how the PSAP
    should handle the call.  For example, a language preference expressed
    in an Accept-Language header may be used as a hint to cause the PSAP
    to route the call to a call taker who speaks the requested language.
    SIP caller preferences may also be used to indicate a need to invoke
    a relay service for communication with people with disabilities in
    the call."

Since this recommendation already is there, it seems that we need to 
describe how the humintlang parameter in SDP relates to it.

I suggest to add to chapter 3, Expected use, the following paragraph:

"Basic preferencs and capabilities for languages modalities and media 
can be expressed by media tags in SIP. These indications may be used in 
parallell with the indications specified in this document. Some aspects 
such as directionality, and exact order of preference are not possible 
to specify at SIP level. Therefore, parties who have such detailed 
preferences or capabilities are recommended to use the coding specified 
in this document. Parties performing negotiation and routing should take 
both sets of indications into consideration. In cases when the 
indication seem to be contradicting, the indications specified in this 
document should be used. "

2. Service requests instead of language and modality indications.
There are two kinds of common relay services that I cannot see how we 
can indicate need for using the coding we have specified so far.
I see a need to either extend the coding or recognize the limitation in 
scope to not cover these two relay service types.

The two cases are:

A) A person with hearing loss, being accustomed to have the captioned 
telephony service.
This service provides:
1) voice through from the primary user to the  other user.
2) voice through from the other user to the primary user.
3) rapidly added real-time text transcription of the speech to the 
primary user sent for presentation to the primary user. Ideally all 
words the other user says is converted to text and the delay from being 
said to being displayed should only be a few seconds.

The users might have some use of seeing each other in video, and the 
primary user may as a last resort accept to have text typed with normal 
typing speed if that is the only available replacement.

Expressing this in SLIM terms would require that the primary user expresses:
( I do not include the language here, but just the modality in order to 
not complicate it further )
1. preference for speech transmission,
2. capability but no specific preference for video transmission
3. strong preference for speech reception AND strong preference for 
rapid captioning of received speech to real-time text reception
4. some acceptance of real-time text reception as alternative to 
captioning.
5. capability but no specific preference for video reception

Since no other user can be expected to both talk and type the same thing 
at the rate of talking.  Maybe it can be solved in some cases by 
automated captioning.
Do we want to introduce two types or qualities of text translation; 
rapid vs "normal"?  I see some similarity with the translation type and 
quality discussion. Note that this is only of interest for translated 
media. Shall we create a coding that clearly requests rapid caption, or 
shall we say that for this need, the user should make a service request 
instad?

B) A person with weak or otherwise hard-to-understand speech or 
cognitive problems with spoken conversations.
This primary user is normally a user of a Speech-to-speech relay service.
That service offers:

1. Speech through from the primary user to the other user.
2. Speech through from the other user to the primary user
3. A communication agent in a full 3-party voice bridge connection, 
supporting the primary user with the communication needs, consisting of 
e.g. : a) repeating in clear speech what the primary user expresses in 
weak or hard-to-understand speech. b) noting what has been said in the 
call in order to refresh the memory of the primary user during or after 
the call. c) Reminding the primary user of the purpose and plan for the 
call when needed.
4. Optionally two way video between the primary user and the 
communications agent. This can ease understanding.
5. Optionally two way text between the primary user and the 
communications agent. This can be an alternative in case of problems.

Some speech-to-speech service users might be prepared to as a last 
resort conduct calls where the primary user types real-time text and the 
other user uses speech.

We have not even talked about the modalities of "weak or 
hard-to-understand speech" and "needs for memory refresh and other 
cognitive support" in SLIM, and it causes severe frustration and 
inefficiency for both parties if a speech-to-speech user is left in a 
call without support from the service,  so I think this need is better 
served by a service need expression for the specch-to-speech service.

That would call for an addition in section 3:

"Some needs of services to enable real-time conversational interaction 
cannot easily be described as language and modality preferences and 
capabilities. Other mechanisms for invoking suitable assisting services 
may be used for such cases."

/Gunnar
[email-masked] skrev den 2015-07-06 07:47:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>
>
>          Title           : Negotiating Human Language in Real-Time Communications
>          Author          : Randall Gellens
> 	Filename        : draft-gellens-slim-negotiating-human-language-02.txt
> 	Pages           : 19
> 	Date            : 2015-07-05
>
> Abstract:
>     Users have various human (natural) language needs, abilities, and
>     preferences regarding spoken, written, and signed languages.  When
>     establishing interactive communication ("calls") there needs to be a
>     way to negotiate (communicate and match) the caller's language and
>     media needs with the capabilities of the called party.  This is
>     especially important with emergency calls, where a call can be routed
>     to a Public Safety Answering Point (PSAP) or call taker capable of
>     communicating with the user, or a translator or relay operator can be
>     bridged into the call during setup, but this applies to non-emergency
>     calls as well (as an example, when calling a company call center).
>
>     This document describes the need and expected use, and describes a
>     solution using new SDP stream attributes.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-gellens-slim-negotiating-human-language/
>
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-gellens-slim-negotiating-human-language-02
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-gellens-slim-negotiating-human-language-02
>
>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

-- 
-----------------------------------------
Gunnar Hellström
Omnitor
[email-masked]
+46 708 204 288