- sg16-avd - lists.packetizer.com

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. &… [View More]gt; 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. > [View Less]

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: … [View More]

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. … [View More]

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 … [View More]

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 … [View More]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 [View Less]

1 0

COM16-D332: GW Control aspects of G.IP2IP
by Albrecht.Schwarz＠alcatel.de 24 Mar '06

24 Mar '06

Hi Peter, just read your D332. Some comments in advance: The signalling requirements draft TR Q.ncap2 reminds me to H.248 Profiles. Guess ETSI's H.248 Profiles for IP-to-IP gateways (TS 102 333, successor ES 283 018) matching very close the majority of sketched signalling requirements. My assumption is, that the signalling interface ("in case there are signalled services on a call indidvidual level") of G.IP2IP is based on H.248. Just as G.799.1 is based on H.248. Now, H.248 Profiles for IP-… [View More]

1 0

COM16-D332: GW Control aspects of G.IP2IP
by Albrecht.Schwarz＠alcatel.de 24 Mar '06

24 Mar '06

Hi Peter, just read your D332. Some comments in advance: The signalling requirements draft TR Q.ncap2 reminds me to H.248 Profiles. Guess ETSI's H.248 Profiles for IP-to-IP gateways (TS 102 333, successor ES 283 018) matching very close the majority of sketched signalling requirements. My assumption is, that the signalling interface ("in case there are signalled services on a call indidvidual level") of G.IP2IP is based on H.248. Just as G.799.1 is based on H.248. Now, H.248 Profiles for IP-… [View More]

1 0

Contributions to the next month SG16 meeting
by OKUBO Sakae 22 Mar '06

22 Mar '06

Dear experts, The following four contributions have been voluntarily posted at the avc-site to facilitate your advance review: http://ftp3.itu.int/av-arch/avc-site/2005-2008/0604_Gen/ ftp://ftp3.itu.int/avc-site/2005-2008/0604_Gen user: avguest password: Avguest 200604SG16_KDDI_2_NGNterminal.zip -- Q.24 KDDI: A notification scheme of the QoS information for NGN terminals H.FSIC_Update.zip -- Q.25 University of North Carolina: H.FSIC Update Work_Plan_for_Next_Generation_H.350_Services.zip … [View More]

1 0

Re: AW: Documents for the SG16 meeting (3-13 April)
by OKUBO Sakae 15 Mar '06

15 Mar '06

Dear Mr. Lehmann, At 14:29 +0100 06/03/13, <Leo.Lehmann(a)bakom.admin.ch> wrote: >I have sent the attached document already to TSB for registration. >But may I also use your offer and ask you to upload the document to >the avc-site? Thank you. I have placed your document at the following site: http://ftp3.itu.int/av-arch/avc-site/2005-2008/0604_Gen/MM_Service_Mobility… -- Best regards, OKUBO Sakae e-mail: sokubo(a)waseda.jp Visiting Professor Graduate School of Science … [View More]

1 0

Re: Fw: SG16: Q3 contributions
by Albrecht.Schwarz＠alcatel.de 13 Mar '06

13 Mar '06

fyi, 3 more in http://ties.itu.int/u/itu-t/edh/sg16/ Albrecht Alcatels1 T05-SG16-060403-D H.248.38 BC Editorial.doc 13-Mar-2006 15:24 51k Alcatelt1 T05-SG16-060403-D H.248.1 StatisticsDescriptorEd04.doc 13-Mar-2006 15:24 302k T05-SG16-060403-D H.248.SPDSPEC_Tables.zip 13-Mar-2006 15:25 56k Albrecht SCHWARZ … [View More] To: tsbedh(a)ITU.INT 13.03.2006 15:02 cc: Albrecht SCHWARZ/DE/ALCATEL@ALCATEL Subject: Fw: SG16: Q3 contributions fyi, I've submitted some more (currently = 26 contributions from ALCATEL) Regards, Albrecht Schwarz http://ties.itu.int/u/itu-t/edh/sg16/ Alcatela1 T05-SG16-060403-D H.248.1 MID_PortRedirectionEd01.doc 11-Mar-2006 12:14 114k Alcatela4 T05-SG16-060403-D H.248.1 IMG Editorial § 6.3.doc 11-Mar-2006 12:14 88k Alcatela5 T05-SG16-060403-D H.248.1 IMG ErrorCode in § 6.3.2.doc 11-Mar-2006 12:14 91k Alcatela6 T05-SG16-060403-D H.248.1 IMG TestState.doc 11-Mar-2006 12:14 181k Alcatela7 T05-SG16-060403-D H.248.1 IMG ServiceChangeMgcID.doc 11-Mar-2006 12:14 92k Alcatelk1 T05-SG16-060403-D H.248.4 FurtherDiscussion 20060223.doc 11-Mar-2006 12:14 161k Alcatelk2 T05-SG16-060403-D H.248.4 ModifiedProposal 20060223.doc 11-Mar-2006 12:14 112k Alcatelm1 T05-SG16-060403-D H.Sup7.H248CtrlAssoc Ed03.doc 11-Mar-2006 12:15 258k Alcatelm2 T05-SG16-060403-D H.Sup7 Phases.doc 11-Mar-2006 12:15 98k Alcatelm3 T05-SG16-060403-D H.Sup7 AddressChanges.doc 11-Mar-2006 12:15 94k Alcatelm4 T05-SG16-060403-D H.Sup7 MIDoperations.doc 11-Mar-2006 12:15 91k Alcatelm5 T05-SG16-060403-D H.Sup7 SCTPassociationEstablishment.doc 11-Mar-2006 12:15 105k Alcatelp1 T05-SG16-060403-D H.248.44 MLPPcomments.doc 13-Mar-2006 14:57 75k Alcatelp2 T05-SG16-060403-D H.248.44 Definitions.doc 13-Mar-2006 14:57 85k Alcatelp3 T05-SG16-060403-D H.248.44 InterworkingH.323.doc 13-Mar-2006 14:57 222k Alcatelp4 T05-SG16-060403-D H.248.44 eMLPP.doc 13-Mar-2006 14:57 86k Alcatelr1 T05-SG16-060403-D H.248.gm_gc_Package_Ed01_20051220.doc 11-Mar-2006 12:15 107k Alcatelr2 T05-SG16-060403-D H.248.gm_gc_Package_Ed02_Adaptations.doc 11-Mar-2006 12:15 116k Alcatelr3 T05-SG16-060403-D H.248.gm_gc_Package_ValueRange.doc 11-Mar-2006 12:15 88k Alcatelv1 T05-SG16-060403-D H.248.GC PolicyEnforcement_Filtering.doc 11-Mar-2006 12:15 116k Alcatelw1 T05-SG16-060403-D H.248.43 RTPXtalk Ed03.doc 13-Mar-2006 11:48 227k Alcatelw2 T05-SG16-060403-D H.248.43 RTPXtalk SymmetricRTP.doc 13-Mar-2006 11:48 119k Alcately1 T05-SG16-060403-D H.248.40 Editorial.doc 11-Mar-2006 12:15 97k Alcately2 T05-SG16-060403-D H.248.40 OutgoingDirection.doc 11-Mar-2006 12:15 85k Alcately3 T05-SG16-060403-D H.248.40 AppI VoRTP.doc 11-Mar-2006 12:15 101k Alcately4 T05-SG16-060403-D H.248.40 AppII Pa2PaDeadlockLatching.doc 11-Mar-2006 12:15 105k ----- Forwarded by Albrecht SCHWARZ/DE/ALCATEL on 13.03.2006 15:00 ----- Albrecht SCHWARZ/DE/ALCAT To: tsbedh(a)ITU.INT EL@ALCATEL cc: itu-sg16(a)external.cisco.com Subject: SG16: Q3 contributions 11.03.2006 12:31 fyi, I've dropped a first set of H.248 related contributions in the ftp box for SG16: /u/itu-t/edh/sg16 Albrecht [View Less]

1 0

SG16: Q3 contributions
by Albrecht.Schwarz＠alcatel.de 11 Mar '06

11 Mar '06

fyi, I've dropped a first set of H.248 related contributions in the ftp box for SG16: /u/itu-t/edh/sg16 Albrecht

1 0

Documents for the SG16 meeting (3-13 April)
by OKUBO Sakae 09 Mar '06

09 Mar '06

Dear WP2/16 experts, Since this meeting is of Study Group level, all the documents are handled by TSB, not by a Rapporteur. However, you may wish to upload your documents to the avc-site on a volunteering basis for advance review by the experts. In that case, place your document at: ftp://ftp3.itu.int/avc-site/Incoming/ user: avguest password: Avguest or email it to me, then I will move it to: http://ftp3.itu.int/av-arch/avc-site/2005-2008/0604_Gen/ ftp://ftp3.itu.int/avc-site/2005-… [View More]

1 0

RE: April Meeting Accomodation
by Paul E. Jones 09 Mar '06

09 Mar '06

Christian, I tried booking a room when I was there last November and couldn't for the same reason. I was hopeful that some space would open, but I've not yet tried to book my room, either. This is most unfortunate. So, I'll take any advise you receive. Paul > -----Original Message----- > From: Christian Groves [mailto:cngroves@bigpond.net.au] > Sent: Wednesday, March 08, 2006 7:44 AM > To: SG16 > Subject: April Meeting Accomodation > > Hello, > > Sorry to use … [View More]

1 0

April Meeting Accomodation
by Christian Groves 08 Mar '06

08 Mar '06

Hello, Sorry to use the exploder for this... Unfortunately it seems Hotel availability for the April SG16 meeting is at a premium between the 3rd and the 7th and I've left it a bit too late. If anyone was in the same boat and has found a solution and or could recommend a hotel with availability i'd appreciate if you could send me an email. Thanks. Regards, Christian

1 0

progress of draft H.460.mb "Message Broadcast for H.323 Systems" and related security issues: call for contributions
by Euchner, Martin 02 Mar '06

02 Mar '06

Dear all, Q.2/16 has scheduled Draft ITU-T Recommendation H.460.mb "Message Broadcast for H.323 Systems" for possible consent at the forthcoming SG16 meeting in April. The latest draft of H.460.mb is available at: http://ftp3.itu.ch/av-arch/avc-site/2005-2008/0511_Gen/AVD-2813a.zip Unfortunately, Q.25 did not have discussion of the potential security issues around H.460.mb at the last joint Rapporteurs Meeting in November 2005/Geneva. The draft text raises a few security questions as open … [View More]issues within Editor notes; there may or may not be more security issues which are not yet identified in the text; and there are also other non-security issues in the document that may deserve some closer view. Together with Paul Jones (Q.2/16 Rapporteur), I would like to take this opportunity to raise the issue at this point in time with the intention to solicit mailing list discussion and/or call for input contributions into the next SG16 meeting, allowing the two Questions to have a fruitful discussion on the draft and to determine how we move forward. Allow me to make a couple of remarks and also ask a few guiding questions: - H.460.mb operates in a multicast environment where H.323-based announcement servers broadcast to a pre-defined set of H.323 receivers/endpoints. As such, we could be interested to study how to secure such an environment. What type of security do we need, how to secure the involved entities? - To which degree can we leverage existing H.235.x Recommendations for usage in H.460.mb? - Where (signaling protection, media protection) do we need to study new (multicast) security mechanisms for this particular application? - Can we re-use any existing work from other groups for this purpose? - Should security for H.460.mb be addressed at this point in time, or can we add-in whatever security measures are necessary at a later/future point in time? - If we have to do something at least on security, what should it be about? What is the most pressing requirement from the market point of view? - Which security infrastructure is adequate for such a multicast scenario? Shared keys, PKI; key management, statically configured, dynamic negotiable? - ... Looking forward to your interest, feedback, views, contributions... With kind regards Martin Euchner. --------------------------------------------------------------------- | Dipl.-Inf. Rapporteur Q.25/16 | Martin Euchner Phone: +49 89 722 55790 | Siemens AG.....................Fax : +49 89 722 62366 | COM GCM PS 3 mailto:Martin.Euchner@siemens.com | mailto:martin.euchner@ties.itu.int | Hofmannstr. 51 Intranet: http://ietf.icn.siemens.de/sr3/Standardisation_Topics/security/ | D-81359 Muenchen Internet: http://www.siemens.de/ | __________________ | Germany --------------------------------------------------------------------- [View Less]

1 0

Request for contributions
by OKUBO Sakae 02 Mar '06

02 Mar '06

Dear WP2/16 experts, The next meeting of SG16 (3-13 April, Geneva) is rapidly approaching. Your contributions are requested on the following topics among other things: 1/ Ongoing works Annex 3 of Collective Letter 3/16 <http://www.itu.int/md/T05-SG16-COL-0003/en> list preliminary items to be discussed during the meeting. The list is attached after my signature for your convenience. 2/ Requirements for the "H.325" system We are continuing to identify what are required for the new … [View More] generation multimedia communication system codenamed "H.325". How it should interwork with NGN would be one of the discussion items; what facilities of NGN we can utilize for our purpose, what facilities we would like to define inside the NGN service stratum, ... 3/ IPTV (relaying Mr. Probst's messages) The TSB Director is organizing an informal consultative meeting on 4-5 April 2006 (see TSB-Circular 71) <http://www.itu.int/ITU-T/IPTV/index.phtml>. Please note that this event will take place during the second and third day of our SG16 meeting. It is likely that during this event, future work on the development of standards will be discussed as well as the role of the different ITU-T Study Groups. Please note that the subject has already been discussed at the last GSI NGN event in January 2006. It is my understanding, that IPTV should be considered here in the large sense of the term, that is distribution of TV programmes over IP on all kind of platforms (xDSL, Fibre, cable, satellite, Wi-Fi, Mobile, etc...). For SG16, there are two questions: a) What activities should we push in this field (e.g H.610 for IP, video codecs, ...) b) What role do we want to play in the coordination? 4/ Networked RFID (relaying Mr. Probst's message) The workshop held last month <http://www.itu.int/ITU-T/worksem/rfid/index.html> was a success both in terms of the information given and the participation of experts in and outside ITU-T. I would like to encourage you to look at the presentations and in particular at the conclusions of the different sessions. You should pay special attention to the conclusions of session 7 <http://www.itu.int/ITU-T/worksem/rfid/program.html>, which contains a list of topics of common interest between the different players active in the development of global standards. -- 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 ****************************************************************** Preliminary list of WP2/16 topics Q.1/16 Multimedia systems, terminals and data conferencing - Progress of H.324 issues relative to call setup acceleration techniques - Progress of H.241 issues relative to a computationally efficient H.264 and reference picture selection - Review of final text of revised T.120-series - Review of the items relative to H.320, H.324, T.120, H.310, etc. Q.2/16 Real-Time Audio, Video, and Data Communication over Packet-Switched Networks - Complete work on documents for consent: H.323v6, H.225.0v6 H.323 Annex Gv2, H.246, and H.460.mb - Progress work in these areas: H.323 Annex I, H.323/SIP Interworking, H.460.geo, H.dhcp, H.gaam, and H.presence Q.3/16 Multimedia Gateway Control Architectures and Protocols - Consent new packages: H.248.19 Amd.1, H.248.23 Cor. or Amd., H.248.BC, H.248.SDPSPEC, H.248.ADID, H.248.IPDC, H.248.DCME, H.248.MLPP, H.248.MGCInfo - Progress packages under consideration: H.248.RTPXtalk Q.4/16 Advanced multimedia communication service features on top of the ITU-T defined multimedia system platforms - Progress ongoing H.350.7 and User Input Indication works - Study new service features Q.5/16 Control of NAT and Firewall Traversal for H.300-Series Multimedia Systems - Progress work in these areas: H.proxy, NAT/FW Framework - Discussion of miscellaneous and new work items Q.21/16 Multimedia Architecture - Progress H.325 requirements and NGN studies - Progress H.saarch - Consideration of new materials, e.g. home networking Q.22/16 Multimedia applications and services - Progress videotelephony Recommendation - Study NGN multimedia services - Consideration of new services such as IPTV Q.24/16 Quality of Service and End-to-end Performance in Multimedia Systems - Consenting H.mmqos - Progressing H.mmqos Annexes A,B,C - Progressing H.trans.control Q.25/16 Multimedia Security in Next-Generation Networks (NGN-MM-SEC) - Progress H.FSIC, H.460.spn, H.mmqos security annex - Study of anti-DDOS MM-issues - Progress MM-NGN security Q.27/16 Telecommunications for Disaster Relief (TDR) Aspects of Multimedia Applications and Services - Carry out case studies - Establish a workplan, including workshops Q.28/16 Multimedia framework for e-health applications - Present and discuss the roadmap after comments from Q 28 experts - Present activities carried out within the eHSCG and HTTF group - Discuss a possible structure for the Recommendation on a ‘Framework for e-health applications in emergency situations’ Q.29/16 Mobility for Multimedia Systems and Services - Developing H.mmsm "Service Mobility for Multimedia Services" - Developing H.mmho "Extension of H.510 to support seamless handover of an H.323 session between different domains" ========== [View Less]

1 0

Re: Generic NAT/firewall traversal studies
by Christian Groves 12 Feb '06

12 Feb '06

Dear Mr. Okubo, With regards to the ETSI Tispan work there are a couple of items relevant to the NAT/Firewall traversal. They are: ETSI TS 102 233 "Gate Control Protocol" ETSI ES 283 018 "RACS: H.248 Profile for the Ia Interface" The Ia Interface Profile makes reference to H.248.37. Regards, Christian OKUBO Sakae wrote: > Dear Q.5/16 experts, > > At the last Rapporteur meeting in Geneva (28 November - 2 December > 2005), I undertook to survey the subject studies in other SGs. … [View More]Here is > some information as I have collected from the NGN-GSI event last month > and Study Group documents at the ITU-T site > <http://www.itu.int/ITU-T/meetingdocs/index.asp>: > > 1/ SG13 > > NGN RACF (Resource and Admission Control Functions) in the transport > stratum contains such functions as "NAPT control", "Firewall working > mode selection". A current draft of Recommendation Y.RACF is found as > TD-WP4-81R2 of SG13 at the 16-27 January 2006 directory. > > It contains definitions of NAP, NAT, NAPT control, NAT traversal in > Section 3. Section 6.2 is titled "NAPT Control and NAT Traversal > Mechanisms and Scenarios." Section 9.2 is titled "Procedures for NAPT > Control and NAT Traversal." > > This work is under Question 4/13 (Requirements and framework for QoS > for NGN). > > 2/ SG11 > > My understanding is that Q.5/11 (Resource control and signalling > requirements and protocols) deals with the protocols related to RACF. > Currently the following draft Recommendation is available as > TD-GEN/11-248 at the 23-27 January 2006 directory of SG11: > > Draft Q.rcp3 − Resource control protocol − Protocol at the Rn/Rw > (ex-Re) interface > > This should address the NAT/firewall traversal, but I cannot find > relevant descriptions there. Presumably it would be in "to be worked > out" status. Other protocols under development are listed in > TD-PLEN/11-74 of SG11. > > 3/ ETSI-TISPAN > > ETSI-TISPN is recommending to reuse its protocols in NGN in its > liaison to SG11 and SG13 (TD-GEN/11-241), and they would be containing > the NAT/firewall traversal, I heard. But I cannot spot a particular > TISPAN specification in that liaison. It was also mentioned that it > would be H.248 and NSIS related (sorry just key words I caught). We > got approval of H.248.37 (Gateway control protocol: IP NAPT traversal > package) from the previous SG16 meeting in July - August 2005. > Probably Q.3/16 expert (Mr. Schwarz?) could help me to clarify the > situation. > > 4/ SG9 > > It has Recommendation J.192 "A Residential Gateway to support the > delivery of cable data services" apparently addressing generic > firewall management solution, managed network address translation > among other things. > [View Less]

1 0

Generic NAT/firewall traversal studies
by OKUBO Sakae 10 Feb '06

10 Feb '06

Dear Q.5/16 experts, At the last Rapporteur meeting in Geneva (28 November - 2 December 2005), I undertook to survey the subject studies in other SGs. Here is some information as I have collected from the NGN-GSI event last month and Study Group documents at the ITU-T site <http://www.itu.int/ITU-T/meetingdocs/index.asp>: 1/ SG13 NGN RACF (Resource and Admission Control Functions) in the transport stratum contains such functions as "NAPT control", "Firewall working mode selection"… [View More]. A current draft of Recommendation Y.RACF is found as TD-WP4-81R2 of SG13 at the 16-27 January 2006 directory. It contains definitions of NAP, NAT, NAPT control, NAT traversal in Section 3. Section 6.2 is titled "NAPT Control and NAT Traversal Mechanisms and Scenarios." Section 9.2 is titled "Procedures for NAPT Control and NAT Traversal." This work is under Question 4/13 (Requirements and framework for QoS for NGN). 2/ SG11 My understanding is that Q.5/11 (Resource control and signalling requirements and protocols) deals with the protocols related to RACF. Currently the following draft Recommendation is available as TD-GEN/11-248 at the 23-27 January 2006 directory of SG11: Draft Q.rcp3 − Resource control protocol − Protocol at the Rn/Rw (ex-Re) interface This should address the NAT/firewall traversal, but I cannot find relevant descriptions there. Presumably it would be in "to be worked out" status. Other protocols under development are listed in TD-PLEN/11-74 of SG11. 3/ ETSI-TISPAN ETSI-TISPN is recommending to reuse its protocols in NGN in its liaison to SG11 and SG13 (TD-GEN/11-241), and they would be containing the NAT/firewall traversal, I heard. But I cannot spot a particular TISPAN specification in that liaison. It was also mentioned that it would be H.248 and NSIS related (sorry just key words I caught). We got approval of H.248.37 (Gateway control protocol: IP NAPT traversal package) from the previous SG16 meeting in July - August 2005. Probably Q.3/16 expert (Mr. Schwarz?) could help me to clarify the situation. 4/ SG9 It has Recommendation J.192 "A Residential Gateway to support the delivery of cable data services" apparently addressing generic firewall management solution, managed network address translation among other things. -- 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 ****************************************************************** [View Less]

1 0

Re: many-to-many relationship in H.248
by Christian Groves 25 Jan '06

25 Jan '06

Hello Sasha, As Albrecht says typically there's only one control association between an MGC-MG pair. An MG can be split into several Virtual MGs which in effect allow one physical MG to have a relationship with multiple MGCs. What scenario / functionality are you looking at? There may be another way via H.248 to achieve want you want. Regards, Christian Albrecht.Schwarz(a)alcatel.de wrote: >Sasha, > >guess this is impossible due to the Control Association concept in H.248. >… [View More]

1 0

Re: many-to-many relationship in H.248
by Albrecht.Schwarz＠alcatel.de 25 Jan '06

25 Jan '06

Sasha, guess this is impossible due to the Control Association concept in H.248. There's only a single Control Association between a MGC-MG pair. Regards, Albrecht PS You should Cc "megaco(a)ietf.org" for H.248 specific questions. "Sasha Ruditsky" … [View More]

1 0

many-to-many relationship in H.248
by Sasha Ruditsky 25 Jan '06

25 Jan '06

Hi In H.248 single MGC normally works with several MGs. However a particular MG works with a single MGC in any given moment of time. In a particular setup with which we are working it is necessary that an MGC instructs an MG to give notifications to a different MGC. Does somebody know a way to achieve this in current H.248? Do you think such way should be defined? Thanks, Sasha

1 0

FW: [AVT] I-D ACTION:draft-ietf-avt-rfc2032-bis-13.txt --> RTP Payload Format for H.261 Video Streams
by simao.campos＠ITU.INT 25 Jan '06

25 Jan '06

Dear experts, For your information. Best regards, Simão -----Original Message----- From: avt-bounces(a)ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Internet-Drafts(a)ietf.org Sent: 24 January 2006 00:50 To: i-d-announce(a)ietf.org Cc: avt(a)ietf.org Subject: [AVT] I-D ACTION:draft-ietf-avt-rfc2032-bis-13.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Working Group of the IETF. Title : RTP … [View More]Payload Format for H.261 Video Streams Author(s) : R. Even Filename : draft-ietf-avt-rfc2032-bis-13.txt Pages : 24 Date : 2006-1-23 This memo describes a scheme to packetize an H.261 video stream for transport using the Real-time Transport Protocol, RTP, with any of the underlying protocols that carry RTP. The memo also describes the syntax and semantics of the SDP parameters needed to support the H.261 video codec. A media type registration is included for this payload format. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avt-rfc2032-bis-13.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request(a)ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-avt-rfc2032-bis-13.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv(a)ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-avt-rfc2032-bis-13.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. [View Less]

1 0

RE: T310 timer and PROGRESS
by Horvath, Ernst 24 Jan '06

24 Jan '06

Paul, In QSIG, which is essentially a symmetrical variant of Q.931, T310 is stopped on receipt of a PROGRESS message with progress indication 1 or 8. This behaviour is useful for a number of supplementary services where expiry of T310 could terminate the call attempt too soon. Regards, Ernst ________________________________ From: Paul E. Jones [mailto:paulej@PACKETIZER.COM] Sent: Monday, January 23, 2006 11:51 PM To: itu-sg16(a)external.cisco.com Subject: T310 timer and PROGRESS … [View More]

1 0

RE: T310 timer and PROGRESS
by Paul E. Jones 23 Jan '06

23 Jan '06

Christian, Thanks for pointing this out to me. It would seem reasonable that we should probably bring over comparable wording to H.323 or, at the very least, list PROGRESS as one of the messages that stops the T310 timer. I suppose the further qualification would be that the PROGRESS message must contain a PI #8 or #1. Would this sound reasonable? If so, I'll draft such a contribution for the next meeting. Paul > -----Original Message----- > From: Christian Groves [mailto:cngroves@… [View More]bigpond.net.au] > Sent: Monday, January 23, 2006 6:11 PM > To: Paul E. Jones > Cc: itu-sg16(a)external.cisco.com > Subject: Re: T310 timer and PROGRESS > > G'Day Paul, > > I had a look at Q.931 as the precurser to H.225 to see what the > intention was there. Whilst not in the core specification there was a > description of the behaviour in an annex described Private Network > interconnection. > > > "M.6.3.1.3 In-band information provided to the physical > PINX at the originating interface > > Any progress indications shall be conveyed towards the physical PINX at > the originating interface. > > On receipt of the Progress description No. 1 or No. 8 in the PROGRESS or > ALERTING message, the physical PINX at the originating interface shall > switch through in the backward direction to the allocated B-channel in > order to enable transfer of in-band tones/information, and stop timer > T310, if running." > > > M.6.3.2.3 In-band information provided by the physical PINX > at the destination interface > > During call establishment, after the first message received in response > to the SETUP message, on receipt of a Progress indicator information > element with a Progress description No. 1 or No. 8 in the PROGRESS or > ALERTING message, the public network shall switch through in the > backward direction to the allocated B channel in order to enable in-band > tones/information provided from the physical PINX at the destination > interface to the calling user, stop timer T310, if running, and if > progress description No. 1 or No. 8 was received in the PROGRESS message > while T310 was running, restart timer T310. > > The public network shall transfer the Progress indicator information > element towards the preceding PINX." > > > Cheers, Christian > > Paul E. Jones wrote: > > > Experts, > > > > > > > > Recently, I asked what should happen when an endpoint receives a > > PROGRESS message indicating that there are in-band tones and > > announcements. Should the T310 timer be stopped? H.225.0 seems to be > > silent on this, but it would certainly seem that it should be stopped. > > > > > > > > Should we stop the timer or should the timer continue to run? It will > > expire in short order (assuming a default value), which suggests the > > timer ought to be terminated and T301 started. > > > > > > > > I would appreciate your input on this. > > > > > > > > Paul > > > > > > > [View Less]

1 0

T310 timer and PROGRESS
by Paul E. Jones 23 Jan '06

23 Jan '06

Experts, Recently, I asked what should happen when an endpoint receives a PROGRESS message indicating that there are in-band tones and announcements. Should the T310 timer be stopped? H.225.0 seems to be silent on this, but it would certainly seem that it should be stopped. Should we stop the timer or should the timer continue to run? It will expire in short order (assuming a default value), which suggests the timer ought to be terminated and T301 started. I would appreciate your … [View More]

2 1