Subject: [Sipping] comments on draft-ietf-sipping-toip-03.txt

From: "Jeff Knighton" <[email-masked]>
Date: Sun, 6 Nov 2005 23:57:17 -0700

Hello ,
 Having spent much of the last 8 years in deaf communication technology, I
am very pleased with the draft-ietf-sipping-toip-03.txt document.  I believe
that the authors have presented a very good description not only the concept
of Text-over-IP, but have addressed much of the context surrounding deaf
communications.  I agree completely with the approach of this document, and
believe that broad acceptance of the ideas presented here would
significantly improve the quality of communications for the deaf community
in the world.  I have a few comments that could perhaps enhance this
document.

1.  Section 6.1.b   This section briefly describes a scenario where a
session is re-directed to a transcoding server to handle a situation where
incompatible text/voice preferences are encountered.  I believe that the
particular capability described in this small section is hugely important to
the deaf community and should be more heavily emphasized.  Basically, what
this section means, is that a hearing person could call a deaf person
directly, and that if the hearing person did not have a text capability,
that the call could automatically be re-directed to a Relay Operator
(transcoding service).  This capability would lead to a fundamental change
to how hearing people initiate a conversation with the deaf.  Currently, at
least in the US, a hearing person wishing to call a deaf person would first
place a call a Relay Service.  Most hearing individuals are not aware of how
this service operates.  With ToIP, a clear opportunity exists to allow the
hearing would to dial a deaf person directly, and the intelligence within
the network allows the communication to occur.

2.  Section 7.5.2.  This section describes interoperation between
half-duplex and full-duplex protocols.  I believe that this section does not
provide sufficient guidance to a very significant problem, especially in the
US.  Baudot, a half-duplex protocol is the most common text protocol used in
the US by the deaf for PSTN communication.  It's nature is half-duplex.
This section states that identification of half-duplex may be done at the
user level (which I definitely agree with) or at the "protocol" level.  What
protocol is being described here?  How might that notification take place?
Another notification which I believe should occur between a gateway and a
user agent is to know when a gateway has to buffer text for transmission.
If I am using a user agent which allows me to transmit to the gateway at 30
characters per second, and the gateway needs to convert the t.140 text to
baudot and transmit at 6 characters per second, I would want to know when my
text has actually been transmitted... otherwise I would have a false
expectation as to when I would expect a response from the remote
participant.  There is no comment within this document proposing this type
of notification.

I hope that this feedback is useful.   I believe that it is important but
would not want the feedback to stand in the way of acceptance of this
document.

Best Regards,

Jeff Knighton
President
Voiceriver Inc.

_______________________________________________
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: "Gunnar Hellstrom" <[email-masked]>
Date: Wed, 9 Nov 2005 23:22:41 +0100

Jeff,
Thanks for positive comments.

Your thoughts on section 7.5.2 are interesting and good.
The interworking between half duplex and full duplex text telephony is
tricky.
There are more variations out there in PSTN than what you would like to
adapt to in a user interface in a SIP UA.
In PSTN there are:
a. full duplex textphones. They are V.18 based.
b. textphones that have full duplex modems but half duplex user interfaces.
They can take an interruption, a plea for the turn, while the other one is
typing. That is V.21, Minitel and Bell 103.
c. strictly half duplex textphones, where it is physically impossible to
transmit both ways simultaneously. That is the US type Baudot, the European
EDT and the Dutch DTMF.

With the half-duplex types, the users use turn-taking indicators to give
turn to the other party.
Various regions have various habits. "GA", "*" and "+" are examples of turn
taking tokens.

I like your idea to signal the characteristics and recommend the user
interface to indicate the duplex condition to the user. Full duplex should
be the default.

There is work in mmusic with a sdp media parameter media-content. One
media-content type parameter discussed is user-floor. That can be used to
indicate to a user that there is a need to be careful in taking the turn to
type.
This draft contains the user-floor media contents parameter that looks
useful.
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-media-content-00.t
xt

Your concerns about the lack of flow control can be met to some degree by
using the CPS ( characters per second ) parameter in sdp specification of
the text rtp.

So, these parameters can be used in an INVITE, OK, or reINVITE.

This is the current section 7.5.2.
"7.5.2 Relay buffer storage

          When text gateway functions are invoked, there will be a need for
          intermediate storage of characters before transmission to a device
          receiving text slower than the transmitting speed of the sender.
          Such temporary storage SHALL be dimensioned to adjust for
          receiving at 30 characters per second and transmitting at 6
          characters per second for up to 4 minutes (i.e. less than 3k
          characters).

          Interoperation of half-duplex and full-duplex protocols MAY
          require text buffering. Some intelligence will be needed to
          determine when to change direction when operating in half-duplex
          mode. Identification may be required of half-duplex operation
          either at the "user" level (ie. users must inform each other) or
          at the "protocol" level (where an indication must be sent back to
          the Gateway). "

I suggest some additions to that section, so that it reads:

"7.5.2 Relay buffer storage

          When text gateway functions are invoked, there will be a need for
          intermediate storage of characters before transmission to a device
          receiving text slower than the transmitting speed of the sender.
          Such temporary storage SHALL be dimensioned to adjust for
          receiving at 30 characters per second and transmitting at 6
          characters per second for up to 4 minutes (i.e. less than 3k
          characters). Gateways SHOULD indicate with the CPS= parameter in
	    the sdp declaration of the text rtp stream the speed of text
          character transmission when the textphone type is resolved.

          Interoperation of half-duplex and full-duplex protocols MAY
          require text buffering. Some intelligence will be needed to
          determine when to change direction when operating in half-duplex
          mode. Identification may be required of half-duplex operation
          either at the "user" level (ie. users must inform each other) or
          at the "protocol" level (where an indication must be sent back to
          the Gateway). If at some stage, a parameter detailing half
          duplex media contents characteristics is introduced in sdp,
          such characteristics SHOULD be used to indicate to a ToIP
          user when the session requires half duplex action and dialog
          turn taking indications in the text. ( By "GA" or "*" or "+"
          or whatever is the user habit in the area where the call is
          placed. ) This would be useful when the other party in a call
          is a half-duplex oriented textphone. The default should be no
          restriction from full duplex operation."

I hope that would take care of your concern.

Gunnar
----------------------------------------------------------------------------
-
Gunnar Hellström, Omnitor
[email-masked] <mailto:[email-masked]>
Mob: +46 708 204 288
Phone: +46 8 556 002 03
www.omnitor.se <http://www.omnitor.se>

-----Original Message-----
From: Jeff Knighton [mailto:[email-masked]]
Sent: Monday, November 07, 2005 7:57 AM
To: [email-masked]; Gunnar Hellstrom; Gregg Vanderheiden
Subject: comments on draft-ietf-sipping-toip-03.txt

Hello ,

Best Regards,

Jeff Knighton
President
Voiceriver Inc.

---

From: "Jeff Knighton" <[email-masked]>
Date: Wed, 9 Nov 2005 16:50:24 -0700

Your proposed changes do address my concerns.  With those changes in place,
I support the draft.
-Jeff

----- Original Message ----- 
From: "Gunnar Hellstrom" <[email-masked]>
To: "Jeff Knighton" <[email-masked]>; <[email-masked]>;
"Gregg Vanderheiden" <[email-masked]>
Sent: Wednesday, November 09, 2005 3:22 PM
Subject: RE: comments on draft-ietf-sipping-toip-03.txt

Jeff,

Gunnar

-----Original Message-----
From: Jeff Knighton [mailto:[email-masked]]
Sent: Monday, November 07, 2005 7:57 AM
To: [email-masked]; Gunnar Hellstrom; Gregg Vanderheiden
Subject: comments on draft-ietf-sipping-toip-03.txt

Hello ,

Best Regards,

Jeff Knighton
President
Voiceriver Inc.