Re: [AVTCORE] draft-ietf-avtcore-multi-party-rtt-mix-00 Issue 1: transport

Gunnar Hellström <gunnar.hellstrom@ghaccess.se> Tue, 12 May 2020 04:46 UTC

Return-Path: <gunnar.hellstrom@ghaccess.se>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10C4B3A0BB5 for <avt@ietfa.amsl.com>; Mon, 11 May 2020 21:46:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=egensajt.se
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VrIhvjMk-_tx for <avt@ietfa.amsl.com>; Mon, 11 May 2020 21:46:18 -0700 (PDT)
Received: from smtp.egensajt.se (smtp.egensajt.se [193.42.159.246]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 599FC3A0BB2 for <avt@ietf.org>; Mon, 11 May 2020 21:46:16 -0700 (PDT)
Received: from [192.168.2.136] (h79-138-72-251.cust.a3fiber.se [79.138.72.251]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: gunnar.hellstrom@ghaccess.se) by smtp.egensajt.se (Postfix) with ESMTPSA id 9D9A620070; Tue, 12 May 2020 06:46:14 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=egensajt.se; s=dkim; t=1589258774; bh=ppfwWWTQzaHpjtuLiD+PY3anetIRMIL577vrQRVOXtY=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=YAVzcOQP9r19eo0iLzDKgM4XCSVC9d1vcnz51jPgZuf0XmlNAU86eiWbyih8Zl5gI xkEtJCC6J5EOgZt6dMPuIdNrmnXECYhI4sWzUS7UgrGH6BRM3sPkEzhZCPEfzYklMU yflS/k2dviJvTa9KP+0aZ1Lf2NKe37eDkQTB086Y=
To: "Dale R. Worley" <worley@ariadne.com>
Cc: avt@ietf.org
References: <87o8qt3nmy.fsf@hobgoblin.ariadne.com>
From: Gunnar Hellström <gunnar.hellstrom@ghaccess.se>
Message-ID: <3cfa3688-f1d1-a27c-4fd6-e38a82974a2d@ghaccess.se>
Date: Tue, 12 May 2020 06:46:12 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0
MIME-Version: 1.0
In-Reply-To: <87o8qt3nmy.fsf@hobgoblin.ariadne.com>
Content-Type: multipart/alternative; boundary="------------557955C31E6619DDF9C3BA8E"
Content-Language: sv
Archived-At: <https://mailarchive.ietf.org/arch/msg/avt/Sfaelo1hHWDTVG82zqBj-AbqHY8>
Subject: Re: [AVTCORE] draft-ietf-avtcore-multi-party-rtt-mix-00 Issue 1: transport
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/avt/>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 12 May 2020 04:46:22 -0000

Dale, thanks for good comments,

Den 2020-05-12 kl. 04:14, skrev Dale R. Worley:
> Speaking to one aspect of one point:
>
> Gunnar Hellstrom <gunnar.hellstrom@ghaccess.se> writes:
>> That
>> means real-time transmission while text is created and accepting some
>> rare dropouts just as we do with voice and video. However, users are
>> nowadays used to text messaging where it is customary to accept a delay
>> and get the text complete in most cases, rather than to have loss. That
>> user experience might be expected from real-time text as well.
I see I did not express myself clearly. The introduction should have been:

That means real-time transmission while text is created and accepting 
some rare dropouts just as we do with voice and video. However, users 
are nowadays used to text messaging where it is customary to accept a_*n 
extra*_ delay_*in case of network errors *_and get the text complete in 
most cases, rather than to have loss. That user experience might be 
expected from real-time text as well.

>> I was attending IETF meetings around the time that "real-time text"
>> became an important project, and my understanding is that the
>> deaf/hard-of-hearing community is very insistent on the real-time nature
>> of it, as in seeing the pacing of how the sender is typing characters.
>> In particular, the SIP MESSAGE method, which resembles mobile phone text
>> messages, was considered quite inadequate.
>>
>> The possibility of lost packets was compensated for by the RTP
>> redundancy mechanism.
>>
>> Poking around, I find https://en.wikipedia.org/wiki/Real-time_text,
>> which points to the Real Time Text Task Force
>> http://www.realtimetext.org/, which has an FAQ
>> http://www.realtimetext.org/FAQ containing
>>
>>      Why is Real-Time Text important to people who are deaf or hard of
>>      hearing?
>>
>>      In addition to its many applications for fully hearing people, Real-Time
>>      Text is important as an equivalent alternative to voice communications
>>      for people who are deaf and hard of hearing. It allows a more natural,
>>      bi-directional flow of text based conversation to take place compared
>>      with the "type-enter-wait-read-response-reply" technology of IM(chat)
>>      and SMS.
>>
>>      In fact: when Real-Time Text is fully mainstream, it will be solving one
>>      of the biggest accessibility problems of Internet communications for
>>      people who are deaf or hard of hearing!
Yes, and it is sad that real-time text has not yet become the way we 
normally communicate in text. If the big text chat services would send 
text while it is created, we would not sit waiting for next complete 
message, but could follow the thoughts of the other party as they are 
expressed in words and be ready to respond sooner. That would save 
stress and time.
>>
>> While searching for that, I found that Verizon has a big page on how to
>> activate RTT on various phone models
>> https://www.verizon.com/about/accessibility/real-time-text
Yes, you can also find similar information from other operators and 
manufacturers. But usually in the Accessibility area.

>>
>> Dale

Thanks,

Gunnar

-- 
Gunnar Hellström
GHAccess
gunnar.hellstrom@ghaccess.se