- sg16-avd - lists.packetizer.com

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

H.323 v5 consented
by okubo＠MXZ.MESH.NE.JP 13 Jun '03

13 Jun '03

Dear SG16 experts, I have placed the subject document at the following place: http://standard.pictel.com/ftp/avc-site/0305_Gen/h323V5consented.zip -- 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 taylor＠NORTELNETWORKS.COM 09 Jun '03

09 Jun '03

FYI. Blame the two-year publication interval on me. -------- Original Message -------- Subject: [Megaco] RFC 3525 on Gateway Control Protocol Version 1 Date: Mon, 09 Jun 2003 09:58:49 -0700 From: rfc-editor(a)rfc-editor.org To: IETF-Announce: ; CC: rfc-editor(a)rfc-editor.org, megaco(a)ietf.org A new Request for Comments is now available in online RFC libraries. RFC 3525 Title: Gateway Control Protocol Version 1 Author(s): C. Groves, M. Pantaleo, T. Anderson, T. Taylor, Editors Status: Standards Track Date: June 2003 Mailbox: Christian.Groves(a)ericsson.com.au, Marcello.Pantaleo(a)eed.ericsson.se, tlatla(a)verizon.net, taylor(a)nortelnetworks.com Pages: 213 Characters: 439674 Obsoletes: 3015 I-D Tag: draft-ietf-megaco-3015corr-03.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3525.txt This document defines the protocol used between elements of a physically decomposed multimedia gateway, i.e., a Media Gateway and a Media Gateway Controller. The protocol presented in this document meets the requirements for a media gateway control protocol as presented in RFC 2805. This document replaces RFC 3015. It is the result of continued cooperation between the IETF Megaco Working Group and ITU-T Study Group 16. It incorporates the original text of RFC 3015, modified by corrections and clarifications discussed on the Megaco E-mail list and incorporated into the Study Group 16 Implementor's Guide for Recommendation H.248. The present version of this document underwent ITU-T Last Call as Recommendation H.248 Amendment 1. Because of ITU-T renumbering, it was published by the ITU-T as Recommendation H.248.1 (03/2002), Gateway Control Protocol Version 1. Users of this specification are advised to consult the H.248 Sub-series Implementors' Guide at http://www.itu.int/itudoc/itu-t/com16/implgd for additional corrections and clarifications. This document is a product of the Media Gateway Control Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST(a)IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST(a)RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info(a)RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info(a)RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager(a)RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR(a)RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute

1 0

H.235v3 and H.245v10 consented
by okubo＠MXZ.MESH.NE.JP 09 Jun '03

09 Jun '03

Dear SG16 experts, The subject documents have been placed at the following site: http://standard.pictel.com/ftp/avc-site/0305_Gen/h235v3aap.zip http://standard.pictel.com/ftp/avc-site/0305_Gen/H245Version10-final.zip -- 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

None
by Jooheung Lee 09 Jun '03

09 Jun '03

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com

1 0