Subject: RE: [Simple] Using MSRP for real time text conversation

From: [email-masked]
Date: Wed, 30 Jun 2004 11:05:17 +0300

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]On Behalf
> Of ext Gunnar Hellstrom
> Sent: 29.June.2004 22:58
> To: Dean Willis; Ben Campbell
> Cc: STF267; Adam Roach; [email-masked]; [email-masked]
> Subject: RE: [Simple] Using MSRP for real time text conversation
> 
> 
> Thanks for good summaries and questions.
> Comments inline,
> 
> 
> >Re-adding my comments to this branch of the thread:
> >
> >Dean Willis wrote:
> >
> >>
> >>
> >> Adam Roach wrote:
> >>
> >>> Gunnar:
> >>>
> >>> I'm very confused. Why do you want to use MSRP for T.140 text? You
> >>> don't *need* MSRP to have T.140 conversations. You just carry them
> >>> like any other real-time streams -- isn't that the point 
> of RFC 2793?
> >>>
> >>
> >> Darn these cross-list discussions. You and Hisham seem to 
> have missed
> >> the first forty messages in this thread, and reacted with 
> justifiable
> >> surprise.
> >>
> >> Recap, for those who missed the first season of our serial drama:
> >>
> >> Gunnar does NOT "want" to use MSRP -- he proposed using 
> T.140 exactly as
> >> you discussed it above. He also wants real-time text in 
> every phone and
> >> messaging device produced, for 100% availability, a goal 
> that I find
> >> agreeable.
> >>
> >> However, I don't want to use T.140. Emulating reliability 
> by requiring
> >> multiple transmissions of every character without regard for real
> >> network conditions is a horrible violation of the 
> principles of RFC2914.
> 
> It is not T.140 you are suspicious to, it is to use the RTP 
> packetisation text/t140 as
> specified in rfc2793 ( and -bis ) that you have doubts about.
> 
> The repetitions are sent together with new characters, and 
> therefore do not cause any
> remarkable increase in load.
> 
> The unusual characteristics of this rtp packetization makes 
> it not as horrible as you seem
> to think.

If it is not as horrible, then can you remind me why we are discussing using MSRP for real time text? I am confused now since Dean gave the reason, but you replied saying that reasoning is not entirely true.

Thanks,
Hisham

> 
> It is not a true character-by-character transmission. All 
> characters typed during a
> buffering interval are transmitted together. The default 
> buffering time is 300 ms. If no
> data is available for transmission, no packet is sent.
> 
> User spend often more time thinking and reading than they 
> spend typing. So, studying max
> values does not give you a good view of the real ( low ) load.
> 
> The additional words about actions in case of congestion 
> should be effective. RTCP info
> can be the base for increasing buffering time.
> 
> >>
> >> So, I raised the question: Could we use a reliable and 
> 2914-compliant
> >> protocol like MSRP to meet the needs of real-time text? We are now
> >> discussing this possibility, using MSRP as the baseline.
> >>
> >> Open questions:
> >>
> >> 1) Would the user experience be acceptable?
> With 300 ms between transmissions if there is data, I would 
> expect MSRP to behave just as
> well as RTP text/t140, assuming that it gets through NAT and 
> firewalls.
> 
> We saw that the bandwidth seems to be 3 times higher for 
> MSRP. If we compensate by
> increasing buffering time we reach 1 second buffering time, 
> and that will be regarded too
> slow and chunky. 500 ms is the limit.
> 
> >>
> >> 2) What is the bandwidth required, relative to T.140?
> >
> >If you send one char per message, absurdly huge. If you use 
> some of the
> >streaming features of MSRP, this might could be somewhat 
> mitigated. But
> >this would be an extremely constrained and mutant usage of 
> MSRP as it is
> >currently described.
> With maximum allowable 500 ms for MSRP it will be 4 kbit/s. 
> With 300 ms buffering it will
> be 2 kbit/s for text/t140. 4 kbit/s would not be popular in a 
> mobile situation. Otherwise
> it is probably OK. We are dealing with calls where it will be 
> in many cases favourable to
> use video and audio as well.
> >
> >>
> >> 3) How much change would this imply for MSRP?
> >>
> >
> >I am assuming the 1 char per message approach is not even on 
> the table.
> >If you use a stream approach, you will need loads of new 
> rules about how
> >to do this, and how to signal you want to do it.
> Look at 500 ms buffering instead.
> Would you dare to recommend it then?
> 
> 
> >
> >> 4) How will this affect the widepsread availability of 
> real-time text?
> >> Cullen has proposed that if this is simple as a check-box 
> in the GUI of
> >> every MSRP client, then EVERYBODY has eal-time text capability.
> >>
> >
> >I have no opinion on this. The jury is still out on the wide-spread
> >acceptance of MSRP.
> 
> I definitely hope that simple and MSRP gets widespread. The 
> current fragmentation in the I
> M world is a severely hampering factor for its message-wise 
> use. Impossible to procure for
> official use, impossible to use for public services. I wish 
> you all luck with a
> standardised protocol to replace the current situation!
> 
> But for its influence on the real time variant, I also want 
> to listen to the word from the
> jury...
> >
> >> 5) What are the pros and cons of the various approaches 
> with respect to
> >> firewalls and NATs? Clearly TCP has some advantages, and MSRP has
> >> relays, but TURN and STUN give us some existing 
> infrastructure for T.140.
> 
> There are also true SIP aware NAT-routers and firewalls that 
> handle SIP and RTP well. I do
> not know how well they handle MSRP.
> >>
> >> 6) is there a sufficient perception of value in the 
> community to justify
> >> adding this sort of function to MSRP, or would yet another 
> protocol be
> >> required?
> >
> >Well, adding this to the MSRP base spec would be long and 
> painful. I am
> >in principle opposed to adding any significant new 
> requirements to MSRP,
> >as it would put at serious risk of never completing it.
> Three small things need to be done:
> a. Optional real time transmission in 500 ms buffers.
> b. MIME declaration of the transmission in a new text/t140p 
> format that is just the plain
> UTF-8 coded T.140 transmission.
> c. A request on the receiver to add received text for display 
> in one window per
> transmitting party.
> 
> 
> 
> >
> >I also don't think that real-time text is in scope, or in 
> charter, for
> >SIMPLE.
> >
> >Now, if we, or someone else, decide(s) that it makes sense to extend
> >MSRP to allow this, I am not strongly opposed, as long as it does not
> >disrupt work on the base spec. (I am not by that statement indicating
> >that I do thing it makes sense.)
> >
> Same here, we have to judge the possible outcome of question 
> 4 above, and balance it
> against the influence on already started activities to 
> specify text/t140 as the way to do
> text conversation, emergency etc.
> 
> Gunnar
> >>
> >> --
> >> Dean
> >>
> >> _______________________________________________
> >> Simple mailing list
> >> [email-masked]
> >> https://www1.ietf.org/mailman/listinfo/simple
> >
> >
> 
> 
> 
> _______________________________________________
> Simple mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/simple
> 

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

---

From: "Gunnar Hellstrom" <[email-masked]>
Date: Wed, 30 Jun 2004 22:50:50 +0200

Hisham asks:
"can you remind me why we are discussing using MSRP for real time text?"

This was the initiating message from Cullen, coming from avt, where we discussed details
in RFC2793bis.

"Dropped off sipping and avt and added simple mailing list...

I like this list but I think you have one other thing you want. You want to
make a protocol that actually gets build and deployed. The narrower the
market is that is addressed by your solution or as it gets more complex to
build, the less the odds are of it being build. IM is going to be build.
Session mode IM is highly likely to be build.

What would you need changed to the current requirements for session mode IM
in SIMPLE for it to meet all of your requirements? I believe there are extra
requirements, I¹m just trying to figure out what they are so perhaps we can
see if they can be addressed in IM.

Cullen"

So, it was merely picking up a market related thought.

The thought of using tcp for text conversation has been up for discussion on and off
through the years. It is allowed but not preferred in H.323. In SIP it has been out of
question so far. We know by experience that we have a fully functional RTP specification
that easily flows with its companion media, and presents with satisfactory reliability.

But Cullen´s challenge was too tempting, so we did the feasability study, and today Mary
added weight to the discussion, claiming that we have an obligation to go ahead.

I also did an interesting experiment today. I and my deaf son set up a text session with
two text/t140 clients. One was set to send immediately, the other we set to different
buffer times. At 300 ms both were quite satisfied with the dialogue quality. At 500 ms, I
still thought it was well usable even if a bit gluish, while he definitely did not like
the non-direct feeling, but could of course converse through it without real problems.
That was a rapid validation of the figures in RFC2793 and T.140. They say that 500 ms is
upper limit and 300 ms shoud be default.

So, further discussions will need to settle if we need to stay with the pseudo-real time
buffering of 500 ms or if we dare to leave an opening for the good 300 ms.

Gunnar
-------------------------------------------
Gunnar Hellström
Omnitor AB
Renathvägen 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 [email-masked]
>Sent: Wednesday, June 30, 2004 10:05 AM
>To: [email-masked]; [email-masked];
>[email-masked]
>Cc: [email-masked]; [email-masked]; [email-masked];
>[email-masked]
>If it is not as horrible, then can you remind me why we are discussing using
>MSRP for real time text? I am confused now since Dean gave the reason, but you
>replied saying that reasoning is not entirely true.
>
>Thanks,
>Hisham
>
>>