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

From: "Roy, Radhika R." <[email-masked]>
Date: Fri, 7 Jul 2006 16:48:54 -0400

Gunnar:
 
Wonderful!

It is a great moment for all of us.

Best regards,
Radhika

  _____  

From: [email-masked] on behalf of Gunnar Hellström
Sent: Fri 7/7/2006 12:33 PM
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.

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

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

-----Ursprungligt meddelande-----
Från: Gunnar Hellström [mailto:[email-masked]
<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,
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
<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
<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: "Arnoud van Wijk" <[email-masked]>
Date: Sat, 8 Jul 2006 00:01:44 +0200

This looks very good.
I still consider it weird to have the word corruption in text of R14. How do
I interpret it since text is a char dropped or not? 

If the others in the workgroup agree with this, we can edit this draft after
the IETF in a -06 version.

And this is now exactly what the IETF is about. The -05 version came out and
everybody could discuss this and add comments etc.

And yes Radhika, it is great for all of us, sadly you had to act quite
unfriendly and high and mighty. But I ignore that, since a good RFC out of
this draft is what the goal is.

Greetz

Arnoud

-----Original Message-----
From: Roy, Radhika R. [mailto:[email-masked]] 
Sent: vrijdag 7 juli 2006 22:49
To: Gunnar Hellström
Cc: Sipping@Ietf. Org; Mary Barnes
Subject: RE: [Sipping] Ready for IESG review: draft-ietf-sipping-toip-05.txt
-Summary

Gunnar:
 
Wonderful!

Best regards,
Radhika

  _____  

Is:
With relay services,
s.b.

5. R14
Is:

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

7. R27 second line
"URL" s.b. "URI"

Is:

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

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

12. 12.2 ref I

13. General comment:

14. General comment

15. 6.2.5.2

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

Radhika,

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

Then R14 would read:

Gunnar

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

Gunnar:

Best regards,
Radhika

  _____

Radhika,

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

[RRR] OK, I appreciate.

Gunnar

---

From: Gunnar Hellström <[email-masked]>
Date: Sat, 8 Jul 2006 06:04:58 +0100

Arnoud,

Thanks for your agreement.

About marking corrupted text:

The words are in Requirement R14 in section 5.2.2.

That is a general transport requirements section. Selection of technology
comes later. So it refers to human requirements. Our response later to this
human requirement is to use RTP with RFC 4103, with error recovery by
redundancy so that corruption does not occur, and loss is minimized and
marked for the rare case it happens.

Gunnar

-----Ursprungligt meddelande-----
Från: Arnoud van Wijk [mailto:[email-masked]]
Skickat: den 7 juli 2006 23:02
Till: 'Roy, Radhika R.'; 'Gunnar Hellström'
Kopia: 'Sipping@Ietf. Org'; 'Mary Barnes'
Ämne: RE: [Sipping] Ready for IESG review:
draft-ietf-sipping-toip-05.txt -Summary

This looks very good.

Greetz

Arnoud

-----Original Message-----
From: Roy, Radhika R. [mailto:[email-masked]]
Sent: vrijdag 7 juli 2006 22:49
To: Gunnar Hellström
Cc: Sipping@Ietf. Org; Mary Barnes
Subject: RE: [Sipping] Ready for IESG review: draft-ietf-sipping-toip-05.txt
-Summary

Gunnar:

Wonderful!

Best regards,
Radhika

  _____

Is:
With relay services,
s.b.

5. R14
Is:

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

7. R27 second line
"URL" s.b. "URI"

Is:

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

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

12. 12.2 ref I

13. General comment:

14. General comment

15. 6.2.5.2

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

Radhika,

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

Then R14 would read:

Gunnar

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

Gunnar:

Best regards,
Radhika

  _____

Radhika,

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

[RRR] OK, I appreciate.

Gunnar