SV: SV: Text Speed in IP networks

Rajesh Kumar rkumar at cisco.com
Fri Jun 20 14:05:29 EDT 2003


Hi Gunnar et al,
I have added the TIA and SG16 lists to this thread.

Here is the SDP that I propose for the "PSTN text format" indicator. If 
this is OK with you and the group, it can be bundled into the BCP draft by 
Andreas and Erik, and added to the V.ToIP text.

Ideally, the definition of the MIME text/t140 should have a parameter 
indicating whether the format is derived from or converted to a PSTN 
format. If this were so, then we would use a boolean variable in the 
format-specific attribute, 'fmtp'. However, I do not propose that we change 
the definition of the MIME text/t140 because of unnecessary logistics and 
effort.

In lieu of the 'fmtp' attribute in SDP, I propose that we use the 'gpmd' 
attribute 
(http://www.ietf.org/internet-drafts/draft-rajeshkumar-mmusic-gpmd-03.txt) 
which is isomorphic to the 'fmtp' attribute but which affords more 
flexibility since it can be used without the inclusion of the corresponding 
parameter in the MIME definition. The referenced internet draft is in last 
call.

You would use 'gpmd' to associate a boolean pstncnv=yes or no with the RTP 
payload type for RFC 2793 text. Omission of this parameter would imply a 
value of 'no', therefore it is incumbent on the PSTN-IP media gateway to 
provide this indication. The IP text phone can just omit this indication in 
the SDP it creates, but it must be able to interpret this parameter 
generated by a PSTN media gateway.

A value of 'yes' implies that the RFC 2793 stream is converted into a PSTN 
text telephone (TTY/TDD) stream. At call establishment, the media gateway 
need not know the format of the PSTN text telephone device (e.g Baudot, 
EDT, native V.18 etc.) that will use this capability.

So, if the creator of the SDP is a media gateway,  one of the examples in 
the BCP document will become:

      m=text 11000 RTP/AVP 98
      a=rtpmap:98 t140/1000
      a=gpmd:98 pstncnv=yes

The second example in the BCP document would become:


     m=text 11000 RTP/AVP 98 100
     a=rtpmap:98 t140/1000
     a=rtpmap:100 red/1000
     a=fmtp:100 98/98
     a=gpmd:98 pstncnv=yes

You would need to register the boolean 'pstncnv' with the ICANN.

You are free to substitute 'fmtp' in place of 'gpmd' in the example above 
if you choose to change the MIME text/t140 to include the 
'pstncnv'  parameter. If you do so, one of the examples above will become:

         m=text 11000 RTP/AVP 98
         a=rtpmap:98 t140/1000
         a=fmtp:98 pstncnv=yes

Best Regards,

Rajesh Kumar


At 08:39 AM 6/20/2003 +0200, Gunnar Hellström wrote:
>Thanks Rajesh for a well motivated proposal.
>My first reaction is positive.
>
>It means that the only element introduced for IP text phones is to recognize
>a Gateway indicator in the SDP, and show that to the user during the call.
>
>And the IP user should understand and react with caution in throwing big
>chunks of text on the call.
>
>It is not nice to request understanding of new symbols in the user interface
>from the user, but in this case I think it is useful. There are other
>differences between IP and PSTN textphones that makes it good to give this
>indicator to the IP user.
>
>1. Many PSTN textphones are half duplex in operation. While they transmit
>they can´t receive. Many of the full duplex ones still merge text from both
>sides into the same window. Both designs require a strict turn-taking for
>the conversation to work. On the IP side it is full duplex with separate
>areas for both sides, so that the dialogue flows freely.
>The gateway will act as a turntaking master for the half duplex types, but
>not for the full duplex ones. In both cases we have a risk that text from an
>IP user typing while receiving will end up being transmitted in the middle
>of the PSTN user´s turn and disturb his display of the dialogue.
>The Gateway indicator can be used also as a remainder to refrain from
>concurrent typing.
>
>2. By this nature of half duplex or common display area for the PSTN
>textphones, the users have introduced strict turntaking control habits. They
>have an agreed character signal that gives turn and another that signals
>invitation to end and yet another to disconnect. In Sweden the turntaking
>charater is * , in Germany it is + , in USA and UK it is GA . The invitation
>to close is in Sweden KLSL* in Germany ++ , in USA and UK   GASK. The
>disconnect signal is in Sweden KLSL, and in USA and UK  SKSK . When using
>full duplex IP textphones you notice that these signals very rapidly fade
>away. You do not use them any more. So, if the user still remembers how
>turntaking was handled, the Gateway indicator will act as a reminder to use
>them in the call.
>
>3. The limitations in character sets in the PSTN textphones will cause some
>characters from the IP side to not convert to anything, or to the common
>"not representable" character we discussed before, and some characters to
>convert to something else. It can be good to get this indicator as a
>reminder that such limitations might exist.
>
>People who will have many cross-border calls will rapidly learn what
>restrictions applies. And it can be described in manuals and education.
>People who seldom call across the border will have a chance to learn from
>mistake and eventually get awareness about the connection between the
>indicator and the fact that the news article he glued in  into a call was
>chopped at the receiving end.
>
>There are too many cases where automation would fail if we tried to insert
>GA detection, * detection line silence detection and precise throtteling
>mechanisms and so on to control IP terminal and gateway behaviour, so I
>think that this is a good compromise.
>
>What is the proposed SDP for such an indicator?
>
>I added a few people from another discussion line where we have discussed to
>make a new Internet Draft for the IP Text Telephone and The IP Total
>Conversation device, or just a text conversation application guide. Maybe
>this duscussion should move to a list.
>
>Gunnar
>-------------------------------------------
>Gunnar Hellström, Omnitor, Renathvägen 2
>SE 121 37 Johanneshov, SWEDEN
>Tel: +46 8 556 002 03  Mob: +46 708204288
>e-mail: gunnar.hellstrom at omnitor.se
>web: www.omnitor.se
>
>
> > -----Ursprungligt meddelande-----
> > Från: Rajesh Kumar [mailto:rkumar at cisco.com]
> > Skickat: den 20 juni 2003 02:14
> > Till: Gunnar Hellström
> > Kopia: Paul E. Jones; Guido Gybels; keith.chu at mindspeed.com; James
> > Hamlin; bpechey at cix.compulink.co.uk; Frank Shearar; Jamie Buchanan; Mike
> > Spanner; cary.barbin at tap.gallaudet.edu; judy.harkins at tap.gallaudet.edu;
> > gv at trace.wisc.edu; fred.lucas at worldnet.att.net; mgarakan at cisco.com;
> > hwildfeu at cisco.com; mmostafa at cisco.com; rmahy at cisco.com;
> > spear at cisco.com; flemming Andreasen
> > Ämne: Re: SV: Text Speed in IP networks
> >
> >
> > Keith, Gunnar and other esteemed colleagues,
> >
> > I have discussed these issues off-line with some folks and I have the
> > following recommendations to make as the basis of potential V.ToIP
> > consensus points in the future.
> >
> > ((Also, thanks to Herb Wildfeur, Paul Jonesand Rohan Mahy for
> > their advice.
> > Although I have used their knowledge freely, I do not claim to represent
> > their views in these recommendations.))
> >
> > 1.  Native IP text phones should know at call establishment if the remote
> > end is a media gateway connected to a PSTN-based TTY devices. Although it
> > is not possible to know at call establishment what the nature of the
> > PSTN-based TTY device is, it is possible for the media gateway to
> > indicate
> > in SDP or H.245 that is a media gateway (as opposed to an IP user device).
> >
> > 2. IP text phones should have a mechanism  to throttle their rate
> > to a safe
> > steady state rate and a safe burst rate when the remote end indicates at
> > session establishment that it is a PSTN-IP media gateway.
> > Although this can
> > be higher, let us for now assume the rates associated with the
> > fastest PSTN
> > device  - the Minitel. Per an earlier email, these are 20  characters per
> > second steady state (based on voice subtitling) and 120 chars/sec in the
> > burst mode (based on the copy-and-paste of short text strings such as
> > paper-mail addresses).
> >
> > 3. The reason why the fastest rate of a PSTN TTY device is
> > considered safe
> > in point #2 above is that is possible for legacy PSTN devices to
> > communicate with each other with minimal buffering (1-2K) and still have
> > lossless transmission without flow control. This is even true when a 1200
> > bps Minitel transmits to a 45.45 bps Baudot device. Therefore, if IP text
> > phones maintain the rate profile of the fastest (not slowest)
> > PSTN TTY when
> > talking to a PSTN TTY, then the normal buffering provided for
> > PSTN-PSTN TTY
> > communication will suffice for transmissions from an IP text phone to a
> > PSTN TTY.
> >
> > 4. When an IP text phone receives an indication via SDP or H.245 at call
> > establishment that the remote end is a PSTN-IP media gateway, the user of
> > the IP text phone should be provided with an indicator (light, soft
> > indicator etc.) that the remote end is a PSTN device.  This
> > should prevent
> > the IP text phone user from copy and pasting large volumes of text, while
> > not precluding the copy and paste of addresses, phone numbers etc. all of
> > which can be done if a Minitel rate profile is adhered to.
> >
> > 5. Flow control between native IP text phones and PSTN media gateways is
> > not needed since the set of PSTN TTY devices is well-known and the
> > throttling mechanism described above will work. Also, flow control should
> > not be included in the successor to RFC 2793 since this would affect RTP
> > conferencing, multicasting etc. Also, text telephones need not implement
> > SPRT which should strictly be a gateway to gateway protocol.
> >
> > 6. IP text phones operating with the text/t140 (RFC 2793) MIME are to be
> > distinguished from Instant Messaging devices which use protocols such as
> > SIMPLE etc. While V.ToIP should factor in interoperability with IP text
> > phones based on RFC 2793, it need not address Instant Messaging devices.
> > Since these speak a different language, direct interoperability with
> > Instant Messaging devices is not possible without some kind of
> > T140-to-Instant_Messaging server/convertor.
> >
> > 7.  Points #1 and #6 above impose requirements on IP text phones and on
> > PSTN-IP media gateways, and therefore must be included in V.ToIP
> > if agreed
> > to. It is strongly recommended that points #2, #3 , #4 and #5 which deal
> > with IP text phones also be included in V.ToIP since we want it to be
> > forward compatible with any IP text telephony standards. These are very
> > reasonable and very light requirements (compared to previous
> > proposals for
> > the IP text telephone being able to dynamically set a bit rate
> > cap based on
> > the nature of the PST TTY device).
> >
> > Do these sound like the seeds of V.ToIP consensus points in
> > future meetings?
> >
> > Regards,
> >
> > Rajesh
> >
> > At 07:29 AM 6/18/2003 +0200, Gunnar Hellström wrote:
> > >OK, can you describe a method for loose flow control, e.g. based on a
> > >character or bit transmission rate negotiation?
> > >
> > >It would be good to have prototype implementations now for
> > verification of
> > >mechanisms.
> > >I also have the impression, as Guido has, that the simple
> > gateways that are
> > >out there work fine without any flow control.
> > >
> > >There are some gateway products using proprietary protocols on
> > the IP side,
> > >from nXi DSPG and Envilogg. There should be user experience from them
> > >available.
> > >
> > >Gunnar
> > >
> > >-------------------------------------------
> > >Gunnar Hellström, Omnitor, Renathvägen 2
> > >SE 121 37 Johanneshov, SWEDEN
> > >Tel: +46 8 556 002 03  Mob: +46 708204288
> > >e-mail: gunnar.hellstrom at omnitor.se
> > >web: www.omnitor.se
> > >
> > >
> > > > -----Ursprungligt meddelande-----
> > > > Från: Paul E. Jones [mailto:paulej at packetizer.com]
> > > > Skickat: den 18 juni 2003 05:30
> > > > Till: Gunnar Hellstrom; Guido Gybels; keith.chu at mindspeed.com; James
> > > > Hamlin
> > > > Kopia: rkumar at cisco.com; bpechey at cix.compulink.co.uk; Frank Shearar;
> > > > Jamie Buchanan; Mike Spanner; cary.barbin at tap.gallaudet.edu;
> > > > judy.harkins at tap.gallaudet.edu; gv at trace.wisc.edu;
> > > > fred.lucas at worldnet.att.net
> > > > Ämne: Re: Text Speed in IP networks
> > > >
> > > >
> > > > Gunnar,
> > > >
> > > > OK... I will not push the issue.  But, I think it would not
> > hurt to allow
> > > > the endpoints to advise the other party of some incoming rate
> > > > limit.  H.323
> > > > has these mechanisms in place, so there would be nothing new that
> > > > would have
> > > > to be added there.  But, we would have to have something new
> > for SDP, I
> > > > think... I may be wrong.
> > > >
> > > > However, if you think that it is not likely that we'll see calls into
> > > > automated systems that send out a lot of text or users
> > cutting and pasting
> > > > text that might over-run the buffers on the peer devices, then
> > > > I'd agree we
> > > > don't need to worry with it.
> > > >
> > > > Personally, I think that the more pervasive the IP systems
> > > > become, the more
> > > > likely it is that we'll see large amounts of text pushed out
> > on the wire.
> > > > Those systems will cause problems for the legacy devices.
> > > >
> > > > Paul
> > > >
> > > > ----- Original Message -----
> > > > From: "Gunnar Hellstrom" <gunnar.hellstrom at omnitor.se>
> > > > To: "Guido Gybels" <Guido.Gybels at rnid.org.uk>;
> > <keith.chu at mindspeed.com>;
> > > > <paulej at packetizer.com>; "James Hamlin" <james.hamlin at rnid.org.uk>
> > > > Cc: <rkumar at cisco.com>; <bpechey at cix.compulink.co.uk>; "Frank Shearar"
> > > > <frank.shearar at rnid.org.uk>; "Jamie Buchanan"
> > > > <jamie.buchanan at rnid.org.uk>;
> > > > "Mike Spanner" <mike.spanner at rnid.org.uk>;
> > > > <cary.barbin at tap.gallaudet.edu>;
> > > > <judy.harkins at tap.gallaudet.edu>; <gv at trace.wisc.edu>;
> > > > <fred.lucas at worldnet.att.net>
> > > > Sent: Tuesday, June 17, 2003 4:33 PM
> > > > Subject: SV: Text Speed in IP networks
> > > >
> > > >
> > > > > Paul,
> > > > > In general, we use human flow control.
> > > > >
> > > > > Flow control and the use of reasonable sized gateway
> > buffers has been
> > > > > discussed some time during the spring.
> > > > >
> > > > > The conclusion is what Guido says. In the transit case
> > there is not much
> > > > > meaning to introduce flow control when both endpoints lack
> > flow control.
> > > > >
> > > > > If at least one end is in a native IP environment, we could
> > apply a flow
> > > > > control mechanism.
> > > > >
> > > > > But there are other more important aspects that made me
> > > > recommend RTP, and
> > > > > with that we lost the opportunity of tight flow control.
> > > > >
> > > > > The reason is that the protocol should be suitable for
> > > > multi-party use and
> > > > > even multi-casting. RTP for voice and video are defined to
> > be used in
> > > > > loosely coupled conferences, and it would be a severe accessibility
> > > > drawback
> > > > > if such meetings could not be subtitled for deaf and
> > hearing impaired
> > > > > participants.
> > > > >
> > > > > In order to keep it simple and compatible, I proposed RTP
> > without flow
> > > > > control, and I still think that that is the simple straighhtforward
> > > > > mechanism. ( even for the transit case, but of course you
> > can introduce
> > > > any
> > > > > protocol there, as long as you can be sure that the
> > operators have the
> > > > money
> > > > > to buy both a transit gateway solution and another gateway
> > solution for
> > > > the
> > > > > native IP case ).
> > > > >
> > > > > All the best
> > > > >
> > > > > Gunnar
> > > > > -------------------------------------------
> > > > > Gunnar Hellstrom, Omnitor, Renathvagen 2
> > > > > SE 121 37 Johanneshov, SWEDEN
> > > > > Tel: +46 8 556 002 03  Mob: +46 708204288
> > > > > e-mail: gunnar.hellstrom at omnitor.se
> > > > > web: www.omnitor.se
> > > > >
> > > > >
> > > > > > -----Ursprungligt meddelande-----
> > > > > > Fran: Guido Gybels [mailto:Guido.Gybels at rnid.org.uk]
> > > > > > Skickat: den 17 juni 2003 09:04
> > > > > > Till: keith.chu at mindspeed.com; gunnar.hellstrom at omnitor.se;
> > > > > > paulej at packetizer.com; James Hamlin
> > > > > > Kopia: rkumar at cisco.com; bpechey at cix.compulink.co.uk;
> > Frank Shearar;
> > > > > > Jamie Buchanan; Mike Spanner; cary.barbin at tap.gallaudet.edu;
> > > > > > judy.harkins at tap.gallaudet.edu; gv at trace.wisc.edu;
> > > > > > fred.lucas at worldnet.att.net
> > > > > > Amne: Re: Text Speed in IP networks
> > > > > >
> > > > > >
> > > > > > Paul,
> > > > > >
> > > > > >
> > > > > > <<Thus, the V.21 terminal may transmit characters at a higher
> > > > > > rate than the receiving baudot terminal.>>
> > > > > > <<Has any language or procedures been discussed on flow control
> > > > > > to this point?>>
> > > > > >
> > > > > > I'm not sure what you understand under flow control for TTYs, as
> > > > > > they simply don't posses any at all. The way we solved them in
> > > > > > our gateway is to use a buffering mechanism, one for each end.
> > > > > > Size and throughput of the buffers on the gateway are
> > > > > > configurable. Because of the low max speed of the terminals, the
> > > > > > buffer doesn't have to be of large size to be able to deal with
> > > > > > it. Beyond that, there is nothing much one can do with things
> > > > > > like V.21 I'm afraid. But it does work like a charm.
> > > > > >
> > > > > > Guido
> > > > > >
> > > > > >
> > > > > >
> > > > > > Guido Gybels
> > > > > > Director of New Technologies
> > > > > >
> > > > > > RNID, 19-23 Featherstone Street
> > > > > > London EC1Y 8SL, UK
> > > > > > Tel +44(0)20-7294 3713
> > > > > > Fax +44(0)20-7296 8069
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > >
> > ************************************************************************
> > > > > > 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
> > > > > >
> > > >
> > ************************************************************************
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > >
> >
> >
> >




More information about the sg16-avd mailing list