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

From: "Gunnar Hellstrom" <[email-masked]>
Date: Sat, 26 Jun 2004 13:35:00 +0200

Arnoud,

I agree that the best opportunity to widespread implementation and interoperability is to
have one good standardised method for real time text conversation per network type.

We have just avoided (?) the threat for fragmentation even on the RTP side by carefully
specifying the application areas and priorities for the two variants text/t140 and
audio/t140c.

Why do I then immediately accept to enter a discussion of another option for the same
function in the same network?

I thought the invitation was an interesting challenge, worth evaluating. "Come use MRSP
and you will reach mass deployment for real time text conversation".

Entering the discussion does not mean that I have accepted that it is a good idea to
standardise the MRSP option.

So far, it seems to me that going with VoIP and IP Multimedia conversation is the more
logical route to keep on. The bandwidth requirements for MSRP was not encouraging. The NAT
traversal functions are less developed than for SIP with RTP.

But let us continue the feasability study a bit further. I would also like to hear the
voice of some industries if it really matters what base protocol that is used for getting
deployed in a majority of IP terminals and supported by network components?

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

>-----Original Message-----
>From: A vWijk [mailto:[email-masked]]
>Sent: Saturday, June 26, 2004 11:39 AM
>To: [email-masked]; [email-masked]; [email-masked];
>[email-masked]
>Subject: Betr.: Using MSRP for real time text conversation
>
>
>Gunnar thank you for the explanation.
>Now, my question is..why do we need to do this?
>
>Can we not just stick to t140/RTP and focus on making the interface and the
>handling of the IM so that a user can easily switch between Interactive text and
>Instant messaging?
>
>Because, any device that will support IM using SIMPLE's MSRP will also use VoIP.
>Thus will support RTP.
>
>I am NOT happy to add yet another way of transporting t140. And even causing 3
>times as much bandwidth.
>
>
>The more alternatives you offer to transport t140, the bigger the chance is that
>several t140 devices cannot interwork with each other!
>And then we end up again with the mess that there are 7 different analogue text
>telephone protocols!
>
>That are my 2 cents here.
>
>greetz
>
>Arnoud
>
>
><<< "Gunnar Hellstrom" <[email-masked]> 26-06 10:27  >>>
>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]
>--------------------------------------------
>
>
>
>-
>This list is maintained by Snowshore Networks - http://www.snowshore.com
>All comments on this list a
>
>

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