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

From: "Roy, Radhika R." <[email-masked]>
Date: Wed, 5 Jul 2006 07:31:31 -0400

Frank:
 
It is not that we are dis-agreeing. In fact, my broader technical point
includes your point too. There are couple of things as follows:

1.	

	For ToIP-to-ToIP users ONLY:

*	

	Any delay can be assumed that the technology can provide from less
than 150 milliseconds to 2 seconds and above for ToIP.
*	

	The issue is: what delay limit do we choose? If it is the mainstream
users, why will they limit their delay more than 150 milliseconds if
technology can provide this capability?
*	

	If users think that they can be satisfied with 400 mSecs or 2
seconds, let them have it.
*	

	So, what is the advantage that we should NOT add the requirement of
150 mSecs to 400 mSecs to 2 secs to more? No one mandating that 150 mSecs is
the ONLY requirement to be satisfied. Rather it is an OPTION. It will help
as one can item 2 explained below.

2.	

	ToIP in Conjunction with Conversational Voice users, say, in the
case of a couple of ToIP users and mainstream users:

*	

	We have assumed that ToIP can be used for Total communications. That
is, its quality will be as good as conversational voice. That is, no one
even realizes that there is a ToIP user in the conference call.
*	

	Per conversational audio standard, the Toll Quality
(MOS/PESQ/R-Factor/Toll Quality -> 4 - 5) requires the end-to-end delay
(ETE) less that 150 mSecs. In this situation, ToIP is well suited to meet
this requirement as technology is available.
*	

	So, if we do not include ETE delay less that 150 mSecs, we will be
contradicting the claim that ToIP can be used for "Total" communications. If
we "limit" the choice only 400 mSecs and above for ToIP, we are accepting
that fact ToIP users will "force" the conference call with the mainstream
audio users with "degraded" audio quality (i.e., MOS/PESQ/R-Factor much less
that 3 or below).

Hope that you will be convinced now.
 
Best regards,
Radhika

  _____  

From: [email-masked] on behalf of Frank Shearar
Sent: Wed 7/5/2006 4:16 AM
To: Sipping@Ietf. Org
Subject: Re: [Sipping] Ready for IESG review: draft-ietf-sipping-toip-05.t
xt

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

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.

[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

_______________________________________________
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