RE: [Simple] RE: [Sipping] RE: text/T140 and audio/t140 was:[avt] Comments/questions on draft-ietf-avt-rfc2793bis-04

[Eric Burger <[e-mail]>]

I have what might be a stupid, stupid question, that might better be raised
on AVT, but here I go anyway.

I think Dean is 100% correct in his assertion that RTP redundancy makes the
congestion problem worse and is wasteful when there is no congestion.

How is this for a counter-proposal:

   Just use TCP with Nagle turned off.

You would get character-by-character, or however much you want to buffer.
You get in-order delivery.  ACKs would definitely get bundled, especially if
we suggest decent window sizes.  Easily negotiable in TCP.  It would become
the dominant mode just by virtue of the number of devices supporting it.

What about Arnoud's point of all the different transport mechanisms for
T.140?  Over half of them are tied to the transport mechanism.  Can't fight
physics.

As for the IP-oriented ones.  Yes, RFC2793/bis is *specified* for them, but
how many implementations are there really?  Yes, it might be used for 80% of
deployed IP systems, but that is still a tiny fraction of the goal of
getting real-time text into every IM device (which I think is realistic).

> -----Original Message-----
> From: Arnoud van Wijk [mailto:[e-mail]]
> Sent: Friday, June 25, 2004 6:07 AM
> To: 'Gunnar Hellstrom'; 'Cullen Jennings'
> Cc: 'Paul E. Jones'; [e-mail]; 'Toip list'
> Subject: RE: [Simple] RE: [Sipping] RE: text/T140 and audio/t140
> was:[avt]Comments/questions on draft-ietf-avt-rfc2793bis-04
> 
> 
> Reading Gunnar here..
> I do have a very BIG worry here.
> "Over the years, T.140 for real time interactive text 
> conversation has been
> specified to go
> over:
> - V.18 modem
> - T.134 in  T.120 data conferencing
> - H.224 for H.320 ISDN mulitmedia
> - AL1   for H.324 multimedia opened through H.245
> - RFC2793 for H.323 multimedia
> - TCP     for H.323 multimedia
> - RFC2793 for H.248 gateways
> - RFC2793 for SIP
> - RFC2793bis audio/t140c for V.152 gateways"
> 
> Yes..but here we have a big risk that those gateways and such 
> are unable to
> communicate with each other, since the transport is again...different.
> 
> So..WHY should we add yet another real-time text transport method?
> 
> And perhaps it is a good idea to start some certification 
> organization that
> certifies that gateway A can interwork with gateway B for T140.
> But would manufacturers care???
> 
> I propose text/t140 to work with SIMPLE IM. And not to add 
> yet another form
> of text transport using MSRP.
> 
> I am 100% pro for working close with SIMPLE to use text/t140, RFC2793.
> 
> Best of Both worlds.......
> 
> Greetz
> 
> Arnoud
> 
> 
> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf
> Of Gunnar Hellstrom
> Sent: vrijdag 25 juni 2004 8:29
> To: Cullen Jennings
> Cc: 'Paul E. Jones'; [e-mail]; 'Toip list'
> Subject: RE: [Simple] RE: [Sipping] RE: text/T140 and audio/t140
> was:[avt]Comments/questions on draft-ietf-avt-rfc2793bis-04
> 
> Cullen,
> 
> Important factors for real time conversational text are:
> 
> 1. Wide deployment
> 2. Good opportunities to combine with voice and video in real 
> time calls
> 3. Same network traversal opportunities as voice and video. 
> No worse or
> different NAT and
> firewall problems than for the other real time media.
> 4. Meet all the other functional requirements you started with citing.
> 5. Be careful with tendencies for fragmentation in options and various
> solutions for the
> same network type, because that may lead to less interoperability.
> 6. A scalable solution that survives even to the stage when 
> it is deployed
> and used in
> every phone.
> 
> So, checking MSRP in positive mood, I find:
> 
> no 2 is likely OK.
> no 3 is likely not solved today, but if you achieve wide 
> deployment it may
> become solved.
> no 4 is probably OK, I am not sure about influence on 
> congestion and network
> load. MSRP
> packets seem to get quite long, and we need to transmit every 
> 300 ms to get
> satisfied
> users.
> no 6 is no blocking factor. MSRP can apparently be used peer-to-peer.
> no 1 is hard to know. Usually it is not the choice of 
> protocol that leads to
> market
> success. You indicate that if we made sure that there is a 
> conversational
> mode for MSRP,
> we would benefit from a possible success of SIMPLE. I realize the
> opportunity.
> 
> no 5 is the most tricky one. If you do text/t140 and I do 
> MSRP/RTT we get no
> communication. That is the situation we came from, with the 
> fragmented world
> of seven
> incompatible protocols for text telephony in PSTN. Now time 
> has come for
> harmonisation and
> interoperability in the world of text communication.
> text/t140 is standardised since year 2000, and included in 
> many documents as
> the way to
> go. All what we need is already approved. We are just working with
> refinements and
> deployment. So for now the deployment should not be confused 
> by knowing that
> alternatives
> may be coming that are in draft stage. If the alternative 
> then comes with
> proper
> mechanisms for negotiation in an offer/answer model it may be 
> OK, if it adds
> very evident
> value in terms of functionality or deployment opportunities. 
> I see great
> risks with
> fragmentation. That is the main threat to proper services.
> 
> What needs to be done in MSRP?
> ------------------------------
> With that said, we could go into looking at MSRP to see what 
> needs to be
> done.
> 
> I found most current specification suitable.
> 
> We have to define a MIME media type. It could be T.140 text 
> without the RTP
> packetisation.
> That is UTF-8 coded Unicode with some usage habit rules. It 
> would be the
> payload from
> RFC2793.
> 
> It should be buffered and sent every 300 ms or so.
> 
> 
> In section 6.5.3 we have this text:
> --------------------------------------------------------------
> When an endpoint receives a SEND request, it MUST perform the
>    following steps.
> 
>    1.  Check that it has state for a session with a local URL matching
>        the To-Path value.  If no matching session exists, return a 481
>        response.
> 
>    2.  Determine that it understands the media type in the 
> body, if any
>        exists.
> 
>    3.  If it does, return a 200 response and render the message to the
>        user.  The method of rendering is a matter of local policy.
> ---------------------------------------------------------------------
> It is only this sentence: "The method of rendering is a 
> matter of local
> policy." that need
> an addition for the real time case.
> "The local policy for real time text shall be to display the 
> text from each
> participant in
> a separate contigous text display area. Time alignment with 
> text transmitted
> according to
> the examples in ITU-T T.140 is RECOMMENDED.
> 
> Can someone check what bandwidth usage we will cause when 
> using MSRP if we
> have a rapid
> typer, typing 9 character per second in English ( causing one 
> byte UTF-8 per
> character),
> thus shipping three characters per SEND request?
> 
> 
> Over the years, T.140 for real time interactive text 
> conversation has been
> specified to go
> over:
> - V.18 modem
> - T.134 in  T.120 data conferencing
> - H.224 for H.320 ISDN mulitmedia
> - AL1   for H.324 multimedia opened through H.245
> - RFC2793 for H.323 multimedia
> - TCP     for H.323 multimedia
> - RFC2793 for H.248 gateways
> - RFC2793 for SIP
> - RFC2793bis audio/t140c for V.152 gateways
> 
> So, I am positive to check if it reasonable to add MSRP to the list of
> transports,
> provided we do not confuse current deployment activites and 
> we do it in a
> way that
> negotiate well with the current SIP RTP solution.
> 
> Gunnar
> -------------------------------------------
> Gunnar Hellstrom
> Omnitor AB
> Renathvagen 2
> SE 121 37 Johanneshov
> SWEDEN
> [phone]
> Mob: [phone]
> www.omnitor.se
> [e-mail]
> --------------------------------------------
> 
> 
> >-----Original Message-----
> >From: [e-mail] 
> [mailto:[e-mail]]On Behalf
> >Of Cullen Jennings
> >Sent: Friday, June 25, 2004 1:14 AM
> >To: Paul H Kyzivat; Gunnar Hellstrom
> >Cc: 'Paul E. Jones'; 'Arnoud van Wijk'; [e-mail]; Gregg
> >Vanderheiden; 'Toip list'; 'Mundra, Satish'
> >Subject: Re: [Simple] RE: [Sipping] RE: text/T140 and audio/t140
> >was:[avt]Comments/questions on draft-ietf-avt-rfc2793bis-04
> >
> >
> >
> >A long time we had a meeting and you said you were 
> interested in a solution
> >that helped people that could not use voice in one or both 
> directions. I
> >said that sounded good and pointed out that the problem was 
> a business case
> >problem not a technical problem.
> >
> >Various people made good arguments that that you need to 
> send it character
> >by character not line by line. You convinced people - thank 
> you. I imagine
> >that people than can use voice will find this useful to for 
> example the
> same
> >reasons you do. It's good you got this point across. I did 
> not understand
> >this when I first starting talking to people. I get it now.
> >
> >Now, I want to ask yourselves seriously - what is your goal 
> here now. Do
> you
> >want to get a solution to this that is widely deployed or is their a
> >particular technology you want to push? Do you want the 
> problem solved no
> >matter what the solution or did you just invent the problem to push a
> >particular solution in the first place?
> >
> >MSRP is a protocol that might be able to be a solution. The odds are
> >reasonable that it will be widely deployed. If this happens, 
> the marginal
> >effort to make it meet your requirements would be extremely low and
> probably
> >you don't need a business case to make it happen. It will 
> get implemented
> >for the fun of it at the same time because it will not take any extra
> >effort.
> >
> >As you point out with T140, it has been standardized for 
> years yet, has it
> >really been very widely implemented? Will it be implemented given the
> >business case that has been presented for it so far. I don't 
> know, maybe,
> >these things take time and effort to catch on, but I find it somewhat
> >doubtful. I would find if very sad to see a group of people 
> who really want
> >to have a solution for this problem to get politically 
> maneuvered into a
> >place where the vendors can say their equipment is fine for 
> section 508 or
> >whatever supercedes it. Yet when the whole systems deploys, 
> for some reason
> >only voice will work but it will not be the fault of any 
> equipment vendor.
> >Be wary of solutions where the phones and GWs will send 
> Voice Band Data
> >packets from which someone else need to extract the data . 
> It will be hard
> >to find the someone else.
> >
> >If you want a solution to the problem, here is my advice: 
> Tell the SIMPLE
> WG
> >that you have a requirement for character by character text. 
> I have not
> seen
> >any requirements other than this that MSRP does not already 
> meet. If you
> >want this, now is the time to make sure SIMPLE agrees to do 
> it. This does
> >not stop you from pursuing the ever loved t140 solutions - 
> you can pursue
> >those too. If you want MSRP to be more than what you refer 
> to as IM, now
> >would be a good time to make sure MSRP is right.
> >
> >I'm sure some people will argue that the t140 solutions are 
> less work than
> >MSRP. That may or may not be true but it is irrelevant. I 
> think we need to
> >think about which one is most likely to get implemented. You 
> say IM is not
> >appropriate in all situations, and you want char-by-char on 
> every phone.
> >That sounds good, but think bigger, how about char-by-char 
> on every phone
> >and on every future IM device. There's going to be a lot 
> more of these than
> >phones and every device that has a keyboard is probably 
> going to be an IM
> >device. Go big - make IM work for what you need on everything with a
> >keyboard and on all the phones. A solution that works for 
> both is more
> >likely to happen than one that just works for phones.
> >
> >Cullen
> >
> >
> >PS - I agree with  Paul K and Deans comments
> >
> >
> >
> >
> >
> >
> >
> >
> >_______________________________________________
> >Simple mailing list
> >[e-mail]
> >https://www1.ietf.org/mailman/listinfo/simple
> >
> >
> 
> 
> -
> 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


-
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