- sg16-avd - lists.packetizer.com

Fwd:Collective 4/16 for WP2 meeting in June already issued
by OKUBO Sakae 20 Apr '06

20 Apr '06

Dear WP2/16 experts, At 3:07 AM -0400 06/04/18, OKUBO Sakae wrote: >Note: H.324 Annex K "Media oriented negotiation acceleration" is to >be consented on 13 June 2006 at an extra WP2/16 meeting dedicated to >this draft. Collective letter for this meeting has been issued and can be found at: http://itu.int/md/T05-SG16-COL-0004 -- Best regards, OKUBO Sakae e-mail: okubo(a)aoni.waseda.jp (<== sokubo(a)waseda.jp, valid until 31 March 2007) Visiting Professor Global Information and Telecommunication Institute (GITI) 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

Collective 4/16 for WP2 meeting in June was issued
by Patrick Luthi 20 Apr '06

20 Apr '06

Dear experts, As decided during the SG16 closing Plenary last week, there will be a WP2 meeting in June in Geneva. The collective letter has been issued by the TSB >The text is found at: >http://itu.int/md/T05-SG16-COL-0004 Best regards, Patrick Luthi Rapporteur for Q.1/16

1 0

Outcome of the SG16 meeting (3-13 April 2006)
by OKUBO Sakae 18 Apr '06

18 Apr '06

Dear WP2/16 experts, The SG16 meeting having finished last Thursday obtained the following results: 1/ Draft Recommendations consented H.222.0 | ISO/IEC 13818-1 Corrigendum 5 "Information Technology - Generic Coding of Moving Pictures And Associated Audio Information: Systems: Corrections identified during integration of third edition" H.241 "Extended video procedures and control signals for H.300 series terminals" H.324 Corrigendum 1 "Clarification in Annex A" H.225.0 v6 "Call signalling protocols and media stream packetization for packet-based multimedia communication systems" H.245 "Control protocol for multimedia communication" H.246 "Interworking of H-Series multimedia terminals with H-Series multimedia terminals and voice/voiceband terminals on GSTN and ISDN" H.323 v6 "Packet-based multimedia communications systems" H.460.21 (ex-H.460.mb) "Message Broadcast for H.323 Systems" H.249 (ex-H.Keys) "Extended User Input Indications" H.248.19 Amendment 1, "Decomposed multipoint control unit, audio, video and data conferencing packages: New Text Overlay Package and Border and Background Package" H.248.23 Corrigendum 1, "Enhanced Alerting packages" H.248.38 "Base Context Package" H.248.39 "H.248 SDP Parameter Identification and Wildcarding" H.248.41 "IP Domain Connection Package" H.248.42 "DCME Interworking Package" H.248.45 "MGC Information Package" H.361 (ex-H.mmqos) "End-to-End Quality of Service (QoS) and Service Priority Signalling in H.323 Systems" Note: H.324 Annex K "Media oriented negotiation acceleration" is to be consented on 13 June 2006 at an extra WP2/16 meeting dedicated to this draft. 2/ Documents approved by SG16 Revised H.323-Series Implementors' Guide Revised H-Series Supplement 4 "Repository of generic parameters for ITU-T Recommendations H.460.x sub-series" Revised Supplement 2 to the H-Series: H.248 Sub-Series: Packages Guide Release 8 New Supplement 6 to the H-Series "Decomposed Gateways - Control Load Quantum - Busy Hour Context Attempts (BHCoA) and Busy Hour Session Attempts (BHSA)" Revised H.248 Sub-series Implementors' Guide Revised H.248 Implementors' Guide Version 2 Revised H.248 Implementors' Guide Version 1 Revised H.350 Sub-series Implementors' Guide 3/ Meeting report of WP2/16 It can be found at the avc-site: http://ftp3.itu.int/av-arch/avc-site/2005-2008/0604_Gen/SG16-WP2-Report-060… 4/ Request to Rapporteurs and Editors Please upload your final text of Draft Recommendation, Supplement or Implementors' Guide to the following dropbox or send me by e-mail: Site: ftp3.itu.int/ User ID: avguest Password: Avguest (Note the uppercase 'A') Directory: avc-site/Incoming 5/ Interim Rapporteur meeting We will hold one Rapporteur meeting for all Questions during 28 August - 1 September 2006 in Ottawa with kind invitation of Nortel before the next SG 16 meeting during 14-24 November 2006. -- Best regards, OKUBO Sakae e-mail: sokubo(a)waseda.jp Visiting Professor Global Information and Telecommunication Institute (GITI) 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

Outcome of the SG16 meeting (3-13 April 2006)
by OKUBO Sakae 18 Apr '06

18 Apr '06

Dear WP2/16 experts, The SG16 meeting having finished last Thursday obtained the following results: 1/ Draft Recommendations consented H.222.0 | ISO/IEC 13818-1 Corrigendum 5 "Information Technology - Generic Coding of Moving Pictures And Associated Audio Information: Systems: Corrections identified during integration of third edition" H.241 "Extended video procedures and control signals for H.300 series terminals" H.324 Corrigendum 1 "Clarification in Annex A" H.225.0 v6 "Call signalling protocols and media stream packetization for packet-based multimedia communication systems" H.245 "Control protocol for multimedia communication" H.246 "Interworking of H-Series multimedia terminals with H-Series multimedia terminals and voice/voiceband terminals on GSTN and ISDN" H.323 v6 "Packet-based multimedia communications systems" H.460.21 (ex-H.460.mb) "Message Broadcast for H.323 Systems" H.249 (ex-H.Keys) "Extended User Input Indications" H.248.19 Amendment 1, "Decomposed multipoint control unit, audio, video and data conferencing packages: New Text Overlay Package and Border and Background Package" H.248.23 Corrigendum 1, "Enhanced Alerting packages" H.248.38 "Base Context Package" H.248.39 "H.248 SDP Parameter Identification and Wildcarding" H.248.41 "IP Domain Connection Package" H.248.42 "DCME Interworking Package" H.248.45 "MGC Information Package" H.361 (ex-H.mmqos) "End-to-End Quality of Service (QoS) and Service Priority Signalling in H.323 Systems" Note: H.324 Annex K "Media oriented negotiation acceleration" is to be consented on 13 June 2006 at an extra WP2/16 meeting dedicated to this draft. 2/ Documents approved by SG16 Revised H.323-Series Implementors' Guide Revised H-Series Supplement 4 "Repository of generic parameters for ITU-T Recommendations H.460.x sub-series" Revised Supplement 2 to the H-Series: H.248 Sub-Series: Packages Guide Release 8 New Supplement 6 to the H-Series "Decomposed Gateways - Control Load Quantum - Busy Hour Context Attempts (BHCoA) and Busy Hour Session Attempts (BHSA)" Revised H.248 Sub-series Implementors' Guide Revised H.248 Implementors' Guide Version 2 Revised H.248 Implementors' Guide Version 1 Revised H.350 Sub-series Implementors' Guide 3/ Meeting report of WP2/16 It can be found at the avc-site: http://ftp3.itu.int/av-arch/avc-site/2005-2008/0604_Gen/SG16-WP2-Report-060… 4/ Request to Rapporteurs and Editors Please upload your final text of Draft Recommendation, Supplement or Implementors' Guide to the following dropbox or send me by e-mail: Site: ftp3.itu.int/ User ID: avguest Password: Avguest (Note the uppercase 'A') Directory: avc-site/Incoming 5/ Interim Rapporteur meeting We will hold one Rapporteur meeting for all Questions during 28 August - 1 September 2006 in Ottawa with kind invitation of Nortel before the next SG 16 meeting during 14-24 November 2006. -- Best regards, OKUBO Sakae e-mail: sokubo(a)waseda.jp Visiting Professor Global Information and Telecommunication Institute (GITI) 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: [Fwd: As for draft Rec. H.248.42 (H.248.DCME)]
by Albrecht.Schwarz＠alcatel.de 07 Apr '06

07 Apr '06

Dear Mr. Naito, I'd like to respond as responsible editor of Draft H.248.42. First of all thank your for your detailed feedback and overview about CME standards on ongoing CME work! >From that perspective I could just identify an editorial error in H.248.42: we did use "G.769" instead "G.767" (e.g. in Fig. 1). So far: only contributions from DCME perspective (= G.763, G.767 & G.768) were submitted. The initial scope was then further on G.704 E1/PDH interfaces only with Q.50 signalling. There weren't any other requirements raised so far considering in addition other "trunk side interface" types. >From that perspective is current applicability scope of H.248.42 limited to * CME equipment with * G.704 E1/PDH trunk types and * Q.50 signalling based on Q.50 Annex A or B. This is my understanding. What I'll do is to provide an update which corrects G.769 to G.767. What I may further do is to revise the text towards "CME" instead "DCME" when you may again confirm that above mentioned H.248.42 requirements (G.704 E1/PDH with Q.50) are matched as well by: * PCME G.765, * IPCME G.769/Y.1242, * VAME Draft I.733 ("guess I cannot reference a draft"). With regards to the incorporation of other "trunk type interfaces", I'm not sure. § 5.6.1/H.248.42 is so far explicitly only refering to "PCM30 systems". I'm not a CME expert, but I could imagine that other digital signal structures may require more detailed considerations (thus also contributions), or do you think the applicability scope could be simply extended (from your CME/Q.50 expertise background point of view)? Thanks for advice and review again! Albrecht ALCATEL Editor H.248.42 .. -------- Original Message -------- Subject: As for draft Rec. H.248.42 (H.248.DCME) Date: Fri, 07 Apr 2006 00:11:25 +0900 From: Y. NAITO <Naito.Yushi(a)dr.MitsubishiElectric.co.jp> To: christian.groves(a)nteczone.com, christian.groves(a)ties.itu.int CC: Naito.Yushi(a)dr.MitsubishiElectric.co.jp Dear Mr. Groves, I am the Rapporteur for Q.15/16 responsible for Circuit Multiplication Equipment and Systems. I found Q.3/16 is drafting the new Recommendation H.248.42, took the glance, and found several points preferable to be modified. I will appreciate if you could check the followings whether if you can reflect them to your final draft. 1. DCME stands for Digital Circuit Multiplexing Equipment which is used in Synchronous or Plesiochronous multiplexed environment. There is other type of similar channel multiplexing equipment used in ATM environment (VAME: draft I.733) or IP environment (IP-CME: G.769) . All these equipment, DCME, VAME and IP-CME, we call them CME (Circuit Multiplication Equipment). 2. There are three types of DCME (G.763 : G.726 ADPCM based, G.767 : G.727 LD-CELP based, G.728 : G.729 CS-ACELP based), one VAME (draft I.733, not yet standardized at this moment), and IP-CME (G.769 ) Note.: packet type equipment, VAME & IP-CME can easily fit different codec by only adding codec profiles. So, we don't specify the relevant codecs for them. 3. All the trunk side interface of DCME, PCME and IP-CME can implement Q.50 interface to ISC for Dynamic Load Control or Supervision. With these facts, I would like to propose you to use CME (more general terminology compared with DCME) instead of DCME, and add G.767 in your list of CMEs. As for draft I.733, we have not finish it yet (possibly at next SG meeting, if we can succeed in finalizing it), and you may omit it at this moment. If you draft any Recommendation related to WP1 questions, we will appreciate if you could send the draft for our review. Of course LSs should not be exchanged between the Questions of the same SG, but it is also difficult to find out, without given notice, something relevant is going on in other WP of the same SG. Thank you in advance, Yushi Naito Rapporteur for Q.15/16, WP1/16 Chair SG16 Vice Chair

1 0

Fw: response from editor of H.PROXY
by Paul E. Jones 06 Apr '06

06 Apr '06

FYI ----- Original Message ----- From: "cathy jiang" <jiangxiaolin(a)mail.ritt.com.cn> To: "patrick.luthi" <patrick.luthi(a)tandberg.net>; "paulej" <paulej(a)packetizer.com> Sent: Thursday, April 06, 2006 11:37 AM Subject: response from editor of H.PROXY > Dear all, > > This following text is our answer to the questions raised in TD-14,which > Mr.Luthi have addressed this afternoon. I also attached the history > documents in this mail, pls check it out. > Q&A > (1)Provide a justification document for why we should move forward with > H.proxy given that we have solutions already, including, but not limited > to, information on scalability as compared to other solutions; and > > A:we already have 2 documents (D-023/D-088) submitted in SG16 November > Plenary meeting in the year of 2004, which are also attached in this email > for your references. These two documents are broadly consented and > approved by the experts in Q5/16 that it should start a WI on proxy aided > NAT/FW traversal scheme. D88 discussed the necessities of proxy-aided > NAT/FW traversal scheme and D23 is all about the feasiblity of PROXY.I > think these two documents can explain well about question(1). > but, if you still feel that these are still insufficient to answer your > question,pls let me know what kind of information specific I should supply > to you and to other experts related. > > (2)Provide clear guidance as to which solution is the right solution in > certain environments in another document in the aforementioned document; > and > > A: We already have TP.HNFT and from the outcome of this Q5 session, we > both should append this kind of information into our documents. > > (3)Deliver a revised draft that properly and adequately addresses the > questions raised during the meeting and clearly explains how the > procedures shall work, including, but not limited to, how endpoints > communicate with the UTS/UTC and/or proxies on either end, where proxy > devices exist, what functionality exists in each component, how the UDP > tunnel works in exacting detail so that there is no ambiguity and that it > can be properly implemented, and how the various components interact to > move packets through the UDP tunnel. > > A: With regard to any comments towards section8.5(proxy in public network > with xtc and xts), i think we should leave it until the decision on how to > deal with this section have been made.if it should be removed from this > document, then question (3) could be out of the question. >

1 0

RE: Contributions to the next month SG16 meeting
by OKUBO Sakae 02 Apr '06

02 Apr '06

Dear Subha, At 4:00 PM -0800 06/03/31, Dhesikan, Subha wrote: >I have sent the attached document already to TSB for registration. >May I please ask you to upload the documents to the avc-site? The >documents >are attached. Thank you for your sending these two documents. They have been zipped and uploaded as per your request. http://ftp3.itu.int/av-arch/avc-site/2005-2008/0604_Gen/Draft_H.mmqos.zip ftp://ftp3.itu.int/avc-site/2005-2008/0604_Gen/Draft_H.mmqos.zip user: avguest password: Avguest -- Best regards, OKUBO Sakae e-mail: sokubo(a)waseda.jp Visiting Professor Global Information and Telecommunication Institute (GITI) 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

FW: WG Action: Conclusion of Media Gateway Control WG (megaco)
by simao.campos＠ITU.INT 27 Mar '06

27 Mar '06

Dear colleagues, FYI Simão -----Original Message----- From: IESG Secretary [mailto:iesg-secretary@ietf.org] Sent: 27 March 2006 17:26 To: IETF Announcement list Cc: megaco(a)ietf.org; Tom Taylor Subject: WG Action: Conclusion of Media Gateway Control WG (megaco) The Media Gateway Control WG (megaco) in the Real-time Applications and Infrastructure Area has concluded. The IESG contact persons are Jon Peterson and Cullen Jennings. The mailing list will remain active. _______________________________________________ IETF-Announce mailing list IETF-Announce(a)ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce

1 0

COM16-D275: H.248.CCC connection capability control Package proposal
by Albrecht.Schwarz＠alcatel.de 24 Mar '06

24 Mar '06

Hi YangboLin, some thoughts in advance. Your package proposal has similar aspects as the ETSI TISPAN discussion on the H.248 Connection Model in Profile ES 283 002 for phy-to-RTP residential/access gateways. We studied the subject, too (see ALCATEL view in uploaded TISPAN docs in the xchange area): /tsg16/sg16/xchange/wp2/q03 TISPAN WG3_TD22_§ 5.3 ConnectionModel Phy-to-Phy.doc 24-Mar-2006 15:52 229k TISPAN WG3_TD23_§ 5.3 ConnectionModel RTP-to-RTP.doc 24-Mar-2006 15:52 1.9M Our understanding is, that the autonomous model is illegal wrt H.248. Therefore I would disagree in considering the controlled and autonomous model equally (as in D275). Our prime concern is, that the MG-autonoumous action in re-directing a bearer segment (between Ta' and Tb') requires the "correlation of Termination info" above the Context level. The aimed functions on bearer connection segments requires firstly operations on addressing information (plus potentially subsequent routing actions). Bearing this in mind, I cannot imagine that Ta' and Tb' could be physical Terminations. Would you agree? Thus, the scope of your capability could be ephemeral Terminations only. Right? Concerning ephemerals, there are again two main classes: 1) connection-oriented bearers, and 2) connectionless. Category (1) requires a dedicated bearer control protocol besides GW control, - autonomous actions on Ta' and Tb' could mean MG-external bearer control signalling activity. Actions which would question the Package scope of "MG internal connections". I would therefore exclude category (1) as well. It remains (2): I could only imagine an IP-based ephemeral without any bearer control protocol (like Q.1970). If yes, then we are again in the same situation as in the ETSI discussion. => the "autonomous model" is (if at all) only applicable for IP and relates to an "MG-embedded IP (edge) router function" (with certain feedback on H.248 ...). The MG-internal redirection of IP bearer connection segments is possible in some (exceptional) cases, but there isn't any general applicability IMHO, primarily due to * IP address/port ranges ("relation to MG capacity") * multi-homed IP interface * support of L2VPNs or L3VPNs at MG * support of multiple IP realms * ... Therefore I got some concerns with the approach of a *generic* Package. An alternative could be the consideration of different H.248 Connection models in Profiles. Best regards, Albrecht

1 0

[Megaco] COM16-D275: H.248.CCC connection capability control Package proposal
by Albrecht.Schwarz＠alcatel.de 24 Mar '06

24 Mar '06

Hi YangboLin, some thoughts in advance. Your package proposal has similar aspects as the ETSI TISPAN discussion on the H.248 Connection Model in Profile ES 283 002 for phy-to-RTP residential/access gateways. We studied the subject, too (see ALCATEL view in uploaded TISPAN docs in the xchange area): /tsg16/sg16/xchange/wp2/q03 TISPAN WG3_TD22_§ 5.3 ConnectionModel Phy-to-Phy.doc 24-Mar-2006 15:52 229k TISPAN WG3_TD23_§ 5.3 ConnectionModel RTP-to-RTP.doc 24-Mar-2006 15:52 1.9M Our understanding is, that the autonomous model is illegal wrt H.248. Therefore I would disagree in considering the controlled and autonomous model equally (as in D275). Our prime concern is, that the MG-autonoumous action in re-directing a bearer segment (between Ta' and Tb') requires the "correlation of Termination info" above the Context level. The aimed functions on bearer connection segments requires firstly operations on addressing information (plus potentially subsequent routing actions). Bearing this in mind, I cannot imagine that Ta' and Tb' could be physical Terminations. Would you agree? Thus, the scope of your capability could be ephemeral Terminations only. Right? Concerning ephemerals, there are again two main classes: 1) connection-oriented bearers, and 2) connectionless. Category (1) requires a dedicated bearer control protocol besides GW control, - autonomous actions on Ta' and Tb' could mean MG-external bearer control signalling activity. Actions which would question the Package scope of "MG internal connections". I would therefore exclude category (1) as well. It remains (2): I could only imagine an IP-based ephemeral without any bearer control protocol (like Q.1970). If yes, then we are again in the same situation as in the ETSI discussion. => the "autonomous model" is (if at all) only applicable for IP and relates to an "MG-embedded IP (edge) router function" (with certain feedback on H.248 ...). The MG-internal redirection of IP bearer connection segments is possible in some (exceptional) cases, but there isn't any general applicability IMHO, primarily due to * IP address/port ranges ("relation to MG capacity") * multi-homed IP interface * support of L2VPNs or L3VPNs at MG * support of multiple IP realms * ... Therefore I got some concerns with the approach of a *generic* Package. An alternative could be the consideration of different H.248 Connection models in Profiles. Best regards, Albrecht _______________________________________________ Megaco mailing list Megaco(a)ietf.org https://www1.ietf.org/mailman/listinfo/megaco

1 0