Subject: [Sipping] SV: items for vor voting in the BOF

From: Gunnar Hellström <[email-masked]>
Date: Thu, 10 Jul 2003 08:57:20 +0200

Please do not complicate this. I made a simple summary of the discussion
that gave the meeting a simple set of choices. Now it is at risk to deviate
again.

We have to keep this clear and simple, and not give the impression to the
industry that this is a big complication so that the whole package of
accessibility issues is thrown out.

What I especially want to prevent is that #1 and #2 are lost because we have
so many other requirements in the list.

Please stick to the origingal for the voting and proposals in the IETF
meeting.
I comment the proposals inline.

Gunnar

-------------------------------------------
Gunnar Hellström, Omnitor, Renathvägen 2
SE 121 37 Johanneshov, SWEDEN
Tel: +46 8 556 002 03  Mob: +46 708204288
e-mail: [email-masked]
web: www.omnitor.se

> -----Ursprungligt meddelande-----
> Från: Paul E. Jones [mailto:[email-masked]]
> Skickat: den 9 juli 2003 19:07
> Till: Henry Sinnreich; 'Gunnar Hellstrom'; [email-masked];
> [email-masked]; [email-masked];
> [email-masked]; [email-masked]; 'Rajesh Kumar';
> [email-masked]; [email-masked]; 'James Hamlin';
> [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Ämne: Re: items for vor voting in the BOF
>
>
> Henry,
>
> I made a number of comments on the previous proposal.  Specifically, I did
> not want to see #3 as it was written.  T.38 AND V.18 are entirely
> separate.

Gunnar> They both rely on the complication to include analogue phone
connector and modem technology. They are both FSK modems in the base. I
agree that the logic on top of that is different, but the complexity of T.38
is at least 10 times more than V.18 plus T.140 and RFC2793.

> Further, if we allow for VBD operation for TTY devices connected via RJ11,
> then V.18 would not be something the phone needs to be complicated with.

Gunnar> No, that is not right. VBD just takes the tones as they are and
transport them to the other end. What shall we do with these tones if they
are sent to a proper SIP textphone? You need to adapt to the habit in the
network you are, and create compatibility, not offer fragmentation.

> Realizing that this is a vote on a number of issues, I'd like to more
> clearly separate the issues.  I removed one sentence that caused
> concern for
> Gunnar related to V.21/V.23.  Thus, please replace #3 with:
>
> 3. MUST/SHOULD provide an interface to legacy TTY devices and transport
> those signals as RFC 2793 text

Gunnar> We should not use the term TTY. That is a local American term, not
understood elsewhere. Text telephone is the agreed term.

>
> 4. MUST/SHOULD provide an interface to legacy TTY devices and allow
> transparent carriage of the TTY protocol through the audio path
> ("pass-through" mode)

Gunnar> Same comment about TTY

>
> 5. MUST/SHOULD provide an RJ11 port for interfacing with legacy
> TTY devices,
> fax devices, modems, and other legacy equipment for the purposes of
> supporting the transfer of information from/to those legacy devices.
>
> 6. MUST/SHOULD provide a 2.5mm audio plug for interfacing with a
> headset or
> legacy TTY device
>
> Note that #5 gets into the area of V.150 modem relay and pass-through, as
> well as T.38 fax relay.  That came from the original #3.
> However, I do not
> see the value in spelling out those protocols for the purposes of
> this vote.
>
> Also, in #2, there is still a reference to a web interface.  I
> said I don't
> think that's necessary, since if one can access the web interface, he/she
> can probably just use a PC for communication.  However, they may not be
> true.  In any case, I can see the web interface as "interesting", but
> certainly could not see mandating it.  Also, I don't agree with
> the comment
> about blind people needing a keyboard and screen.

Gunnar> The comment was that blind people need a way to get an electronic
interface to the input and output for operations of the phone.
They probably need to get the user interface device themselves, but need the
standardised interface on the phone. The same interface should be possible
to use for text input and display.
I agree that the comment does not need to be there in the text, it was meant
to be for clarification in the discussion, but apparently was not clear
enough.

> I propose
> rewording #2 as
> follows:
>
> 2. MUST/SHOULD provide a way to input text and display text, through any
>    method: Built in user interfaces, standard wired or wireless interfaces
> for
>    keyboard and display, or support for text through its web interface.
>
> OR, better:
>
> 2A. MUST/SHOULD provide a way to input text and display text
> through either
> a
>     built in user interfaces or standard wired or wireless interfaces
>     (including a screen and keyboard)
>
> 2B. MUST/SHOULD provide a way to input text and display text through its
>     web interface.
>
> Paul
>
> ----- Original Message -----
> From: "Henry Sinnreich" <[email-masked]>
> To: "'Gunnar Hellstrom'" <[email-masked]>;
> <[email-masked]>; <[email-masked]>;
> <[email-masked]>; <[email-masked]>;
> <[email-masked]>; "'Rajesh Kumar'" <[email-masked]>;
> <[email-masked]>; <[email-masked]>; "'James Hamlin'"
> <[email-masked]>; <[email-masked]>;
> <[email-masked]>; <[email-masked]>;
> <[email-masked]>; <[email-masked]>; <[email-masked]>;
> <[email-masked]>; <[email-masked]>
> Sent: Sunday, July 06, 2003 4:14 PM
> Subject: RE: items for vor voting in the BOF
>
>
> > Please see the attached slide for voting at the IETF BOF on "Interactive
> > Text Support for SIP Telephony Devices".
> >
> > We have no day/time yet for the BOF, but expect to get it scheduled, as
> > discussed with Rohan Mahy.
> >
> > Many thanks to Gunnar Hellstrom for the formulation of the text.
> >
> > Thanks, Henry
> >
> > > -----Original Message-----
> > > From: Gunnar Hellstrom [mailto:[email-masked]]
> > > Sent: Wednesday, July 02, 2003 3:44 AM
> > > To: Henry Sinnreich
> > > Cc: [email-masked]; [email-masked];
> > > [email-masked]; [email-masked];
> > > [email-masked]; 'Rajesh Kumar'; 'James Hamlin';
> > > [email-masked]; [email-masked];
> > > [email-masked]; [email-masked]; [email-masked];
> > > [email-masked]; [email-masked];
> > > [email-masked]; [email-masked]
> > > Subject: SV: items for vor voting in the BOF
> > >
> > >
> > > Henry,
> > > Yes please use the sentences in the IETF meeting, with no 3
> > > amended as below.
> > >
> > > Some thoughts an explanations:
> > >
> > > Blind reference:
> > > ----------------
> > > The reference about display interface for blind people refers
> > > to a need for blind people to follow hat is displayed on the
> > > phone through a device of their choice. It may be voice
> > > synthesis or electromechanical braille display or display
> > > with enlargement or extra strong light. We do not expect the
> > > phone to include these special devices, so a standardised
> > > interface to them must be provided. The SIP phone will have
> > > states so it will be impossible to expect that you shall be
> > > able to operate it without feedback from the phone. The
> > > mobile industry made the mistake to not initially provide a
> > > standardised interface to operate the mobile phone and that
> > > has caused enormous problems for blind people. The AT command
> > > interface available to 3GPP mobile phones seem to have
> > > overcome this mistake by including commands and responses for
> > > accessing most things required for operation through a serial
> > > command language that can be issued through Bluetooth or a
> > > USB or serial connector. Products are emerging. Something
> > > similar must be done on SIP phones. I concentrated on deaf
> > > issues, but I see that we have common interests here.
> > >
> > > The web interface:
> > > ------------------
> > > I saw a comment that the web interface should not be
> > > mentioned as a solution. That may be true, it was with
> > > hesitation that I added it. But: I have seen SIP phones with
> > > the possibility to add the video component from a nearby
> > > computer. Similar things can be done for text. It is still
> > > valid to let the phone have all the other SIP phone
> > > functionality. I can imagine PDA access through Bluetooth
> > > executing a web browser to operate the phone. The text
> > > component could be accessible through that interface.
> > > Handling only the user interface aspect of the text part is
> > > an enormous difference from handling the complete SIP
> > > protocol and all audio coding. The sum is of course that when
> > > we open for many ways to add text and that the person
> > > carrying a text interface with him, will find that it can not
> > > be attached to any phone, and then accessibility is again
> > > limited. I am quite sure that phones will not come without
> > > display, and that they will follow the trend on PDAs and
> > > mobile phones, to include a full aphanumeric keyboard because
> > > it is needed for address and phonebook use, as well as to
> > > provide a good user interface to the very popular real time
> > > text conversation function ;-) . So, I am not too worried
> > > that we give many options.
> > >
> > >
> > > The analogue interface.
> > > -----------------------
> > > The statement no 3 about the analogue adapter is not really
> > > formulated in a strict IETF style. A starting sentence is needed:
> > >
> > > 3. A SIP device MAY provide analogue adapter functionality
> > > through an RJ11 port. IF an RJ11 port is provided for a PSTN
> > > device adapter interface, THEN it MUST/SHOULD provide T.38
> > > support for fax AND V.18+RFC2793 support for text alternating
> > > with voice. If T.38 or RFC2793 negotiation fails then it MAY
> > > try to connect for G.711 and pass the audio through.
> > >
> > >
> > >
> > >
> > > -------------------------------------------
> > > Gunnar Hellstrom, Omnitor, Renathvagen 2
> > > SE 121 37 Johanneshov, SWEDEN
> > > Tel: +46 8 556 002 03  Mob: +46 708204288
> > > e-mail: [email-masked]
> > > web: www.omnitor.se
> > >
> > >
> > > > -----Ursprungligt meddelande-----
> > > > Fran: Henry Sinnreich [mailto:[email-masked]]
> > > > Skickat: den 2 juli 2003 02:27
> > > > Till: 'Gunnar Hellstrom'
> > > > Kopia: [email-masked]; [email-masked];
> > > > [email-masked]; [email-masked]; [email-masked];
> > > > [email-masked]; [email-masked]; [email-masked];
> > > > [email-masked]; [email-masked];
> > > 'James Hamlin';
> > > > 'Rajesh Kumar'; [email-masked];
> > > [email-masked];
> > > > [email-masked]; [email-masked]; [email-masked]
> > > > Amne: items for vor voting in the BOF
> > > >
> > > >
> > > > Gunnar,
> > > >
> > > > I will use with your permission your formulation to put these three
> > > > items to vote in the BOF, for MUST or SHOULD:
> > > >
> > > > 1. MUST/SHOULD include protocol support for RFC2793 for text.
> > > >
> > > > 2. MUST/SHOULD provide a way to input text and display
> > > text, through
> > > > any
> > > > method: Built in user interfaces, standard wired or
> > > wireless interfaces
> > > > for keyboard and display ( that is needed anyway for blind
> > > people), or
> > > > support for text through its already mandated web interface.
> > > >
> > > > ----
> > > > And, with some doubt:
> > > >
> > > > 3. IF an RJ11 port is provided for a PSTN device adapter interface,
> > > > THEN it MUST/SHOULD provide T.38 support for fax AND V.18+RFC2793
> > > > support for text alternating with voice. If T.38 or RFC2793
> > > > negotiation fails then it MAY try to connect for G.711 and pass the
> > > > audio through.( is there any need to mandate also modem support? )
> > > >
> > > > I believe these are very reasonable requirements.
> > > >
> > > > Thanks, Henry
> > > >
> > > > > -----Original Message-----
> > > > > From: Gunnar Hellstrom [mailto:[email-masked]]
> > > > > Sent: Tuesday, July 01, 2003 4:08 PM
> > > > > To: Rajesh Kumar; James Hamlin
> > > > > Cc: [email-masked]; [email-masked];
> > > > > [email-masked]; [email-masked]; [email-masked];
> > > > > [email-masked]; [email-masked]; [email-masked];
> > > > > [email-masked]; [email-masked];
> > > > > [email-masked]; [email-masked];
> > > > > [email-masked]; [email-masked];
> > > [email-masked]
> > > > > Subject: SV: SV: SV: Internet draft on real time text conversation
> > > > >
> > > > >
> > > > > I see the discussion going in circles.
> > > > >
> > > > > Henry gave me the delicate task to sum up and get a
> > > proposed writing
> > > > > into the Sipdev specification.
> > > > >
> > > > > After looking back in the discussion, I come to the
> > > conclusion that,
> > > > > the only requirements that make real sense and takes deaf
> > > telecomms
> > > > > a bit towards equal opportunities is that SIP devices:
> > > > >
> > > > > 1. MUST include protocol support for RFC2793 for text.
> > > > >
> > > > > 2. MUST provide a way to input text and display text, through any
> > > > > method: Built in user interfaces, standard wired or wireless
> > > > > interfaces for keyboard and display ( that is needed anyway for
> > > > > blind people), or support for text through its already
> > > mandated web
> > > > > interface.
> > > > >
> > > > > ----
> > > > > And, with some doubt:
> > > > >
> > > > > 3. IF an RJ11 port is provided for a PSTN device adapter
> > > interface,
> > > > > THEN it MUST provide T.38 support for fax AND
> > > V.18+RFC2793 support
> > > > > for text alternating with voice. If T.38 or RFC2793 negotiation
> > > > > fails then it MAY try to connect for G.711 and pass the audio
> > > > > through.( is there any need to mandate also modem support? )
> > > > >
> > > > >
> > > > >
> > > > > ----
> > > > > I am sure SIP signaling can take care of most tricky
> > > situations that
> > > > > have been up for discussion.
> > > > >
> > > > > E.g.
> > > > > A SIP phone without RJ11 port in contact with a PSTN
> > > device through
> > > > > a gateway, would signal RFC2793 capability. That will
> > > make a gateway
> > > > > involved in the call perceive any indication on use of modem-like
> > > > > tones from PSTN as text if possible.
> > > > >
> > > > >
> > > > >
> > > > > I intend to propose text with that content soon for the
> > > sipdev spec.
> > > > >
> > > > > With that, we could perhaps change topic to discuss
> > > contents of the
> > > > > text capable device I-D that Erik and Andreas made a
> > > first draft of.
> > > > >
> > > > > Has time been booked in the SIPPING meeting in Wienna to discuss
> > > > > that?
> > > > >
> > > > > Can Erik and Andreas provide us with a second draft?
> > > > >
> > > > > Best regards
> > > > >
> > > > > Gunnar
> > > > >
> > > > >
> > > > > -------------------------------------------
> > > > > Gunnar Hellstrom, Omnitor, Renathvagen 2
> > > > > SE 121 37 Johanneshov, SWEDEN
> > > > > Tel: +46 8 556 002 03  Mob: +46 708204288
> > > > > e-mail: [email-masked]
> > > > > web: www.omnitor.se
> > > > >
> > > > >
> > > > > > -----Ursprungligt meddelande-----
> > > > > > Fran: Rajesh Kumar [mailto:[email-masked]]
> > > > > > Skickat: den 1 juli 2003 19:15
> > > > > > Till: James Hamlin
> > > > > > Kopia: [email-masked]; [email-masked];
> > > > > > [email-masked]; [email-masked]; [email-masked];
> > > > > > [email-masked]; [email-masked];
> > > [email-masked];
> > > > > > [email-masked]; [email-masked];
> > > > > > [email-masked]; [email-masked];
> > > > > > [email-masked]; [email-masked];
> > > > > [email-masked];
> > > > > > [email-masked]
> > > > > > Amne: RE: SV: SV: Internet draft on real time text conversation
> > > > > >
> > > > > >
> > > > > > James,
> > > > > >
> > > > > > The intent here is that the called party could be any SIP
> > > > > phone, not
> > > > > > just SIP phones specially designated for text-only
> > > > > operation. I think
> > > > > > the intent expressed by Guido and Gunnar et al is that a
> > > > > PSTN TTY user
> > > > > > should be able
> > > > > > to open an RFC 2793 text channel with any SIP phone user,
> > > > > and that the
> > > > > > latter should either have an integral keyboard/display
> > > or a port
> > > > > > to such a display. So the problem of call
> > > discrimination when the
> > > > > > caller is a V.21 or
> > > > > > V.23 legacy textphone is not solved unless you allow
> > > > > passthrough fallback
> > > > > > when you cannot tell whether the V.21 signal is text or not -
> > > > > > regardless of the existence of gateways/servers that do PSTN
> > > > > > textphone to RFC 2793 conversion.
> > > > > >
> > > > > > In general, the solution of designating special phone
> > > numbers for
> > > > > > deaf-accessible operation militates against the stipulation
> > > > > that the
> > > > > > deaf be able to create text channels from any PSTN or SIP phone
> > > > > > number, and to any PSTN or SIP phone number.  Here, textphone
> > > > > > detection has to be on the basis of control signals
> > > > > exchanged in the
> > > > > > bearer stream or on the content of the bearer stream,
> > > and not on a
> > > > > > priori numbering plans that create a "deaf ghetto".
> > > > > >
> > > > > > For technical reasons,  I still think you must mandate
> > > passthrough
> > > > > > operation to enable universal interoperability.
> > > > > >
> > > > > > Kind regards to all.
> > > > > >
> > > > > > Rajesh
> > > > > >
> > > > > >
> > > > > >
> > > > > > At 04:33 PM 7/1/2003 +0100, James Hamlin wrote:
> > > > > > >Rajesh
> > > > > > >
> > > > > > >It would be possible for people on the IP network to have PSTN
> > > > > > numbers that
> > > > > > >are taken from a block that is assigned only to text.
> > > Therefore
> > > > > > the gateway
> > > > > > >between PSTN and the IP network knows from the called number
> > > > > > that the intent
> > > > > > >is to use text.
> > > > > > >
> > > > > > >Regards
> > > > > > >
> > > > > > >James
> > > > > > >
> > > > > > >-----Original Message-----
> > > > > > >From: Rajesh Kumar [mailto:[email-masked]]
> > > > > > >Sent: 01 July 2003 16:05
> > > > > > >To: A vWijk
> > > > > > >Cc: [email-masked]; [email-masked];
> > > > > > >[email-masked]; [email-masked]; [email-masked];
> > > > > > >[email-masked]; [email-masked];
> > > [email-masked];
> > > > > > >[email-masked]; [email-masked];
> > > > > > >[email-masked]; [email-masked];
> > > > > > >[email-masked]; [email-masked];
> > > > > > >[email-masked]; [email-masked];
> > > > > > >[email-masked]
> > > > > > >Subject: Re: SV: SV: Internet draft on real time text
> > > conversation
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > >>> "[email-masked]" 07/01/03 16:04 >>>
> > > > > > >
> > > > > > >Arnoud,
> > > > > > >
> > > > > > >As I indicated in another email, interoperability with legacy
> > > > > > V.21 and V.23T
> > > > > > >  TY devices is not feasible unless you support a passthrough
> > > > > > >fallback. I have no hidden agenda here, I am just presenting a
> > > > > > >technical difficulty that SG16/Q11 and TIA TR.30.1 have been
> > > > > > >struggling with for the past 6 months. I do not know how
> > > > > you can do
> > > > > > >without TTY passthrough if you want universal
> > > > > interoperability. Here
> > > > > > >was my mail, sent yesterday:
> > > > > > >
> > > > > > >There is a real technical difficulty which I would want you all
> > > > > > to consider.
> > > > > > >
> > > > > > >Let us say that you mandate T.140/RFC 2793 for all SIP
> > > > > phones and do
> > > > > > >not mandate TTY passthrough.
> > > > > > >
> > > > > > >Let us say the call originates from a PSTN TTY and is
> > > routed via
> > > > > > a gatewayt
> > > > > > >  o a SIP phone, which has native RFRC2793-based text
> > > > > > > capabilities.
> > > > > > >
> > > > > > >SG16/Q11 has struggled with the fact that you cannot always
> > > > > > discriminate aT
> > > > > > >  TY call from a non-TTY call when V.21 or V.23
> > > > > modulations are used.
> > > > > > >In this case, there is no basis for the gateway to convert the
> > > > > > >PSTN
> > > > > > TTY signali
> > > > > > >  nto RFC 2793/T.140. However, the gateway can determine
> > > > > that this is
> > > > > > >a modulated signal based on answer tone (if present) or on
> > > > > specific
> > > > > > >FSK frequencies. It can use VBD passthrough (G.711) in
> > > > > this case but
> > > > > > >not RFC 2793 since it does not know if the V.21/V.23
> > > > > signal is text
> > > > > > >or not.
> > > > > > >
> > > > > > >Ergo, we cannot preclude a requirement for G.711 VBD
> > > passthrough
> > > > > > support onS
> > > > > > >  IP phones in favor of T.140. You can mandate both as musts,
> > > > > > but you cannoth
> > > > > > >  ave an interoperable solution if you do not have passthrough.
> > > > > > >
> > > > > > >Rajesh
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >At 04:02 PM 7/1/2003 +0200, A vWijk wrote:
> > > > > > > >Paul,
> > > > > > > >How do you feel by mandating T.140/RTP along with the TTY
> > > > > > passthrough on>
> > > > > > >  IP telephones and such?
> > > > > > > >The technology is then ready for the T.140 usage.
> > > Which may be
> > > > > > very very>
> > > > > > >  rapidly!
> > > > > > > >And remember..as I am stating over and over again. RFC2793 is
> > > > > > NOT limited>
> > > > > > >  for the hearing impaired users only!
> > > > > > > >Many other services will be possible with text conversation.
> > > > > > > >And that will likely stimulate the acceptance of T.140 too.
> > > > > > > >
> > > > > > > >And if we explain the goal of T.140 and the possibilities.
> > > > > > Then I do not>
> > > > > > >  see any problems for the governments to subsidize this
> > > > > > development and buy>
> > > > > > >  IP telephones for the hearing impaired.
> > > > > > > >Ofcourse, we have to guarantee the legacy TTY
> > > support. But also
> > > > > > > >that it has to be phased out.
> > > > > > > >
> > > > > > > >Please do not lock out T.140 by mandating TTY voice
> > > > > > fallback/passthrough>
> > > > > > >  for IP telephones and clients/servers etc.
> > > > > > > >
> > > > > > > >greetz
> > > > > > > >
> > > > > > > >Arnoud van Wijk
> > > > > > > >
> > > > > > > ><<< "Paul E. Jones" <[email-masked]>  7/ 1  5:47a >>>
> > > > > > > >Rajesh,
> > > > > > > >
> > > > > > > >I agree with your concerns.  Also, I think the case is even
> > > > > > stronger for
> > > > > > > >other countries where such issues are as thoughtfully
> > > > > > considered.  I really
> > > > > > > >doubt that we'll see any requirements in many countries.
> > > > > > > >
> > > > > > > >Another factor is cost.  It might be a small
> > > per-unit cost to
> > > > > > > >include necessary support, but even if it is $10,
> > > $10 times the
> > > > > > > >number
> > > > > > of devices a
> > > > > > > >large, mass manufacturing company will produce in a
> > > > > > > >highly-competitive, low-margin environment becomes a
> > > > > major issue.
> > > > > > > >Thus, there will be a push-back from the extremely
> > > high-volume
> > > > > > > >manufacturers, I think.
> > > > > > > >
> > > > > > > >Considering all things, what I think the best roadmap is:
> > > > > > > >   1) Create devices that are dual TTY/T.140 devices
> > > that work
> > > > > > on PSTN or
> > > > > > >IP
> > > > > > > >   2) Make sure every IP phone, residential gateway / analog
> > > > > > > >terminal adapter, etc.
> > > > > > > >      can properly carry TTY signals, modem signals,
> > > > > fax, etc. and that
> > > > > > > >      a standard TTY device can interface with said device
> > > > > > > >
> > > > > > > >Over time, we may see increased support for T.140
> > > > > natively on every
> > > > > > > >IP phone.  But, I really suspect that for a long
> > > time to come,
> > > > > > (2) is going to
> > > > > > > >be extremely important.  Even so, with (1) in existence,
> > > > > it means
> > > > > > > >that people can start to take advantage of T.140 as
> > > soon as the
> > > > > > devices are put
> > > > > > > >into their hands... and so the transition begins.
> > > > > > > >
> > > > > > > >Paul
> > > > > > > >
> > > > > > > >----- Original Message -----
> > > > > > > >From: "Rajesh Kumar" <[email-masked]>
> > > > > > > >To: "A vWijk" <[email-masked]>
> > > > > > > >Cc: <[email-masked]>; <[email-masked]>;
> > > > > > > ><[email-masked]>; <[email-masked]>;
> > > > > > <[email-masked]>;
> > > > > > > ><[email-masked]>; <[email-masked]>; <[email-masked]>;
> > > > > > > ><[email-masked]>;
> > > <[email-masked]>;
> > > > > > > ><[email-masked]>;
> > > <[email-masked]>;
> > > > > > > ><[email-masked]>; <[email-masked]>;
> > > > > > > ><[email-masked]>; <[email-masked]>;
> > > > > > <[email-masked]>
> > > > > > > >Sent: Monday, June 30, 2003 11:21 PM
> > > > > > > >Subject: Re: SV: SV: Internet draft on real time text
> > > > > conversation
> > > > > > > >
> > > > > > > >
> > > > > > > > > Dr. van Wijk,
> > > > > > > > >
> > > > > > > > > While I support your sentiments, are you sure that
> > > > > > governments all over
> > > > > > > >the
> > > > > > > > > world will provide these mobile text phones to the
> > > > > > hard-of-hearing on a
> > > > > > > > > subsidized basis? Also, the monthly plans that go with it?
> > > > > > > > >
> > > > > > > > > While I do not know about other countries, I seriously
> > > > > > doubt that the US
> > > > > > > > > will do such a thing in the near future. I think the US
> > > > > > deaf community
> > > > > > >is
> > > > > > > > > stuck with Baudot devices for a long time, unless they can
> > > > > > afford PCs on
> > > > > > > > > their own budget.Probably a USB interface on the SIP phone
> > > > > > to a cheap
> > > > > > > > > device is probably the best shot at universal
> > > > > > accessibility. Even so, I
> > > > > > > > > doubt if the US government will subsidize the SIP
> > > > > phone + keypad
> > > > > > > > > +
> > > > > > >screen
> > > > > > > > > combo, even it is cheaper that the Baudot TTY.  This
> > > > > is because
> > > > > > > > > this
> > > > > > >would
> > > > > > > > > entail a mass replacement for thousands of
> > > existing Baudot
> > > > > > > > > devices.
> > > > > > > > >
> > > > > > > > > I might be wrong - I hope I am.
> > > > > > > > >
> > > > > > > > > Rajesh
> > > > > > > > >
> > > > > > > > > At 12:33 PM 6/26/2003 +0200, A vWijk wrote:
> > > > > > > > > >Paul,
> > > > > > > > > >I am also looking at a larger scale.
> > > > > > > > > >Imagine that 3 companies
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >*******************************************************************
> > > > > >**
> > > > > > >***
> > > > > > >This email and any files transmitted with it are
> > > confidential and
> > > > > > >intended solely for the use of the individual or
> > > entity to whom
> > > > > > >they are addressed. Any views or opinions expressed are solely
> > > > > > >those of the author and do not necessarily represent
> > > RNID policy.
> > > > > > >
> > > > > > >If you are not the intended recipient you are advised that
> > > > > any use,
> > > > > > >dissemination, forwarding, printing or copying of this
> > > email is
> > > > > > >strictly prohibited.
> > > > > > >
> > > > > > >If you have received this email in error please notify
> > > the RNID
> > > > > > >Helpdesk by telephone on: +44 (0) 207 296 8282.
> > > > > > >
> > > > > > >The Royal National Institute for Deaf People
> > > > > > >Registered Office 19-23 Featherstone Street
> > > > > > >London EC1Y 8SL No. 454169 (England)
> > > > > > >Registered Charity No. 207720
> > > > > >
> > > > >
> > > >*******************************************************************
> > > > > >**
> > > > > > >***
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
>
>
>

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 9 Jul 2003 13:07:06 -0400

Henry,

I made a number of comments on the previous proposal.  Specifically, I did
not want to see #3 as it was written.  T.38 AND V.18 are entirely separate.
Further, if we allow for VBD operation for TTY devices connected via RJ11,
then V.18 would not be something the phone needs to be complicated with.
Realizing that this is a vote on a number of issues, I'd like to more
clearly separate the issues.  I removed one sentence that caused concern for
Gunnar related to V.21/V.23.  Thus, please replace #3 with:

5. MUST/SHOULD provide an RJ11 port for interfacing with legacy TTY devices,
fax devices, modems, and other legacy equipment for the purposes of
supporting the transfer of information from/to those legacy devices.

6. MUST/SHOULD provide a 2.5mm audio plug for interfacing with a headset or
legacy TTY device

Note that #5 gets into the area of V.150 modem relay and pass-through, as
well as T.38 fax relay.  That came from the original #3.  However, I do not
see the value in spelling out those protocols for the purposes of this vote.

Also, in #2, there is still a reference to a web interface.  I said I don't
think that's necessary, since if one can access the web interface, he/she
can probably just use a PC for communication.  However, they may not be
true.  In any case, I can see the web interface as "interesting", but
certainly could not see mandating it.  Also, I don't agree with the comment
about blind people needing a keyboard and screen.  I propose rewording #2 as
follows:

OR, better:

2A. MUST/SHOULD provide a way to input text and display text through either
a
    built in user interfaces or standard wired or wireless interfaces
    (including a screen and keyboard)

Paul

---

From: "Paul E. Jones" <[email-masked]>
Date: Thu, 10 Jul 2003 13:59:51 -0400

Gunnar,

> that gave the meeting a simple set of choices. Now it is at risk to
deviate

I am certainly not trying to complicate matters.  I really thought that
point #3 was quite confusing as it was written and I merely tried to break
it apart into a few choices.  Each one may be independently accepted or
rejected.

> accessibility issues is thrown out.

Agreed... but things are not necessarily always simple.

> I comment the proposals inline.

I don't like the original voting proposal... especially the comment about
the blind, web interface, and #3 entirely.  You want to reduce complexity,
but I think 3 is complex as it is now.

> is at least 10 times more than V.18 plus T.140 and RFC2793.

Not necessarily.  If we go with the 2.5mm jack, for example, that would
suggest we support phones with input for TTY, so we'd consider V.18 in the
senario, but not T.38.  It just depends on what we want as baseline
requirements.

> network you are, and create compatibility, not offer fragmentation.

You continue to assume that every single IP phone will have text support.
While I'm fully supportive of the goal, I just have doubts that it will be
the reality.  As I've argued before, there will be many low-margin IP phone
manufacturers who would do no more than put an audio input on the phone
(either 2.5mm or RJ-11) and interface with legacy TTY devices.  The biggest
hurdle with adding native text support is the user interface.  This can
become complicated by the fact that the UA may be some distance from the
user.  For example, an "IP phone" might include devices like "residential
gateways" with one or two ports on them.  They might normally be used to
connect regular phones, not IP phones, and have no V.18 support in them.
You might not call them IP phones, but we do have to worry with how they all
interwork.

Speaking strictly of IP phones, I just can't imagine that every manufacturer
of every low-margin IP phone is going to properly support a text interface.
This really concerns me, as *if* such a class of devices are produced, then
we have a huge gap, with what you call "proper" SIP text phones on one side
unable to work with a large class of "improper" SIP text phones.  Thus, I
contend that we need to take this in steps.  We need to encourage the move
to text, but not leave legacy TTY devices out in the cold entirely.

> understood elsewhere. Text telephone is the agreed term.

The name makes no difference to me.

> Gunnar> Same comment about TTY

Ditto.

> to be for clarification in the discussion, but apparently was not clear

So can we agree to remove it?  There are a large number of issues we need to
consider for the blind users and may result in subsequent revisions of this
document going forward.

Paul

> >    method: Built in user interfaces, standard wired or wireless
interfaces
[email-masked]
interface,
> > > > > > > > ><<< "Paul E. Jones" <[email-masked]>  7/ 1  5:47a
>>>
> > > > > > > > >Rajesh,
> > > > > > > > >