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

["A vWijk" <[e-mail]>]

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" <[e-mail]> 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
[phone]
Mob: [phone]
www.omnitor.se
[e-mail]
--------------------------------------------



-
This list is maintained by Snowshore Networks - http://www.snowshore.com
All comments on this list a

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