- sg16-avd - lists.packetizer.com

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 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" ==========

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. 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. >

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". 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 ******************************************************************

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. >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" > <sasha@RADVISION To: <itu-sg16(a)external.cisco.com> > .COM> cc: > Subject: many-to-many relationship in H.248 > 25.01.2006 21:22 > > > > > >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

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" <sasha@RADVISION To: <itu-sg16(a)external.cisco.com> .COM> cc: Subject: many-to-many relationship in H.248 25.01.2006 21:22 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

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 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.

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 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

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@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 > > > > > > >

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 input on this. Paul

2 1