[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Simple] I-DAction: draft-hellstrom-simple-text-transmission-00.txt - the need
There was a good discussion about real-time text transport with MSRP in the
SIMPLE meeting, and an agreement to continue the discussion in the list.
At least three topics crystallized:
-The need for real-time-text among mainstream IM users.
-The transport method for real-time-text in IM sessions.
-The extent and mechanisms for erasure of already transmitted text.
I want to start the discussion on the need for real-time text in connection
with IM sessions.
I have observed that some people think that a real-time-text feature in IM
would be only for the benefit of deaf users. That view was also mentioned in
the meeting.
We will get much better push for implementations if we agree that this
feature is something for all. It will enhance the user experience of any IM
session, and especially intensive conversational ones.
Some IM systems displays that the other end is typing a response. The fact
that the designers felt the need to tell me that a response is currently
being typed indicates a need for conveying that information. A more natural
way of conveying that would be to start displaying what is being typed now
rather than waiting for a whole message to be completed. The acceptance of
that observation should be enough to convince all to introduce time-sampled
real-time text transport in IM systems.
If that is not enough to get an agreement that this is a generally desirable
feature, I have a few more observations:
I have noticed that if you ask people about their IM experience they tell
things that should result in communications developers to implement
real-time text functionality.
These are typical examples of questions and answers when discussing
message-wise IM:
Q: Do you use IM.
A: Yes, a lot, and it is good.
Q: Do you have two-party chats, or multi-party chats?
A: Sometimes multi-party chats for pleasure, but in 99% of the cases it is
two-party chats set up by intention to sort out a specific question.
Q: Do you change your language when you have an intensive IM discussion or
are in a hurry?
A: Yes, I shorten off sentences and break them up in short few word
statements so that I can keep the communication going. The language gets
corrupt, but we manage with the communication.
Q: Do you have other concerns when typing?
A: Yes, I want to send as soon as possible so that the other person does not
start to think that they need to explain more or add items.
Q: What do you think when you are waiting for next message?
A: I often think "what will next entry be". I start to wonder if they need
more info or more precise questions right away so they do not waste typing
time on things I know. Sometimes this leads to me sending another message
before I had a response, and then confusion starts. It starts to be
complicated to know what answer belongs to what question.
Real-time text can be used to sort out these witnessed draw-backs of
message-wise IM among mainstream users. It would be sad to leave the IM
systems without this feature. The real-time text feature is defined for
real-time conversational service use in RTP by RFC 4103, but thereasoning
above indicate a need to define the feature also for IM systems.
So, if we have sufficient agreement on the reasoning above we can move to
next question: What transport mechanism shall we use for real-time text in
connection with MSRP?
Gunnar
-------------------------------------------------------------------
Gunnar Hellström
Omnitor
www.omnitor.se
-----Original Message-----
From: simple-bounces at ietf.org [mailto:simple-bounces at ietf.org] On Behalf Of
Adam Roach
Sent: Monday, March 10, 2008 4:29 PM
To: Ben Campbell
Cc: 'Paul E. Jones'; Erik.Zetterstrom at omnitor.se; Gunnar Hellström; 'Simple
WG'; 'Gregg Vanderheiden'
Subject: Re:
[Simple]I-DAction:draft-hellstrom-simple-text-transmission-00.txt
On 3/10/08 11:22 AM, Ben Campbell wrote:
>
> On Mar 10, 2008, at 10:59 AM, Adam Roach wrote:
>
>>
>> I think #4 is exactly the right way to do it -- send the real-time
>> text over RTP; reiterate it on message boundaries in MSRP; and do
>> some kind of correlation in the SDP to indicate that a specific MSRP
>> stream is associated with the specific RTP stream.
>>
>
> I'm a little confused--if you have already sent it over RTP, why do
> you need to reiterate it?
>
> Thanks!
RTP doesn't have defined semantics around message boundaries. The redundant
information in MSRP overlays those semantics on top of the real-time text.
(It will also repair any text lost over the text RTP channel, as text RTP
merely sends text redundantly, whereas MSRP's use of TCP involves explicit
acknowledgments).
Also, this kind of solution has nice incremental fail-back behavior: a
client using this mechanism will end up negotiating a reasonable user
experience with:
1. Other clients using this mechanism (with full functionality)
2. Clients that implement just MSRP but not RTP text (albeit without
the realtime component)
3. Clients that implement just RTP text but not MSRP (albeit without
the message boundary component).
/a
_______________________________________________
Simple mailing list
Simple at ietf.org
https://www.ietf.org/mailman/listinfo/simple
__________ NOD32 2933 (20080310) Information __________
Detta meddelande dr genomsvkt av NOD32 Antivirus.
http://www.nod32.com
_______________________________________________
Simple mailing list
Simple at ietf.org
https://www.ietf.org/mailman/listinfo/simple