- 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 22 Feb '00

22 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