[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Simple] I-DAction: draft-hellstrom-simple-text-transmission-00.txt - the need
Hi Paul,
I don't think 4103 in parallel is "something else just for deaf people". I
think (and have seen with AIM REAL-TIME/IM ) that there is very real market
for IM with real-time preview for mainstream users. Not all want it - not
all want voice or video. But many do.
The advantages of parallel 4103 and MSRP are many.
- better compatibility with other IM and REAL-TIME TEXT systems
- lower bandwidth
- MSRP looks like what people expect (and increases probability people won't
mess it up in implementation or setup)
- redundancy (failure of either channel for any reason is backed up by the
other (Very important if going to be used for emergencies in the future)
- better compatibility with terminals that don't understand both
(implementing either correctly results in proper operation and successful
messages).
Compatibility with the older TTY is also important since one of the things
we are trying to do is eliminate the requirement on industry by the FCC that
TTYs be supported except in special gateways. But it must work well there.
Finally - it would provide better compatibility with products that already
implement REAL-TIME TEXT using 4103.
HAVING SAID THAT -
I also fully support systems that want to do it ENTIRELY in MSRP. But that
would be within their systems. And it should be a companies (Or system's )
choice. MSRP w/REAL-TIME TEXT preview or MSRP with 4103 REAL-TIME TEXT
preview. (or whatever IM and RTT they want to use)
Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.
If Attachment is a mail.dat try http://www.kopf.com.br/winmail/
> -----Original Message-----
> From: Paul E. Jones [mailto:paulej at packetizer.com]
> Sent: Friday, March 21, 2008 11:57 AM
> To: 'Dean Willis'
> Cc: '"'Gunnar Hellström'"'; 'Simple WG';
> Erik.Zetterstrom at omnitor.se; 'Gregg Vanderheiden'
> Subject: RE: [Simple] I-DAction:
> draft-hellstrom-simple-text-transmission-00.txt - the need
>
> Dean, at al,
>
> Re-inventing SCTP with what? RTT support or MSRP in general?
>
> In any case, I do not think TOTE is the right solution. I've
> also seen a proposal to send RFC 4103 in parallel to MSRP. I
> believe anything that is outside of MSRP should be off the
> table for discussion, because anything else would:
> 1) Create a special solution for deaf users
> 2) Create more work for everybody (phones, SBCs, softswitches, etc.)
> 3) Require special consideration for all manufacturers and
> network operators who
> must comply with regulatory requirements
>
> I believe it is imperative that we bring to market a single
> IM solution for SIP that works. Thus far, that's not
> happened and I was excited by the prospect that MSRP might
> make that happen. I personally want a solution that is as
> natural as possible and will not present significant
> complexity to implement and deploy.
>
> I believe it is important to question whether we need real-time text.
> Personally, I do not think we do. However, many of the folks
> I've worked with in the deaf community feel we do. Who am I
> to say what the deaf community needs? In my view, if there
> is a significant portion of our global population that feels
> they need RTT, then we should find a way to make it work if
> there is a way to do it.
>
> MSRP is designed in such a way that we can enable it to
> support RTT without making great leaps. Using the chunking
> method already defined within MSRP is fairly
> straight-forward. The only thing I see it doing is
> increasing the bandwidth and number of packets that need to
> be processed. As Geir Arne rightly point out, text packets
> are nothing compared to the processing of 50pps of audio and
> become a blip on the radar compared to video. Further, there
> is nothing "illegal" about sending 1 character per packet today, so...
> what would a system do? It must handle it.
>
> I think it is important to decide whether we want to create
> an IM system that will work in the same way for RTT and
> non-RTT. I would argue that it's a heck of a lot easier to
> accommodate both with MSRP than to consider separate
> solutions. I want to find a way that will reduce complexity,
> reduce cost of development and deployment, and will enable us
> to meet forthcoming regulatory requirements.
>
> Paul
>
> > -----Original Message-----
> > From: Dean Willis [mailto:dean.willis at softarmor.com]
> > Sent: Monday, March 17, 2008 2:29 PM
> > To: Paul E. Jones
> > Cc: "'Gunnar Hellström'"; 'Simple WG'; Erik.Zetterstrom at omnitor.se;
> > 'Gregg Vanderheiden'
> > Subject: Re: [Simple] I-DAction: draft-hellstrom-simple-text-
> > transmission-00.txt - the need
> >
> >
> > On Mar 16, 2008, at 3:48 PM, Paul E. Jones wrote:
> >
> > >
> > > What do you mean by "the transport system"? I thought
> the argument
> > > we were making was for using MSRP as the transport. Honestly, I
> > > would think that if we present a strong-enough case for the first
> > > question ("why RTT?"), then I suspect there would be
> little debate
> > > over using MSRP. And, I still think those arguing
> against MSRP have
> > > weaknesses in their systems. Our engineers certainly
> were open to
> > > it.
> >
> > The problem as I understand it is fundamental to the way MSRP is
> > currently specified.
> >
> > MSRP relays may (and probably will) bundle up small packets
> into large
> > ones. That is, they'll strip the real-time right out of the text.
> >
> > Now, I personally feel MSRP is over-specified. It has all sorts of
> > neat capabilities for muxing and controlling independent flows that
> > I've heard it said we've reinvented SCTP. But it is what it is, and
> > that's an awkward beast for carrying RTT.
> >
> > To meet the requirements of RTT, we need something that is lighter
> > than MSRP, but still has the reliability and congestion
> control of TCP.
> >
> > I think this makes RTT an ideal candidate for something
> like the TOTE
> > session protocol described in:
> >
> >
> http://www.ietf.org/internet-drafts/draft-rosenberg-sip-tote-00.txt
> >
> > I'm interested in getting a BOF going to look at
> multi-purpose session
> > protocols suitable for end-to-end use in a session
> initiated by SIP or
> > other rendezvous protocols. I think RTT provides a great
> use-case for
> > such a protocol.
> >
> > --
> > Dean
> >
>
>
>
>
_______________________________________________
Simple mailing list
Simple at ietf.org
https://www.ietf.org/mailman/listinfo/simple