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

From: "Roy, Radhika R." <[email-masked]>
Date: Mon, 3 Jul 2006 13:28:00 -0400

Hi, Mary:
 
I have differences with Gunnar in some of his comments. Gunnar is NOT
correct. He might need to see my answers.
 
Please inline [RRR].
 
Best regards,
Radhika

  _____  

From: [email-masked] on behalf of Gunnar Hellström
Sent: Sun 7/2/2006 11:32 AM
To: Sipping@Ietf. Org
Subject: RE: [Sipping] Ready for IESG review: draft-ietf-sipping-toip-05.t
xt

Mary, 

Radhika brings up some questions and want you to make the decisions. 
Below are my comments and advice as a co-contributor, numbered as Radhika´s 
comments: 

2.1 and 2.2. The term real-time text 
------------------------------------ 

There were unimportant historical reasons to use "interactive" and 
"conversational". 
I have not perceived the very strict distinction between "text" and 
"real-time text" as Radhika´s comments indicate. But I am happy to be 
consistent and use the term wherever it is suitable. 
I thought it did not read well with "real-time text relay service" when in 
practice in real world it is called "text relay" since long. 

My advice: Accept to use the term "real-time text" in the places indicated. 

[RRR] It is not about the subjective statement like to be "happy." It is
about "technical" consistency. The bottom line is this: "Text Gateway" is
NOT equal to "Real-time Text Gateway." Period. If someone does not like the
long term, he/she can find suitable term, but one must NOT use technical
"worng" term. They can use "Gateway/Bridge/Relay" per say. What do they like
to bring another technically "wrong" qulifying adjective like "Text" which
by definition is "non-real-time?"

[RRR] So, the propsal is to use "Real-Time Text Gateway/Bridge/Relay," "RT
Text Gateway/Bridge/Relay," "ToIP Gateway/Bridge/Relay" or
"Gateway/Bridge/Relay."

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. If all users are ToIP, it may be true. But it is not true
where there is a mix of users, for example, in a multipoint conference call.
In a multipoint conference call, where users consist of ToIP users and Voice
users. In this conference call, the users' expectiation is to have the
"superior" conference call where voice needs to provide its best performance
(say MOS score of 5 in tool quality). 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?

[RRR] We are considering ToIP as full communications. That is, ToIP can be
used to provide the performance as voice does. That is, if the toll quality
voice is to maintain one-way end-to end delay less than 150 milliseconds,
ToIP will also be used to provide the same performance.

[RRR] However, if one does not want to provide toll quality voice, the
performance can be degraded from MOS figure from 5 to 2.5 or less if one
needs to have. In this case the one-way end-to-end delay may be anything
from 150 milliseconds to 1000 milliseconds or more.

[RRR] In the same token like voice, if ToIP needs to perform with end-t-end
delay more 150 milliseconds, maybe 1000 milliseconds or more, it can be
done.

For audio and video the delay is noticable but not annoying at 400 ms. 
For real-time text the same situation is seen with 1 s delay. 

[RRR] Again, you are mixing apples with oranges. What is the
baseline/performance of your performance? Are you talking about MOS figures
comparing with those of Voice or something else? As explained above, we are
not talking about what people can tolerate or not. We are talking about what
is superior quality (MOS=5 or Toll Quality) and other dgraded qualities in
comparison with Voice.

For audio and video the delay is annoying, but the connection can still be 
used at 800 ms delay. 
For real-time text the same user experience is seen at 2 s delay. 

[RRR] Please see answers provided above.

At higher delay figures turntaking collissions appears and makes the 
conversational situation very disturbing. Users are able to adapt and 
introduce procedures that make it possible but inefficient. 

The values for text are documented in ITU-T F.700 [25] 

The original text is good. 

[RRR] Original text is technically erronous.

Advice: Do not accept. 

[RRR] Please accept the modified texts as suggested. Otherwise, there will
be serious technical errors. One of the problems will be as follows: ToIP,
unlike Voice, is meant for "degraded" quality when it comes to be working
with conversational Voice.

[RRR] ToIP can be used to provide the superior toll quality per with Voice.
If needed, end-to-end delays can be up to 2 seconds or more for "degraded"
quality of communications.

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." 

My advice: Do not accept. 

[RRR] It is again technically ill-advised. Please accept the modifications
suggested as explained below.

An indication of loss is only needed in the cases when it was impossible to 
recreate the character. The user does not bother if the character was 
received in its original transmission or by a recovery scheme, but it is 
quite important to get a mark in a place where something really have been 
lost. 

[RRR] It depends. We have to consider what kinds of users we are
considering. As we have mentioned, people may use in may purposes. If any
real-time texts are produced in "court" for legal purposes, the modified
"text" produced by the algorithms are extremely important.

[RRR] The users who do not like to recieve the "modified" the text produced
by the algorithms, they may not use this capability. It is up to them. That
does not mean, other users should not have this capability if technology is
ther to have it.

[RRR] So, it will be utterly a dis-service to the users who want to use have
this capability.

[RRR] So, the advice is to accept this requirement.

2.5 Include mainstream users in users of alternative alerting 
-------------------------------------------------------------- 
The comment proposes to add a phrase in R25: 

R25: User Agents for ToIP services MUST have alerting methods (e.g., for 
incoming sessions) that can be used by deaf and hard of hearing people and 
the main stream normal users who cannot use audio communications because of 
safety or other reasons or provide a range of alternative, but equivalent, 
alerting methods that can be selected by all users, regardless of their 
abilities. 

Do never accept this way of using the word "normal" to distinguish from 
people with disabilities. It is politically incorrect. 
I think mainstream is OK but on the limit. 
Furthermore "all users, regardless of their abilities" was already there 
later in the sentence so the addition just complicates the sentence. 

[RRR] I do not read this way. The draft already mentions two groups of
users: "deaf and hard of hearing people and the main stream users."

[RRR] The above text uses an "extra" word - "NORMAL." If this word NORMAL is
a problem, I will be willing to delete it. Other than this, the above texts
are OK because it explains that ToIP is "forced" to be used not only for
deaf and heard and hearing people, but even the maintream users are also
"forced" to use in certain circumstances.

[RRR] Therefore, the above text is "technically" and "politically"
consistent if the word "NORMAL" is deleted.

Advice: Do not accept the proposal. 

[RRR] The above proposal SHOULD be accepeted otherwise people will have
mis-understandings that ToIP is only used by deaf and heard of hearing
people. (May be the word "NORMAL" may be deleted.)

2.6 Introduce QOS requirements 
---------------------------------- 
The comment proposes this addition: 
Rxx: Like conversational audio, real-time text SHALL be provided the same 
level of Quality-of-Services (QOS) over all networks (e.g., Wire-line and 
Wireless LAN, Cellular Network, IP) to meet the real-time application 
performances. 

The idea is right, but the requirements are different. Real-time text can 
accept longer delays and more jitter. It is very important that it is not 
downprioritized in a congestion situation compared to audio. 

Advice: accept the idea, but change the words. I have no proposal. 

[RRR] OK, thanks.

2.7 Mobility 

OK, accept addition of WLAN 

[RRR] OK, Thanks

3. Editor 

For me it is OK as it is. No change needed. All earlier authors are either 
editors or contributors now, and the IETF procedures explain that that has 
equal value. In most other standardisation bodies the authors are not even 
mentioned in the final depersonalised product. In IETF we maintain the 
names, and that is good for finding the track back to experts in the area. 
But why put so much effort in discussion of who are mentioned as editors? 
For me the important thing is to get a document out there approved and ready

to be used for harmonisation and better communication functionality for all.

Can you, Radhika please think in such directions and accept the current 
distribution of editors and contributors? That would ease the progress of 
the document and be of benefit for all. 

[RRR] I do not accept this. This violates the very principle of the
editorship. An editor is assigned by the authors of the draft, not vice
versa. To the utter surprise of all authors of this, the editor has stopped
all communications with the authors as used to do for a long time. All
authors of this draft are in dark what this editor is doing and will be
doing. How can this folks claim that he is an editor of this draft?

[RRR] An editor is one who submits to the comments of all authors of the
draft. If an editor does not work with the consensus of the authoths of the
draft and works indepedently, he/she must resign.

[RRR] An editor has added another editor, as if, this draft is their
personal property, and they are writing and modifying and sending to the
IETF without working with the authors of this draft. How do they claim to be
the editors? Has this draft become their own personal property?

[RRR] I have suggested the WG to appoint an editor like Tom Taylor who will
be working under the guidance of the WG.

Gunnar 

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

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

-----Ursprungligt meddelande----- 
Från: Roy, Radhika R. [mailto:[email-masked]
<mailto:[email-masked]> ] 
Skickat: den 1 juli 2006 13:30 
Till: Mary Barnes 
Kopia: [email-masked] 
Ämne: RE: [Sipping] Ready for IESG review: draft-ietf-sipping-toip-05.t 
xt 

Hi, Mary: 

As indicated, I am enclosing my comments in the enclosed paper. 

I appreciate your lead in this respect. 

Best regards, 
Radhika 

_______________________________________________ 
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
<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 

_______________________________________________
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: Gunnar Hellström <[email-masked]>
Date: Mon, 3 Jul 2006 20:44:14 +0100

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.

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".

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.

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] 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.

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.

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

"

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.

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

Gunnar

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

Hi, Mary:

Please inline [RRR].

Best regards,
Radhika

  _____

Mary,

Advice: Do not accept.

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

[RRR] OK, thanks.

2.7 Mobility

[RRR] OK, Thanks

3. Editor

Gunnar

-

-----Ursprungligt meddelande-----

Hi, Mary:

Best regards,
Radhika