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

From: Gunnar Hellström <[email-masked]>
Date: Fri, 11 Jul 2003 00:08:53 +0200

Poul,
No rush. I mean to begin the work to create a BCP or RFC with an I-D now, or
between now and next IETF meeting.
BCP seems to be a less formal type of document than an RFC, so do not be
scared by its name

I agree that new gateway environments call for further standardisation, like
the one going on now in ITU.

If something comes up in that work that should influence the SIP text
telephony or SIP total conversation specs, it should be good timing to let
these pieces of work influence each other.

There could also be details coming from the camarillo I-D or RFC 3351 that
should be reflected in the intended spec. Descriptions about ways to invoke
ither services, like transcoding service.

I hope this will be covered in a BOF, with the explanation that Barry Dingle
wrote, and agreed to start a new work. I expect it to take 8 months to reach
maturity.

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 10 juli 2003 20:12
> Till: Gunnar Hellström; Henry Sinnreich; [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
>
>
> Gunnar,
>
> So, I don't agree with getting this started and helping to steer
> direction,
> but I disagree that everything is standardized.  As you know, we are still
> working on the standards for transport of TTY signals between
> PSTN gateways
> (ITU-T Q11/16).  There are still open questions as to whether a large
> trunking gateway should use one port for audio and one for text or
> "multiplex" on the same port.  (I put that in quotes, as it's not truly
> multiplexing, but switching between one media type and another, but still
> from the same source... the PSTN trunk.)
>
> We then have to consider how those GWs will then interface with the IP
> phones.  This is where I can see the BCP showing value to ensure that the
> current practices are documented.  However, the current practices may have
> to be amended, expanded, etc.  In just the past few weeks, we've had
> discussions on carrying text over audio, using RFC 2793 only,
> inserting GWs
> in the middle, etc.  So, I think we have a few things to talk
> about.  Thus,
> I would prefer that this be written and modified over the next
> few meetings,
> rather than rushed to RFC/BCP status.
>
> Paul
>
> ----- Original Message -----
> From: "Gunnar Hellström" <[email-masked]>
> To: "Paul E. Jones" <[email-masked]>; "Henry Sinnreich"
> <[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]>
> Sent: Thursday, July 10, 2003 3:16 AM
> Subject: SV: items for vor voting in the BOF
>
>
> > Poul,
> > We are seeking a form of document where we can collect the
> pieces that are
> > already well standardised for text in IP, but apparently a bit hard to
> find,
> > so we have an apparent risk that developers keep inventing new,
> incompatible
> > solutions for text while the IP voice telephony side converges.
> >
> > We cannot afford to let IP text conversation be as fragmented
> as it was in
> > PSTN. It must be a proper telecom feature on the same status level as
> voice
> > and video if we are ever to get any accessibility in this world. And it
> must
> > be included in mainstream developments.
> >
> > The PSTN functions for text are good and important where they are ,but
> > nothing of the functionality level that we would drag into the future as
> any
> > best common solution. That has been stated many times in the discussions
> > here.
> >
> > Gateways are defined and in operation.
> >
> > It is exactly the right moment now to create a document that
> collects the
> > views on IP text conversation. With that we can all contribute
> to make it
> > widespread. Without it, there is a risk of continued fragmentation.
> >
> > We proposed BCP (Best Common Practise) merely because everything is
> already
> > standardised and it is not good to have the same standard in two
> documents.
> > A BCP can pick up and clarify and put emphasis on standards created in
> other
> > documents. Of course it shall take the traditional route to be an I-D
> first.
> > I am flexible on this. If there is enough new material in it, it can be
> > proposed as an RFC.
> >
> > So, doing it now is the most important.
> >
> > 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:30
> > > Till: Gunnar Hellstrom; Henry Sinnreich; [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
> > >
> > >
> > > Gunnar,
> > >
> > > Do you think it might be a bit premature to publish a BCP?  After
> > > all, it's
> > > not widely used at this point, but it is expected to become much
> > > more widely
> > > used over the next few years.  What is still not sorted out is
> > > how this will
> > > be married with the existing PSTN TTY equipment out there.  There was
> some
> > > discussion of using specialized gateways for interworking,
> > > putting RFC 2793
> > > on IP phones, doing pass-though on IP phones, etc.  We still haven't
> even
> > > settled the issue of how text will even be entered into the average IP
> > > phone.  I recognize that it's a best "current" practice, but given the
> > > amount of focus on this right now and the volatility, I think it might
> be
> > > better to just produce an I-D and re-publish that for a period of time
> and
> > > not rush to produce a BCP.
> > >
> > > Paul
> > >
> > > ----- Original Message -----
> > > From: "Gunnar Hellstrom" <[email-masked]>
> > > To: "Henry Sinnreich" <[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:45 PM
> > > Subject: SV: items for vor voting in the BOF
> > >
> > >
> > > > OK, looks fine.
> > > >
> > > > What about the external alerting connections? There was some good
> points
> > > > that it can be arranged by logging in a SIP alerter with
> the same user
> > > name
> > > > in the sip server. That is a good design, that one can do a lot of
> smart
> > > > things with. Evenso, the direct connection on the phone is
> simple and
> > > > needed.
> > > >
> > > >
> > > > Whatever the outcome of the voting, we also agreed that it would be
> good
> > > to
> > > > have a BCP ( Best Current Practice ) on what SIP text
> > > conversation is. The
> > > > SDP for it, some good habits in design, what is need to support the
> > > > transactions for invoking transcoding according to camarillo...
> > > etc. Erik
> > > > Zetterstrom and Andreas Piirimets made an initial draft. I
> > > think they are
> > > > prepared to issue a new, slightly improved. Barry Dingle had a good
> > > > formulation promoting it. Has it progressed? I suggest that
> > > these actions
> > > > are handled jointly in the sipping meeting.
> > > >
> > > > Is anything like the sipdev activity going on for
> multimedia devices?
> I
> > > > would like to participate there and get text included there as well
> > > together
> > > > with video and voice.
> > > >
> > > > 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: Henry Sinnreich [mailto:[email-masked]]
> > > > > Skickat: den 6 juli 2003 22:14
> > > > > Till: '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]; [email-masked]
> > > > > Amne: 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: Henry Sinnreich <[email-masked]>
Date: Sun, 13 Jul 2003 15:22:47 +0200

From:	Marcia Beaulieu [[email-masked]]
Sent:	Tuesday, July 08, 2003 5:04 PM
To:	Henry Sinnreich; 'Dean Willis'; 'Henry Sinnreich';
[email-masked]
Cc:	[email-masked]; [email-masked]
Subject:	RE: Request for ad-hoc meeting on interactive text in
SIP  devices

Meeting rooms at the Austria Center are not available after the
regularly 
scheduled
meetings.  We are charged rent for the rooms and we do not rent them
longer 
than
what is needed.

Marcia

At 02:54 PM 7/2/03 -0500, Henry Sinnreich wrote:
> > Would an evening "after hours" schedule work?
>

---

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

Gunnar,

Do you think it might be a bit premature to publish a BCP?  After all, it's
not widely used at this point, but it is expected to become much more widely
used over the next few years.  What is still not sorted out is how this will
be married with the existing PSTN TTY equipment out there.  There was some
discussion of using specialized gateways for interworking, putting RFC 2793
on IP phones, doing pass-though on IP phones, etc.  We still haven't even
settled the issue of how text will even be entered into the average IP
phone.  I recognize that it's a best "current" practice, but given the
amount of focus on this right now and the volatility, I think it might be
better to just produce an I-D and re-publish that for a period of time and
not rush to produce a BCP.

Paul

----- Original Message ----- 
From: "Gunnar Hellstrom" <[email-masked]>
To: "Henry Sinnreich" <[email-masked]>; <[email-masked]>;
"'James Hamlin'" <[email-masked]>; <[email-masked]>;

> OK, looks fine.
>
> What about the external alerting connections? There was some good points
> that it can be arranged by logging in a SIP alerter with the same user
name
> in the sip server. That is a good design, that one can do a lot of smart
> things with. Evenso, the direct connection on the phone is simple and
> needed.
>
>
> Whatever the outcome of the voting, we also agreed that it would be good
to
> have a BCP ( Best Current Practice ) on what SIP text conversation is. The
> transactions for invoking transcoding according to camarillo... etc. Erik
> Zetterstrom and Andreas Piirimets made an initial draft. I think they are
> formulation promoting it. Has it progressed? I suggest that these actions
> Is anything like the sipdev activity going on for multimedia devices? I
together
> > [email-masked]; [email-masked]; [email-masked];
> > Please see the attached slide for voting at the IETF BOF on "Interactive
> > We have no day/time yet for the BOF, but expect to get it scheduled, as
> > > formulated in a strict IETF style. A starting sentence is needed:
> > >
> > > > [email-masked]; [email-masked]; [email-masked];
> > > > [email-masked]; [email-masked]; [email-masked]
> > > > I will use with your permission your formulation to put these three
> > > > 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
> > > > 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? )
> > > >
> > > > > [email-masked]; [email-masked]; [email-masked];
> > > > > Subject: SV: SV: SV: Internet draft on real time text conversation
> > > > >
> > > > >
> > > > > 2. MUST provide a way to input text and display text, through any
> > > > > interfaces for keyboard and display ( that is needed anyway for
> > > > > 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
> > > > > involved in the call perceive any indication on use of modem-like
> > > > > Has time been booked in the SIPPING meeting in Wienna to discuss
> > > > > that?
> > > > >
> > > > > > Amne: RE: SV: SV: Internet draft on real time text conversation
> > > > > >
> > > > > >
> > > > > > James,
> > > > > >
> > > > > > when you cannot tell whether the V.21 signal is text or not -
> > > > > > regardless of the existence of gateways/servers that do PSTN
> > > > > > 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
> > > > > > >It would be possible for people on the IP network to have PSTN
> > > > > > numbers that
> > > > > > >between PSTN and the IP network knows from the called number
> > > > > > that the intent
> > > > > > >is to use text.
> > > > > > >
> > > > > > >Regards
> > > > > > >
> > > > > > >James
> > > > > > >
> > > > > > >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
> > > > > > >There is a real technical difficulty which I would want you all
> > > > > > to consider.
> > > > > > >
> > > > > > >SG16/Q11 has struggled with the fact that you cannot always
> > > > > > discriminate aT
> > > > > > >In this case, there is no basis for the gateway to convert the
> > > > > > >PSTN
> > > > > > TTY signali
> > > > > > >a modulated signal based on answer tone (if present) or on
> > > > > specific
> > > > > > >  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
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > >How do you feel by mandating T.140/RTP along with the TTY
> > > > > > passthrough on>
> > > > > > >  IP telephones and such?
> > > > > > > >And remember..as I am stating over and over again. RFC2793 is
> > > > > > NOT limited>
> > > > > > > >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>
> > > > > > > ><<< "Paul E. Jones" <[email-masked]>  7/ 1  5:47a >>>
> > > > > > > >Rajesh,
> > > > > > > >
> > > > > > > >I agree with your concerns.  Also, I think the case is even
> > > > > > stronger for
> > > > > > > >doubt that we'll see any requirements in many countries.
> > > > > > > >
> > > > > > > >Considering all things, what I think the best roadmap is:
> > > > > > > >   2) Make sure every IP phone, residential gateway / analog
> > > > > > > >terminal adapter, etc.
> > > > > > > >      a standard TTY device can interface with said device
> > > > > > > >
> > > > > > > >be extremely important.  Even so, with (1) in existence,
> > > > > it means
> > > > > > > ><[email-masked]>; <[email-masked]>; <[email-masked]>;
> > > > > > > > > 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
> > > > > > >they are addressed. Any views or opinions expressed are solely
> > > > > > >If you are not the intended recipient you are advised that
> > > > > any use,

---

From: "Paul E. Jones" <[email-masked]>
Date: Thu, 10 Jul 2003 14:11:33 -0400

Gunnar,

So, I don't agree with getting this started and helping to steer direction,
but I disagree that everything is standardized.  As you know, we are still
working on the standards for transport of TTY signals between PSTN gateways
(ITU-T Q11/16).  There are still open questions as to whether a large
trunking gateway should use one port for audio and one for text or
"multiplex" on the same port.  (I put that in quotes, as it's not truly
multiplexing, but switching between one media type and another, but still
from the same source... the PSTN trunk.)

We then have to consider how those GWs will then interface with the IP
phones.  This is where I can see the BCP showing value to ensure that the
current practices are documented.  However, the current practices may have
to be amended, expanded, etc.  In just the past few weeks, we've had
discussions on carrying text over audio, using RFC 2793 only, inserting GWs
in the middle, etc.  So, I think we have a few things to talk about.  Thus,
I would prefer that this be written and modified over the next few meetings,
rather than rushed to RFC/BCP status.

Paul

----- Original Message ----- 
From: "Gunnar Hellström" <[email-masked]>
To: "Paul E. Jones" <[email-masked]>; "Henry Sinnreich"

> Poul,
> We are seeking a form of document where we can collect the pieces that are
find,
incompatible
> We cannot afford to let IP text conversation be as fragmented as it was in
voice
must
any
> It is exactly the right moment now to create a document that collects the
> views on IP text conversation. With that we can all contribute to make it
already
documents.
other
first.
some
even
be
and
points
smart
good
V.18+RFC2793
support? )
for
negotiation
discuss
not -
textphone
number
legacy
passthrough
been
musts,
too.
possibilities.
even
device
<[email-masked]>;
US

---

From: Gregg Vanderheiden <[email-masked]>
Date: Mon, 14 Jul 2003 02:56:39 -0500

Hi All,

Can someone post the current form of the items that are up for vote at the
BOF?

Is it still the original 3?  Or has it been revised based on comments?

Thanks 	

Gregg

 -- ------------------------------ 
Gregg C Vanderheiden Ph.D. 
Professor - Ind. Engr. & BioMed Engr.
Director - Trace R & D Center 
University of Wisconsin-Madison 

-----Original Message-----
From: Henry Sinnreich [mailto:[email-masked]] 
Sent: Sunday, July 13, 2003 8:23 AM
To: 'Gunnar Hellstrom'; 'Henry Sinnreich'; [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]; [email-masked]
Subject: RE: items for vor voting in the BOF

Marcia

---

From: Gunnar Hellström <[email-masked]>
Date: Thu, 10 Jul 2003 09:16:58 +0200

Poul,
We are seeking a form of document where we can collect the pieces that are
already well standardised for text in IP, but apparently a bit hard to find,
so we have an apparent risk that developers keep inventing new, incompatible
solutions for text while the IP voice telephony side converges.

We cannot afford to let IP text conversation be as fragmented as it was in
PSTN. It must be a proper telecom feature on the same status level as voice
and video if we are ever to get any accessibility in this world. And it must
be included in mainstream developments.

The PSTN functions for text are good and important where they are ,but
nothing of the functionality level that we would drag into the future as any
best common solution. That has been stated many times in the discussions
here.

We proposed BCP (Best Common Practise) merely because everything is already
standardised and it is not good to have the same standard in two documents.
A BCP can pick up and clarify and put emphasis on standards created in other
documents. Of course it shall take the traditional route to be an I-D first.
I am flexible on this. If there is enough new material in it, it can be
proposed as an RFC.

Gunnar