[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
Paul,
You make statements like " there is no consideration whatsoever for RFC
4103." Yet it was developed under commission from a major phone mfgr and
is embodied in carrier standards.
In fact there are more products that support 4103 than MSRP. But that is
irrelevant. That is like saying there are more PSTN phones than VoIP
phones so we should do VoIP.
Looking backward or even sideways is not the way to handle this discussion.
We need to look at what is correct going forward. We need to keep an open
mind and look at all the options, look in DETAIL at the implementations.
Things that look complicated often are not so bad and may be more stable.
Things that look simple have a nasty tendency to get more complicated in the
details. Mixing things sometimes helps and sometimes is worse.
So instead of declaring one solution (That we haven?t implemented) the
winner lets at least get some implementations up and see how hard it is do
to things. and their relative merits.
Lets do it quickly. Then lets look at both. Then lets decide. I do think
we want to move quickly. I don't think we want to move precipitously.
Act in haste - repent at leisure.
So - lets stop deciding the results before we have the data. Lets make some
systems both ways and look at implementation times and resulting robustness.
And see how both match up to the 'human' factor.
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: Saturday, March 22, 2008 10:51 AM
> To: 'Gregg Vanderheiden'; 'Dean Willis'
> Cc: '"'Gunnar Hellström'"'; 'Simple WG'; Erik.Zetterstrom at omnitor.se
> Subject: RE: [Simple] I-DAction:
> draft-hellstrom-simple-text-transmission-00.txt - the need
>
> Gregg,
>
> I really see no value in the redundancy and I really do
> believe it complicates things.
>
> RFC 4103 all by itself complicates things enough, given that
> it is carried in an RTP stream that is separate from the
> voice steam. For a gateway, this is a ugly. For an IM
> client of some sort, it introduces a whole new protocol suite
> (RTP/RTCP and RFC 4103) that would otherwise not be there.
>
> If you're suggesting that an enterprise might do whatever it
> wants, I have no objection. But, if you want to require that
> the carrier networks must transport both RFC 4103 and MSRP in
> parallel, I have real objections.
> Carriers in the US have largely agreed to use MSRP and there
> is no consideration whatsoever for RFC 4103.
>
> Paul
>
> > -----Original Message-----
> > From: Gregg Vanderheiden [mailto:gv at trace.wisc.edu]
> > Sent: Saturday, March 22, 2008 12:24 AM
> > To: 'Paul E. Jones'; 'Dean Willis'
> > Cc: '"'Gunnar Hellström'"'; 'Simple WG'; Erik.Zetterstrom at omnitor.se
> > Subject: RE: [Simple] I-DAction: draft-hellstrom-simple-text-
> > transmission-00.txt - the need
> >
> > Yes Paul it would be entirely redundant. That was my point. That
> > would be one of its strengths.
> >
> > I don't think it necessarily complicates things. They are both
> > established
> > standards. Voice and MSRP are both used together. MSRP
> and 4103 can
> > too.
> > Each have their strengths, and using them together may be much more
> > straightforward than trying to get one to function as two.
> >
> > I think we should explore them both and see how the work
> out. ALSO I
> > think both should be options going forward. Companies can choose
> > their options.
> >
> >
> > 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 10:04 PM
> > > To: 'Gregg Vanderheiden'; 'Dean Willis'
> > > Cc: '"'Gunnar Hellström'"'; 'Simple WG';
> Erik.Zetterstrom at omnitor.se
> > > Subject: RE: [Simple] I-DAction:
> > > draft-hellstrom-simple-text-transmission-00.txt - the need
> > >
> > > Gregg,
> > >
> > > I view sending 4103 in parallel to MSRP as entirely
> redundant. It
> > > will also be more complicated to deliver.
> > >
> > > In the face of all of the other complexities trying to
> get a single
> > > internationally supported IM system working -- and I will
> be quick
> > > to point out that we (the IETF) have been at this for nearly a
> > > decade -- I do not want to further delay efforts by adding more
> > > complexity.
> > >
> > > Paul
> > >
> > > > -----Original Message-----
> > > > From: Gregg Vanderheiden [mailto:gv at trace.wisc.edu]
> > > > Sent: Friday, March 21, 2008 1:17 PM
> > > > To: 'Paul E. Jones'; 'Dean Willis'
> > > > Cc: '"'Gunnar Hellström'"'; 'Simple WG';
> > Erik.Zetterstrom at omnitor.se
> > > > Subject: 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