Subject: Re: [Simple] RE: [Sipping] RE: text/T140 and audio/t140 was:[avt]Comments/questions on draft-ietf-av

From: Paul Kyzivat <[email-masked]>
Date: Thu, 24 Jun 2004 09:23:45 -0400

Guido Gybels wrote:
> Gregg,
> 
> I agree with all you say and I'd like to add an important point. It seems we are going back to discussions we had a year ago. Messaging can NOT replace interactive text anymore than it replaces voice communication for hearing people. I have attached the short paper that I wrote for last year's IETF discussion on this topic.
> 
> One critical issue is that of relay communications: if you want to use a relay service for text-to-speech, like for example RNID Typetalk, messaging simply does not work at all. Streamed, character by character text is a MUST for that type of conversation.

Maybe I missed something, but I don't recall anyone here recently 
suggesting that messaging *should* replace interactive text.

I believe Cullen was asking if interactive text could be integrated into 
the MSRP work. (Sorry Cullen if I misrepresent you.)

I suggested that IM *clients* might be modified to support *either* 
message exchange or real time text. In that scenario, which protocol to 
use would be negotiated by the two endpoints. If one can do both IM and 
RTT, and the other can only do IM, then the conversation would use IM. 
(Maybe I'm wrong, but I suspect if the choice is between IM and nothing, 
that you would prefer IM, regardless of how unsuitable you find it.)

I accept your point that IM isn't suitable for a bunch of the 
communication needs of the hearing impaired. (Among others.) But I also 
want you to accept that RTT isn't a suitable substitute for IM in the 
applications that millions (actually probably 10s or 100s of millions) 
of people use it everyday.

So RTT is a different medium that IM. However it is in some ways more 
closely connected to IM than to voice or video, because both work with text.

The choice seems to be whether RTT is supported by a unique set of (hard 
or soft) devices, or whether it is supported by the some or all of the 
devices that already support voice, video, or IM.

If it is supported only by special devices, then you will only be using 
it to communicate with those who bother to have such a device. If you 
can arrange for it to be supported by more common devices, then you will 
have a broader range of people to communicate with. It seems to me there 
is at least a possibility of getting typical IM devices to support RTT - 
more likely than getting voice or video phones to do so.

	Paul

> Best wishes,
> 
> Guido
> 
> 
> 
> 
> Guido Gybels
> Director of New Technologies
> 
> RNID, 19-23 Featherstone Street
> London EC1Y 8SL, UK
> Tel +44(0)20-7294 3713
> Fax +44(0)20-7296 8069
> 
> 
> 
>>>>"Gregg Vanderheiden" <[email-masked]> 06/23/04 04:25pm >>>
>>>
> Hi all
> 
> A sixpack of quick comments. 
> 
> 1 - if you don't have anything else, a phone keypad for text entry and even
> a 12 character display is wonderful.   The alternative is nothing.
> 
> 2 - if possible, any type or size of keyboard with one key per character is
> better easier simpler faster.
> 
> 3 - real time text (rather than messages) is much better for conversations.
> 4
>   - even 5 second message delay breaks all of our conversational protocols
> and expectations and leads to interruptions, misinterpretations of intent
> etc -- especially if one of the communicators is used to speech.  Delays
> beyond this are another form of communication (messaging) which is not bad
> it just is not conversation.   It is definitely communication, interaction,
> a lot of things.  But it differs from conversation as we know it. 
> 
> 5 - it would be great to have bridges between messaging and conversation
> technologies to use when conversation technologies are not possible or
> available for some reason. 
> 
> 6 - messaging is preferred by some and for some situations.  It is not
> inferior - it is just different.  It will be better at some tasks and worse
> at others. 
> 
> 
>  
> Gregg
> 
>  -- ------------------------------ 
> Gregg C Vanderheiden Ph.D. 
> Professor - Ind. Engr. & BioMed Engr.
> Director - Trace R & D Center 
> University of Wisconsin-Madison 
> 
> -
> 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 
> 
> 
> 
> 
> ************************************************************************
> This email and any files transmitted with it are confidential
> and intended solely for the use of the individual or entity to
> whom they are addressed. Any views or opinions expressed
> are solely those of the author and do not necessarily represent
> RNID policy.
> 
> If you are not the intended recipient you are advised that any
> use, dissemination, forwarding, printing or copying of this
> email is strictly prohibited.
> 
> If you have received this email in error please notify the RNID
> Helpdesk by telephone on: +44 (0) 207 296 8282.
> 
> The Royal National Institute for Deaf People  
> Registered Office 19-23 Featherstone Street 
> London EC1Y 8SL No. 454169 (England)
> Registered Charity No. 207720
> ************************************************************************
> 

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

---

From: "Paul E. Jones" <[email-masked]>
Date: Thu, 24 Jun 2004 19:15:47 -0400

Paul,

> of people use it everyday.

ICQ once had a mode wherein one could send character-at-a-time and it worked
pretty well (may still be in there).  What was nice about it was that one
could begin his/her reply even before the other person finished his/her
message.  I found the two-way exchange much better than today's IM systems,
as there was virtually no delay-- it was real-time.

One of the reasons why the IM systems today have problems in scaling is that
they have to interface with servers that handle message exchange between all
those users you spoke about.  The farm of servers to run the existing IM
systems do a lot of work and it's not a trivial task.  The problem with the
model is that farm of central servers that receive and dispatch messages.
(Perhaps SIMPLE has done something to improve on the current state of
technology, but I'll confess that I don't know.)

If we can solve the scalability issues required to handle lots of voice and
video streams flowing between users, then it would not take a great leap to
do the same thing for text (literally).  There may be more text sessions,
but the only change in resource requirements from blocks of text and RTT are
the resources required to process messages (as there are more RTT packets).
For voice, those fifty or so packets per second would not flow through
centralized servers and neither should the text.  If the system operated
allowing media to flow point-to-point, the RTT would scale.  I guess the
question is whether we will be able to allow audio to flow point-to-point or
whether the FWs, NATs, "session border controllers", and such devices will
inhibit that.

Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 25 Jun 2004 10:30:06 -0400

> as there was virtually no delay-- it was real-time.

Different strokes for different folks. I personally hate that.

> technology, but I'll confess that I don't know.)

Well, MSRP is being designed so it can be used point to point. OTOH, it 
seems that nobody believes it will be used that way in practice. Most 
people seem to think that network administrators won't want to let IM 
thru the firewall without logging it. And the explicit support of relays 
(rather than the hacks involving TURN that are proposed for RTP) is also 
assumed to be the solution for NATs. So whatever cost their is for 
having relays is assumed to be a requirement or a feature.

> do the same thing for text (literally). 

But those techniques don't lend themselves to easily 
monitoring/recording all the media. Because IM is newer and so lacks the 
legal precedents that voice has, and because the volume (in bits) of IM 
is substantially less than voice, it is feasible to log it all. (Whether 
that is a good thing from a social perspective or not.) At least in case 
of IM to/from enterprises it seems that is the intent. That argues 
against using an approach where relays are extra burdensome.

 > There may be more text sessions,

I think you may be arguing for RTT as an alternative to MSRP or other 
message oriented transport of IM. If so, T.140 fails to meet many of the 
requirements that MSRP has been asked to solve, around confirmation of 
messages, transmission of material of variouls media types, etc.

> whether the FWs, NATs, "session border controllers", and such devices will

STUN is the preferred technique for getting RTP thru nats and firewalls. 
It does result in e2e flows, and it would work for RTT as well. But IM 
is a different story.

	Paul (K)

---

From: "Paul E. Jones" <[email-masked]>
Date: Fri, 25 Jun 2004 14:25:00 -0400

Paul,

> against using an approach where relays are extra burdensome.

If somebody is so bent on recording everything coming in and out of his
realm of control, then let him buy the horsepower to do it.  I do not think
that a peer-to-peer model that works like voice and video should be pushed
aside for the sake of logging, irrespective of whether "page mode" or
"character-at-a-time" mode is used.

> messages, transmission of material of variouls media types, etc.

The loss of characters is detected with RFC 2793, though the sender is not
notified that characters are lost necessarily (I suppose this might be
gathered from the RTCP stats, but certainly no indication of specific text).
I see this as a carry-over from the existing systems.  I can see it as
useful, but not terribly useful.  One should get a BYE message from the SIP
session and if there was text in flight as the BYE came across the wire,
then the user should suspect it was lost.

MSRP definitely has the upper hand on transmitting non-text information,
such as pictures and other such things.  Perhaps the non-text information
could be transported via MSRP and text as RFC 2793.  Some devices will not
be able to accommodate the non-text information, anyway.  While it would
result in the RTT mode you don't like, it would also enable interworking
between IM systems and legacy TTY devices used by the deaf.  The latter
cannot operate in "block" mode.
 
> It does result in e2e flows, and it would work for RTT as well. But IM

One way... not sure if it is preferred.  Wasn't it intended to be a
temporary solution from MIDCOM?  In any case, I agree that would work in
many cases and would be useful for all RTP flows (audio, video, and RFC 2793
text).

Paul