Subject: RE: Tiny ant vs big Mammoths, was RE: [Simple] Using MSRP for real time text conversation

From: [email-masked]
Date: Fri, 2 Jul 2004 10:19:00 +0300

Arnoud,

You speak as if you have done the market research already for all of us :) How do you know that people will appreciate it once they discover it? How do you know that people will use it? How do you know that it adds value to the phone instead of just implementing something that no one will use? How do you know that if I like interactive text, then my mum and dad will and buy a phone like mine just to use interactive text???? How do you know...?

Did people complain to you that IM the way it is these days in annoying to use? or are you just stating your opinion?

And about mobile phones. If you can type an SMS faster than 2 characters a second, you're a genius. Even if you can, I don't believe operators would want to floor they scarce air interface with IP packets that carry 2 characters at a time.

Thanks,
Hisham

> -----Original Message-----
> From: ext Arnoud van Wijk [mailto:[email-masked]]
> Sent: 02.July.2004 00:38
> To: 'Henry Sinnreich'; 'Dean Willis'
> Cc: [email-masked]; Khartabil Hisham 
> (Nokia-TP-MSW/Helsinki);
> [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject: RE: Tiny ant vs big Mammoths, was RE: [Simple] Using MSRP for
> real time text conversation
> 
> 
> Henry,
> Do you know what the danger is?
> I already see it emerging.
> 
> Here at the IETF many are wonderful and quite supporters for 
> Interactive
> text. But their bosses..higher up pointed haired bosses are 
> just dumb and
> only see what they know.
> 
> Interactive text is scary for them. They do not believe that 
> many will use
> it under condition that it is available in as many phones as possible!
> All mobile phones offer SMS (Europe, Asia). But most do not 
> use it. But a
> significant group does. Even though text input is very clumsy using
> numerical key combinations.
> 
> Too many say right now EXACT the same thing as with Interactive text.
> SMS/Interactive text? Hardly anybody is interested in it. Why 
> send text
> while you can just as quickly place a voice call? There is no need for
> SMS/Interactive text. People won't use it Don't like it.
> 
> (sounds familiar?)
> 
> My message to the vendors is simple: implement interactive 
> text. Text/t140.
> If you have a phone with IM capabilities, add interactive text!
> Try interactive text in as many phones you produce! People 
> will be grateful
> for it and buy your products.
> I am not saying that every phone must have it. But in every 
> price range,
> have enough models with text/t140.
> It is cheap to implement, it adds value to your phone for the 
> buyers. And
> those who don't care, will likely later appreciate 
> interactive text as soon
> they discover it. And keep buying your IP phones for their 
> kids, family
> members..new phone etc etc.
> 
> We, the IETF cannot mandate this. But we are a bunch of smart 
> people. So, we
> do know what we do.
> 
> Greetz
> 
> Arnoud
> 
> 
> 
> 
> -----Original Message-----
> From: Henry Sinnreich [mailto:[email-masked]] 
> Sent: donderdag 1 juli 2004 21:53
> To: 'Arnoud van Wijk'; 'Dean Willis'
> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject: RE: Tiny ant vs big Mammoths, was RE: [Simple] Using 
> MSRP for real
> time text conversation
> 
> Arnoud,
> 
> I have to agree with Dean's arguments and add that in dealing 
> with real
> vendors and program managers, even what is 100% consensus in 
> the IETF is "in
> the next generation" (in a next life probably) under 
> consideration for them.
> 
> So let's do a reality check and come back with these issues 
> after we had a
> couple of months to check with vendors and program managers, 
> so we don't
> spin our wheels here in the list.
> 
> Henry
> 
> Henry Sinnreich
> MCI
> 400 International Parkway
> Richardson, Texas 75081
> USA
>  
> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf
> Of Arnoud van Wijk
> Sent: Thursday, July 01, 2004 12:24 PM
> To: 'Dean Willis'
> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject: RE: Tiny ant vs big Mammoths, was RE: [Simple] Using 
> MSRP for real
> time text conversation
> 
> Dean,
> 
> I said this to indicate that the method Interactive text is using for
> redundancy will only slightly increase the bandwidth. There 
> are generally no
> more packets per second being sent with redundancy, the 
> redundant generation
> is sent with the normal next batch of typed characters in the 
> following
> packet! 
> Think of a bus with 10 characters in it or a bus with 20 
> characters in it.
> It is then the same bus.
> 
> It is not 1 packet per character! Unless you t  y  p  e   s  
> o    s  l  o  w
> that there is a second or more between every character or so. :-)
> 
> And if there is a congestion like you described with so many 
> Interactive
> text streams. Normal congestion mechnism that are used for 
> other RTP traffic
> will also apply for Interactive text.
> Also as stated in the 07 version of the RFC 2793 bis draft, 
> if there is a
> good mechanism that prevents dropped packets..then that can 
> be used instead
> of the 2 generations redundancy.
> 
> So, I do not see the problem.
> 
> Greetz
> 
> Arnoud
> 
> 
> 
> -----Original Message-----
> From: Dean Willis [mailto:[email-masked]] 
> Sent: donderdag 1 juli 2004 18:04
> To: A vWijk
> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject: Re: Tiny ant vs big Mammoths, was RE: [Simple] Using 
> MSRP for real
> time text conversation
> 
> A vWijk wrote:
> > My comment marked with ***
> > *** The discussion about MSRP is only to play with the idea 
> of using MSRP
> for interactive text.
> > The idea to lift with the instant messaging revolution on 
> terminals is
> apealing.
> > But we stay with t140/rtp as described in RFC 2793( bis-07).
> > But introducing new interactive text formats raises the danger of
> incompatibilities. So that is why I am negative about just 
> using MSRP for
> interactive text.
> > 
> > So... t140/RTP is a great solution and the redundancy usage of 2
> generations are indeed sent by the next packet that would be 
> sent anyway. So
> there is hardly any load increase at all.
> > And I had yesterday a call with interactive text (t140/RTP) 
> along with
> audio and video, the connection was not so good, 20% packets 
> drop with peaks
> to about 40% lost packets. Sound was bad (according the 
> hearing person,
> video was also bad with blocks in it..but the interactive 
> text worked just
> flawlessly. When disabling the interactive text, the audio 
> and video staryed
> just as crappy as they were.
> > We talk about 2-3 kbit/sec out of 384 kbit total bandwidth 
> used!!! THAT is
> now we are talking about (yes with redundancy on!)..a tiny 
> little ant along
> the Mammoths.
> > 
> > Just to bring it into the right perspective. :-)
> > 
> > So, there is nothing wrong with RFC2793 interactive text. 
> Except perhaps
> that a device that does not support RTP cannot use T140/RTP.
> > 
> 
> No, let's put it in the right perspective.
> 
> Assume real-time text drives 2kb/s of bandwidth, or approximately 3 
> packets per second.
> 
> Assume 20,000,000 users are running real-time-text sessions 
> concurrently. This is approximately peak load for a really big mobile 
> operator, and well below peak load for the Internet as a whole.
> 
> Assume that real-time text continues to operate without the sort of 
> congestion control that forces it to "back off" in the event 
> of network 
> congestion.
> 
> We now have 40 billion (40E9) bits per second of 
> non-bandwidth-controlled traffic out there, or approximately 60E6 
> packets per second.
> 
> Will any of this ever traverse a link that is also trying to 
> carry nice 
> friendly TCP traffic? Will that link ever get congested? Will the 
> real-time text "starve out" the TCP traffic when it does? The answers 
> here are most likely "yes" . . .
> 
> How can you assure us that this will never happen? Are 
> operators going 
> to build dedicated networks for real-time text? Are we going to use 
> DS-markings to make real-time text low priority and discardable?
> 
> Or, otherwise said, what gives real-time-text the "right" to 
> cheat the 
> rules and unfairly consume scarce network resources? Does any 
> application have that right?
> 
> --
> Dean
> 
> 
> 
> -
> This list is maintained by Snowshore Networks - 
http://www.snowshore.com
All comments on this list are the comments of the message originators and
Snowshore is not to be held responsible for any actions or comments found
on this list. The archives for this list can be found at
http://flyingfox.snowshore.com/toip_archive/maillist.html

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: "Arnoud van Wijk" <[email-masked]>
Date: Sun, 4 Jul 2004 11:31:53 +0200

Hisham,
Actually...
I did some market research. Based on 15 people.
3 deaf, 5 worked in deaf related business (hearing people)
And 7 don't care about deaf (2 of them are IM freaks).

Result:

First telling them about total conversation and Interactive text
(text/t140).
It did not mean much to them, they looked glassy eyed. Real-time charcter
per character..oh Yawn... lovely... pish posh. They could not imagine it. No
concept of it.

Then I showed them.
They could communicate with somebody in Sweden, and with me on a different
terminal in a different room.
All were deeply impressed.

The 3 deaf wanted to take it home right now. Being able to communicate
everywhere , everytime..finally free! 
The 5 who worked in the deaf business, they loved it and want to see it
implemted and mainstream. They love it and will use it regularly to
communicate with deaf and some even say that it can be quite convenient for
hearing people as well.

The 7 hearing, non deaf related liked it too!
They said, wow... this is much more direct then IM, you can actually call
people in situations where voice is a bit not done (think cinema, concert,
restaurant, train). They see it as direct real-time IM.
They will keep using IM anyway. But see uses for text/t140 too and will use
it if it is convenient.
The 2 IM freaks agreed, though they prefer IM, but if somebdoy contacts them
via interactive text text/t140, they will use it too.
"It depends who to contact to use the right text communication method. I
like the choice to have an alternative".

So. Yes.. I know people will like it. Not everybody will use interactive
text. Some will thus only use if somebody else uses it, whether a deaf
person or one who likes to use text/t140.

All of them hope that interactive text will be mainstream and will use it
with varying degrees, from sometimes, to daily. 

So, this is my message, from an interactive text user AND having
showed/demonstrated interactive text to other people. It is not my desire
only.

Greetz

Arnoud

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: vrijdag 2 juli 2004 9:19
To: [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: Tiny ant vs big Mammoths, was RE: [Simple] Using MSRP for real
time text conversation

Arnoud,

You speak as if you have done the market research already for all of us :)
How do you know that people will appreciate it once they discover it? How do
you know that people will use it? How do you know that it adds value to the
phone instead of just implementing something that no one will use? How do
you know that if I like interactive text, then my mum and dad will and buy a
phone like mine just to use interactive text???? How do you know...?

Did people complain to you that IM the way it is these days in annoying to
use? or are you just stating your opinion?

And about mobile phones. If you can type an SMS faster than 2 characters a
second, you're a genius. Even if you can, I don't believe operators would
want to floor they scarce air interface with IP packets that carry 2
characters at a time.

Thanks,
Hisham

---

From: "Gunnar Hellstrom" <[email-masked]>
Date: Tue, 6 Jul 2004 08:22:31 +0200

I opened a new thread under the name

RE: [Simple] Using MSRP for (pseudo?) real time text conversation

For discussing conclusions and negotiation.
Hope you all will join there.

I agree with Arnoud in the impression that any user you show real time text conversation
to, say that it is very good and needed in future services.

So, please look for the new subject line and start thinking about what inter-relations
that are needed do declare and negotiate what text service you can and want to use. And
answer these messages, so that we get back to one thread.

Gunnar

-------------------------------------------
Gunnar Hellstrom
Omnitor AB
Renathvagen 2
SE 121 37 Johanneshov
SWEDEN
+46 8 556 002 03
Mob: +46 708 204 288
www.omnitor.se
[email-masked]
--------------------------------------------

>From: [email-masked] [mailto:[email-masked]]On
>Behalf Of Arnoud van Wijk
>Sent: Sunday, July 04, 2004 11:32 AM
>To: [email-masked]; [email-masked];
>[email-masked]
>This list is maintained by Snowshore Networks - http://www.snowshore.com

---

From: "Barry Dingle" <[email-masked]>
Date: Wed, 7 Jul 2004 12:43:39 +1000

Some thoughts on this subject. I approach this from a Service level.

Real time or near real time text service is essential for some legislative environments eg. Australia where 'equivalent' service
to telephony is defined for people who cannot effectively use telephony.

Use of mainstream protocols is important for the disabled community in order that they can communicate with all people not just
amongst people with the same special terminals.

MSRP provides a very useful mainstream, text communication service. It provides a different 'user feel' to a
character-by-character service. Its performance could improve over time.

text/t140 (RFC2793) is an important near real time text service that is consistent with traditional multimedia services and with
the SIP controlled real time multiservice environment.

Choice is important for users so that we do not get locked into one service if a better service becomes available. Therefore
negotiation is essential.

Both MSRP and rfc2793 work with SIP/SDP so negotiation should not be too difficult.

Cheers,

Barry DINGLE
Telecommunications Consultant
Project Manager - ACIF Any-to-Any Text Connectivity Options WG
Fellow of the University of Melbourne
   [email-masked]
Mob:   +61 (0)41 911 7578
Fixed: +61 (0)3 9725 3937
----- Original Message ----- 
From: "Gunnar Hellstrom" <[email-masked]>
To: "Arnoud van Wijk" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Tuesday, July 06, 2004 4:22 PM
Subject: RE: Tiny ant vs big Mammoths, was RE: [Simple] Using MSRP for real time text conversation

> >They could communicate with somebody in Sweden, and with me on a different terminal in a different room.
> >The 3 deaf wanted to take it home right now. Being able to communicate everywhere , everytime..finally free!
> >The 5 who worked in the deaf business, they loved it and want to see it implemted and mainstream. They love it and will use
it regularly to
> >communicate with deaf and some even say that it can be quite convenient for hearing people as well.
> >
> >They said, wow... this is much more direct then IM, you can actually call people in situations where voice is a bit not done
(think cinema, concert,
> >They will keep using IM anyway. But see uses for text/t140 too and will use it if it is convenient.
> >The 2 IM freaks agreed, though they prefer IM, but if somebdoy contacts them via interactive text text/t140, they will use it
too.
> >"It depends who to contact to use the right text communication method. I like the choice to have an alternative".
> >
> >So. Yes.. I know people will like it. Not everybody will use interactive text. Some will thus only use if somebody else uses
it, whether a deaf
> >All of them hope that interactive text will be mainstream and will use it with varying degrees, from sometimes, to daily.
> >
> >So, this is my message, from an interactive text user AND having showed/demonstrated interactive text to other people. It is
not my desire

---

From: Mike Hammer <[email-masked]>
Date: Thu, 08 Jul 2004 11:32:54 -0400

Barry,

I would object to the ENTERED aspect, as that starts into specifying the 
nature of the service beyond the transmission performance requirements.  As 
a user, I always want to reserve the right to edit and erase or correct my 
text before indicating intent to transmit information.  If you want to make 
it more generic and service independent, you would need to say something like:

Transmission delay must be less than N ms from when the sender intends for 
the text data to be sent.  "Intent" can be automated or manually indicated.

Note that the main difference between the RTT and IM modes of texting is 
that the RTT user has his intent to send automated to do so after every 
character, with possibly a buffer batching characters into one message when 
within 300 ms of each other.  In the case of IM, the intent to send is an 
explicit indication by hitting the ENTER, SEND, or similar key.  A 
performance metric should not preclude that feature.

Q:  Does the 300ms batching count against the transmission delay in your 
ENTERED proposal?  My suggestion would put that outside the transmission delay.

It would be possible on IM systems to put a timer on the sending aspect 
that in the limit would approach the behavior of RTT.  However, the 
approach of some systems to interleave lines of text of various parties 
engaged in an IM session into the same window would need to change.

Mike

At 10:49 AM 7/8/2004 +1000, Barry Dingle wrote:
>Mike,
>Comments below.
>From: "Mike Hammer" <[email-masked]>
>To: "Barry Dingle" <[email-masked]>
>Sent: Thursday, July 08, 2004 1:04 AM
>Subject: Re: Tiny ant vs big Mammoths, was RE: [Simple] Using MSRP for 
> > Does Australia define what is considered "real-time", form a 
> performance measurement perspective?
> >
>Good question. We are keen to base our services (text and other) on 
>international specifications and that is progressively
>happening. Our end-to-end service performance requirements are following a 
>similar approach. That means (at present) that ITU-T
>F.700 is used as a starting point.
>
>(Note that the F.700 T1 2 second delay figure (for useable service) is 
>often quoted but there is growing interest in specifying
>the T2 1 second delay figure (for good service) - along with the lower 
>character corruption rate as well.)
>
> > In other words, if the data arrives within, say one second, of when it 
> was transmitted, be that data one character or one
>sentence, is that fast
> > enough to be real time?
> >
>You use a very specific way to define delay in your statement 'when it was 
>transmitted'. From a user perspective, text
>conversation delay is from when each character is entered to when it is 
>displayed at the remote end. It includes any buffering
>delay.
>
>If I reword your statement to "if the data arrives within, say one second, 
>of when it was ENTERED, be that data one character or
>one sentence, is that fast enough to be real time?" then my answer would 
>be POSSIBLY YES. The proviso is that the 'user feel' is
>different - more bursty. Maybe we need to specify the variability of delay 
>as well as the delay to cover this situation. (To
>start discussion, based on recent discussions, how about a 500 ms delay 
>variation max?)
>
> > The reason I ask is that some folks on these mail lists have claimed 
> that IM is not real time, but I think they are basing
>that conclusion on their
> > experience with SMS, for which there is an observable delay, rather 
> than a point-point IM model which is as fast as 2793 once
>the send key is pressed.
> >
>We should base our discussions on 'agreed user requirements', not names 
>like 'real time' with different meanings to different
>people. But the requirements should not be 'manufactured' to suit a 
>particular service. I said 'real time or near real time'
>because I believe that some' near real time' services can be adequate for 
>text. (Note - speech and video may have different
>requirements!!)
>
>
> > Mike
> >
> >
> > At 12:43 PM 7/7/2004 +1000, you wrote:
> > >Real time or near real time text service is essential for some 
> legislative environments eg. Australia where 'equivalent'
>service
> > >Use of mainstream protocols is important for the disabled community in 
> order that they can communicate with all people not
>just
> > >text/t140 (RFC2793) is an important near real time text service that 
> is consistent with traditional multimedia services and
>with
> > >Choice is important for users so that we do not get locked into one 
> service if a better service becomes available. Therefore
> > > > >The 5 who worked in the deaf business, they loved it and want to see
> > > it implemted and mainstream. They love it and will use
> > >it regularly to
> > > > >They said, wow... this is much more direct then IM, you can actually
> > > call people in situations where voice is a bit not done
> > >(think cinema, concert,
> > > > >The 2 IM freaks agreed, though they prefer IM, but if somebdoy
> > > contacts them via interactive text text/t140, they will use it
> > >too.
> > > > >"It depends who to contact to use the right text communication method.
> > > I like the choice to have an alternative".
> > > > >
> > > > >So. Yes.. I know people will like it. Not everybody will use
> > > interactive text. Some will thus only use if somebody else uses
> > >it, whether a deaf
> > > > >All of them hope that interactive text will be mainstream and will use
> > > it with varying degrees, from sometimes, to daily.
> > > > >

---

From: "Barry Dingle" <[email-masked]>
Date: Thu, 8 Jul 2004 10:49:45 +1000

Mike,

Comments below.

Barry DINGLE

----- Original Message ----- 
From: "Mike Hammer" <[email-masked]>
To: "Barry Dingle" <[email-masked]>
Sent: Thursday, July 08, 2004 1:04 AM
Subject: Re: Tiny ant vs big Mammoths, was RE: [Simple] Using MSRP for real time text conversation

> Does Australia define what is considered "real-time", form a performance measurement perspective?
>
Good question. We are keen to base our services (text and other) on international specifications and that is progressively
happening. Our end-to-end service performance requirements are following a similar approach. That means (at present) that ITU-T
F.700 is used as a starting point.

(Note that the F.700 T1 2 second delay figure (for useable service) is often quoted but there is growing interest in specifying
the T2 1 second delay figure (for good service) - along with the lower character corruption rate as well.)

> In other words, if the data arrives within, say one second, of when it was transmitted, be that data one character or one
sentence, is that fast
> enough to be real time?
You use a very specific way to define delay in your statement 'when it was transmitted'. From a user perspective, text
conversation delay is from when each character is entered to when it is displayed at the remote end. It includes any buffering
delay.

If I reword your statement to "if the data arrives within, say one second, of when it was ENTERED, be that data one character or
one sentence, is that fast enough to be real time?" then my answer would be POSSIBLY YES. The proviso is that the 'user feel' is
different - more bursty. Maybe we need to specify the variability of delay as well as the delay to cover this situation. (To
start discussion, based on recent discussions, how about a 500 ms delay variation max?)

> The reason I ask is that some folks on these mail lists have claimed that IM is not real time, but I think they are basing
that conclusion on their
> experience with SMS, for which there is an observable delay, rather than a point-point IM model which is as fast as 2793 once
the send key is pressed.
We should base our discussions on 'agreed user requirements', not names like 'real time' with different meanings to different
people. But the requirements should not be 'manufactured' to suit a particular service. I said 'real time or near real time'
because I believe that some' near real time' services can be adequate for text. (Note - speech and video may have different
requirements!!)

---

From: "Barry Dingle" <[email-masked]>
Date: Fri, 9 Jul 2004 17:20:50 +1000

Mike,

As I said at the start of my first message, I am referring to requirements at a "Service level". Maybe I should have said a
"User Service level" to be very clear.

I am a firm believer in designing services/systems/protocols that are based on User Service requirements as a starting point. We
can then use this information to define the performance of individual components of the service (in this case). One does not say
this is the transmission characteristics of protocol and then change the User Requirements to suit.

One can of course do what you suggest and define some different user requirements based on what IM can achieve - but you are
defining a Different Service. OK, it is not radically different but different none the less. The key difference in the User
Requirements could be the ability to edit before sending.

The term 'Instant Messaging' is very descriptive of the service. It is fast messaging. It is not real time or near real time.

Many of us use the term "Text Conversation" to reflect the immediacy and real time, interactive nature of the service that we
have been talking about.

The ITU-T F.700 requirements are often quoted especially in relation to real time text services. It specifies both a 'useable'
service and a 'good' service. Most people have called up the 'useable' figures. The discussions recently are saying that maybe
we should be using the 'good' service figures in F.700 - that is, allowable delays from character entry to display of less than
1 second instead of 2 seconds.

I am fully in favour of IM as it provides a very useful service. I said that negotiation is very desirable so that users can
choose their preference but can fallback to an alternative. This is very much in the philosophy of the IETF.

As I also said, negotiation allows for a protocol to be enhanced and maybe become more acceptable for a particular service - if
the different versions of the protocol can be identified and included in the negotiation procedure.

 Now to your specific questions -

1) It is very hard to include 'user intent' in a protocol specification. 'Character entry' and 'character display' are easily
identifiable actions and allow performance measurability.

2) Any buffering delay MUST be included in any user delay performance measurement. If the buffering is of short duration, then
it could enable that protocol to meet the 'near real time' criterion.

3) If we can negotiate at session startup that IM can send with short delays, then it becomes an option for the real time text
service.

4) Delay is only one of the factors that must be considered. Other issues could include the interworking with existing text
services.

/Barry
==================
> Barry,
>
> I would object to the ENTERED aspect, as that starts into specifying the nature of the service beyond the transmission
performance requirements.  As
> a user, I always want to reserve the right to edit and erase or correct my text before indicating intent to transmit
information.  If you want to make
> Transmission delay must be less than N ms from when the sender intends for the text data to be sent.  "Intent" can be
automated or manually indicated.
>
> Note that the main difference between the RTT and IM modes of texting is that the RTT user has his intent to send automated to
do so after every
> character, with possibly a buffer batching characters into one message when within 300 ms of each other.  In the case of IM,
the intent to send is an
> explicit indication by hitting the ENTER, SEND, or similar key.  A performance metric should not preclude that feature.
>
> Q:  Does the 300ms batching count against the transmission delay in your ENTERED proposal?  My suggestion would put that
outside the transmission delay.
>
> It would be possible on IM systems to put a timer on the sending aspect that in the limit would approach the behavior of RTT.
However, the
> approach of some systems to interleave lines of text of various parties engaged in an IM session into the same window would
need to change.
> >sentence, is that fast enough to be real time?
> > >
> >that conclusion on their experience with SMS, for which there is an observable delay, rather
> > than a point-point IM model which is as fast as 2793 once the send key is pressed.
> > >
> > legislative environments eg. Australia where 'equivalent' service
> > order that they can communicate with all people not just
> > is consistent with traditional multimedia services and with

---

From: Mike Hammer <[email-masked]>
Date: Fri, 09 Jul 2004 10:50:07 -0400

Barry,

Agree that these are different user services, given that one allows editing 
before transmission, while the other edits post-transmission.

I think you are also agreeing that if the "Instant" in IM meets fast delay 
requirements (e.g. the 1-2 seconds) then it could also be classified as 
"real-time".  But to keep a distinction, it would be real-time messaging 
versus real time text.

Mike

At 05:20 PM 7/9/2004 +1000, Barry Dingle wrote:

>Mike,
>
>As I said at the start of my first message, I am referring to requirements 
>at a "Service level". Maybe I should have said a
>I am a firm believer in designing services/systems/protocols that are 
>based on User Service requirements as a starting point. We
>can then use this information to define the performance of individual 
>components of the service (in this case). One does not say
>One can of course do what you suggest and define some different user 
>requirements based on what IM can achieve - but you are
>defining a Different Service. OK, it is not radically different but 
>different none the less. The key difference in the User
>The term 'Instant Messaging' is very descriptive of the service. It is 
>fast messaging. It is not real time or near real time.
>
>Many of us use the term "Text Conversation" to reflect the immediacy and 
>real time, interactive nature of the service that we
>have been talking about.
>
>The ITU-T F.700 requirements are often quoted especially in relation to 
>real time text services. It specifies both a 'useable'
>service and a 'good' service. Most people have called up the 'useable' 
>figures. The discussions recently are saying that maybe
>we should be using the 'good' service figures in F.700 - that is, 
>allowable delays from character entry to display of less than
>I am fully in favour of IM as it provides a very useful service. I said 
>that negotiation is very desirable so that users can
>As I also said, negotiation allows for a protocol to be enhanced and maybe 
>become more acceptable for a particular service - if
>1) It is very hard to include 'user intent' in a protocol specification. 
>'Character entry' and 'character display' are easily
>2) Any buffering delay MUST be included in any user delay performance 
>measurement. If the buffering is of short duration, then
>3) If we can negotiate at session startup that IM can send with short 
>delays, then it becomes an option for the real time text
>service.
>
>4) Delay is only one of the factors that must be considered. Other issues 
>could include the interworking with existing text
>services.
>
>/Barry
>==================
> > Barry,
> >
> > I would object to the ENTERED aspect, as that starts into specifying 
> the nature of the service beyond the transmission
> > a user, I always want to reserve the right to edit and erase or correct 
> my text before indicating intent to transmit
> > Transmission delay must be less than N ms from when the sender intends 
> for the text data to be sent.  "Intent" can be
> > Note that the main difference between the RTT and IM modes of texting 
> is that the RTT user has his intent to send automated to
>do so after every
> > character, with possibly a buffer batching characters into one message 
> when within 300 ms of each other.  In the case of IM,
>the intent to send is an
> > Q:  Does the 300ms batching count against the transmission delay in 
> your ENTERED proposal?  My suggestion would put that
> > >happening. Our end-to-end service performance requirements are 
> following a similar approach. That means (at present) that
>ITU-T
> > > > In other words, if the data arrives within, say one second, of when 
> it was transmitted, be that data one character or one
> > >You use a very specific way to define delay in your statement 'when it 
> was transmitted'. From a user perspective, text
> > >conversation delay is from when each character is entered to when it 
> is displayed at the remote end. It includes any
>buffering
> > >delay.
> > >
> > >If I reword your statement to "if the data arrives within, say one 
> second, of when it was ENTERED, be that data one character
>or
> > >one sentence, is that fast enough to be real time?" then my answer 
> would be POSSIBLY YES. The proviso is that the 'user feel'
>is
> > >different - more bursty. Maybe we need to specify the variability of 
> delay as well as the delay to cover this situation. (To
> > > > The reason I ask is that some folks on these mail lists have 
> claimed that IM is not real time, but I think they are basing
> > >We should base our discussions on 'agreed user requirements', not 
> names like 'real time' with different meanings to different
> > >because I believe that some' near real time' services can be adequate 
> for text. (Note - speech and video may have different
> > >requirements!!)
> > >
> > >
> > > > Mike
> > > >
> > > >
> > > > > > I agree with Arnoud in the impression that any user you show 
> real time
> > > > > text conversation
> > > > > > So, please look for the new subject line and start thinking 
> about what
> > > > > inter-relations
> > > > > > that are needed do declare and negotiate what text service you 
> can and
> > > > > want to use. And
> MSRP for
> > > > > > >per character..oh Yawn... lovely... pish posh. They could not 
> imagine
> > > > > it. No
> > > > > > >concept of it.
> > > > > > >
> > > > > > >Then I showed them.
> MSRP for
> > > > > > >How do you know that people will appreciate it once they 
> discover it?
> > > > > How do
> > > > > > >you know that people will use it? How do you know that it adds 
> value
> > > > > to the
> > > > > > >you know that if I like interactive text, then my mum and dad 
> will and
> > > > > buy a

---

From: "Gunnar Hellstrom" <[email-masked]>
Date: Sat, 10 Jul 2004 08:58:17 +0200

Mike,

I get the impression that you missed the intensive mail exchange that took place in the
lists the last two weeks or so.
You can find it in the archive of the simple group.

I appreciate that Barry refers to the service descriptions in F.700 and F.703. I think
they reflect well the service we know that there is a need for, but is not yet wide
spread.

The "real time" we are talking about gives the same feeling for text as voice telephony
gives for voice users. No waiting. The receiver builds understanding of the thought while
it is expressed by the transmitting person. If you say a word in mistake, you say
"whoops - I meant...", if you type something in error you can erase it in front of the
reader?s eyes, or type "whoops - I meant ...".
This direct mode is needed to get really deep in a text based discussion. It is also
needed if you want to offer online text translation of a speech or conference.

If a sentence of text is stored until pressing ENTER or SEND, the typing person may get
stressed by the feeling to need to complete the thought soon, and the reader may get
stressed by sitting waiting and start fancying that the typing person types away in long
explanations that are not needed, or on the wrong track.

Of course there are also situations, when the message oriented transmission is perfectly
suitable.

In previous discussions and documents we have used the terms "conversational text" "text
conversation" and "interactive text" and even "real time interactive text conversation"
for the real time, character-by-character (or close to) mode. We have noted that it is
sometimes hard to get the distinction across and wondered if we need yet another term, or
just sharpen the definitions.

IM applications often have a button, where a real time voice and video conversation can be
started. Then real time protocols are invoked, with RTP for media transport. It would be
natural to also enter real time conversational mode in text with that button. Most natural
the text transmission would also be RTP.

But with the value of a real timish text mode, there may be a reason to also make the near
real-time MSRP mode, with transmission every 900 ms and smoothened presentation. In good
network conditions that will still meet the requirement for "good" real time text as
specified in F.700.

Gunnar

>From: [email-masked] [mailto:[email-masked]]On Behalf
>Of Mike Hammer
>Sent: Friday, July 09, 2004 4:50 PM
>To: Barry Dingle; [email-masked]; [email-masked]; [email-masked]
>Cc: Barry Dingle

---

From: Mike Hammer <[email-masked]>
Date: Mon, 12 Jul 2004 12:19:55 -0400

Gunnar,

No, I have seen the whole conversation in all its talk-past one another 
glory.  Even so, I have a full appreciation for the mode of communication 
service that goes by the name of RTT and fully support having that 
capability become mainstream.

I fully understand the distinction between instant text, character by 
character, and instant messaging.  For, my own personal use, I have a 
preference for one over the other.  The use of one or the other should be a 
matter of negotiation, not wide availability, or lack thereof, of each mode.

I only asked a simple question, both to Barry and to you in sidebars to the 
email threads:  "When can a text communications service be considered 
real-time?"

Barry responded, albeit putting it on the mail list.  In several of your 
messages you imply that instant messaging is not instant, i.e. 
real-time.  I suspect this impression of yours is based on personal 
anecdotal experience (I'm guessing SMS), and not generally applicable to 
all such services provided today.

I was simply trying to clarify a term being used on these lists, that has 
both technical and legal implications.  Please don't hold a desire for 
clarity against me.  I am not pushing any agenda.

Mike