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

From: "Gunnar Hellstrom" <[email-masked]>
Date: Sat, 26 Jun 2004 09:37:49 +0200

This is a continuation of the discussion about the feasability of using simple:s instant
messaging protocol MSRP for real time text conversation.

(The discussion was held under the subject: "RE: [Simple] RE: [Sipping] RE: text/T140 and
audio/t140was:[avt]Comments/questions on draft-ietf-avt-rfc2793bis-04". I thought it was
time to make it more clear what the real subject is.)

One factor for checking the feasibility of using MSRP for real time text conversation is
the bandwidth it creates.

We have just had a discussion about the real time requirements for the real time
experience of a text conversation. We have an old recommended figure saying that we should
ship session conencts at least every 300 ms. This is confirmed to give a good real time
experience. Some voices have been for transmission more often, but I think they are not
based on real experienced needs. Transmission less often creates an unpleasant chunkiness
in the perception of the dialogue.

So, for now, let us assume that transmission in 300 ms intervals is used (when there is
new text available for transmission ).

I made a calculation of a normal MSRP based text conversation exchange with material from
the MSRP specification.

This is the packet that needs to be sent for theree characters of text from the session:
------------------Lower level headers - do not bother to calculate
here----------------------
--------------------------IP V4 header  20 bytes -----
----------------------------TCP header  24 bytes -----
----------------------------MRSP SEND -189 bytes-including 3 bytes
payload--------------------
MSRP SEND
Boundary: d93kswow
To-Path:msrp://bob.atlanta.com:8888/9di4ea
From-Path:msrp://alicepc.atlanta.com:7777/iau39
TR-ID: 123
Message-ID: 123
Content-Type: "text/t140p"
Hi,
-------d93kswow+
--------------------------------End of SEND request-----------

So, it sums up to 233 bytes transmission = 1864 bits.

In order to get the real time experience we should allow 3.3 packets per second. That
makes 6150 bits/second.

The return direction will have approximately the same load by the 200 OK and the TCP
acknowledgements.

So, we would need approximately 6 kbit/s both ways for this text session. Most of it is
overhead, so it does not change much if we use the highest typing speed we design for,
that is 30 characters per second and type in Korean that will require 3 bytes UTF-8 per
character.

Using RTP, with text/t140 and two generations of redundancy that give good reliability,
consumes around 2 kbit/s in the same situation.

6 kbit/s is a bit high load, but I would say that it is not totally out of scope.

What do you think?

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]
--------------------------------------------

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

---

From: "A vWijk" <[email-masked]>
Date: Tue, 29 Jun 2004 14:05:49 +0200

So,

the answer to that "discussion" whether it it relevant to look at MRSP to use for real-time character per character text is actually unfavourable.
RFC 2793 gives a better and less bandwidth consuming solution which is ALREADY implemented!
Even though as Gunnar correctly pointed out, interactive text's bandwidth usage is so low compared to the audio and video streams

To avoid confusion. Just forget MRSP for real-time interactive text usage.
Just focus on adding the option to IM to switch between IM per message and real-time chat depending when the user desires/needs it. And switch back to IM mode.

greetz

Arnoud

Drs. Arnoud A. T. van Wijk
Viataal
Research & Development
Afdeling RDS
Theerestraat 42
5271 GD Sint-Michielsgestel
The Netherlands.
Mobile: +31651921948
International text telephone: +31735588408

>>> "Gunnar Hellstrom" <[email-masked]> 06/29/04 07:49am >>>
Adam,
Sorry for the confusion.
Yes, we have what we need for real time text in RTP with text/t140.

The discussion was started by a suggestion that use of MRSP for real time text would cause
a better uptake by the industry.

I do not know how that suggestion can be evaluated. Text/t140 is so easy to do, so it is
merely the understanding of the opportunities that is needed.

--------------------------

A lot has been said about good behaviour in the Internet in the thread, possibly
indicating that using real time text would not be good behaviour in the Internet. I think
it is. With MRSP we saw that we would have a load of about 6 kbit/s when actively typing,
and with text/140 it will be around 2.5 kbit/s when actively typing. Occasional jitter of
1 second is of no major concern. At severe congestion, some hampered conversation could
continue even if buffering was increased to 5 seconds, and that way of handling congestion
is now in rfc2793bis-07 that was published yesterday.

So, with this reasonable behaviour compared to the real time companions voice and video,
who gladly grab 40 kbit/s or more and require to have an even flow, I think text behaves
very well. I hope all are prepared to include it in real time conversational designs in
order to make conversational services a bit more usable for all.

Gunnar

>-----Original Message-----
>From: Adam Roach [mailto:[email-masked]] 
>Sent: Monday, June 28, 2004 11:38 PM
>To: Gunnar Hellstrom
>Cc: [email-masked]; [email-masked]; [email-masked];
>[email-masked] 
>Subject: Re: [Simple] Using MSRP for real time text conversation
>
>
>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?
>
>  INVITE sip:[email-masked] SIP/2.0
>  Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8
>  To: Bob <[email-masked]>
>  From: Alice <[email-masked]>;tag=1928301774
>  Call-ID: a84b4c76e66710
>  CSeq: 314159 INVITE
>  Max-Forwards: 70
>  Date: Thu, 21 Feb 2002 13:02:03 GMT
>  Contact: <sip:[email-masked]>
>  Content-Type: application/sdp
>  Content-Length: 147
>
>  v=0
>  o=UserA 2890844526 2890844526 IN IP4 here.com
>  s=-
>  c=IN IP4 pc33.atlanta.com
>  t=0 0
>  m=text 49172 RTP/AVP 97
>  a=rtpmap:97 t140/1000
>
>
>What are you trying to do that cannot be accomplished by this?
>
>/a
>
>

---

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

I am not willing to delay the completion of MSRP for this. However, I am not going to kill the idea of using MSRP for real-time text. I believe it is worth considering, but after the base MSRP spec has passed.

It sounds reasonable to have real-time text as an implementation choice for clients where users can flick a switch to turn it on or off. Having a 500ms buffer seems to aid in solving the character-by-character issues. 

This requires 1 of 2 things: specify the behaviour in a way that enables one side (the sender) to support real-time text while the other can be oblivious of that. Or, specify an SDP negotiation for it.

Again, I am against the idea of having the solution for this appear in the current MSRP spec as it will cause delays. We have external standardisation bodies awaiting this and it so close to completion now I would hate to delay it any further.

Regards,
Hisham 

> 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.
> 
> 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
> >>

---

From: "Mary Barnes" <[email-masked]>
Date: Wed, 30 Jun 2004 12:22:26 -0400

Hisham,

I totally understand not wanting to delay MSRP.  However, it seems to me
that real time text is a really good basic use case for MSRP.  I realize it
may not be specifically detailed in the charter, but there had been a
general agreement way back in SIPPING in London to make sure that
requirements for hearing impaired were built into the base specs, rather
than bolted on after the fact.  And, it's clearly part of the SIPPING
charter, that perhaps should have been explicitly propagated to the SIMPLE
WG charter:
" 2. Messaging-like applications of SIP -

  - support for hearing-/speech-impaired calling  "

Regards,
Mary.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, June 30, 2004 3:02 AM
To: [email-masked]; [email-masked];
[email-masked]
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]
Subject: RE: [Simple] Using MSRP for real time text conversation

I am not willing to delay the completion of MSRP for this. However, I am not
going to kill the idea of using MSRP for real-time text. I believe it is
worth considering, but after the base MSRP spec has passed.

It sounds reasonable to have real-time text as an implementation choice for
clients where users can flick a switch to turn it on or off. Having a 500ms
buffer seems to aid in solving the character-by-character issues. 

This requires 1 of 2 things: specify the behaviour in a way that enables one
side (the sender) to support real-time text while the other can be oblivious
of that. Or, specify an SDP negotiation for it.

Again, I am against the idea of having the solution for this appear in the
current MSRP spec as it will cause delays. We have external standardisation
bodies awaiting this and it so close to completion now I would hate to delay
it any further.

Regards,
Hisham