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

["Arnoud van Wijk" <[e-mail]>]

Gunnar,
I am always open for alternatives. Even just to learn from it.
If choices are to be made..let it be on the right rationale and valid
reasons. And not beliefs and uninformed choices and politics.

I love to learn. :-)

Greetz

Arnoud


-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf
Of Gunnar Hellstrom
Sent: zaterdag 26 juni 2004 13:35
To: A vWijk; [e-mail]; [e-mail]; [e-mail]
Subject: RE: Betr.: Using MSRP for real time text conversation

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


>-----Original Message-----
>From: A vWijk [mailto:[e-mail]]
>Sent: Saturday, June 26, 2004 11:39 AM
>To: [e-mail]; [e-mail]; [e-mail];
>[e-mail]
>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" <[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
>
>


-
This list is maintained by Snowshore Networks - http://www.snowshore.com
All comments on this list are the comments of the message originators and
Snowshore is not to be held responsible for any actions or comments found
on this list. The archives for this list can be found at
http://flyingfox.snowshore.com/toip_archive/maillist.html



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