Subject: RE: [Sipping] Ready for IESG review: draft-ietf-sipping-toip-05.t xt

From: "Roy, Radhika R." <[email-masked]>
Date: Tue, 4 Jul 2006 22:23:49 -0400

Gunnar:
 
I am completely OPEN to accept any superior technical arguments. Please see
my replies in line [RRR]. I am sure that you will be convinced.
 
Please do not hesitate to let me know if you still have any more technical
questions. I appreciate that your time and patience.
 
Best regards,
Radhika

  _____  

From: Gunnar Hellström [mailto:[email-masked]]
Sent: Mon 7/3/2006 3:44 PM
To: [email-masked]; Sipping@Ietf. Org
Subject: SV: [Sipping] Ready for IESG review: draft-ietf-sipping-toip-05.t
xt

Radhika,

I will try once more and add explanations to the cases when you think I am
not right.

2.1. and 2.2 The term "real-time text"
Here I have already accepted that we may very well add "real-time" where you
suggest and delete the words "conversational" and "interactive".
I have also agred that we use the term "real-time text" as often as it is
practical nowadays.

[RRR] OK, thnak you so much.

So, this is just an effort to ask you to open your mind to existing use of
the word "text".
Most often the setting indicates if we are talking about a real-time service
or a store-and retrieval service.
In my every-day job, I work a lot with real-time conversational services
with video, real-time text and audio. In that setting it is not needed to
keep saying real-time text. When we talk about text people know it is the
text with real-time flow we are talking about. Since long there has been
text telephones, text relay services, text calls, text gateways, text users
and we always mean that they use real-time text. If not, we need to mark it
by for example adding "message".

[RRR] You are coming from a different angle that is non-technical. When we
create standards, we MUST live with examples that do not create further
"technical" confusions. To use a NEW name is always some pains initially,
but it is not so after a while when we are used to. I know ITU-T used the
term "Text" in the past, and we are paying a "price" now because any
networks when they see "Text" is being transferred, they provide
"best-effort" services. That is why, we have decided that let us use
"Real-Time Text," "RT Text," "RTT," or "ToIP" so that no one should be
confused.

[RRR] Let us take a little pain for now, but it will help all of us to
achieve the long-term "tecnical" objectives: QOS for real-time text
compatible with that of conversations voice. 

[RRR] (By the way, video is the secondary need because video may not always
be as real-time as conversational voice, and RTT always must be compatible
with conversational voice. The other thing is that video is "often" provided
lower priority that voice. But we want, RTT must be provided the same higher
priority like that of conversational voice.)

[RRR] So, please see that we have so much to loose if RTT is not considered
"exactly" in the same way like that of conversational voice.

You seem to have the stored and forwarded use of text as your dominant
environment, and therefore feel a need to add "real-time" always when it is
used for real-time. Let both exist and in specifications make it clear what
aspect we are talking about. With that reasoning it should be allowed to
leave "real-time" out sometimes when it is clear from the environment what
we talk about.

[RRR] Yes, you right that "Text" is considered as "store and forward" as a
standard. If someone provides "Text" service like that of "Real-Time Text
(RTT)"equivalent to conversational service, it will be highly EXCEPTIONAL
thing. We are standardizing so that people MUST provide real-time service
all the time (as opposed to exceptional service), not best-effort service.

[RRR] I am requesting again that let us stick to ONLY one thing: RTT/ToIP/RT
Text/Real-Time Text.

In the MIME registry, we have a set of different usage of text collected
under the same main media name "text". There are at least the "red" and
"t140" that are for real-time use, and some others for stored use. I think
that sometimes the media subtype does not even imply if it is for real-time
or for stored and forwarded use. So let us accept that the MIME type "text"
is valid for all usage of real-time and non-real-time text.

[RRR] You are right that text covers both in the abvoe registration. Again,
it is another "technical" confusion to use "Text" for both "real-time text"
and "non-real-time text." That is why, another "adjective" has been used
before this "text" to qualify as real-time: RED or T120.

[RRR] It again reinforces the fact why we should EXPLICITLY use ONLY one
thing with a qualifier before the word "Text": RTT/ToIP/RT Text/Real-Time
Text. Because this draft is explictly for real-time text (not for both "Text
and Real-Time Text).

2.3 The timing requirements on real-time text
---------------------------------------------
This comment is not correct. The delay requirements on real-time text are
less stringent than on audio and video. The bad effects of not meeting the
requirements are similar for all media but the timing values are different.

[RRR] It depends.....What is the overall end-to-end delay
requirement for the superior quality of conversational voice communications?
Ist it not less that 150 milliseconds one-to-one delay?"

I am basing the figures on brief research. We usually do not have enough
resources in the accessibility field to afford proper research resulting in
MOS figures, but we have fairly good indications that one second end-to-end
delay is sufficient and good, and comparable to how 400 ms delay is
experienced by audio users. Usually text is typed, and the typing can be
occasionally stopped for natural reasons for a second or so, without any
experienced harm on the dialogue.

[RRR] Gunnar, you do not need to do your own resarch. Countless tests had
been done over the last 50 years. ITU-T has published all standards related
to MOS/PESQ scores for all audio codecs starting from G.711 to G.729 to
others.

[RRR] It is well-established in ITU-T MOS/PESQ/Speech Quality standards. You
can access those standards published by ITU-T. Let me cite some examples.
MOS=PESQ= Between 4 and 5=> End-to-End Delay (codec-to-codec) is less that
150 milliseconds. As you go lower MOS/PSEQ figures, you may increase delay
to 400 mSecs to 2 seconds and more as you have stated.

[RRR] So, it is not your, mine, or anyone else's idea to say what is
confortable or not. The standards are already there. The whole world is
following those standards including IETF.

We are lacking full and detailed research results on user experience of the
various quality factors. I am very interested to get information if you have
access to any results supporting your statements that timing requirements
should be equal between audio and real-time text.
I have a monor study without MOS values supporting the accepted delay
firgures from ITU-T F.700.

[RRR] Yes, please contact ITU-T, you will get those standards. I can give
you some documents that vendors are using following ITU-T standards for
MOS/PESQ/R-Factor where delay and loss figure are there.

2.4 Indication of loss
----------------------
"R14: Where it is possible, loss of real-time text during transport should
be

detected and the user should be informed.

The comment Proposes the addition:

 "Like conversational audio, if some algorithms are used to recreate the
lost real-time text, the users must be informed what has been recreated."
"

Please understand that the error recovery system is not composing any
approximate replica of the original character, it simply recovrs the
character exactly. Therefore, only if it is completely lost, the place needs
to be marked.

[RRR] You are right as for now the way the standard has been created because
RTT standards do not standardize any algorithms that recover text or a
replica of text.

[RRR] I am not talking about RTT standards. Like audio, people may use many
"proprietary" algorithms to receate a replica or recover texts. If so, then
this requirement is applicable. Otherwise, no one cares. We are extending
the expectation what the future technology may bring.

[RRR] So, it is a complementary requirement that further the use of RTT.

2.5 Include mainstream users in users of alternative alerting
--------------------------------------------------------------
I can accept to only delete the word "normal".  That was the urgent issue.

[RRR] OK, I appreciate.

Gunnar

----------------------------------------------------------------------------
-
Gunnar Hellström, Omnitor
[email-masked]
Mob: +46 708 204 288
Phone: +46 8 556 002 03
www.omnitor.se

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Frank Shearar" <[email-masked]>
Date: Wed, 5 Jul 2006 10:16:35 +0200

Unquoted text is Gunnar Hellstrom, RRR is Radhika Roy, FBS is me:

[FBS] As you say, these standards are for voice. They're not for text,
they're not for video, they're not for data, they're not for whiteboards, or
any other modality that has yet to be invented. I think it's wrong for us to
assume that voice and text work exactly the same way. In fact, I posit that
they do NOT.

frank

---

From: Gunnar Hellström <[email-masked]>
Date: Wed, 5 Jul 2006 13:33:22 +0100

Radhika,
I concentrate this response on the delay requirements.
Recap:
We discuss
http://www.ietf.org/internet-drafts/draft-ietf-sipping-toip-05.txt
You wanted to insert a phrase in R10 of sipping-toip

So that it would read: [with your proposed insert marked by []:

R10: Characters must be transmitted soon after entry of each character so
that the maximum delay requirement can be met [RRR insert: so that the
performance of the real-time text communications can be compatible with that
of the conversational audio communications. However, in some situations, ]
An end-to-end delay time of one second is regarded as good, while a delay of
two seconds is possible to use.

[RRR]Rational: The conversational audio may demand the end-to-end delay of
the order a few 100s of milliseconds instead of 2 seconds, and the real-time
text needs to be compatible to this requirement.

I still claim that the requirements on real-time text is less stringent than
on audio and that your proposed insert is not right. If you want I can
accept to add some words about shorter delays than 1 second is appreciated.
( see research below)

Proposal: Use this more elaborated text for R10:

R10: Characters must be transmitted soon after entry of each character so
that the maximum delay requirement can be met. An end-to-end delay time of
one second is regarded as good, while shorter delays down to 300 ms are
noticed and appreciated by the users and systems with longer delays of up to
two seconds are still possible to use.

-----
(GH) Rationale
The ergonomic factors in typing, reading and answering real-time text are
different from when talking, listening and answering real-time voice in
conversational situations. Therefore we cannot directly transfer the delay
requirements   from the voice conversation application. You refer to ITU
G-series documents. But they handle only audio.
I instead also point at previous ITU work. In F.700, Multimedia Framework,
the media have descriptions including quality requirements for various
applications. F.703 Multimedia conversational service description, selects
the media parameters valid for the conversational situation.

It is more correct to refer to these documents as sources than to try to
transfer the figures from voice without checking application on human
conversations.

We have done some brief research on this, and here is the report: ( it was
done in connection to a discussion if it would be feasible to use the SIMPLE
protocols for the real-time text application, therefore the mentioning of
SIMPLE and MSRP as well as RTP for the transport. )

Report from Omnitor, 2005-06-27:
Human requirements on real-time text for conversation

This is a report from brief research on human requirements on real-time text
for conversational applications.

The study was made by Omnitor in June 2005.

The main tool was the open source IP textphone application Sipcon1, where
buffering of text can be set. It was also possible to activate text
smoothing, that presents received text in a rate that evens out all
jerkiness in text appearance.

This presentation smoothing turned out to be extremely important for
acceptance of intervals between transmissions.

We tried different buffer times between text transmissions and with and
without smoothing.

Short text conversations on real topics that required intensive interaction
were held by three persons, two at a time. It was one hearing persons and
two deaf. All three were used to both text telephony, total conversation and
instant messaging. Judgement of usability was collected immediately after
each conversation.

Findings

- 1 s buffer time and no smoothing was irritating jerky. Not acceptable.

- 300 ms buffer time felt very rapid and good contact. Perfect.

- 1 s buffer time was experienced a little delayed, but no practical
influence on the dialogue.

- 3 s buffer time was experienced to be smooth and possible, no real problem
to have a conversation, but sometimes one started to think that the other
one was hesitating on an answer.

- 10 s buffer time created misunderstandings, conversation collisions, long
waiting and stressful feeling. Not acceptable.

- Sentence-wise transmission. Observations were done with Microsoft MSN
Messenger. This method was experienced to give irritating delays. You see
that the other person is typing but immediately wonder how long it will take
before next sentence will come. It easily creates confusing double threads
in the dialogue. Not good usability for tight real time discussions between
two people. We also saw that the transmission took between 1 and 6 seconds
that adds to the disconnected feeling.

Conclusions:

1. Earlier stated requirements are confirmed.
ITU-T F.700 Multimedia Framework descriptions, section A.3.2.1 describes the
conversational text medum, and sets the following quality requirements:

"

T1:                 Usable text conversation quality characterized by:

Font support for ISO-10646-1 Language area Latin-1 plus the target language
area for
the implementation.

                      No more than 1 corrupted, dropped or marked missing
character per 100.

                      Delay from character input in the transmitter to
display in the receiver shorter than 2 s.

T2:                 Good text conversation quality characterized by:

                      Font support for all characters in ISO-10646-1.

                      No more than 1 corrupted, dropped or marked missing
character per 500.

                      Delay from character input in the transmitter to
display in the receiver shorter than 1 s.

"

The obseration that 3s was possible to use but experienced to be a slightly
irritating confirms quality level T1.

The observation that 1 s buffering was experienced to be good confirms
quality level T2.

The observation that 300 ms buffering was experienced to give an even more
efficient dialogue is worth considering when selecting technology for the
service.

Section A.3.2 of F.700 states:

"

When text is the support for conversational services, the timing aspects of
text entry and display are critical. Text may be transmitted and displayed
in near real time, as text is entered. It may also be transmitted only after
specific end-of-sentence action or on a specific send request. In a
conversation between two users, the near real-time conversation is important
for optimized benefit of the conversation. For multi-user conferences, a
sentence based transmission may be more relevant in an open discussion,
while for a subtitled speech, the real-time text transmission is preferred.

"

This was confirmed in the trial with sentence wise transmission, that was
experienced to be possible to use, but stressful, while it is popular for
multi-user discussions.

2. Smoothing of presentation is essential if longer buffering than 300 ms is
used.
Already at 1 second intervals, the bursts were annoying and confused
reading.

3. Technical implications
a. Sentence-wise transmission in Instant Messaging services is good for its
purpose of multi-party chatting and occasional message exchange, but cannot
replace a real time text conversation as well as it cannot replace a voice
conversation with maintained user satisfaction.

b. Earlier discussions have concluded that the instant messaging protocols
could be used for automatic transmission on short time intervals or word
boundaries, but that they would cause too much network load if transmission
was done more often than once per second. This is at least valid for
peer-to-peer protocols not using the call control channel. So, there is a
possibility to meet the studied user requirements with such protocols, if
transmission is arranged every second. One possible protocol is MSRP from
IETF SIMPLE. Transmission every 2 seconds can be considered for specific
applications, if required for example of economic reasons.

c. Real time protocol transmission of text ( RTP )gives low network load,
even if transmission is done at 300 ms intervals, and can fulfill the user
requirements easily and give proven user satisfaction.

d. Even if transmission is made in chunks, presentation of received text
should be done smoothly character by character.

Conclusion of conclusions
-Use already standardised RTP and 300 ms between packets for best user
satisfaction ( ETSI TS 126 235, IETF RFC 4103).

-Use peer-to-peer instant messaging protocols with one second between
transmissions ( e.g. MSRP) if there are strong indications that it would
create advantages in form of much better mainstream uptake or much better
connectivity.

-Do not use longer intervals of transmission for mainstream use of real time
conversations.

----------------------------------------------------------------------------
----------------------------------------------------------------

Do you accept to not include your insert, or do you want some softening
words added like. Lower delays down to

Gunnar

-----Ursprungligt meddelande-----
Från: [email-masked] [mailto:[email-masked]]
Skickat: den 5 juli 2006 03:24
Till: Gunnar Hellström
Kopia: Sipping@Ietf. Org
Ämne: RE: [Sipping] Ready for IESG review: draft-ietf-sipping-toip-05.t
xt

Gunnar:

Best regards,
Radhika

  _____

Radhika,

2.4 Indication of loss
----------------------

[RRR] OK, I appreciate.

Gunnar

---

From: Gunnar Hellström <[email-masked]>
Date: Thu, 6 Jul 2006 14:35:52 +0100

Radhika,
One more item from your comment list:

We wrote earlier:
"2.4 Indication of loss
----------------------
"R14: Where it is possible, loss of real-time text during transport should
be detected and the user should be informed.

----------------------------------------------------------------------------
-
I find it unlikely that a recovery procedure will be designed that tries to
recover characters in a way that may result in errors in the text. I do not
want to enter the words of similarities with audio error concealment.

Would it suit you if we just enter the words "or corrupted" in the
requirement?

Then R14 would read:
R14: Where it is possible, loss or corruption of real-time text during
transport should
be detected and the user should be informed.

Gunnar

-----Ursprungligt meddelande-----
Från: Roy, Radhika R. [mailto:[email-masked]]
Skickat: den 5 juli 2006 03:24
Till: Gunnar Hellström
Kopia: Sipping@Ietf. Org
Ämne: RE: [Sipping] Ready for IESG review: draft-ietf-sipping-toip-05.t
xt

Gunnar:

Best regards,
Radhika

  _____

Radhika,

2.4 Indication of loss
----------------------

[RRR] OK, I appreciate.

Gunnar

---

From: Gunnar Hellström <[email-masked]>
Date: Fri, 7 Jul 2006 17:33:04 +0100

I have reviewed draft-ietf-sipping-toip-05 and want to convey some
observations mainly of editorial nature, combined with my conclusions of the
last few days of discussion in the list.

1. Page 3, second paragraph:
Delete the superflous " character at the end of the paragraph.

2. Sec 4, definitions. Half duplex:
Is:
Half duplex: media can only be sent simultaneously in one direction
s.b.
Half duplex: media can only be sent in one direction at a time

3. In 5.2.2 , first paragraph, second line

Is:
With relay services,
s.b.
With relay services, as well as in direct user-to-use conversation,
[Rationale] Without the addition it is easy to get the impression that the
relay service is the main reason for the real-time performance, while it is
in reality for the whole conversational experience.

4. Next paragraph, R10: third line:
Is:
while a delay of two seconds
s.b.
while shorter delay down to 300 ms is noticed by the users and appreciated,
and a delay of two seconds
[Rationale]Discussed recently in the list

5. R14
Is:
R14: Where it is possible, loss of real-time text during transport
s.b.
R14: Where it is possible, loss or corruption of real-time text during
transport
[rationale] Discussed recently in the list

6. R26 last line
"both" s.b. "all"

7. R27 second line
"URL" s.b. "URI"
[rationale] URIs are used for addressing in SIP.
Also insert an explanation of URI in the acronyms section in 4.

8. 5.2.5.2 second para, last line

Is:
Telephony Modem (CTM) solution [8] and c) "Baudot mode" solution.
s.b.
Telephony Modem (CTM) solution [8] both collectively called "Baudot mode"
solution in USA.

9. 6.2.3 First line
Is:  Invokation
s.b. Invocation

10. In 11. Contributors, first line
Delete words "preliminary drafts of"
[rationale]The contributors are contributing during the whole process.

11. 12.1 ref 14
date s.b. May 2006

12. 12.2 ref I
The reference is very verbose and has no specific title.
Proposal: change to refer to the ETSI guide on real time text relay
services:

ETSI TR 101 806: "Human Factors (HF); Guidelines for Telecommunication Relay
Services for Text Telephones".

13. General comment:
Use term "real-time text" rather than plainly "text" in connection with text
relay services and text gateways

14. General comment
Replace "Interactive" and "conversational" with "real-time" where
applicable.

15. 6.2.5.2
Insert Wireless LANs among the mobile methods
[rationale] - discussed in the list

16. New section "7.5 Quality of Service aspects"
Proposed new text in response to the requirements from the discussion in the
list:

"Where QoS mechanisms are used, the real time text streams should be
assigned appropriate QoS characteristics so that the performance
requirements can be med and not degraded unfavourable in comparison to voice
performance in congested situations."

-----Ursprungligt meddelande-----
Från: Gunnar Hellström [mailto:[email-masked]]
Skickat: den 6 juli 2006 14:36
Till: Roy, Radhika R.
Kopia: Sipping@Ietf. Org; Gregg Vanderheiden
Ämne: SV: [Sipping] Ready for IESG review: draft-ietf-sipping-toip-05.t
xt- Indication of loss

Radhika,

We wrote earlier:
"2.4 Indication of loss
----------------------

Then R14 would read:

Gunnar

-----Ursprungligt meddelande-----
Från: Roy, Radhika R. [mailto:[email-masked]]
Skickat: den 5 juli 2006 03:24
Till: Gunnar Hellström
Kopia: Sipping@Ietf. Org
Ämne: RE: [Sipping] Ready for IESG review: draft-ietf-sipping-toip-05.t
xt

Gunnar:

Best regards,
Radhika

  _____

Radhika,

2.4 Indication of loss
----------------------

[RRR] OK, I appreciate.

Gunnar

---

From: "Gregg Vanderheiden" <[email-masked]>
Date: Fri, 7 Jul 2006 13:06:56 -0500

All these edits match with my understanding and conversations with others on
this topic.

Note for background (not for edit) - 
2 second latency in emergency call could lead to cross messages but real
time nature should allow recovery.  We will be doing some studies on this.
For ordinary conversation 2 second should work but 1 second or less would be
much better.  

Gregg

 -- ------------------------------ 
Gregg C Vanderheiden Ph.D. 
Professor - Ind. Engr. & BioMed Engr.
Director - Trace R & D Center 
University of Wisconsin-Madison 
The Player for my DSS sound file is at http://tinyurl.com/dho6b 

> -----Original Message-----
> Sent: Friday, July 07, 2006 11:33 AM
> To: Mary Barnes; Sipping@Ietf. Org
> Cc: Gregg Vanderheiden
> Subject: SV: [Sipping] Ready for IESG review: 
> draft-ietf-sipping-toip-05.txt - Summary
> 
> I have reviewed draft-ietf-sipping-toip-05 and want to convey 
> some observations mainly of editorial nature, combined with 
> my conclusions of the last few days of discussion in the list.
> 
> Half duplex: media can only be sent simultaneously in one 
> direction s.b.
> With relay services, as well as in direct user-to-use 
> conversation, [Rationale] Without the addition it is easy to 
> get the impression that the relay service is the main reason 
> for the real-time performance, while it is in reality for the 
> whole conversational experience.
> 
> while shorter delay down to 300 ms is noticed by the users 
> and appreciated, and a delay of two seconds 
> R14: Where it is possible, loss of real-time text during 
> transport s.b.
> R14: Where it is possible, loss or corruption of real-time 
> text during transport [rationale] Discussed recently in the list
> 
> 6. R26 last line
> "both" s.b. "all"
> 
> 7. R27 second line
> "URL" s.b. "URI"
> ETSI TR 101 806: "Human Factors (HF); Guidelines for 
> Telecommunication Relay Services for Text Telephones".
> 
> 13. General comment:
> Use term "real-time text" rather than plainly "text" in 
> connection with text relay services and text gateways
> 
> 
> 14. General comment
> Replace "Interactive" and "conversational" with "real-time" 
> where applicable.
> 
> 15. 6.2.5.2
> Insert Wireless LANs among the mobile methods [rationale] - 
> discussed in the list
> 
> "Where QoS mechanisms are used, the real time text streams 
> should be assigned appropriate QoS characteristics so that 
> the performance requirements can be med and not degraded 
> unfavourable in comparison to voice performance in congested 
> situations."
> 
> 
> 
> 
> 
> 
> --------------
> "R14: Where it is possible, loss of real-time text during 
> transport should be detected and the user should be informed.
> 
>  "Like conversational audio, if some algorithms are used to 
> recreate the lost real-time text, the users must be informed 
> what has been recreated."
> "
> 
> Please understand that the error recovery system is not 
> composing any approximate replica of the original character, 
> it simply recovrs the character exactly. Therefore, only if 
> it is completely lost, the place needs to be marked.
> 
> [RRR] You are right as for now the way the standard has been 
> created because RTT standards do not standardize any 
> algorithms that recover text or a replica of text.
> 
> [RRR] I am not talking about RTT standards. Like audio, 
> people may use many "proprietary" algorithms to receate a 
> replica or recover texts. If so, then this requirement is 
> applicable. Otherwise, no one cares. We are extending the 
> expectation what the future technology may bring.
> 
> --------------
> I find it unlikely that a recovery procedure will be designed 
> that tries to recover characters in a way that may result in 
> errors in the text. I do not want to enter the words of 
> similarities with audio error concealment.
> 
> Would it suit you if we just enter the words "or corrupted" 
> in the requirement?
> 
> Then R14 would read:
> R14: Where it is possible, loss or corruption of real-time 
> text during transport should be detected and the user should 
> be informed.
> 
> 
> Gunnar
> 
> --------------
> Ämne: RE: [Sipping] Ready for IESG review: 
> draft-ietf-sipping-toip-05.t xt
> 
> 
> Gunnar:
> 
> I am completely OPEN to accept any superior technical 
> arguments. Please see my replies in line [RRR]. I am sure 
> that you will be convinced.
> 
> Please do not hesitate to let me know if you still have any 
> more technical questions. I appreciate that your time and patience.
> 
> Best regards,
> Radhika
> 
>   _____
> 
> Subject: SV: [Sipping] Ready for IESG review: 
> draft-ietf-sipping-toip-05.t xt
> 
> 
> 
> Radhika,
> 
> I will try once more and add explanations to the cases when 
> you think I am not right.
> 
> Here I have already accepted that we may very well add 
> "real-time" where you suggest and delete the words 
> "conversational" and "interactive".
> I have also agred that we use the term "real-time text" as 
> often as it is practical nowadays.
> 
> So, this is just an effort to ask you to open your mind to 
> existing use of the word "text".
> Most often the setting indicates if we are talking about a 
> real-time service or a store-and retrieval service.
> In my every-day job, I work a lot with real-time 
> conversational services with video, real-time text and audio. 
> In that setting it is not needed to keep saying real-time 
> text. When we talk about text people know it is the text with 
> real-time flow we are talking about. Since long there has 
> been text telephones, text relay services, text calls, text 
> gateways, text users and we always mean that they use 
> real-time text. If not, we need to mark it by for example 
> adding "message".
> 
> [RRR] You are coming from a different angle that is 
> non-technical. When we create standards, we MUST live with 
> examples that do not create further "technical" confusions. 
> To use a NEW name is always some pains initially, but it is 
> not so after a while when we are used to. I know ITU-T used 
> the term "Text" in the past, and we are paying a "price" now 
> because any networks when they see "Text" is being 
> transferred, they provide "best-effort" services. That is 
> why, we have decided that let us use "Real-Time Text," "RT 
> Text," "RTT," or "ToIP" so that no one should be confused.
> 
> [RRR] Let us take a little pain for now, but it will help all 
> of us to achieve the long-term "tecnical" objectives: QOS for 
> real-time text compatible with that of conversations voice.
> 
> [RRR] (By the way, video is the secondary need because video 
> may not always be as real-time as conversational voice, and 
> RTT always must be compatible with conversational voice. The 
> other thing is that video is "often" provided lower priority 
> that voice. But we want, RTT must be provided the same higher 
> [RRR] So, please see that we have so much to loose if RTT is 
> not considered "exactly" in the same way like that of 
> conversational voice.
> 
> You seem to have the stored and forwarded use of text as your 
> dominant environment, and therefore feel a need to add 
> "real-time" always when it is used for real-time. Let both 
> exist and in specifications make it clear what aspect we are 
> talking about. With that reasoning it should be allowed to 
> leave "real-time" out sometimes when it is clear from the 
> environment what we talk about.
> 
> [RRR] Yes, you right that "Text" is considered as "store and 
> forward" as a standard. If someone provides "Text" service 
> like that of "Real-Time Text (RTT)"equivalent to 
> conversational service, it will be highly EXCEPTIONAL thing. 
> We are standardizing so that people MUST provide real-time 
> service all the time (as opposed to exceptional service), not 
> best-effort service.
> 
> [RRR] I am requesting again that let us stick to ONLY one 
> thing: RTT/ToIP/RT Text/Real-Time Text.
> 
> In the MIME registry, we have a set of different usage of 
> text collected under the same main media name "text". There 
> are at least the "red" and "t140" that are for real-time use, 
> and some others for stored use. I think that sometimes the 
> media subtype does not even imply if it is for real-time or 
> for stored and forwarded use. So let us accept that the MIME 
> type "text"
> [RRR] You are right that text covers both in the abvoe 
> registration. Again, it is another "technical" confusion to 
> use "Text" for both "real-time text"
> and "non-real-time text." That is why, another "adjective" 
> has been used before this "text" to qualify as real-time: RED or T120.
> 
> [RRR] It again reinforces the fact why we should EXPLICITLY 
> use ONLY one thing with a qualifier before the word "Text": 
> RTT/ToIP/RT Text/Real-Time Text. Because this draft is 
> explictly for real-time text (not for both "Text and Real-Time Text).
> 
> 
> This comment is not correct. The delay requirements on 
> real-time text are less stringent than on audio and video. 
> The bad effects of not meeting the requirements are similar 
> for all media but the timing values are different.
> 
> I am basing the figures on brief research. We usually do not 
> have enough resources in the accessibility field to afford 
> proper research resulting in MOS figures, but we have fairly 
> good indications that one second end-to-end delay is 
> sufficient and good, and comparable to how 400 ms delay is 
> experienced by audio users. Usually text is typed, and the 
> typing can be occasionally stopped for natural reasons for a 
> second or so, without any experienced harm on the dialogue.
> 
> [RRR] Gunnar, you do not need to do your own resarch. 
> Countless tests had been done over the last 50 years. ITU-T 
> has published all standards related to MOS/PESQ scores for 
> all audio codecs starting from G.711 to G.729 to others.
> 
> [RRR] It is well-established in ITU-T MOS/PESQ/Speech Quality 
> standards. You can access those standards published by ITU-T. 
> Let me cite some examples.
> MOS=PESQ= Between 4 and 5=> End-to-End Delay (codec-to-codec) 
> is less that 150 milliseconds. As you go lower MOS/PSEQ 
> figures, you may increase delay to 400 mSecs to 2 seconds and 
> more as you have stated.
> 
> [RRR] So, it is not your, mine, or anyone else's idea to say 
> what is confortable or not. The standards are already there. 
> The whole world is following those standards including IETF.
> 
> We are lacking full and detailed research results on user 
> experience of the various quality factors. I am very 
> interested to get information if you have access to any 
> results supporting your statements that timing requirements 
> I have a monor study without MOS values supporting the 
> accepted delay firgures from ITU-T F.700.
> 
> [RRR] Yes, please contact ITU-T, you will get those 
> standards. I can give you some documents that vendors are 
> using following ITU-T standards for MOS/PESQ/R-Factor where 
> delay and loss figure are there.
> 
> 2.4 Indication of loss
> ----------------------
> "R14: Where it is possible, loss of real-time text during 
> transport should be
> 
>  "Like conversational audio, if some algorithms are used to 
> recreate the lost real-time text, the users must be informed 
> what has been recreated."
> "
> 
> Please understand that the error recovery system is not 
> composing any approximate replica of the original character, 
> it simply recovrs the character exactly. Therefore, only if 
> it is completely lost, the place needs to be marked.
> 
> [RRR] You are right as for now the way the standard has been 
> created because RTT standards do not standardize any 
> algorithms that recover text or a replica of text.
> 
> [RRR] I am not talking about RTT standards. Like audio, 
> people may use many "proprietary" algorithms to receate a 
> replica or recover texts. If so, then this requirement is 
> applicable. Otherwise, no one cares. We are extending the 
> expectation what the future technology may bring.
> 
> --------------
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP
> 
> 
> 
> 
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP
> 
> 
> 
>