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.
- 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.
- 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.
- 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@omnitor.se web: www.omnitor.se
-----Ursprungligt meddelande----- Från: Rajesh Kumar [mailto:rkumar@cisco.com] Skickat: den 20 juni 2003 02:14 Till: Gunnar Hellström Kopia: Paul E. Jones; Guido Gybels; keith.chu@mindspeed.com; James Hamlin; bpechey@cix.compulink.co.uk; Frank Shearar; Jamie Buchanan; Mike Spanner; cary.barbin@tap.gallaudet.edu; judy.harkins@tap.gallaudet.edu; gv@trace.wisc.edu; fred.lucas@worldnet.att.net; mgarakan@cisco.com; hwildfeu@cisco.com; mmostafa@cisco.com; rmahy@cisco.com; spear@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.))
- 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).
- 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).
- 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.
- 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.
- 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.
- 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.
- 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@omnitor.se web: www.omnitor.se
-----Ursprungligt meddelande----- Från: Paul E. Jones [mailto:paulej@packetizer.com] Skickat: den 18 juni 2003 05:30 Till: Gunnar Hellstrom; Guido Gybels; keith.chu@mindspeed.com; James Hamlin Kopia: rkumar@cisco.com; bpechey@cix.compulink.co.uk; Frank Shearar; Jamie Buchanan; Mike Spanner; cary.barbin@tap.gallaudet.edu; judy.harkins@tap.gallaudet.edu; gv@trace.wisc.edu; fred.lucas@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@omnitor.se To: "Guido Gybels" Guido.Gybels@rnid.org.uk;
paulej@packetizer.com; "James Hamlin" james.hamlin@rnid.org.uk Cc: rkumar@cisco.com; bpechey@cix.compulink.co.uk; "Frank Shearar" frank.shearar@rnid.org.uk; "Jamie Buchanan" jamie.buchanan@rnid.org.uk; "Mike Spanner" mike.spanner@rnid.org.uk; cary.barbin@tap.gallaudet.edu; judy.harkins@tap.gallaudet.edu; gv@trace.wisc.edu; fred.lucas@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@omnitor.se web: www.omnitor.se
-----Ursprungligt meddelande----- Fran: Guido Gybels [mailto:Guido.Gybels@rnid.org.uk] Skickat: den 17 juni 2003 09:04 Till: keith.chu@mindspeed.com; gunnar.hellstrom@omnitor.se; paulej@packetizer.com; James Hamlin Kopia: rkumar@cisco.com; bpechey@cix.compulink.co.uk;
Frank Shearar;
Jamie Buchanan; Mike Spanner; cary.barbin@tap.gallaudet.edu; judy.harkins@tap.gallaudet.edu; gv@trace.wisc.edu; fred.lucas@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
participants (1)
-
rkumar＠cisco.com