February 2005 - sg16-avd - lists.packetizer.com

Re: Number Allocations
by OKUBO Sakae 15 Feb '05

15 Feb '05

Dear Mr. Lehmann and Mr. Schwarz, At 10:00 +0100 05/02/15, Leo.Lehmann(a)bakom.admin.ch wrote: >Attached you will find my report from last SG13 meeting. May Iask >you to register the docuemnt for our Melbourne meeting? It has been registered as AVD-2670 and uploaded to the Melbourne directory. At 12:21 +0100 05/02/15, Albrecht.Schwarz(a)alcatel.de wrote: >Please allocate numbers for following two contributions: They have been numbered as follows: AVD-2671 Question(s): Q.3/16 Source*: ALCATEL Title: H.248.14 ? Analysis of Potential Issues AVD-2672 Question(s): Q.3/16 Source*: ALCATEL Title: H.248.14 ? Feedback on Inactivity Counter Proposal The current list of registered documents can be found at the following place: http://ftp3.itu.int/av-arch/avc-site/2005-2008/0502_Mel/0502_Mel.html http://ftp3.itu.int/av-arch/avc-site/2005-2008/0502_Mel/0502_Mel.xls You can download documents by ftp with the following URL: ftp://ftp3.itu.int/avc-site/2005-2008/0502_Mel User: avguest Password: Avguest -- Best regards, OKUBO Sakae e-mail: sokubo(a)waseda.jp Visiting Professor Graduate School of Science and Engineering Waseda University ****************************************************************** 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 H.323 videoconferencing: arranged by advice ******************************************************************

1 0

Re: Request Document Numbers
by OKUBO Sakae 15 Feb '05

15 Feb '05

Dear Paul and all, At 00:32 -0500 05/02/15, Paul E. Jones wrote: >Please allocate numbers for the following documents: AVD-numbers have been allocated to them as follows: AVD-2668 Support for the Internet Low Bit Rate Codec (iLBC) within H.323 Systems Cisco Systems AVD-2669 Transport of Geographic Information in H.323 Systems (H.460.geo) Editor (P Jones) Using this opportunity, can I ask all the contributors to check if your documents are properly registered? I might have lost a couple of e-mails. The current list is as follows: http://ftp3.itu.int/av-arch/avc-site/2005-2008/0502_Mel/0502_Mel.html http://ftp3.itu.int/av-arch/avc-site/2005-2008/0502_Mel/0502_Mel.xls -- Best regards, OKUBO Sakae e-mail: sokubo(a)waseda.jp Visiting Professor Graduate School of Science and Engineering Waseda University ****************************************************************** 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 H.323 videoconferencing: arranged by advice ******************************************************************

1 0

Re: Document number request
by OKUBO Sakae 15 Feb '05

15 Feb '05

Dear Faisal, At 20:24 +0530 05/02/14, faisal.siyavudeen(a)cisco.com wrote: >I have uploaded AVD-2666 and AVD-2667 to /avc-site/Incoming/ folder. They have been moved to /avc-site/2005-2008/0502_Mel/ directory. -- Best regards, OKUBO Sakae e-mail: sokubo(a)waseda.jp Visiting Professor Graduate School of Science and Engineering Waseda University ****************************************************************** 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 H.323 videoconferencing: arranged by advice ******************************************************************

1 0

Re: Document number request
by OKUBO Sakae 14 Feb '05

14 Feb '05

Dear Faisal, At 12:36 +0530 05/02/14, faisal.siyavudeen(a)cisco.com wrote: >I would like to request document numbers for the following documents >to bepresented at the Melbourne meeting. Thank you for your input contributions. The following AVD-numbers have been allocated to them: AVD-2666 Title: New no-bandwidth error code in H.225.0 AdmissionRejectReason Question(s): Q.2 Source: Cisco Systems, Inc. Purpose: Proposal AVD-2667 Title: Revised H.225.0 Recommendation Question(s): Q.2 Source: Editor Purpose: Proposal (Revised recommendation for discussion and approval) The current list of registered documents can be found at the following place: http://ftp3.itu.int/av-arch/avc-site/2005-2008/0502_Mel/0502_Mel.html http://ftp3.itu.int/av-arch/avc-site/2005-2008/0502_Mel/0502_Mel.xls -- Best regards, OKUBO Sakae e-mail: sokubo(a)waseda.jp Visiting Professor Graduate School of Science and Engineering Waseda University ****************************************************************** 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 H.323 videoconferencing: arranged by advice ******************************************************************

1 0

Re: Request any expert advice to the proposed revises about H.248 .14
by Albrecht.Schwarz＠alcatel.de 14 Feb '05

14 Feb '05

Dear LinYangbo, just a feedback: we are presently preparing comments on your preliminary contribution. But we are still struggling with your scenario C because of it's overlapping with ServiceChange procedures. Nevertheless, we'll write down our view latest end of this week for submission to our meeting. Best regards Albrecht Yangbo Lin <linyangbo@huawe To: Kevin Boyle <kboyle(a)nortel.com>, ITU-T SG16 i.com> <itu-sg16(a)external.cisco.com> cc: 12.02.2005 21:20 Subject: Re: Request any expert advice to the proposed revises about H.248 .14 Dear All, From 9 to 23 Feb in this year is the "Spring Festival" of China, the most importantest traditional festival for the East, just like the Christmas for the West. Thus, let me bring all the best wishes to all of you ---- Happy Chinese New Year! All of the effort we continue to do for H.248 is to make such most importantest protocol between MG and MGC more perfect. We need to edit or supply the base protocol and the appendix packages once and again just for meeting the more and more requests. So the package maybe full fit the request of the day when it was defined, but the current request from the actual application need it been revised. firstly, the relation of MGC and MG is principal and subordinate from the point of view of control, but peer to peer from the point of view of communication. So MGC monitors MG's status by AuditValue command with empty Audit descriptor and MG monitors MGC's status by Notify command with "ito" observed event are independent each other in theory. MGC can tell MG how to monitor itself, for example using the "mit" parameter to tell MG the message silence limit of MGC. However it is unreasonable for MGC to determine whether MG should monitor itself as the package's original definition. Typically, without MG startup the monitor mechanism on its own initiative, how can we resolve those scenarios described in this contribution's "problem discussion" section? Secondly, the actual networks condition is very complex and the protocol should have the ability to accommodate the different requests as more as possible. We can not only depend the transport to provide the all reliability, just like besides IPSec we should have Interim AH Scheme. The section "MGC-MG link monitoring" in the newest Draft H.248.1 v3 also indicates that we should adopt this application level monitoring when the transport layer can't supply the same function. So the UDP is just a example, the essential we need is a communication-link monitoring mechanism which is independent to the transport layer. In fact, the UDP is also the most common transport layer, should we make a protocol without considering it? finally, the proposed revises to H.248.14 in this contribution is completely compatible with the existing mechanism defined in H.248.14. We recommend the implementer to adopt the new enhanced mechanism because it can resolve more problems, however it is no mandatory. In fact, the implementer may remain the existing devices which comply the original mechanism and develop the new devices which comply the enhanced mechanism in a same networks. It is just a version different and fully backward compatible. Please take above clarifies into your consideration. Thank you very much! Sincerely, Yangbo ----- Original Message ----- From: Kevin Boyle To: Yangbo Lin ; ITU-T SG16 Sent: Tuesday, February 08, 2005 5:00 AM Subject: RE: Request any expert advice to the proposed revises about H.248 .14 I believe this is the third meeting at which we will consider these changes, with the Question rejecting the changes the previous two times (Beijing last May, and Geneva in November). I will reiterate for everyone's benefit that the current definition of the package came about as a result of a significant amount of debate across several meetings. The mandate that the MGC first enable this mechanism was one of the key items in those discussions, and was specifically one of the criteria that had to be met to allow the package to consent. I do not believe that we need to attempt to build UDP reliability at the H.248 application layer -- reliability is a transport issue and needs to be solved there. As was mentioned the last two times this was brought up, if guaranteed connections are a requirement for your implementation, then you should use SCTP or TCP as the transport. Forcing additional requirements on other systems that may not need them doesn't appear to be the right way to solve this to me. Kevin From: Yangbo Lin [mailto:linyangbo@huawei.com] Sent: Friday, February 04, 2005 8:59 PM To: ITU-T SG16 Cc: Yangbo Lin Subject: Request any expert advice to the proposed revises about H.248.14 Dear All: The attached document is about some proposed revises to H.248.14 Inactivity Timer Package. It is intended to ITU-T SG16 Rapporteur Meeting on Melbourne (Feb-Mar 2005), but maybe no the final contribution. The delay contribution with the same subject (D0021) had been discussed in the ITU-T SG16 Plenary Meeting on Geneva (Nov 2004). However there were some misunderstanding for that contribution had not been clarified adequately then. So I renewed the document to give more detail about the essentiality of these revises. Please pay attention to the section "Problem Discussion" for the object secenario we aim to resolve, and the chapter "Conclusion" for the detailed revises we proposed. I issue the document inside this mail-list in order to gain your expert advices as more as possible. Any advice or comment from anyone of you is highly appreciated. Thank you very much! Sincerely, Yangbo

1 0

Re: Document number request
by OKUBO Sakae 14 Feb '05

14 Feb '05

Dear Christian, At 14:36 +1100 05/02/14, Christian Groves wrote: >I'd like to request document numbers for the following documents: Thank you for your contributions. They have been numbered as follows: AVD-2660: H.248.1 Annex F: Editorial Improvements and Corrections AVD-2661: H.248.1v3: Corrections and Improvements AVD-2662: H.248.1: Enhancements to the Profile Template AVD-2663: H.248.x Sub Series IG: Additions AVD-2664: Introduction of a H.248.x Symmetric RTP/RTCP NAPT Package >The above documents are source : LM Ericsson AVD-2665: Draft H Series Supplement 2 - H.248.x sub-series Package Guide Release 7 >The above document is source : Editor An updated list of registered documents can be found at: http://ftp3.itu.int/av-arch/avc-site/2005-2008/0502_Mel/0502_Mel.html http://ftp3.itu.int/av-arch/avc-site/2005-2008/0502_Mel/0502_Mel.xls -- Best regards, OKUBO Sakae e-mail: sokubo(a)waseda.jp Visiting Professor Graduate School of Science and Engineering Waseda University ****************************************************************** 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 H.323 videoconferencing: arranged by advice ******************************************************************

1 0

Re: Contributions to the Melbourne meeting
by OKUBO Sakae 13 Feb '05

13 Feb '05

Dear Sasha, At 19:15 -0500 05/02/12, Sasha Ruditsky wrote: >Can I have a document numbers for the following contribution to Q5: Thank you for your contributions. They have been registered as follows: AVD-2657 "FW/NAT traversal problems" AVD-2658 "Using H.225.0 as transport for H.323 RAS messages" AVD-2659 "Method for media traversal of FW/NAT for H.323" An updated list of registered documents can be found at: http://ftp3.itu.int/av-arch/avc-site/2005-2008/0502_Mel/0502_Mel.html http://ftp3.itu.int/av-arch/avc-site/2005-2008/0502_Mel/0502_Mel.xls -- Best regards, OKUBO Sakae e-mail: sokubo(a)waseda.jp Visiting Professor Graduate School of Science and Engineering Waseda University ****************************************************************** 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 H.323 videoconferencing: arranged by advice ******************************************************************

1 0

Re: Request any expert advice to the proposed revises about H.248 .14
by Yangbo Lin 12 Feb '05

12 Feb '05

Dear All, >From 9 to 23 Feb in this year is the "Spring Festival" of China, the most importantest traditional festival for the East, just like the Christmas for the West. Thus, let me bring all the best wishes to all of you ---- Happy Chinese New Year! All of the effort we continue to do for H.248 is to make such most importantest protocol between MG and MGC more perfect. We need to edit or supply the base protocol and the appendix packages once and again just for meeting the more and more requests. So the package maybe full fit the request of the day when it was defined, but the current request from the actual application need it been revised. firstly, the relation of MGC and MG is principal and subordinate from the point of view of control, but peer to peer from the point of view of communication. So MGC monitors MG's status by AuditValue command with empty Audit descriptor and MG monitors MGC's status by Notify command with "ito" observed event are independent each other in theory. MGC can tell MG how to monitor itself, for example using the "mit" parameter to tell MG the message silence limit of MGC. However it is unreasonable for MGC to determine whether MG should monitor itself as the package's original definition. Typically, without MG startup the monitor mechanism on its own initiative, how can we resolve those scenarios described in this contribution's "problem discussion" section? Secondly, the actual networks condition is very complex and the protocol should have the ability to accommodate the different requests as more as possible. We can not only depend the transport to provide the all reliability, just like besides IPSec we should have Interim AH Scheme. The section "MGC-MG link monitoring" in the newest Draft H.248.1 v3 also indicates that we should adopt this application level monitoring when the transport layer can't supply the same function. So the UDP is just a example, the essential we need is a communication-link monitoring mechanism which is independent to the transport layer. In fact, the UDP is also the most common transport layer, should we make a protocol without considering it? finally, the proposed revises to H.248.14 in this contribution is completely compatible with the existing mechanism defined in H.248.14. We recommend the implementer to adopt the new enhanced mechanism because it can resolve more problems, however it is no mandatory. In fact, the implementer may remain the existing devices which comply the original mechanism and develop the new devices which comply the enhanced mechanism in a same networks. It is just a version different and fully backward compatible. Please take above clarifies into your consideration. Thank you very much! Sincerely, Yangbo ----- Original Message ----- From: <mailto:kboyle@nortel.com> Kevin Boyle To: <mailto:linyangbo@huawei.com> Yangbo Lin ; <mailto:itu-sg16@external.cisco.com> ITU-T SG16 Sent: Tuesday, February 08, 2005 5:00 AM Subject: RE: Request any expert advice to the proposed revises about H.248 .14 I believe this is the third meeting at which we will consider these changes, with the Question rejecting the changes the previous two times (Beijing last May, and Geneva in November). I will reiterate for everyone's benefit that the current definition of the package came about as a result of a significant amount of debate across several meetings. The mandate that the MGC first enable this mechanism was one of the key items in those discussions, and was specifically one of the criteria that had to be met to allow the package to consent. I do not believe that we need to attempt to build UDP reliability at the H.248 application layer -- reliability is a transport issue and needs to be solved there. As was mentioned the last two times this was brought up, if guaranteed connections are a requirement for your implementation, then you should use SCTP or TCP as the transport. Forcing additional requirements on other systems that may not need them doesn't appear to be the right way to solve this to me. Kevin _____ From: Yangbo Lin [mailto:linyangbo@huawei.com] Sent: Friday, February 04, 2005 8:59 PM To: ITU-T SG16 Cc: Yangbo Lin Subject: Request any expert advice to the proposed revises about H.248.14 Dear All: The attached document is about some proposed revises to H.248.14 Inactivity Timer Package. It is intended to ITU-T SG16 Rapporteur Meeting on Melbourne (Feb-Mar 2005), but maybe no the final contribution. The delay contribution with the same subject (D0021) had been discussed in the ITU-T SG16 Plenary Meeting on Geneva (Nov 2004). However there were some misunderstanding for that contribution had not been clarified adequately then. So I renewed the document to give more detail about the essentiality of these revises. Please pay attention to the section "Problem Discussion" for the object secenario we aim to resolve, and the chapter "Conclusion" for the detailed revises we proposed. I issue the document inside this mail-list in order to gain your expert advices as more as possible. Any advice or comment from anyone of you is highly appreciated. Thank you very much! Sincerely, Yangbo

1 0

RE: Contributions to the Melbourne meeting
by OKUBO Sakae 12 Feb '05

12 Feb '05

Dear Roni, At 20:36 +0200 05/02/11, Even, Roni wrote: >Can I have a document number for a contribution to Q5 >The contribution title will be "NAT traversal through SBCs issues and >suggested solutions" AVD-2656 has been allocated to your contribution. An updated list of registered documents can be found at the following place: http://ftp3.itu.int/av-arch/avc-site/2005-2008/0502_Mel/0502_Mel.html http://ftp3.itu.int/av-arch/avc-site/2005-2008/0502_Mel/0502_Mel.xls -- Best regards, OKUBO Sakae e-mail: sokubo(a)waseda.jp Visiting Professor Graduate School of Science and Engineering Waseda University ****************************************************************** 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 H.323 videoconferencing: arranged by advice ******************************************************************

1 0

Re: Q29/16 Input documents Melbourne
by OKUBO Sakae 08 Feb '05

08 Feb '05

Dear Mr. Lehmann, At 15:04 +0100 05/02/08, Leo.Lehmann(a)bakom.admin.ch wrote: >Attached you will find two input documents from Q.29/16: >- completed Revision of technical report "combined mobility" including >securuty aspects >- Mobility Definitions for H.510 > >May I ask you to register these documents for Q.29/16 session at the >Melbourne meeting? Thanks a lot for your help AVD-2654 and AVD-2655 have been allocated to your contributions. They have been uploaded to the 0502_Mel directory. http://ftp3.itu.int/av-arch/avc-site/2005-2008/0502_Mel/AVD-2654.zip http://ftp3.itu.int/av-arch/avc-site/2005-2008/0502_Mel/AVD-2655.zip or ftp://ftp3.itu.int/avc-site/2005-2008/0502_Mel/AVD-2654.zip ftp://ftp3.itu.int/avc-site/2005-2008/0502_Mel/AVD-2655.zip user: avguest password: Avguest >By the way: Do you think that there is an interest of the >participants at the Melbourne meeting if I give in my role as SG13 >liaison officer a short report of the last SG13 meeting in Geneva? Your report of SG13 activities is very much appreciated. -- Best regards, OKUBO Sakae e-mail: sokubo(a)waseda.jp Visiting Professor Graduate School of Science and Engineering Waseda University ****************************************************************** 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 H.323 videoconferencing: arranged by advice ******************************************************************

1 0