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

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

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



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