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

From: "Roy, Radhika R." <[email-masked]>
Date: Thu, 6 Jul 2006 10:03:07 -0400

Gunnar:
 
OK, agreed. We are done. I appreciate your time and effort.
 
Best regards,
Radhika
 
BTW: It is unfortunate for us that we, being authors, have to resolve our
technical differences in the WG mailing list. Let us do a soul search as we
do the similar thing next time around.

  _____  

From: Gunnar Hellström [mailto:[email-masked]]
Sent: Thu 7/6/2006 9:35 AM
To: Roy, Radhika R.
Cc: Gregg Vanderheiden; Sipping@Ietf. Org
Subject: SV: [Sipping] Ready for IESG review: draft-ietf-sipping-toip-05.t
xt - Indication of loss

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. 

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. 

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

- 
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 

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

- 
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 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: 

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