Re: [MMUSIC] Notes from Orlando human language draft discussion

Gunnar Hellstrom <gunnar.hellstrom@omnitor.se> Sat, 16 March 2013 07:23 UTC

Return-Path: <gunnar.hellstrom@omnitor.se>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0102621F8CF4 for <mmusic@ietfa.amsl.com>; Sat, 16 Mar 2013 00:23:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level:
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_18=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uqENuXVgb2qf for <mmusic@ietfa.amsl.com>; Sat, 16 Mar 2013 00:23:16 -0700 (PDT)
Received: from vsp-authed-02-02.binero.net (vsp-authed02.binero.net [195.74.38.226]) by ietfa.amsl.com (Postfix) with SMTP id 0C5D221F8CF0 for <mmusic@ietf.org>; Sat, 16 Mar 2013 00:23:14 -0700 (PDT)
Received: from smtp01.binero.se (unknown [195.74.38.28]) by vsp-authed-02-02.binero.net (Halon Mail Gateway) with ESMTP; Sat, 16 Mar 2013 08:23:04 +0100 (CET)
Received: from [192.168.50.38] (h79n2fls31o933.telia.com [212.181.137.79]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-10-01.atm.binero.net (Postfix) with ESMTPA id 998933A149; Sat, 16 Mar 2013 08:23:04 +0100 (CET)
Message-ID: <51441DD6.5040706@omnitor.se>
Date: Sat, 16 Mar 2013 08:23:02 +0100
From: Gunnar Hellstrom <gunnar.hellstrom@omnitor.se>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4
MIME-Version: 1.0
To: Randall Gellens <randy@qti.qualcomm.com>
References: <p0624061acd691d9b38bc@dhcp-42ec.meeting.ietf.org> <514370DA.8080704@omnitor.se> <p06240627cd694d3bc6d3@dhcp-42ec.meeting.ietf.org>
In-Reply-To: <p06240627cd694d3bc6d3@dhcp-42ec.meeting.ietf.org>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: mmusic@ietf.org
Subject: Re: [MMUSIC] Notes from Orlando human language draft discussion
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 16 Mar 2013 07:23:17 -0000

On 2013-03-15 23:14, Randall Gellens wrote:
> At 8:04 PM +0100 3/15/13, Gunnar Hellstrom wrote:
>
>>  Examples:
>>  1. Many deafblind persons prefer to sign for sending, but require 
>> text reception.
>>
>>  2. Many hard-of-hearing persons want to talk but receive text back.
>>
>>  3. Many persons with speech disabilities want to send text but 
>> receive speech
>
> Yes, but that does not mean that the media streams need to be 
> explicitly negotiated such.  E.g., just because someone intends to 
> primarily use a text stream for sending does not mean it must be 
> prohibited to receive text back.
Yes, very true.
Other media and media directions than the ones you declare preference 
for are usually also appreciated, and sometimes important.
You said some time ago that a medium-direction with no language 
indication just means that there is no preferred language use of it, but 
it may very well be desired in the call and should be connected if 
supported. That was why the a=sendonly and a=recvonly attributes cannot 
be used for preference indications.

Let us take the deaf-blind example.

A deaf-blind person may prefer to sign, and prefer to receive text, and 
be able to send text.
But in contact with another deaf-blind person with same preferences and 
capabilities, there are then two choices:
1. Connect the call directly and type both ways.
or
2. Connect a relay service that handles sign-to-text translation both ways.

I would assume that most users for this case would select the direct 
connection, but that is a matter of preference and situation.

This can create a need for level of preference indication between two 
different media, and not just by position of a language within one medium.
I mean for the example above: prefer sign out, but manage text out.

/Gunnar