Subject: Re: [MMUSIC] draft-gellens-mmusic-negotiating-human-language-00.txt - asymmetric preferences

From: Gunnar Hellstrom <[email-masked]>
Date: Mon, 08 Jul 2013 12:08:38 +0200

Randall,
It is good to see this shape up.

One initial comment:

The draft discourages in an infavourable way from specifying 
asymmetrical preferences.

In 7.1, it says:

"In an offer, the 'humintlang-send' values constitute a list in
    preference order (first is most preferred) of the languages the
    offerer wishes to send, and the 'humintlang-recv' values constitute a
    list in preference order of the languages the offerer wishes to
    receive.  Both SHOULD have the same values in the same order, because
    otherwise it is harder to match desired resources."

A typical example of a user who do not want to specify the same value in 
both directions is a hard-of-hearing user who prefers to speak English 
but might accept to type English text on the transmission side,  but 
prefers to read English text and do not have sufficient hearing to at 
all handle hearing spoken English on the receiving side.

In the audio media specification there would then be humintlang-send 
value English,  and nothing in the humintlang-recv.
While in the text media specification there would be humintlang-send 
value for English, that would need a very much lower preference than the 
audio send, and the humintlang-recv value for English.

Note also the need for an absolute preference indication. Or relative 
between media. This user will be quite disappointed to be forced to 
handle the call in text both ways.

With this background, the SHOULD in the cited section is not desirable. 
I suggest to delete that sentence.

There is a similar problem with the last paragraph in 7.1

"  When placing an emergency call, and in any other case where the
    language cannot be assumed from context, each media stream in an
    offer SHOULD specify both 'humintlang-send' and 'humintlang-recv'
    attributes (to avoid ambiguity), and both SHOULD be set to the same
    values in the same order."

Since users may have capability for only one direction of a modality, it is not reasonable to require them to
  specify a value in the direction they do not have a capability in.

So this paragraph should be deleted or modified.

Thanks

Gunnar

------------------------------------------------------------------------
Gunnar Hellström
Omnitor
[email-masked]
+46708204288
On 2013-07-08 00:39, [email-masked] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>
>
> 	Title           : Negotiating Human Language Using SDP
> 	Author(s)       : Randall Gellens
> 	Filename        : draft-gellens-mmusic-negotiating-human-language-00.txt
> 	Pages           : 13
> 	Date            : 2013-07-07
>
> 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 communicate and ideally match (i.e., negotiate) the caller's
>     language preferences 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 plus an optional SIP "hint."
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-gellens-mmusic-negotiating-human-language
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-gellens-mmusic-negotiating-human-language-00
>
>
> 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

---

From: Gunnar Hellstrom <[email-masked]>
Date: Mon, 08 Jul 2013 14:08:32 +0200

There is a good description of avoidance of using subtags in 7.1, third 
paragraph from the end.

It may be good to inform after that paragraph about the language tags 
that can be used for video.
There are separate language tags for sign languages.
So, for the video medium, that can be used to distinguish between two 
different usages of video; for sign language versus for assisting 
hearing with the view of the speaking human for lip-reading or for just 
emphasizing the understanding by a view of the speaker.

Insert a new paragraph to be the third from the end of 7.1:

For indication of preferences and capabilities of sign languages, the 
specific sign language tags of RFC 5646 SHALL be used in the video media 
specifications.
Preference and capability of a spoken language tag (i.e. not a sign 
language) indicated in the video media specification SHOULD be used for 
indicating a view of the speaking human that may be needed or preferred 
for speech-reading assisted hearing.

Regards

Gunnar

---

From: Gunnar Hellstrom <[email-masked]>
Date: Tue, 09 Jul 2013 07:50:15 +0200

On 2013-07-09 03:51, Randall Gellens wrote:
> Re: [MMUSIC] draft-gellens-mmusic-negotiating-human-langua
> Hi Gunnar,
>
> Thanks for the quick review and comments.
>
>
> At 12:08 PM +0200 7/8/13, Gunnar Hellstrom wrote:
>
>> In 7.1, it says:
>> A typical example of a user who do not want to specify the same value 
>> in both directions is a hard-of-hearing user who prefers to speak 
>> English but might accept to type English text on the transmission 
>> side,  but prefers to read English text and do not have sufficient 
>> hearing to at all handle hearing spoken English on the receiving side.
>
> This is very similar to the use case included of a user who can hear 
> English but not speak; an audio and text stream are set up, both using 
> English.  The point of negotiating language is to get the call to a 
> callee who can communicate with the caller (e.g., a PSAP and call 
> taker who understand at least one language in common with the 
> caller).  The point is not to fully specify exactly how the media will 
> be used; there is no need to do so and it won't help get the call to 
> the right callee, but will make things much more complex.
>
> It is simpler and more robust to handle cases such as you describe and 
> the one in the document now by negotiating the needed media as two-way 
> streams.
Yes, two-way streams should usually be setup, on the media level. A 
media direction without a declared preference is usually valuable 
anyway. But that is not what the language specification aims at. The 
goal is to match caller, callee and possibly required assisting services 
to fill gaps between in preferences and capabilites between caller and 
callee.

I said that the proper declaration for this example would be:
In the audio media specification there would be humintlang-send value 
English,  and nothing in the humintlang-recv.
While in the text media specification there would be humintlang-send 
value for English, (that would need a very much lower preference than 
the audio send), and the humintlang-recv value for English.
You say that the declaration should instead be symmetrical:
In the audio media specification there would be humintlang-send value 
English,  and English in the humintlang-recv.

This is falsely declaring a preference, and cannot contribute to more 
successful matching.

If this person calls another person with the same characteristics, and 
the same declaration, a comparison of their preferences would result in 
connecting them together without assisting service, because the language 
specifications indicate that they happily both talk and hear.
Resulting in that they are left there without an opportunity to talk to 
each other.

Instead keeping the declaration to the truth and not have a value for 
audio humintlang-recv, makes it possible to evaluate the need, and 
provide a two-way captioned telephony service for the call.

Another point for truthful declaration is that the parties can get 
indications on how to behave in the call. If a call-center get a call 
from the deaf person in the example above with spoken English 
declaration both ways, and English text specification both ways, it is 
natural for the call center to try speaking a welcome phrase. There is 
no indication that typing will be needed. The calling person has no 
hearing capability and need therefore to explain with voice  "I am deaf, 
please type". The call starts with a disappointing confusion instead of 
a nice welcome in the appropriate language and modality that would be 
achievable if the declaration shows the real preferences and capabilities.

So, therefore I suggest to delete the sentences requiring symmetric 
humintlang declarations.

Thanks
Gunnar Hellström

> -- 
> Randall Gellens

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 8 Jul 2013 23:56:34 -0700

This is very similar to the use case included of a user who
        can
        hear English but not speak; an audio and text stream are set up,
        both
        using English.  The point of negotiating language is to get the
        call to a callee who can communicate with the caller (e.g., a
        PSAP and
        call taker who understand at least one language in common with
        the
        caller).  The point is not to fully specify exactly how the
        media
        will be used; there is no need to do so and it won't help get
        the call
        to the right callee, but will make things much more complex.

      It is simpler and more robust to handle cases such as you
        describe and the one in the document now by negotiating the
        needed
        media as two-way streams.
    
    [BA]  I think this example points out the limitations of a call routing approach that relies solely on language. In this case, it is important for the "hint" to cause the call to be routed to an endpoint that can handle text media, since otherwise the caller will not be able to communicate.  Since both the audio and text media are set up using English in both directions, one might conclude that the "hint" need only express the language preference (English), but that would not be sufficient to get a satisfactory result.  What needs to be expressed in the "hint" is *both* a preference for English and a requirement for text media support.

---

From: Gunnar Hellstrom <[email-masked]>
Date: Tue, 09 Jul 2013 09:58:20 +0200

On 2013-07-09 08:56, Bernard Aboba wrote:
>
>     This is very similar to the use case included of a user who can
>     both using English.  The point of negotiating language is to get
>     the call to a callee who can communicate with the caller (e.g., a
>     PSAP and call taker who understand at least one language in common
>     with the caller).  The point is not to fully specify exactly how
>     the media will be used; there is no need to do so and it won't
>     help get the call to the right callee, but will make things much
>     more complex.
>     It is simpler and more robust to handle cases such as you describe
>     and the one in the document now by negotiating the needed media as
>     two-way streams.
>
> [BA]  I think this example points out the limitations of a call 
> routing approach that relies solely on language. In this case, it is 
> important for the "hint" to cause the call to be routed to an endpoint 
> that can handle text media, since otherwise the caller will not be 
> able to communicate.  Since both the audio and text media are set up 
> using English in both directions, one might conclude that 
> the "hint" need only express the language preference (English), but 
> that would not be sufficient to get a satisfactory result.  What needs 
> to be expressed in the "hint" is *both* a preference for English and a 
> requirement for text media support.
<GH>And the humintlang specification allows that if the requirement to 
have symmetric specifications per media is deleted ( as described in 
another mail ).

But there is also a need for absolute preference. Or relative order of 
preference between media.

It is easy to use a sign language example fort that situation.

A person prefers to use British sign language in both directions but is 
capable with some reluctance to use English text. That is natural. Text 
is always slower and less expressive than sign language or spoken language.

A call goes to a call center that declared spoken English and English 
text in both directions.
The result can be a direct connection using English text, or invocation 
of a sign relay service translating between British sign language and 
spoken English.

An ability to declare that the British sign language is preferred over 
the English text would result in the invocation of the sign relay 
service and make both sides happy with a call with good flow.

Without the relative preference between media, the call will likely 
result in the direct text communication that will work but with less 
satisfaction.

This can be solved either by an absolute preference indication  : 
British sing language *preferred*  , English text *managed*
Or by some order of preference between the media;  video *preferred* 
text *managed*

I think an absolute preference indication is easiest to handle. Media 
preference will collide with relative preference between languages in 
each medium.

I suggest that that is introduced with some suitable coding.

/Gunnar Hellström

> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

---

From: Randall Gellens <[email-masked]>
Date: Mon, 8 Jul 2013 18:51:25 -0700

Hi Gunnar,

In 7.1, it says:

"In an offer, the
'humintlang-send' values constitute a list in

preference order (first is most preferred) of the
languages the

offerer wishes to send, and the 'humintlang-recv' values
constitute a

list in preference order of the languages the offerer
wishes to

receive.  Both SHOULD have the same values in the
same order, because

otherwise it is harder to match desired
resources."

A typical example of a user who do not
want to specify the same value in both directions is a hard-of-hearing
user who prefers to speak English but might accept to type English
text on the transmission side,  but prefers to read English text
and do not have sufficient hearing to at all handle hearing spoken
English on the receiving side.

This is very similar to the use case included of a user who can
hear English but not speak; an audio and text stream are set up, both
using English.  The point of negotiating language is to get the
call to a callee who can communicate with the caller (e.g., a PSAP and
call taker who understand at least one language in common with the
caller).  The point is not to fully specify exactly how the media
will be used; there is no need to do so and it won't help get the call
to the right callee, but will make things much more complex.

It is simpler and more robust to handle cases such as you
describe and the one in the document now by negotiating the needed
media as two-way streams.

--

Randall Gellens

Opinions are personal;    facts are
suspect;    I speak for myself only

-------------- Randomly selected tag: ---------------

... Any resemblance between the above views and those of my

employer, my terminal, or the view out my window are purely

coincidental.  Any resemblance between the above and my own

views is non-deterministic.  The question of the existence of

views in the absence of anyone to hold them is left as an

exercise for the reader.  The question of the existence of the

reader is left as an exercise for the second god coefficient.

(A discussion of non-orthogonal, non-integral polytheism

is beyond the scope of this article.)

---

From: Randall Gellens <[email-masked]>
Date: Mon, 8 Jul 2013 19:03:22 -0700

Hi Gunnar,

Thanks again for the quick review and comments.

I agree it can be helpful to include a clarifying note that a
spoken language can be used with a video stream to indicate a request
to see the speaker.  I'm not sure that normative language is
needed here but I have added informative text to both 7.1 and 7.4 (on
silly states).

At 2:08 PM +0200 7/8/13, Gunnar Hellstrom wrote:

There is a good description of avoidance
of using subtags in 7.1, third paragraph from the end.

So, for the video medium, that can be used to distinguish between two
different usages of video; for sign language versus for assisting
hearing with the view of the speaking human for lip-reading or for
just emphasizing the understanding by a view of the speaker.

For indication of preferences and capabilities of sign languages, the
specific sign language tags of RFC 5646 SHALL be used in the video
media specifications.

Preference and capability of a spoken language tag (i.e. not a sign
language) indicated in the video media specification SHOULD be used
for indicating a view of the speaking human that may be needed or
preferred for speech-reading assisted hearing.

Regards

Gunnar

Gunnar Hellström

Omnitor

+46708204288

mmusic mailing list

[email-masked]

--

Randall Gellens

-------------- Randomly selected tag: ---------------

Studied carefully, a modern payphone reveals itself as a little

fortress, carefully designed and redesigned over generations, to resist

coin, slugs, zaps of electricity, chunks of coin-shaped ice, prybars,

magnets, lockpicks, blasting caps. Public pay- phones must survive in a

world of unfriendly, greedy people, and a modern payphone is as

exquisitely evolved as a cactus.

--Bruce Sterling

---

From: Randall Gellens <[email-masked]>
Date: Tue, 9 Jul 2013 14:48:30 -0700

At 11:56 PM -0700 7/8/13, Bernard Aboba wrote:

> routing approach that relies solely on language. In this case, it 
> is important for the "hint" to cause the call to be routed to an 
> endpoint that can handle text media, since otherwise the caller 
> will not be able to communicate.  Since both the audio and text 
> media are set up using English in both directions, one might 
> conclude that the "hint" need only express the language preference 
> (English), but that would not be sufficient to get a satisfactory 
> result.  What needs to be expressed in the "hint" is *both* a 
> preference for English and a requirement for text media support.

[RG] In the case of emergency calls, policy based routing can look at 
media needs and with the proposal to include language in SDP, also 
language.  So for emergency calls, there is no need for a SIP "hint." 
The SIP "hint" is in the current draft because at the Orlando 
discussion it was suggested as a way to allow non-emergency calling 
facilities that lack the ability to examine SDP when determining call 
handling.  I agree that it isn't sufficient if the caller requests 
non-audio media.  I think currently, corporate call centers usually 
have a dedicated number for text communications, while for audio they 
resort to "press 1 for <default language>, 2 for <alternate language 
1>, ..." approaches.  So having just language in the hint would map 
to current usage.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
This is not a novel to be tossed aside lightly.  It should
be thrown with great force.               --Dorothy Parker