- sg16-avd - lists.packetizer.com

Re: [H.323 Annex H Mobility] Clarification Request
by Roy, Radhika R, ALARC 22 Feb '00

22 Feb '00

Hi, Nicolas and Jaakko: We agreed that the "location area" will not be included. So, any reference to the location area shall be removed. With repsect to TMSI, LMTI, MSRN, I guess, both Lucent's and AT&T's (+ Motorola's in Red Bank) contributions have proposed new aliases. For example, H.323 uses alias like E.164, name, URL, email, network addresses (e.g., IP, ATM) etc. Similarly, the aliases like TMSI, LMSI, MSRN, and others can also be used. Please note that aliases are the abstraction in the H.323 layer. In H.246 Annex E, we have also seen why UMI needs to be added as another alias in H.323. From that point of view, we do not see any problems. We also like to see comments of other members on this topic. However, we like to see whether this abstraction of TMSI, LMTI, and MSRN in the H.323 layer causes any problems in the radio link layer. If it is so, we will definitely consider NOT to use those aliases in H.323. Nicholas - Is it possible to justify how the abstraction of TMSI, LMTI, and MSRN is cusing a problem in the radio link layer? May be a contribution will be helpful to explain this. We feel that it will rather be helpful as we have seen in the case of H.246 Annex E. Best regards, Radhika R. Roy > -----Original Message----- > From: Nicolas Tran [SMTP:Nicolas.Tran@ALCATEL.FR] > Sent: Tuesday, February 22, 2000 9:38 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: [H.323 Annex H Mobility] Clarification Request > > Hi Jaakko, > I took a little bit of time to go through the TD 2-129 "H.323 Annex > Mobility", and I have the following comments about the section 6.2.2 > "Visitor Location Function (VLF)" > I am astonished to see that the Location Area is listed as one of the > elements of the VLF database because it had been agreed while discussing > the Alcatel contribution that the Location Area is NOT a concept to be > handled by H323 mobility. > although the whole text proposed by the Alcatel contribution has not > been accepted, the principles of this contribution (that proposes the > independance between the lower layer and H.323 Multimedia system) has been > agreed .Hence the Visitor Location > Function (VLF) section should not contain elements such as TMSI, LMTI, > MSRN corresponding to the radio concept. > > Perhaps, would it be suitable, as requested to Alcatel for the > registration section of his contribution, to provide message sequence > charts explaining why the VLF should handle such TMSI, LMTI, MSRN > entities. > > Thanks a lot, > Nicolas.

1 0

Registered payload types for G.723.1/G.729
by Frank Derks 22 Feb '00

22 Feb '00

H.225.0 specifies that the payload types for G.723.1 and G.729 are 4 and 18 respectively. When I take a look at the registered payload types at the IANA, these two codecs are not listed. Does this mean that the IANA list is not up-to-date or that these codecs are not officially registered. Frank ----------------------------------------------------- Frank Derks |Tel +31 35 6893238 | Advanced Development |Fax +31 35 6891030 | Philips Business Communications|P.O. Box 32 | |1200 JD Hilversum | |The Netherlands | ----------------------------------------------------| E-mail: mailto:frank.derks@philips.com | WWW: http://www.sopho.philips.com | -----------------------------------------------------

1 0

[H.323 Annex H Mobility] Clarification Request
by Nicolas Tran 22 Feb '00

22 Feb '00

Hi Jaakko, I took a little bit of time to go through the TD 2-129 "H.323 Annex Mobility", and I have the following comments about the section 6.2.2 "Visitor Location Function (VLF)" I am astonished to see that the Location Area is listed as one of the elements of the VLF database because it had been agreed while discussing the Alcatel contribution that the Location Area is NOT a concept to be handled by H323 mobility. although the whole text proposed by the Alcatel contribution has not been accepted, the principles of this contribution (that proposes the independance between the lower layer and H.323 Multimedia system) has been agreed .Hence the Visitor Location Function (VLF) section should not contain elements such as TMSI, LMTI, MSRN corresponding to the radio concept. Perhaps, would it be suitable, as requested to Alcatel for the registration section of his contribution, to provide message sequence charts explaining why the VLF should handle such TMSI, LMTI, MSRN entities. Thanks a lot, Nicolas.

1 0

Re: H.323 Annex N draft
by Roy, Radhika R, ALARC 22 Feb '00

22 Feb '00

Hi, Mike: Yes, H.323 QOS will operate independent of the transport mechanisms. That is why, we all brought contributions in the first palce and all our efforts have been made to fulfill that goal. Acordingly, we have created new terminology that is known as H.323 appliction layer QOS. We have define how H.323 QOS works indpendent of any transport mechnaims on end-to-end basis. We have also defined how end-to-end H.323 QOS is signaled vis RAS during the pre-call setup time to discover what kind of QOS classes or parameters are available in a given zone or in different zones with the help of the GKs. However, a given H.323 QOS class can be chosen by an endpoint to setup (Q.931/932) the call. This may also trigger H.245 OLCs to go for the media for which QOS will be provided to convert the astraction of H.323 QOS to the corresponding network layer QOS (where mapping is needed). Mr. Bowen edited TD-57 WP2/16 accordingly based on the contributions that were accepted in the last Red Bank meeting (Oct'99). The agreement reached in the last SG16 meeting is as follows [TD-74 (plen) p-20]: D.472(2/16) [Ericsson] - Generic QoS bearer for IP and ATM A general method of discussing QoS was presented. This is believed to be more appropriate to IP than the method of TD57, which was viewed as being too ATM-centric. Support was expressed for the idea that TD-57 is too ATM-centric. It was noted that the ATM Forum terminology is used rather than the ITU-T forum QoS terminology. It was agreed that this contribution should be reflected in future versions TD57. TD57(2/16) [Rapp.] - QoS Architecture and Supporting Protocol It was noted that there appear to be a conflict between point 1(3) from APC-1705 and xxx accepted at this meeting. It was agreed that : 1)This is not ready for determination 2)The H.323 material will go in a new Annex N "QoS in H.323 Systems and Networks." 3)It will be determined no earlier than Nov 2000, and more likely in 2001. 4)Liaisons need to be sent to: a)IETF b)TIPHON c)ATM Forum d)SG13 4)3GPP 5)3GPP2 5)Mr. Bowen will update Annex N to reflect D.472, and it will be attached to the liaisons. 6)Mr. Buckley will write the liaison. This liasion will solict specific input against the draft Annex N. 7)Going forward, Mr. Buckley will edit Annex N. He is also chair of the TIPHON QoS working group. TD5(2/16) is related. It was noted that this work seems very similar to the approach of 3GPP and TIPHON. D.451(2/16) reports on QoS work in TIPHON. It covers such advanced topics as allocating QoS budget between multiple carriers. Therefore, the scope provided in your edited document does NOT reflect the agreement. Moreover, the backward compatibility requirement will also mandate the mapping of H.323 QOS over RSVP (Guaranteed, Controlled, Best effort) and ATM QOS (CBR, rt-VBR, nrt-VBR, ABR, UBR). For example, once an H.323 QOS is agreed on end-to-end basis, an endpoint may use RSVP to implement the H.323 QOS over the transport network. Therefore, it mandates that H.323 QOS MUST be mapped to provide the backward comapatibility. Similar is the case for the ATM QOS. Hope that this clarify that the H.323 QOS mapping over the transport network is a requirement and the scope MUST reflect this. However, you are welcome to bring contributions to justify your case in the next OSAKA meeting (May'00) and we will definitely discuss it. I also plan to provide comments for other part of the document later. Best regards, Radhika R. Roy > -----Original Message----- > From: Mike Buckley [SMTP:mikebuckley@ATTMAIL.COM] > Sent: Monday, February 21, 2000 8:06 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: H.323 Annex N draft > > Hi Radhika, > > Thanks for your quick comments. > > The agreement last week was that the H.323 mechanisms should operate > independently of transport mechanism. This is included in the > requirements. So > all the mechanisms you list are included. > > The backward compatibility is an important issue and one we should discuss > carefully as to its implications. In principle I agree with you, backward > compatibility with existing H.323 mechanisms should be an important > factor. I > am not yet sure yet what the implications of this are in the QoS area. > > Mike > > ____________________ Begin Original Message > ___________________________ > Date: Mon Feb 21 17:56:43 -0500 2000 > From: internet!ATT.COM!rrroy (Roy, Radhika R, ALARC) > Subject: Re: H.323 Annex N draft > To: internet!MAILBAG.INTEL.COM!ITU-SG16 > Content-Type: Text > Content-Length: 2192 > > Hi, Mike and All: > > I did not have the time go through the whole document yet. However, a > quick > look into the document provides me to point out about the scope as > follows: > > 1. The contributions were provided for mapping of H.323 QOS over the > network > layer QOS. For example, IETF's DiffServ, IntServ/RSVP, and MPLS, and ATM > QOS > classes: CBR, VBR, rt-VBR, nrt-VRB, and ABR. Those contributions were > accepted in the last Red Bank (Oct'99) meeting. Accordingly, the then > editor > Rich Bowen produced the TD in the last SG16 meeting. > > So, the scope of H.323 QOS mapping over the network layer QOS (IP, ATM) > shall be there. > > However, if you have any disagreement over the decision made in the last > Red > Bank meeting, please submit a contribution in the upcoming OSAKA meeting > (May'00), we can discuss. Until the decision is made based on > contributions, > the scope of the document shall remain the same as submitted by Mr. Rich > Bowen. > > 2. So far the backward compatibility is concerned, it shall not only > consider Appendix II, but it shall also consider ATM QOS provided in H.323 > Annex C. Accordingly, both backward compatibilities should be included as > per norm of the ITU standards. > > BTW, if you would keep the text the way I suggested, I would think that I > did not have to provide my comments as stated above. > > Best regards, > Radhika R. Roy, AT&T > > PS: I am yet to finish reading the whole document. Hope to provide more > comments later. > > > -----Original Message----- > > From: Mike Buckley [SMTP:mikebuckley@ATTMAIL.COM] > > Sent: Monday, February 21, 2000 2:31 PM > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > Subject: H.323 Annex N draft > > > > Attached is the first draft of the new Annex N of H.323. This was > issued > > at last > > week's meeting as TD126 of WP2 but the attached version includes some > > further > > minor revisions and additions of informational material (in the > > Appendices) which > > needs further review in the light of the adoption of the generic QoS > > bearer > > descriptor. > > > > Comments and contributions welcome. > > > > Mike Buckley (editor) > > mikebuckley(a)44comms.com > > +44-1457-877718 (T) > > +44-1457-877721 (F) << File: [No Description] >>

1 0

Re: Annex E
by Reddy, Paul K 22 Feb '00

22 Feb '00

Hi Jane, Please see the following URLs for latest H.246 Annex E determined documents at SG16 WP2 meetings from Feb 7, 2000 to Feb 18,2000 in Geneva, Switzerland: Document1: H.246 Annex E - Terms of reference file: pl-44.doc http://standard.pictel.com/ftp/avc-site/Incoming/pl-44.doc Document2: H.246 Annex E - Main document : pl-41.doc http://standard.pictel.com/ftp/avc-site/Incoming/pl-41.doc Please send any contributions on H.246 Annex E Mobility work to Paul K. Reddy, Editor of H.246 Annex E at paul.k.reddy(a)intel.com. regards, Paul Paul K. Reddy Intel Corporation Mailto:paul.k.reddy@intel.com Office Phone: +1.503.264.9896 Mobile Phone:+1.503.807.9564 -----Original Message----- From: Jane Hua [mailto:huajane@YAHOO.COM] Sent: Monday, February 21, 2000 10:24 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Annex E Hi All, Can anybody please provide me the latest version of Annex E of H.323? TIA and best regards, Jane __________________________________________________ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com

1 0

Re: Please upload the decided/determined/approved texts
by Reddy, Paul K 22 Feb '00

22 Feb '00

Hello Everybody, I have uploaded H.246 Annex E determined documents into the Incoming directory of standard.pictel.com Document1: H.246 Annex E - Terms of reference file: pl-44.doc http://standard.pictel.com/ftp/avc-site/Incoming/pl-44.doc Document2: H.246 Annex E - Main document : pl-41.doc http://standard.pictel.com/ftp/avc-site/Incoming/pl-41.doc Please send your contributions on H.246 Annex E Mobility work to Paul K. Reddy, Editor of H.246 Annex E at paul.k.reddy(a)intel.com. I will work with Mr. Paul Guram,from Motorola, Mobility Ad Hoc group chair to announce the Mobility work conference call information on this reflector to review and discuss the contributions on H.246 Annex E, H.323 Annex H and H.323 Annex I Mobility work in H.323 networks. Regards, Paul Paul K. Reddy Intel Corporation Mailto:paul.k.reddy@intel.com Office Phone: +1.503.264.9896 Mobile Phone:+1.503.807.9564 > -----Ursprüngliche Nachricht----- > Von: Sakae OKUBO [SMTP:sakae.okubo@TIES.ITU.INT] > Gesendet am: Freitag, 18. Februar 2000 18:34 > An: ITU-SG16(a)mailbag.cps.intel.com > Betreff: Please upload the decided/determined/approved texts > > Dear Editors, > > Could you please upload your documents of decision, determination or > approval at the /Incoming of the PictureTel ftp site? Please make an > announce through the reflector when you have uploaded your documents. > > Best regards, > > Sakae OKUBO > *********************************************************** > Waseda Research Center > Telecommunications Advancement Organization of Japan (TAO) > 5th Floor, Nishi-Waseda Bldg. > 1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo > 169-0051 Japan > Tel: +81 3 5286 3830 (to be transferred) > +81 3 3204 8194 (direct) > Fax: +81 3 5287 7287 > e-mail: okubo(a)giti.or.jp > ***********************************************************

1 0

Annex E
by Jane Hua 22 Feb '00

22 Feb '00

Hi All, Can anybody please provide me the latest version of Annex E of H.323? TIA and best regards, Jane __________________________________________________ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com

2 1

AW: Please upload the decided/determined/approved texts
by Karl.Klaghofer＠ICN.SIEMENS.DE 22 Feb '00

22 Feb '00

H.450.9 as determined in Geneva has been uploaded to the Incoming directory of standard.pictel.com. Regards, Karl Klaghofer, Siemens AG > -----Ursprüngliche Nachricht----- > Von: Sakae OKUBO [SMTP:sakae.okubo@TIES.ITU.INT] > Gesendet am: Freitag, 18. Februar 2000 18:34 > An: ITU-SG16(a)mailbag.cps.intel.com > Betreff: Please upload the decided/determined/approved texts > > Dear Editors, > > Could you please upload your documents of decision, determination or > approval at the /Incoming of the PictureTel ftp site? Please make an > announce through the reflector when you have uploaded your documents. > > Best regards, > > Sakae OKUBO > *********************************************************** > Waseda Research Center > Telecommunications Advancement Organization of Japan (TAO) > 5th Floor, Nishi-Waseda Bldg. > 1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo > 169-0051 Japan > Tel: +81 3 5286 3830 (to be transferred) > +81 3 3204 8194 (direct) > Fax: +81 3 5287 7287 > e-mail: okubo(a)giti.or.jp > ***********************************************************

1 0

Report of WP2/16
by Sakae OKUBO 22 Feb '00

22 Feb '00

Dear Q12-14/16 experts, A provisional report of WP2/16 has been uploaded to /incoming as follows: wp2_report_000218.zip TD74/plen REPORT PART I GENERAL TD64/plen REPORT PART II A1 DRAFT REVISED AND NEW RECOMMENDATIONS TD65/plen PART IIB TD84/plen LIAISON STATEMENTS TD82/plen TD96/plen TD87/plen PLANNED RAPPORTEUR MEETINGS TD28/plne STATUS REPORT FOR RECOMMENDATIONS OF WP2/16 This will be replaced with the final version which Mr. Tosco is producing. Please note this and other documents will soon be moved to ftp://standard.pictel.com/avc-site/0002_Gen/ or http://standard.pictel.com/ftp/avc-site/0002_Gen/ and the index is given by 0002_Gen.html there. Best regards, Sakae OKUBO *********************************************************** Waseda Research Center Telecommunications Advancement Organization of Japan (TAO) 5th Floor, Nishi-Waseda Bldg. 1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan Tel: +81 3 5286 3830 (to be transferred) +81 3 3204 8194 (direct) Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp ***********************************************************

1 0

Re: Please upload the decided/determined/approved texts
by Sakae OKUBO 21 Feb '00

21 Feb '00

Dear Q12-14/16 experts, On behalf of H.323 Editor (P Jones), H.225.0 Editor (R Bowen) and H.222.0 Editor (myself), I have uploaded the following files to /Incoming: H2220AMD7_final.zip Amendment 7 to H.222.0, decided H2250V4_det_0002.zip H.225.0 V4, determined H323V3_IG_0002.zip H.323 V3 Implementor's Guide, approved H323V4_det_0002.zip H.323 V4, determined H323_AnnexD_det_0002.zip Annex D to H.323, determined TD-20_plen.zip Delta of Amd 7 to H.222.0 relative to the white They will soon be moved to /0002_Gen. Best regards, Sakae OKUBO *********************************************************** Waseda Research Center Telecommunications Advancement Organization of Japan (TAO) 5th Floor, Nishi-Waseda Bldg. 1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan Tel: +81 3 5286 3830 (to be transferred) +81 3 3204 8194 (direct) Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp ***********************************************************

1 0

Re: H.323 Annex N draft
by Roy, Radhika R, ALARC 21 Feb '00

21 Feb '00

Hi, Mike and All: I did not have the time go through the whole document yet. However, a quick look into the document provides me to point out about the scope as follows: 1. The contributions were provided for mapping of H.323 QOS over the network layer QOS. For example, IETF's DiffServ, IntServ/RSVP, and MPLS, and ATM QOS classes: CBR, VBR, rt-VBR, nrt-VRB, and ABR. Those contributions were accepted in the last Red Bank (Oct'99) meeting. Accordingly, the then editor Rich Bowen produced the TD in the last SG16 meeting. So, the scope of H.323 QOS mapping over the network layer QOS (IP, ATM) shall be there. However, if you have any disagreement over the decision made in the last Red Bank meeting, please submit a contribution in the upcoming OSAKA meeting (May'00), we can discuss. Until the decision is made based on contributions, the scope of the document shall remain the same as submitted by Mr. Rich Bowen. 2. So far the backward compatibility is concerned, it shall not only consider Appendix II, but it shall also consider ATM QOS provided in H.323 Annex C. Accordingly, both backward compatibilities should be included as per norm of the ITU standards. BTW, if you would keep the text the way I suggested, I would think that I did not have to provide my comments as stated above. Best regards, Radhika R. Roy, AT&T PS: I am yet to finish reading the whole document. Hope to provide more comments later. > -----Original Message----- > From: Mike Buckley [SMTP:mikebuckley@ATTMAIL.COM] > Sent: Monday, February 21, 2000 2:31 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: H.323 Annex N draft > > Attached is the first draft of the new Annex N of H.323. This was issued > at last > week's meeting as TD126 of WP2 but the attached version includes some > further > minor revisions and additions of informational material (in the > Appendices) which > needs further review in the light of the adoption of the generic QoS > bearer > descriptor. > > Comments and contributions welcome. > > Mike Buckley (editor) > mikebuckley(a)44comms.com > +44-1457-877718 (T) > +44-1457-877721 (F) << File: [No Description] >>

2 1

H.323 Annex N draft
by Mike Buckley 21 Feb '00

21 Feb '00

Attached is the first draft of the new Annex N of H.323. This was issued at last week's meeting as TD126 of WP2 but the attached version includes some further minor revisions and additions of informational material (in the Appendices) which needs further review in the light of the adoption of the generic QoS bearer descriptor. Comments and contributions welcome. Mike Buckley (editor) mikebuckley(a)44comms.com +44-1457-877718 (T) +44-1457-877721 (F)

1 0

Re: Please upload the decided/determined/approved texts
by Euchner Martin 21 Feb '00

21 Feb '00

as requested I've uploaded the determined, changed marked versions of H.235v2 and of H.323 Annex J to the Incoming directory. ftp://standard.pictel.com/avc-site/Incoming/H0235Ev2r3_determined.zip <ftp://standard.pictel.com/avc-site/Incoming/H0235Ev2r3_determined.zip> ftp://standard.pictel.com/avc-site/Incoming/H323AnnexJr3_determined.zip <ftp://standard.pictel.com/avc-site/Incoming/H323AnnexJr3_determined.zip> Kind regards, Martin Euchner. ----------------------------------------------------------------------- | Dipl.-Inf. Phone: +49 89 636-46201 | Martin Euchner Fax : +49 89 636-48000 | Siemens AG | ZT IK 3 mailto:Martin.Euchner@mchp.siemens.de | Intranet: http://zt-security.mchp.siemens.de/de/Competence/Standardization/ITU-T_SG16/ index.html | Otto-Hahn-Ring 6 Internet: http://www.siemens.de | D-81730 Muenchen | __________________ | Germany ----------------------------------------------------------------------- -----Original Message----- From: Sakae OKUBO [SMTP:sakae.okubo@TIES.ITU.INT] Sent: Friday, February 18, 2000 6:34 PM To: ITU-SG16(a)mailbag.cps.intel.com Subject: Please upload the decided/determined/approved texts Dear Editors, Could you please upload your documents of decision, determination or approval at the /Incoming of the PictureTel ftp site? Please make an announce through the reflector when you have uploaded your documents. Best regards, Sakae OKUBO *********************************************************** Waseda Research Center Telecommunications Advancement Organization of Japan (TAO) 5th Floor, Nishi-Waseda Bldg. 1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan Tel: +81 3 5286 3830 (to be transferred) +81 3 3204 8194 (direct) Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp ***********************************************************

1 0

Re: Please upload the decided/determined/approved texts : H.245
by Mike Nilsson 21 Feb '00

21 Feb '00

I have uploaded the file H245_L.zip This contains the following files relating to H.245 Version 6. H245NCML.doc : Clean copy of version 6 H245WCML.doc : Full version with changes shown relative to version 6. H245DELL.doc : Cut-down version with changes shown relative to version 6. WhiteToVersion6WCM.doc : Full version with changes shown relative to the white paper. WhiteToVersion6DEL.doc : Cut-down version with changes shown relative to the white paper. Best regards Mike Nilsson ********************************************************************** * Mike Nilsson Tel: +44 1473 645413 * * Applications Technology Group Fax: +44 1473 645011 * * Internet and Multimedia Applications Email: mike.nilsson(a)bt.com * * BT Advanced Communications Technology Centre [B54 Room 94] * * Adastral Park * * Martlesham Heath * * Ipswich IP5 3RE * * UK * ********************************************************************** > -----Original Message----- > From: Sakae OKUBO [SMTP:sakae.okubo@TIES.ITU.INT] > Sent: Friday, February 18, 2000 5:34 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Please upload the decided/determined/approved texts > > Dear Editors, > > Could you please upload your documents of decision, determination or > approval at the /Incoming of the PictureTel ftp site? Please make an > announce through the reflector when you have uploaded your documents. > > Best regards, > > Sakae OKUBO > *********************************************************** > Waseda Research Center > Telecommunications Advancement Organization of Japan (TAO) > 5th Floor, Nishi-Waseda Bldg. > 1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo > 169-0051 Japan > Tel: +81 3 5286 3830 (to be transferred) > +81 3 3204 8194 (direct) > Fax: +81 3 5287 7287 > e-mail: okubo(a)giti.or.jp > ***********************************************************

1 0

Re: Ad Hoc Mobility Group
by Roy, Radhika R, ALARC 20 Feb '00

20 Feb '00

Hi, Everyone: I missed one point in the last email. We would also like to thank Ed for his excellent effort as an editor of H.323 Annex H in a difficult time when the idea H.323 mobility was yet to be clearer differentiating itself from lower layer IP and wireless mobility. More importantly, Ed will be around with us as a contributor which is the most important need for H.323 Annex H. Best regards, Radhika R. Roy, AT&T H.323 Ad Hoc Mobility Group PS: Paul Guram - It is OK for me for the conf call on March 20, 22, 23, & 24 (NOT on March 21). -----Original Message----- From: Roy, Radhika R, ALARC Sent: Sunday, February 20, 2000 1:28 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: Ad Hoc Mobility Group Hi, Everyone: Let us all welcome Paul in his effort to continue the work of H.323 Annex H for arranging the conference calls between now and the next Rap. meeting to be held on May 15-19 so that we can determine this important document in November 2000. Let us also welcome Jaakko to work as the editor of Annex H as well as Paul Reddy for his excellent job for performing his work related to H.246 Annex E which had been determined in the last Feb 7-18 SG16 meeting. Now we have set a mark that H.323 is becoming ready to support mobility. The next important thing is that we have to complete H.323 Annex H first. As Paul pointed out: Let us start with a scenario of H.323 - Roaming within an H.323 Network. In the meantime, I also have a plan to send an email to Jean-Claude related to VLF and HLF information flows in the context H.323 mobility. I guess that this will also provide an opportunity to all how this problem can be addressed in the context of H.323 mobility. The time in the conference call is very precious and we only be able to hold few conferences before the next Rap. meeting. We definitely have to make decisions more quickly in the conf calls for putting more stuffs by the editor so that the document can take a reasonable shape for determination in November 2000. We hope that we have crossed the first phase of our understanding how we can address H.323 mobility problems. Any discussions via emails will expedite our understanding more quickly because the time in the conference calls is very short. I would also request Paul to clarify how the contributions for the conference calls could be sent(I guess that the editor will be the right person). Editor can provide the URL and contribution number as we did in the past. Best Regards, Radhika R. Roy AT&T +1 732 420 1580 rrroy(a)att.com -----Original Message----- From: Guram Paul-LPG019 [mailto:lpg019@EMAIL.MOT.COM] Sent: Saturday, February 19, 2000 6:06 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Ad Hoc Mobility Group Hello SG16 ad hoc mobility group members, The following is a report on the current status and future plan of this ad hoc group. If I have missed out on any important points please respond to the group. 1. To ensure rapid completion of sufficient work in Annex H such that it can be considered for determination at the earliest opportunity, Paul Guram (Motorola) has been elected to chair future meetings of the mobility ad hoc group. It is planned to hold a number of conference calls, kindly facilitated by IMTC (as before), between now and the Rapporteurs meeting in May in Osaka. The group will always endeavour to reach quick agreed conclusions, after appropriate debate, to help the editor of Annex H to complete his task. 2. Ed Martinez (Motorola) has indicated that, due to his time being taken up by other work in his company, he is unable to additionally carry out the duties of the editorship for Annex H. The ad group will miss Ed and would like to thank him for the work he did and the leadership he showed in making mobility part of the overall H.323 agenda. Jaakko Sundquist (Nokia), who performed the editor's work in the Geneva meeting because of Ed's absence, has accepted to become the new editor for Annex H. This will, no doubt, be officially confirmed by Dale Skran (Q13 Rapporteur) in due course. 3. The next conference call is planned to be during the week beginning 20 March. Please inform me personally, i.e. not via the reflector, as to which dates (20 March to 24 March) are suitable for you to attend, and I will then arrange for the meeting to take place on the most appropriate date. The agenda of this meeting is as below. The main objective is to (a) define mobility scenarios, and (b) to agree on the scenario that we will pursue first for Annex H. This will help to focus on our work of defining all the aspects of this chosen scenario under the guidelines of our agreed terms of reference at the Geneva meeting. (To help in defining the scenarios, a look at the ETSI Tiphon scenarios may be useful. However, typical example scenarios are "roaming within an H.323 network", "inter-working between PSTN and H.323 networks for terminals" etc. etc. Contributions (with diagrams) on the scenario topics are to be sent via the reflector by Friday the 10th March. This will give all the participants enough time to consider the proposals for the meeting. This will allow discussion on items already seen and studied by the participants, thus saving time on lengthy presentations by the contributors, and secondly allowing participants, who may not to be able to take part in the live discussions, to have the opportunity to communicate their comments via email. Agenda: 1. Brief Introductions and agreement of agenda 2. Mobility Scenarios for Annex H 3. Adoption of the first scenario to study (in its entirety) 4. Issues related to the progress on Annex I, and H.246 Annex E 5. Report back from other mobility groups (3GPP, 3G.IP, IMT2000, MWIF, etc.). (this will be given by any participant who attends/has access to the appropriate group, and information will be that relevant to our work) 6. Any other business 7. Agenda and date of next conference call 4. On 17 February morning there was a joint ad hoc meeting with the JQG4 from SG11. See the notes below which are also being sent to JQG4. Interaction between JQG4 and our ad hoc group will continue at appropriate times in order to advance our respective work in the two groups. Notes of a Joint Ad Hoc Meeting between SG11/ JQG4 and SG16/Ad hoc Mobility Group, on Thursday 17 February 2000 in Geneva Present: Jean-Claude Samou France Telecom Frederic Delmond France Telecom Janusz Dobrowaski Lucent Technologies Vineet Kumar INTEL Paul Reddy INTEL Nicolas Tran Alcatel CIT Tatiana Tchaika ITU-T Paul Guram Motorola JQG4 Issue Manager Jean-Claude Samou explained that there are five JQGs in the IMT2000 area: JQG1 deals with radio aspects. Matters on the air interface are directly handled by other bodies such as 3GPP, JQG2 did not start, JQG3 deals with VHE scenarios and protocols. Since this is IN related, Question 22 of SG11 progresses the work, JQG4 deals with the Mobility Management aspects, and JQG5 deals with the bearer control protocol and moves are afoot to move this work into WP2 of SG11. There is work in the IMT2000 area which could help the work in the SG16 mobility ad hoc group: H.246 Annex E defines the NNI between H.323 and GSM/ANSI-41. Work on the development of a common mobility management protocol is going on in IMT2000. We need to look at how each group can help each other in this respect, and see if the common set of operations could be adopted for the SG16. A generic state machine being developed Q22/11 should be studied to help the SG16 ad hoc group to see if it can be applicable to the packet network. The relevant recommendations for study are Q.1751 and Q.1721. Mr Delmond presented the following output document. This was seen as very useful input into the later work to be done within Annex H. <<JQG4 Output Geneva 9910 v5.1.doc>> Regards Paul

2 1

Re: Ad Hoc Mobility Group
by Roy, Radhika R, ALARC 20 Feb '00

20 Feb '00

Hi, Everyone: Let us all welcome Paul in his effort to continue the work of H.323 Annex H for arranging the conference calls between now and the next Rap. meeting to be held on May 15-19 so that we can determine this important document in November 2000. Let us also welcome Jaakko to work as the editor of Annex H as well as Paul Reddy for his excellent job for performing his work related to H.246 Annex E which had been determined in the last Feb 7-18 SG16 meeting. Now we have set a mark that H.323 is becoming ready to support mobility. The next important thing is that we have to complete H.323 Annex H first. As Paul pointed out: Let us start with a scenario of H.323 - Roaming within an H.323 Network. In the meantime, I also have a plan to send an email to Jean-Claude related to VLF and HLF information flows in the context H.323 mobility. I guess that this will also provide an opportunity to all how this problem can be addressed in the context of H.323 mobility. The time in the conference call is very precious and we only be able to hold few conferences before the next Rap. meeting. We definitely have to make decisions more quickly in the conf calls for putting more stuffs by the editor so that the document can take a reasonable shape for determination in November 2000. We hope that we have crossed the first phase of our understanding how we can address H.323 mobility problems. Any discussions via emails will expedite our understanding more quickly because the time in the conference calls is very short. I would also request Paul to clarify how the contributions for the conference calls could be sent(I guess that the editor will be the right person). Editor can provide the URL and contribution number as we did in the past. Best Regards, Radhika R. Roy AT&T +1 732 420 1580 rrroy(a)att.com -----Original Message----- From: Guram Paul-LPG019 [mailto:lpg019@EMAIL.MOT.COM] Sent: Saturday, February 19, 2000 6:06 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Ad Hoc Mobility Group Hello SG16 ad hoc mobility group members, The following is a report on the current status and future plan of this ad hoc group. If I have missed out on any important points please respond to the group. 1. To ensure rapid completion of sufficient work in Annex H such that it can be considered for determination at the earliest opportunity, Paul Guram (Motorola) has been elected to chair future meetings of the mobility ad hoc group. It is planned to hold a number of conference calls, kindly facilitated by IMTC (as before), between now and the Rapporteurs meeting in May in Osaka. The group will always endeavour to reach quick agreed conclusions, after appropriate debate, to help the editor of Annex H to complete his task. 2. Ed Martinez (Motorola) has indicated that, due to his time being taken up by other work in his company, he is unable to additionally carry out the duties of the editorship for Annex H. The ad group will miss Ed and would like to thank him for the work he did and the leadership he showed in making mobility part of the overall H.323 agenda. Jaakko Sundquist (Nokia), who performed the editor's work in the Geneva meeting because of Ed's absence, has accepted to become the new editor for Annex H. This will, no doubt, be officially confirmed by Dale Skran (Q13 Rapporteur) in due course. 3. The next conference call is planned to be during the week beginning 20 March. Please inform me personally, i.e. not via the reflector, as to which dates (20 March to 24 March) are suitable for you to attend, and I will then arrange for the meeting to take place on the most appropriate date. The agenda of this meeting is as below. The main objective is to (a) define mobility scenarios, and (b) to agree on the scenario that we will pursue first for Annex H. This will help to focus on our work of defining all the aspects of this chosen scenario under the guidelines of our agreed terms of reference at the Geneva meeting. (To help in defining the scenarios, a look at the ETSI Tiphon scenarios may be useful. However, typical example scenarios are "roaming within an H.323 network", "inter-working between PSTN and H.323 networks for terminals" etc. etc. Contributions (with diagrams) on the scenario topics are to be sent via the reflector by Friday the 10th March. This will give all the participants enough time to consider the proposals for the meeting. This will allow discussion on items already seen and studied by the participants, thus saving time on lengthy presentations by the contributors, and secondly allowing participants, who may not to be able to take part in the live discussions, to have the opportunity to communicate their comments via email. Agenda: 1. Brief Introductions and agreement of agenda 2. Mobility Scenarios for Annex H 3. Adoption of the first scenario to study (in its entirety) 4. Issues related to the progress on Annex I, and H.246 Annex E 5. Report back from other mobility groups (3GPP, 3G.IP, IMT2000, MWIF, etc.). (this will be given by any participant who attends/has access to the appropriate group, and information will be that relevant to our work) 6. Any other business 7. Agenda and date of next conference call 4. On 17 February morning there was a joint ad hoc meeting with the JQG4 from SG11. See the notes below which are also being sent to JQG4. Interaction between JQG4 and our ad hoc group will continue at appropriate times in order to advance our respective work in the two groups. Notes of a Joint Ad Hoc Meeting between SG11/ JQG4 and SG16/Ad hoc Mobility Group, on Thursday 17 February 2000 in Geneva Present: Jean-Claude Samou France Telecom Frederic Delmond France Telecom Janusz Dobrowaski Lucent Technologies Vineet Kumar INTEL Paul Reddy INTEL Nicolas Tran Alcatel CIT Tatiana Tchaika ITU-T Paul Guram Motorola JQG4 Issue Manager Jean-Claude Samou explained that there are five JQGs in the IMT2000 area: JQG1 deals with radio aspects. Matters on the air interface are directly handled by other bodies such as 3GPP, JQG2 did not start, JQG3 deals with VHE scenarios and protocols. Since this is IN related, Question 22 of SG11 progresses the work, JQG4 deals with the Mobility Management aspects, and JQG5 deals with the bearer control protocol and moves are afoot to move this work into WP2 of SG11. There is work in the IMT2000 area which could help the work in the SG16 mobility ad hoc group: H.246 Annex E defines the NNI between H.323 and GSM/ANSI-41. Work on the development of a common mobility management protocol is going on in IMT2000. We need to look at how each group can help each other in this respect, and see if the common set of operations could be adopted for the SG16. A generic state machine being developed Q22/11 should be studied to help the SG16 ad hoc group to see if it can be applicable to the packet network. The relevant recommendations for study are Q.1751 and Q.1721. Mr Delmond presented the following output document. This was seen as very useful input into the later work to be done within Annex H. <<JQG4 Output Geneva 9910 v5.1.doc>> Regards Paul

1 0

Some questions regarding H.341
by Michaela Goffri 20 Feb '00

20 Feb '00

Hi, Can anyone answer the following questions regarding H.341: Procedural: 1. What is the status of the document: is it scheduled to become a standard and if yes, when? 2. Is there any mailing lists/discussion forums to get clarifications/suggestions? Following are the technical questions: 1. In the proposed model (Figure 2), when the entire GW is represented as an interface, what type this interface is? Are RAS/H.225/H.245 represented as a separate ifIndex entries and if yes of what type and what is the ifStack model for them? 2. Should a linkUp/linkDown/coldStart traps be sent for this interface or it is implementation dependent? 3. In the MmTerminalDataCapability textual convention there is no t38fax. How to report the t38? H.225 in GW: 4. Should the callsignalStatsTable be implemented in the GW? Most (if not all) counters will be incremented for both incoming and outgoing directions. Is this the intention? Which side is considered as "In" and which side is considered as "Out" for GW? 5. Why callSignalConfigT303 and callSignalConfigT3031 do not have a DEFVAL as defined in H225. RAS in GW: 6. rasConfigurationGatekeeperIdentifier is defined as read-only. As such, it is impossible to remotely configure a desired GK. Shouldn't it be RW? 7. rasConfigurationGatekeeperDiscoveryAddress: the purpose is not clear. Is it a configured (by user) GK address or it is the GK address, resulted from discovery process? In the first case, shouldn't it be RW? 8. rasRegistrationTable : how many entries are in this table for a GW? Just one? 9. rasRegistrationAliasTable : for the GW it is the list of all aliases it registered in the GK? 10. rasRegistrationAliasTable : What is the intention for GW? To keep entry in the table for every call? If yes, how the calls are represented: those, coming from the lan, have the source address of the endpoint and destination of a GW and those, coming from the SCN vice versa? 11. rasConfigurationTable : the description says ".... The number of entries equals to the number of configuration parameters." If the table is indexed by the ifIndex, why the number of parameters is relevant? H.245 in GW: 12. h245ConfigurationTable : the description says "..The number of entries equals to the number of H.245 stacks in a system.". Why there supposed to be several H.245 stacks in the system? For different versions of H.245? 13. h245CapExchangeStatsTable : is this table applicable for a GW? Gateway 14.h323GwSystemTable : all entries in the table (except ..LocalTime) are read only. It seems others could be made read-write in order to allow remote changes (like location, contact person, country code). 15. h323GwConfigurationH323Table : h323GwConfigurationH323CallSignalingAddressTag and h323GwConfigurationH323CallSignalingAddress are defined read-only. It seems if they where defined read-write, it would allow change of this address to a non-standard value. Otherwise, they either contain a well-known address or an address which is configured by other means (like RS232). having these entries RW, would allow easy remote management . On the other hand, h323GwConfigurationH323GatekeeperAddressTag and h323GwConfigurationH323GatekeeperAddress are defined as read-write. Isn't it in contradiction with the description of this variable? Why to allow to the user to change the address of the gatekeeper, this GW is registered with? 16. h323GwCapabilitiesPstnTotalPorts : is it the total number of say, E1/T1 ports this GW supports? 17. h323GwConnectionsCommand : why it is read-write? To allow manager to control the call state remotely? In which cases it might be useful? 18. h323GwConnectionsPstnTable : Currently the table contains only an index. What else supposed to be defined there? Thanks, Michaela

1 0

Ad Hoc Mobility Group
by Guram Paul-LPG019 19 Feb '00

19 Feb '00

Hello SG16 ad hoc mobility group members, The following is a report on the current status and future plan of this ad hoc group. If I have missed out on any important points please respond to the group. 1. To ensure rapid completion of sufficient work in Annex H such that it can be considered for determination at the earliest opportunity, Paul Guram (Motorola) has been elected to chair future meetings of the mobility ad hoc group. It is planned to hold a number of conference calls, kindly facilitated by IMTC (as before), between now and the Rapporteurs meeting in May in Osaka. The group will always endeavour to reach quick agreed conclusions, after appropriate debate, to help the editor of Annex H to complete his task. 2. Ed Martinez (Motorola) has indicated that, due to his time being taken up by other work in his company, he is unable to additionally carry out the duties of the editorship for Annex H. The ad group will miss Ed and would like to thank him for the work he did and the leadership he showed in making mobility part of the overall H.323 agenda. Jaakko Sundquist (Nokia), who performed the editor's work in the Geneva meeting because of Ed's absence, has accepted to become the new editor for Annex H. This will, no doubt, be officially confirmed by Dale Skran (Q13 Rapporteur) in due course. 3. The next conference call is planned to be during the week beginning 20 March. Please inform me personally, i.e. not via the reflector, as to which dates (20 March to 24 March) are suitable for you to attend, and I will then arrange for the meeting to take place on the most appropriate date. The agenda of this meeting is as below. The main objective is to (a) define mobility scenarios, and (b) to agree on the scenario that we will pursue first for Annex H. This will help to focus on our work of defining all the aspects of this chosen scenario under the guidelines of our agreed terms of reference at the Geneva meeting. (To help in defining the scenarios, a look at the ETSI Tiphon scenarios may be useful. However, typical example scenarios are "roaming within an H.323 network", "inter-working between PSTN and H.323 networks for terminals" etc. etc. Contributions (with diagrams) on the scenario topics are to be sent via the reflector by Friday the 10th March. This will give all the participants enough time to consider the proposals for the meeting. This will allow discussion on items already seen and studied by the participants, thus saving time on lengthy presentations by the contributors, and secondly allowing participants, who may not to be able to take part in the live discussions, to have the opportunity to communicate their comments via email. Agenda: 1. Brief Introductions and agreement of agenda 2. Mobility Scenarios for Annex H 3. Adoption of the first scenario to study (in its entirety) 4. Issues related to the progress on Annex I, and H.246 Annex E 5. Report back from other mobility groups (3GPP, 3G.IP, IMT2000, MWIF, etc.). (this will be given by any participant who attends/has access to the appropriate group, and information will be that relevant to our work) 6. Any other business 7. Agenda and date of next conference call 4. On 17 February morning there was a joint ad hoc meeting with the JQG4 from SG11. See the notes below which are also being sent to JQG4. Interaction between JQG4 and our ad hoc group will continue at appropriate times in order to advance our respective work in the two groups. Notes of a Joint Ad Hoc Meeting between SG11/ JQG4 and SG16/Ad hoc Mobility Group, on Thursday 17 February 2000 in Geneva Present: Jean-Claude Samou France Telecom Frederic Delmond France Telecom Janusz Dobrowaski Lucent Technologies Vineet Kumar INTEL Paul Reddy INTEL Nicolas Tran Alcatel CIT Tatiana Tchaika ITU-T Paul Guram Motorola JQG4 Issue Manager Jean-Claude Samou explained that there are five JQGs in the IMT2000 area: JQG1 deals with radio aspects. Matters on the air interface are directly handled by other bodies such as 3GPP, JQG2 did not start, JQG3 deals with VHE scenarios and protocols. Since this is IN related, Question 22 of SG11 progresses the work, JQG4 deals with the Mobility Management aspects, and JQG5 deals with the bearer control protocol and moves are afoot to move this work into WP2 of SG11. There is work in the IMT2000 area which could help the work in the SG16 mobility ad hoc group: H.246 Annex E defines the NNI between H.323 and GSM/ANSI-41. Work on the development of a common mobility management protocol is going on in IMT2000. We need to look at how each group can help each other in this respect, and see if the common set of operations could be adopted for the SG16. A generic state machine being developed Q22/11 should be studied to help the SG16 ad hoc group to see if it can be applicable to the packet network. The relevant recommendations for study are Q.1751 and Q.1721. Mr Delmond presented the following output document. This was seen as very useful input into the later work to be done within Annex H. <<JQG4 Output Geneva 9910 v5.1.doc>> Regards Paul

1 0

FW: Protocol Action: RTP Payload for Text Conversation to Proposed Standard
by Gunnar Hellstrom 18 Feb '00

18 Feb '00

As you see below, RTP-Text for transport of T.140 text conversation in IP environments is approved by the IESG. An RFC number will be assigned soon. This was a prerequisite for approval of H.323 Annex G Text Conversation and Text SET. Best regards Gunnar Hellström ------------------------------------------ Gunnar Hellstrom LM Ericsson E-mail gunnar.hellstrom(a)omnitor.se Tel +46 8 556 002 03 Mob +46 708 204 288 fax +46 8 556 002 06 -----Original Message----- From: scoya(a)cnri.reston.va.us [mailto:scoya@cnri.reston.va.us]On Behalf Of The IESG Sent: Friday, February 18, 2000 6:21 PM To: IETF-Announce: ; Cc: RFC Editor; Internet Architecture Board; rem-conf(a)es.net Subject: Protocol Action: RTP Payload for Text Conversation to Proposed Standard The IESG has approved the Internet-Draft 'RTP Payload for Text Conversation' <draft-ietf-avt-rtp-text-05.txt> as a Proposed Standard. This document is the product of the Audio/Video Transport Working Group. The IESG contact persons are Scott Bradner and Vern Paxson. Technical Summary This document defines a way to carry low-rate text in RTP packets, in accordance with ITU-T Recommendation T.140. The payload format provides for non-duplicated, in-order delivery, with loss detection and optional limited loss recovery via redundancy. Working Group Summary The initial draft was revised as a result of input from the working group and there is good working group consensus for publishing the document. Protocol Quality Vern Paxson reviewed the the spec for the IESG. Note to RFC Editor: The IESG requests that the Revision History section at the end of the document be removed prior to publication as an RFC.

1 0

Re: Guidance from the Dalai Lama and Abba Eban
by Gösta Linder (LME) 18 Feb '00

18 Feb '00

Another wise comment by Abba Ebban 1915 that still might be relevant; "History teaches us that men and nations behave wisely once they have exhausted all other alternatives." Be happy/Gösta -----Original Message----- From: Greg Ratta [mailto:gratta@lucent.com] Sent: den 18 februari 2000 15:42 To: ITU-SG16(a)mailbag.cps.intel.com Subject: Guidance from the Dalai Lama As we are finishing the ITU-T SG 16 meeting and observing the recent activity moving forward ITU-T Recommendation H.248 / Megaco, I found this gem attributed to be from the Dalai Lama. I hope you find it as enjoyable and relevant as I did. My only regret is that this did not pass my way two weeks ago. I N S T R U C T I O N S F O R L I F E 1. Take into account that great love and great achievements involve great risk. 2. When you lose, don't lose the lesson. 3. Follow the three Rs: - Respect for self - Respect for others and - Responsibility for all your actions. 4. Remember that not getting what you want is sometimes a wonderful stroke of luck. 5. Learn the rules so you know how to break them properly. 6. Don't let a little dispute injure a great friendship. 7. When you realize you've made a mistake, take immediate steps to correct it. 8. Spend some time alone every day. 9. Open your arms to change, but don't let go of your values. 10. Remember that silence is sometimes the best answer. 11. Live a good, honorable life. Then when you get older and think back, you'll be able to enjoy it a second time. 12. A loving atmosphere in your home is the foundation for your life. 13. In disagreements with loved ones, deal only with the current situation. Don't bring up the past. 14. Share your knowledge. It's a way to achieve immortality. 15. Be gentle with the earth. 16. Once a year, go someplace you've never been before. 17. Remember that the best relationship is one in which your love for each other exceeds your need for each other. 18. Judge your success by what you had to give up in order to get it. 19. Approach love and cooking with reckless abandon. Greg Ratta, Vice Chairman, ITU-T WP 1/11, Broadband Signalling Lucent Technologies Tel: +1 732 332 5174, Fax: +1 732 949 1196, gratta(a)lucent.com

1 0

Guidance from the Dalai Lama
by Greg Ratta 18 Feb '00

18 Feb '00

As we are finishing the ITU-T SG 16 meeting and observing the recent activity moving forward ITU-T Recommendation H.248 / Megaco, I found this gem attributed to be from the Dalai Lama. I hope you find it as enjoyable and relevant as I did. My only regret is that this did not pass my way two weeks ago. I N S T R U C T I O N S F O R L I F E 1. Take into account that great love and great achievements involve great risk. 2. When you lose, don't lose the lesson. 3. Follow the three Rs: - Respect for self - Respect for others and - Responsibility for all your actions. 4. Remember that not getting what you want is sometimes a wonderful stroke of luck. 5. Learn the rules so you know how to break them properly. 6. Don't let a little dispute injure a great friendship. 7. When you realize you've made a mistake, take immediate steps to correct it. 8. Spend some time alone every day. 9. Open your arms to change, but don't let go of your values. 10. Remember that silence is sometimes the best answer. 11. Live a good, honorable life. Then when you get older and think back, you'll be able to enjoy it a second time. 12. A loving atmosphere in your home is the foundation for your life. 13. In disagreements with loved ones, deal only with the current situation. Don't bring up the past. 14. Share your knowledge. It's a way to achieve immortality. 15. Be gentle with the earth. 16. Once a year, go someplace you've never been before. 17. Remember that the best relationship is one in which your love for each other exceeds your need for each other. 18. Judge your success by what you had to give up in order to get it. 19. Approach love and cooking with reckless abandon. Greg Ratta, Vice Chairman, ITU-T WP 1/11, Broadband Signalling Lucent Technologies Tel: +1 732 332 5174, Fax: +1 732 949 1196, gratta(a)lucent.com

1 0

One endpoint with multiple Connections.
by Hans Viens 18 Feb '00

18 Feb '00

Hi Folks! I have an endpoint that support 3 ports for H.323 connections and 1 port that support PSTN. Then I introduce the PSTN/H.323 gateway functionnality. Now, I would like to register that endpoint to a GK. How could I do this for the GK to know that I support 1 gateway port and 3 H.323 connections ??? Thanks for your support, Hope to get some news soon, Hans ------------------------------------------------ Hans Viens, Ing. St. Concepteur en logiciel / Software Designer Mediatrix Peripherals, Inc. / Mediatrix Telecom, Inc. 4229 Garlock Street, Sherbrooke QC J1L 2C8 Canada Tel.: (819) 829-8749 ext. 255, Fax: (819) 829-5100 E-Mail: hviens(a)mediatrix.com

2 1

Re: Q15: H.245 for videoFastUpdateMB, videoFastUpdateGOB, videoNo tDecodedM Bs (Was Q15: Date: Sat, 12 Feb 2000 19:24:45 -0800)
by Gary Sullivan 17 Feb '00

17 Feb '00

Ari, I suppose it is understandable that it might be difficult to reconcile videoFastUpdateMBs with H.263 Annex K or with MPEG-4, since videoFastUpdateMB was specified years before either one of those existed. That's history, not politics. In the case of MPEG-4 visual, I'm not sure whether specifying a macroblock number is sufficiently explicit. Even the "simple" profile of MPEG-4 requires support of more than one "visual object". I am not sure how you would know which "visual object" you were referring to when you sent the command. I'm not an expert on how MPEG-4 is handled in the system. I believe the intent is for MPEG-4 visual to be able to be handled either by carrying an MPEG-4 Systems stream or by H.245 itself without MPEG-4 Systems, but I'm not sure just how. -Gary S. +> -----Original Message----- +> From: ari.hourunranta(a)NOKIA.COM [mailto:ari.hourunranta@NOKIA.COM] +> Sent: Wednesday, February 16, 2000 12:59 AM +> To: ITU-SG16(a)MAILBAG.INTEL.COM +> Subject: Re: Q15: H.245 for videoFastUpdateMB, videoFastUpdateGOB, +> videoNo tDecodedM Bs (Was Q15: Date: Sat, 12 Feb 2000 19:24:45 -0800) +> +> +> Hi +> +> I am not giving any answers, but rather pointing out more +> problems related +> to the topic. +> +> In videoFastUpdateMBs, the statement saying that firstGOB is +> only relative +> to H.263 and firstMB is only relative to H.261 sounds weird. +> You could +> interpret it so that if you are using H.263 Annex K +> (slices), you should +> still request updates for GOBs, although MB-level start +> index would be much +> more natural. In case of MPEG-4 visual, use of +> videoFastUpdateMBs seems to +> be forbidden, although there is no technical reason why it +> should be (maybe +> political?). I am sure most of the implementors use common sense when +> interpreting the specifications, but still it wouldn't harm if the +> specification would be understandable. +> +> Regards, +> +> Ari +> +> ------------------------------------------------------------ +> Ari Hourunranta +> Nokia Mobile Phones +> ari.hourunranta(a)nokia.com +> ------------------------------------------------------------ +>

1 0

Re: question on video transcoder or gateway
by Gary Sullivan 17 Feb '00

17 Feb '00

Weiming Shen et al, The only real way to translate in either direction in general is to decode (including IDCT) and then re-encode. This is because H.261 cannot represent the half-pel motion used in H.263, and H.263 cannot represent the loop filter in H.261. Unless you can somehow stop the original encoder from using features that aren't found in both standards, you're stuck doing real transcoding. The re-encoding complexity can be reduced significantly by re-using the motion vectors and prediction mode selections from the incoming video rather than doing a new motion estimation in the re-encoder. Since motion estimation and mode selection can take a lot of processing power, getting rid of some of that can help. For best performance it would be good to have the re-encoder do a local refinement of the incoming motion vectors and to try different prediction modes. There are standards for gateways and multipoint conferencing units. I don't think they give much advice in them about this issue. I don't recall which standards those are, but if you look at a list of the H-series standards list at www.itu.int <http://www.itu.int> you'll probably spot them. -Gary -----Original Message----- From: wmshen [mailto:wmshen@PUBLIC.WH.HB.CN] Sent: Tuesday, February 15, 2000 7:04 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: question on video transcoder or gateway Hello, all experts, I am a Ph.D student working on video communication. I am wondering about how the video transcoder/gateway works between H.261 and H.263, and between IP network and PSTN or ISDN, in paticular i wonder whether there is a method by which bitstreams can be translated directly between H.261 and H.263 format. Who knows the technique details on above topics or where may i get some useful reference infomation? Any help will be approciated. Weiming Shen

1 0

Re: H.245 for videoFastUpdateMB, videoFastUpdateGOB, videoNotDeco dedM Bs (Was Q15: Date: Sat, 12 Feb 2000 19:24:45 -0800)
by Gary Sullivan 17 Feb '00

17 Feb '00

Roni et al, Yes, but it is not proper to make a "normative reference" to an appendix. If the only definition in H.263 that is consistent with the intended interpretation is the definition in an appendix, then H.263 must not be referenced as the source of the definition. An appendix is "advice" not "prescription". It does not have the force that the body text or an annex has. The H.245 text needs to be changed so that it contains the definition right in the H.245 text, not just a reference to H.263. Also there are two definitions of macroblock numbering in H.263. The one that's not in the appendix starts its numbering from zero. Since that's the only one that is proper for referencing, the usual presumption would be that it is the one to look at for the definition. (It's in Annex K.) -Gary +> -----Original Message----- +> From: Roni Even [mailto:Roni_e@accord.co.il] +> Sent: Thursday, February 17, 2000 1:51 AM +> To: 'Mailing list for parties associated with ITU-T Study Group 16' +> Cc: Gary Sullivan +> Subject: RE: H.245 for videoFastUpdateMB, videoFastUpdateGOB, +> videoNotDeco dedM Bs (Was Q15: Date: Sat, 12 Feb 2000 19:24:45 -0800) +> +> +> Gary, +> +> About videoNotDecodedMBs Appendix I/H.263 explains the +> macroblocks numbering +> from 1 to N, it looks consistent with H.245 to me. +> +> Appendix I/H.263 +> +> Assume N macroblocks within each frame enumerated mb = 1...N +> from top-left +> to bottom-right. Let {nerr, mbfirst, mblast} be the feedback +> message to the +> encoder, where mbfirst * mb * mblast indicates a set of erroneous +> macroblocks in frame nerr. +> +> H.245 +> videoNotDecodedMBs indicates to the far-end video encoder +> that a set of MBs +> has been received erroneously and that any MB in the +> specified set has been +> treated as not coded. The encoder may use this information +> to compensate +> transmission errors, as illustrated in Appendix I/H.263. +> firstMB indicates +> the number of the first MB treated as not coded, and +> numberOfMBs indicates +> the number of MBs treated as not coded. The MB numbering is +> done according +> to H.263. The temporal reference of the picture containing +> not decoded MBs +> is indicated in temporalReference. This indication shall +> only be used with +> the H.263 video compression algorithm. +> +> I see the problem with videoFastUpdateMB +> Roni Even +> +> +> +> ********************************************** +> Roni Even +> VP Product Marketing +> Accord Networks +> Email: roni_e(a)accord.co.il +> Tel: +972-3-9251412 +> Fax: +972-3-9211571 +> *************************************************** +> +> > -----Original Message----- +> > From: Gary Sullivan [SMTP:garysull@MICROSOFT.COM] +> > Sent: Sun, February 13, 2000 9:31 PM +> > To: ITU-SG16(a)MAILBAG.INTEL.COM +> > Subject: H.245 for videoFastUpdateMB, videoFastUpdateGOB, +> > videoNotDecodedM Bs (Was Q15: Date: Sat, 12 Feb 2000 +> 19:24:45 -0800) +> > +> > +> > +> > +> > +> > This time copying the APC people as well, since they +> should be the H.245 +> > gurus: +> > +> > +> -----Original Message----- +> > +> From: Gary Sullivan [mailto:garysull@microsoft.com] +> > +> Sent: Saturday, February 12, 2000 7:29 PM +> > +> To: Thomas Wiegand (E-mail) +> > +> Cc: ITU-T Q. 15/SG16 Advanced Video Coding Experts +> Group (E-mail) +> > +> Subject: Q15: Date: Sat, 12 Feb 2000 19:24:45 -0800 +> > +> +> > +> +> > +> ITU-T Advanced Video Coding Experts Group (Q.15/SG16) +> > +> Email from Gary Sullivan <garysull(a)microsoft.com>: +> > +> +> > +> +> > +> To the U. Erlangen folks and other video experts, +> > +> +> > +> I have the strong impression that we have been here +> before discussing +> > +> this same issue. I thought we clarified these issues in H.245. +> > +> However, I'm looking at H.245 and I'm seeing what looks +> like some old +> > +> (pre-1998) text. Since the records on this would be at +> > +> least a couple +> > +> of years old, I don't seem to be able to track them all down. +> > +> +> > +> I have questions about two paragraphs in H.245. Here's the +> > +> first one: +> > +> +> > +> videoFastUpdateGOB SEQUENCE +> > +> { +> > +> firstGOB INTEGER (0..17), +> > +> numberOfGOBs INTEGER (1..18) +> > +> }, +> > +> +> > +> videoFastUpdateMB SEQUENCE +> > +> { +> > +> firstGOB INTEGER (0..255) OPTIONAL, +> > +> firstMB INTEGER (1..8192) OPTIONAL, +> > +> numberOfMBs INTEGER (1..8192), +> > +> ... +> > +> }, +> > +> +> > +> "videoFastUpdateMB commands the far-end video encoder +> to perform a +> > +> fast update of one or more MBs. firstGOB indicates +> the number of +> > +> the first GOB to be updated and is only relative to +> H.263, firstMB +> > +> indicates the number of the first MB to be updated and is only +> > +> relative to H.261 and numberOfMBs indicates the +> number of MBs to +> > +> be updated. It shall only be used with video compression +> > +> algorithms that define MBs, for example, H.261 and H.263. +> > +> Terminals may respond to this command with a GOB update which +> > +> includes the MBs requested." +> > +> > +> > (If I now recall correctly, it was not U. Erlangen that +> put the above +> > ambiguous statements into H.245 -- I believe they pre-dated the +> > error tracking work.) +> > +> > Let me try a little more on the above: +> > +> > A GOB in H.261 is not a raster-scan-order set of macroblocks +> > in a picture (instead it is a raster-scan-order set of +> > macroblocks in a rectangle within the picture). But a GOB +> > in H.263 is a raster-scan-order set of macroblocks in a picture. +> > +> > Reviewing GOB layout in H.261, each GOB contains 33 MBs. +> > +> > In H.261 CIF, GOBs are laid out in the picture like this: +> > +> > 1 2 +> > 3 4 +> > 5 6 +> > 7 8 +> > 9 10 +> > 11 12 +> > +> > In H.261 QCIF the layout is +> > +> > 1 +> > 3 +> > 5 +> > +> > and each GOB has a vertical size of 3 macroblocks and a horizontal +> > size of 11 macroblocks. In H.261, MBs are numbered from 1 to 33 +> > in raster scan order within each GOB. +> > +> > In H.263, GOBs are numbered like this in all picture sizes: +> > +> > 0 +> > 1 +> > 2 +> > . +> > . +> > . +> > +> > The height of a GOB in H.263 depends on the height of the picture, +> > with QCIF and CIF containing a single row of macroblocks per GOB +> > and taller pictures containing 2 or 4 rows of macroblocks per GOB. +> > +> > So my guess is that when it is saying firstGOB is "only relative to +> > H.263", +> > it is saying that we should assume the GOB layout is in +> the manner of +> > H.263. So that a GOB is synonymous with one or more rows +> of macroblocks. +> > +> > Then when it says firstMB is "only relative to H.261" I'm +> guessing it is +> > saying that the MBs should be numbered starting from MB +> number 1 being the +> > first MB in the GOB and then proceeding in raster scan +> order within the +> > GOB. +> > +> > Does the above interpretation seem correct? +> > +> > If firstMB + numberOfMBs > 11, it's not clear what to assume. In +> > H.261 this would address a GOB in the next row of MBs in +> the picture, +> > but in H.263 there are other MBs in the same GOB and jumping to the +> > next row of MBs in the picture would break my assumption +> that bitstream +> > order would be the most reasonable. So my guess is that the order +> > assumed in the scanning of MBs should depend on the bitstream order +> > normal for the particular video codec in use. +> > +> > +> +> > +> What the heck does "only relative to H.263" mean? +> > +> What does "only relative to H.261" mean? +> > +> What values are you supposed to send with this command? +> > +> +> > +> Here's the next one: +> > +> +> > +> videoNotDecodedMBs SEQUENCE +> > +> { +> > +> firstMB INTEGER (1..8192), +> > +> numberOfMBs INTEGER (1..8192), +> > +> temporalReference INTEGER (0..255), +> > +> ... +> > +> }, +> > +> +> > +> "videoNotDecodedMBs indicates to the far-end video +> encoder that a +> > +> set of MBs has been received erroneously and that any +> MB in the +> > +> specified set has been treated as not coded. The +> encoder may use +> > +> this information to compensate transmission errors, +> as illustrated +> > +> in Appendix I of H.263. firstMB indicates the number +> of the first +> > +> MB treated as not coded, and numberOfMBs indicates +> the number of +> > +> MBs treated as not coded. The MB numbering is done +> according to +> > +> H.263. The temporal reference of the picture containing not +> > +> decoded MBs is indicated in temporalReference. This indication +> > +> shall only be used with the H.263 video compression +> algorithm." +> > +> +> > +> What does "numbering according to H.263 mean"? The +> only numbering +> > +> defined in H.263 starts with macroblock number 0, not 1. +> > +> > +> > Here my guess would be that MBs are numbered in raster scan order +> > from 1 to the number of MBs in a picture. +> > +> > +> > +> +> > +> I really thought we fixed both of these problems two years ago. +> > +> +> > +> Best Wishes, +> > +> +> > +> Gary Sullivan +> > +> +> > +> +> > +> ------------------------------------------------------------- +> > +> ------------------- +> > +> *** ITU-T Advanced Video Coding Experts Group (Q.15/SG16) +> > +> Email List Message *** +> > +> To send messages, address them to +> > +> "itu-adv-video(a)standard.pictel.com". +> > +> To subscribe or unsubscribe, send email to +> > +> "majordomo(a)standard.pictel.com". +> > +> Note: Only people whose exact email address is subscribed to +> > +> the list can post. +> > +> Subscriptions: "subscribe itu-adv-video +> > +> YOUR-EMAIL-ADDRESS" in message body. +> > +> Unsubscriptions: "unsubscribe itu-adv-video +> > +> YOUR-EMAIL-ADDRESS" in message body. +> > +> ------------------------------------------------------------- +> > +> ------------------- +> > +> +>

1 0