*** 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=
> […
[View More]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
[View Less]
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 …
[View More]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
> > > > > >
> > > >
> > ************************************************************************
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > >
> >
> >
> >
[View Less]
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 …
[View More]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
> > > > > >
> > > >
> > ************************************************************************
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > >
> >
> >
> >
[View Less]
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 …
[View More]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
*******************************************************************
[View Less]
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) …
[View More]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>
<P><FONT SIZE=3D2>FYI for those of you who were interested in the H.460 =
Annex B work.</FONT>
</P>
<P><FONT SIZE=3D2>Kevin</FONT>
</P>
<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: The IESG [<A =
HREF=3D"mailto:iesg-secretary@ietf.org">mailto:iesg-secretary@ietf.org</=
A>] </FONT>
<BR><FONT SIZE=3D2>Sent: Thursday, June 19, 2003 2:41 PM</FONT>
<BR><FONT SIZE=3D2>To: IETF-Announce </FONT>
<BR><FONT SIZE=3D2>Cc: avt(a)ietf.org</FONT>
<BR><FONT SIZE=3D2>Subject: Last Call: RTP Control Protocol Extended =
Reports (RTCP XR) to a Proposed Standard </FONT>
</P>
<BR>
<P><FONT SIZE=3D2>---------------</FONT>
<BR><FONT SIZE=3D2>The IESG has received a request from Audio/Video =
Transport WG to consider </FONT>
<BR><FONT SIZE=3D2>the following Internet-Draft(s) as a Proposed =
Standard. </FONT>
<BR><FONT SIZE=3D2>o Audio/Video Transport (AVT): RTP Control Protocol =
Extended Reports </FONT>
<BR><FONT SIZE=3D2> (RTCP XR) </FONT>
<BR><FONT SIZE=3D2> =
<draft-ietf-avt-rtcp-report-extns-06.txt></FONT>
<BR><FONT SIZE=3D2> Proposed Standard</FONT>
<BR><FONT =
SIZE=3D2> &nb=
sp; &nb=
sp; &nb=
sp; &nb=
sp; &nb=
sp; &nb=
sp; &nb=
sp; </FONT>
</P>
<P><FONT SIZE=3D2>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.</FONT></P>
<P><FONT =
SIZE=3D2> &nb=
sp; &nb=
sp; &nb=
sp; &nb=
sp; &nb=
sp; &nb=
sp; &nb=
sp; </FONT>
<BR><FONT SIZE=3D2>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></FONT>
</P>
</BODY>
</HTML>
------_=_NextPart_001_01C33696.6C6EFA34--
-------
[View Less]
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 …
[View More]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
*******************************************************************
[View Less]
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, …
[View More]Kanagawa-ken Fax: +81 46 847 5413
239-0847 Japan
*******************************************************************
[View Less]
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. …
[View More]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
[View Less]
Dear SG16 experts,
The subject documents have been placed at the following site:
http://standard.pictel.com/ftp/avc-site/0305_Gen/h235v3aap.ziphttp://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 …
[View More] Tel: +81 46 847 5406
3-4 Hikarinooka, Yokosuka-shi, Kanagawa-ken Fax: +81 46 847 5413
239-0847 Japan
*******************************************************************
[View Less]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)lists.intel.com
