June 2003 - sg16-avd - lists.packetizer.com

FWMIME-Version: 1.0
by simao.campos＠ITU.INT 30 Jun '03

30 Jun '03

Dear colleagues For your information. Best regards, Simao -----Original Message----- From: Aaron Falk [mailto:falk@isi.edu] Sent: 27 June 2003 21:21 Subject: DCCP design review in Vienna The Datagram Congestion Control Protocol (DCCP) is holding a protocol design review at the Vienna IETF. DCCP is a new transport protocol offering congestion control to (largely multimedia) flows which do not require the reliability of TCP. The charter page is at [1]. More information on the motivation for the working group can be found at [2]. This working group is following an agressive schedule of about 18 months, hoping to publish the spec this November. The three specification documents draft-ietf-dccp-spec draft-ietf-dccp-ccid2 draft-ietf-dccp-ccid3 are fairly stable and we are nearing completion of an expert review of the documents. (There will be a revision of the drafts before the IETF to incorporate some of the expert reviewer comments. Links to current versions can always be found on the dccp charter page.) We are hoping that, by holding a design review at this time, we will surface issues which may reveal themselves to the larger IETF community. Interested folks -- particularly from potential user communities -- are invited to attend. --aaron (dccp wg chair) [1] http://www.ietf.org/html.charters/dccp-charter.html [2] http://www.ietf.org/internet-drafts/draft-ietf-dccp-problem-00.txt

1 0

FW: DCCP design review in Vienna
by simao.campos＠itu.int 30 Jun '03

30 Jun '03

Dear colleagues For your information. Best regards, Simao -----Original Message----- From: Aaron Falk [mailto:falk@isi.edu] Sent: 27 June 2003 21:21 Subject: DCCP design review in Vienna The Datagram Congestion Control Protocol (DCCP) is holding a protocol design review at the Vienna IETF. DCCP is a new transport protocol offering congestion control to (largely multimedia) flows which do not require the reliability of TCP. The charter page is at [1]. More information on the motivation for the working group can be found at [2]. This working group is following an agressive schedule of about 18 months, hoping to publish the spec this November. The three specification documents draft-ietf-dccp-spec draft-ietf-dccp-ccid2 draft-ietf-dccp-ccid3 are fairly stable and we are nearing completion of an expert review of the documents. (There will be a revision of the drafts before the IETF to incorporate some of the expert reviewer comments. Links to current versions can always be found on the dccp charter page.) We are hoping that, by holding a design review at this time, we will surface issues which may reveal themselves to the larger IETF community. Interested folks -- particularly from potential user communities -- are invited to attend. --aaron (dccp wg chair) [1] http://www.ietf.org/html.charters/dccp-charter.html [2] http://www.ietf.org/internet-drafts/draft-ietf-dccp-problem-00.txt

1 0

H.323 poster
by okubo＠MXZ.MESH.NE.JP 24 Jun '03

24 Jun '03

Dear SG16 experts, At the last month SG16 meeting, we discussed the opportunity to produce the subject poster as part of the ITU-T promotion. Here is a relevant record of the WP2 report. ---------- 3.1.10 Promotion activities in TD-11/PLEN WP2 will coordinate to produce the "H.323 poster." Mr. Paul Jones undertakes this coordination role. Volunteers are solicited, particularly those who are good at arts. We will try to produce a draft by the end of July 2003. ---------- This is to solicit volunteers to get this ITU-T poster done. Anyone who is willing to contribute is requested to get in touch with Mr. Paul Jones <paulej(a)packetizer.com>. One of the actions could be to collect similar posters from which we can get some hints. At the Bruges meeting one year ago, we received TIPHON T-shirt illustrating its architecture. Another could be to list strengths of H.323 by words. -- Best regards, OKUBO Sakae e-mail: sokubo(a)waseda.jp Visiting Professor Graduate School of Science and Engineering Waseda University ******************************************************************* YRP Office GITI, Waseda University YRP Ichibankan 312 Tel: +81 46 847 5406 3-4 Hikarinooka, Yokosuka-shi, Kanagawa-ken Fax: +81 46 847 5413 239-0847 Japan *******************************************************************

1 0

Access to avc-site - Correction
by okubo＠MXZ.MESH.NE.JP 22 Jun '03

22 Jun '03

Dear SG16 experts, Here are updates to the subject matter: Downloading <http://ftp3.itu.int/av-arch/avc-site/> or <ftp://avguest:Avguest@ftp3.itu.int/avc-site> <== corrected Please note that the setting of user: avguest, password: Avguest is needed for FTP access (but not for HTTP) Uploading <ftp://avguest:Avguest@ftp3.itu.int/avc-site/Incoming> <== corrected user: avguest, password: Avguest -- Best regards, OKUBO Sakae e-mail: sokubo(a)waseda.jp Visiting Professor Graduate School of Science and Engineering Waseda University ******************************************************************* YRP Office GITI, Waseda University YRP Ichibankan 312 Tel: +81 46 847 5406 3-4 Hikarinooka, Yokosuka-shi, Kanagawa-ken Fax: +81 46 847 5413 239-0847 Japan *******************************************************************

1 0

FwdMime-Version: 1.0
by okubo＠MXZ.MESH.NE.JP 22 Jun '03

22 Jun '03

*** FYI -- S Okubo *** > From: simao.campos(a)itu.int > To: garysull(a)microsoft.com, aluthra(a)motorola.com, > wiegand@hhi.de,probst-pa@bluewin.ch, > johnmagill@probecom.co.uk,Leonardo.Chiariglione@TILAB.COM > Cc: matsumoto(a)giti.waseda.ac.jp, okubo(a)giti.waseda.ac.jp > Subject: H.264 is available as pre-published text in the ITU-T web > site. > Date: Fri, 20 Jun 2003 10:24:05 +0200 > X-OriginalArrivalTime: 20 Jun 2003 08:24:07.0863 (UTC) FILETIME= > [51865C70:01C33705] > X-Biglobe-VirusCheck: Fri, 20 Jun 2003 17:24:20 +0900 > > Gentlemen > > This is to inform that H.264 is available as a pre-published > Recommendation from the ITU-T Web site as of yesterday. Further, as > a formal step, the approval of H.264 at the SG Plenary on 30 May > 2003 will be announced to the ITU-T membership in TSB Circular > Letter 170, that will probably go out today. > > The text has been sent now for translation and processing for > publication. As this is a fairly complex text, we will certainly be > contacting Gary, Thomas and Ajay for editorial questions. > > Best regards, and again many kudos for the astounding work > accomplished. > > Cheers, > Simao

1 0

ReMime-Version: 1.0
by rkumar＠cisco.com 20 Jun '03

20 Jun '03

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(a)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(a)mindspeed.com; James > > Hamlin; bpechey(a)cix.compulink.co.uk; Frank Shearar; Jamie Buchanan; Mike > > Spanner; cary.barbin(a)tap.gallaudet.edu; judy.harkins(a)tap.gallaudet.edu; > > gv(a)trace.wisc.edu; fred.lucas(a)worldnet.att.net; mgarakan(a)cisco.com; > > hwildfeu(a)cisco.com; mmostafa(a)cisco.com; rmahy(a)cisco.com; > > spear(a)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(a)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(a)mindspeed.com; James > > > > Hamlin > > > > Kopia: rkumar(a)cisco.com; bpechey(a)cix.compulink.co.uk; Frank Shearar; > > > > Jamie Buchanan; Mike Spanner; cary.barbin(a)tap.gallaudet.edu; > > > > judy.harkins(a)tap.gallaudet.edu; gv(a)trace.wisc.edu; > > > > fred.lucas(a)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(a)omnitor.se> > > > > To: "Guido Gybels" <Guido.Gybels(a)rnid.org.uk>; > > <keith.chu(a)mindspeed.com>; > > > > <paulej(a)packetizer.com>; "James Hamlin" <james.hamlin(a)rnid.org.uk> > > > > Cc: <rkumar(a)cisco.com>; <bpechey(a)cix.compulink.co.uk>; "Frank Shearar" > > > > <frank.shearar(a)rnid.org.uk>; "Jamie Buchanan" > > > > <jamie.buchanan(a)rnid.org.uk>; > > > > "Mike Spanner" <mike.spanner(a)rnid.org.uk>; > > > > <cary.barbin(a)tap.gallaudet.edu>; > > > > <judy.harkins(a)tap.gallaudet.edu>; <gv(a)trace.wisc.edu>; > > > > <fred.lucas(a)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(a)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(a)mindspeed.com; gunnar.hellstrom(a)omnitor.se; > > > > > > paulej(a)packetizer.com; James Hamlin > > > > > > Kopia: rkumar(a)cisco.com; bpechey(a)cix.compulink.co.uk; > > Frank Shearar; > > > > > > Jamie Buchanan; Mike Spanner; cary.barbin(a)tap.gallaudet.edu; > > > > > > judy.harkins(a)tap.gallaudet.edu; gv(a)trace.wisc.edu; > > > > > > fred.lucas(a)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 > > > > > > > > > > > > ************************************************************************ > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >

1 0

Re: SV: SV: Text Speed in IP networks
by Rajesh Kumar 20 Jun '03

20 Jun '03

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(a)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(a)mindspeed.com; James > > Hamlin; bpechey(a)cix.compulink.co.uk; Frank Shearar; Jamie Buchanan; Mike > > Spanner; cary.barbin(a)tap.gallaudet.edu; judy.harkins(a)tap.gallaudet.edu; > > gv(a)trace.wisc.edu; fred.lucas(a)worldnet.att.net; mgarakan(a)cisco.com; > > hwildfeu(a)cisco.com; mmostafa(a)cisco.com; rmahy(a)cisco.com; > > spear(a)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(a)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(a)mindspeed.com; James > > > > Hamlin > > > > Kopia: rkumar(a)cisco.com; bpechey(a)cix.compulink.co.uk; Frank Shearar; > > > > Jamie Buchanan; Mike Spanner; cary.barbin(a)tap.gallaudet.edu; > > > > judy.harkins(a)tap.gallaudet.edu; gv(a)trace.wisc.edu; > > > > fred.lucas(a)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(a)omnitor.se> > > > > To: "Guido Gybels" <Guido.Gybels(a)rnid.org.uk>; > > <keith.chu(a)mindspeed.com>; > > > > <paulej(a)packetizer.com>; "James Hamlin" <james.hamlin(a)rnid.org.uk> > > > > Cc: <rkumar(a)cisco.com>; <bpechey(a)cix.compulink.co.uk>; "Frank Shearar" > > > > <frank.shearar(a)rnid.org.uk>; "Jamie Buchanan" > > > > <jamie.buchanan(a)rnid.org.uk>; > > > > "Mike Spanner" <mike.spanner(a)rnid.org.uk>; > > > > <cary.barbin(a)tap.gallaudet.edu>; > > > > <judy.harkins(a)tap.gallaudet.edu>; <gv(a)trace.wisc.edu>; > > > > <fred.lucas(a)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(a)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(a)mindspeed.com; gunnar.hellstrom(a)omnitor.se; > > > > > > paulej(a)packetizer.com; James Hamlin > > > > > > Kopia: rkumar(a)cisco.com; bpechey(a)cix.compulink.co.uk; > > Frank Shearar; > > > > > > Jamie Buchanan; Mike Spanner; cary.barbin(a)tap.gallaudet.edu; > > > > > > judy.harkins(a)tap.gallaudet.edu; gv(a)trace.wisc.edu; > > > > > > fred.lucas(a)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 > > > > > > > > > > > > ************************************************************************ > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >

1 0

This mailinglist
by okubo＠MXZ.MESH.NE.JP 20 Jun '03

20 Jun '03

Dear SG16 experts, This mailinglist has been operating stably since May, but has a known problem of not being able to handle MIME messages as you saw in recent Mr. Boyle's posting. It also means that file attachment in your posting does not work. Please post your message in plain text until further advice is given. If you need to distribute a file, please consider the use of ftp site <ftp://avguest:Avguest@ftp3.itu.int/avc-site/Incoming>. Please also note that the previous mailinglist provided by Intel will soon be closed. -- Best regards, OKUBO Sakae e-mail: sokubo(a)waseda.jp Visiting Professor Graduate School of Science and Engineering Waseda University ******************************************************************* YRP Office GITI, Waseda University YRP Ichibankan 312 Tel: +81 46 847 5406 3-4 Hikarinooka, Yokosuka-shi, Kanagawa-ken Fax: +81 46 847 5413 239-0847 Japan *******************************************************************

1 0

FWMIME-Version: 1.0
by kboyle＠NORTELNETWORKS.COM 19 Jun '03

19 Jun '03

This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C33696.6C6EFA34 Content-Type: text/plain FYI for those of you who were interested in the H.460 Annex B work. Kevin -----Original Message----- From: The IESG [mailto:iesg-secretary@ietf.org] Sent: Thursday, June 19, 2003 2:41 PM To: IETF-Announce Cc: avt(a)ietf.org Subject: Last Call: RTP Control Protocol Extended Reports (RTCP XR) to a Proposed Standard --------------- The IESG has received a request from Audio/Video Transport WG to consider the following Internet-Draft(s) as a Proposed Standard. o Audio/Video Transport (AVT): RTP Control Protocol Extended Reports (RTCP XR) <draft-ietf-avt-rtcp-report-extns-06.txt> Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg(a)ietf.org or ietf(a)ietf.org mailing lists by 2003-07-03. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-avt-rtcp-report-extns-06.txt ------_=_NextPart_001_01C33696.6C6EFA34 Content-Type: text/html Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML> <HEAD> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; = charset=3Dus-ascii"> <META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version = 5.5.2656.31"> <TITLE>FW: Last Call: RTP Control Protocol Extended Reports (RTCP XR) = to a Proposed Standard </TITLE> </HEAD> <BODY> FYI for those of you who were interested in the H.460 = Annex B work. Kevin -----Original Message----- From: The IESG [<A = HREF=3D"mailto:iesg-secretary@ietf.org">mailto:iesg-secretary@ietf.org</= A>] Sent: Thursday, June 19, 2003 2:41 PM To: IETF-Announce Cc: avt(a)ietf.org Subject: Last Call: RTP Control Protocol Extended = Reports (RTCP XR) to a Proposed Standard --------------- The IESG has received a request from Audio/Video = Transport WG to consider the following Internet-Draft(s) as a Proposed = Standard. o Audio/Video Transport (AVT): RTP Control Protocol = Extended Reports   (RTCP XR)     = <draft-ietf-avt-rtcp-report-extns-06.txt>     Proposed Standard           &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;    The IESG plans to make a decision in the next few = weeks, and solicits final comments on this action.  Please send = any comments to the iesg(a)ietf.org or ietf(a)ietf.org mailing lists by = 2003-07-03.           &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;    Files can be obtained via <A = HREF=3D"http://www.ietf.org/internet-drafts/draft-ietf-avt-rtcp-report-e= xtns-06.txt" = TARGET=3D"_blank">http://www.ietf.org/internet-drafts/draft-ietf-avt-rtc= p-report-extns-06.txt</A> </BODY> </HTML> ------_=_NextPart_001_01C33696.6C6EFA34-- -------

1 0

Transfer of avc-site
by okubo＠mxz.mesh.ne.jp 17 Jun '03

17 Jun '03

Dear SG16 experts, As decided at the October 2002 meeting of SG16, the subject FTP site for system experts is in the process of moving from PictureTel (now Polycom) to ITU. All of the files in <http://standard.pictel.com/ftp/avc-site/> are also available at the following place: <http://ftp3.itu.int/av-arch/avc-site/> or <ftp://avguest:Avguest@ftp3.itu.int/av-arch/avc-site> Please note that the setting of user: avguest, password: Avguest is needed for FTP access (but not for HTTP) For uploading your document, please drop it at <ftp://avguest:Avguest@ftp3.itu.int/av-arch/avc-site/Incoming> user: avguest, password: Avguest and advise S Okubo <sokubo(a)waseda.jp> or P Jones <paulej(a)packetizer.com>, otherwise post your message at the mailinglist <itu-sg16(a)external.cisco.com>. Please advise the above persons of any problem you would find. Both of the FTP sites will be running for a week or two, then the PictureTel FTP site will be discontinued. Using this opportunity, I would like to thank Polycom (PcitureTel) for its support of this essential tool for the system standardization in ITU-T SG16 since early 1998, particularly Messrs. Bob Weber, Patrick Luthi, David Lindbergh, Martin Jacobsen and others who have administered the avc-site. -- Best regards, OKUBO Sakae e-mail: sokubo(a)waseda.jp Visiting Professor Graduate School of Science and Engineering Waseda University ******************************************************************* YRP Office GITI, Waseda University YRP Ichibankan 312 Tel: +81 46 847 5406 3-4 Hikarinooka, Yokosuka-shi, Kanagawa-ken Fax: +81 46 847 5413 239-0847 Japan *******************************************************************

1 0