- sg16-avd - lists.packetizer.com

IP Telecom Services Workshop 2000: Call for Participation
by Gregory W. Bond 11 Aug '00

11 Aug '00

[Please accept our apologies for multiple copies of this call.] ------------- CALL FOR PARTICIPATION --------------- IP TELECOM SERVICES WORKSHOP 2000 (IPTS 2000) co-located with Fall 2000 Voice on the Net (VON) organized by AT&T Labs Research pulver.com Cobb Galleria, Atlanta, Georgia, U.S.A September 11, 2000 http://www.research.att.com/conf/ipts2000/ ----------------------------------------------------------- IPTS 2000 is a new workshop dedicated to the important, emerging field of IP Telecom Services research. In contrast to the services available on the PSTN, a new world of telecom services is possible on an IP-based infrastructure. This world presents new challenges for service development, deployment and management. This one-day workshop will serve as a forum for the dissemination of research relating to these challenges. We have put together an excellent technical program that includes 7 original research papers, two invited speakers, and a round table discussion. We look forward to the participation from you and your colleagues in the telecom industry and the research community. Registration is now open at http://pulver.com/ipts2000/register.html. TECHNICAL PROGRAM Keynote Speaker - Eric Sumner, President and CEO of dynamicsoft Invited Speaker - Joe Rinde, AT&T Labs "Why Service? What Services?" DFC as the basis for ECLIPSE, an IP communications software platform Greg Bond, Eric Cheung, Andrew Forrest, Michael Jackson, Hal Purdy, Chris Ramming, and Pamela Zave AT&T Labs Research Experimenting with PARLAY in a SIP Environment: Early Results Stephane Desrochers, Roch H. Glitho, Kindy Sylla Ericsson Research Canada Approach For Services in Converged Networks Sanjiv Kapur, Rakesh Vij Hughes Software Systems Unified Messaging using SIP and RTSP Kundan Singh and Henning Schulzrinne Columbia University SPHINX: A Study in Convergent Telephony and Advanced Scenarios for H.323-SIP Interoperation Kumar V. Vemuri Lucent Technologies Where Should Services Reside in Internet Telephony Systems? Xiaotao Wu and Henning Schulzrinne Columbia University A Transformation Approach for Service Creation in a Hybrid IP-IN Network Cyril Carrez, Elie Najm, Alexandre Tauveron Ecole Nationale Superieure des Telecom Roundtable Discussion - topic to be announced REGISTRATION IPTS 2000 will be held on September 11, 2000 in Atlanta, Georgia. The workshop will be co-located with Fall 2000 Voice on the Net (VON). Registration details for IPTS 2000 can be found at http://www.research.att.com/conf/ipts2000. Hotel information can be found at http://www.pulver.com/von/hotel.html. Registration for IPTS 2000 does not include registration for Fall 2000 VON. Registration details for Fall 2000 VON can be found at http://pulver.com/von. IPTS 2000 is organized by AT&T Labs Research (http://www.research.att.com) and pulver.com (http://pulver.com) WORKSHOP CO-CHAIRS Greg Bond, AT&T Labs Research Eric Cheung, AT&T Labs Research PROGRAM COMMITTEE Mauricio Arango, Sun Microsystems Labs Joanne Atlee, University of Waterloo Ralph Blumenthal, Daewoo Telecom Scott Hoffpauir, BroadSoft Evan Magill, University of Strathclyde Peter Mataga, dynamicsoft Bernie Pagurek, Carleton University Jonathan Rosenberg, dynamicsoft Henning Schulzrinne, Columbia University Greg Utas, Nortel Networks Pamela Zave, AT&T Labs Research FURTHER GENERAL INFORMATION http://www.research.att.com/conf/ipts2000 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: H.323 QOS
by Roy, Radhika R, ALCOO 11 Aug '00

11 Aug '00

Hi, Mike: The basic problem is to express the end-to-end H.323 QOS parameters of each medium (audio, video, data) that are applicable no matter what the underlying transport network (or networks) is. The answer of this problem is Table 1 that I have provided. Now we have to group those parameters in different combinations for each medium that makes sense from the enduser point of view to satisfy their requirements. This is the simple problem. A by-product of this solution needs to satisfy RSVP and ATM QOS as H.323v2/v3/v4 spec is doing today. I am surprised to see that you are still saying that your are NOT familiar with H.323. If it is so, we have problems. An editor needs to be on the top of everything because the last editor did a good amount of job in a very short period of time addressing all issues. We are now going backward and losing our valuable time just because the editor is NOT familiar with H.323. If you ask questions, I would be happy to answer as much as I can. I like to see other members also provide comments on this. Best regards, Radhika -----Original Message----- From: Mike Buckley [mailto:mikebuckley@44COMMS.COM] Sent: Friday, August 11, 2000 9:01 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: H.323 QOS Radhika, I think we are in total agreement until your last two paragraphs. Lets figure out what problem we are solving and what we need to do to achieve this, then examine the issues of backward compatibility. You are a lot more familiar than I am with the existing H.323 mechansims. Why are these not transport mechansm independent as per your model? Mike Mike Buckley +44-1457-877718 (T) +44-1457-877721 (F) mikebuckley(a)44comms.com ----- Original Message ----- From: "Roy, Radhika R, ALCOO" <rrroy(a)ATT.COM> To: <ITU-SG16(a)MAILBAG.INTEL.COM> Sent: Friday, August 11, 2000 12:58 PM Subject: Re: H.323 QOS Hi, Mike: Let me try again. What is the reference point of H.323 QOS? Is it not H.323? If it is so, what do we mean by H.323? The answer is: Audio (different codecs), Video (different codecs), and Data (T.120 applications) that are used by H.323. What are the QOS/performance characteristics of audio, video, and data from the application point of view that is generated by audio codecs, video codecs, and data (T.120) applications? These QOS/performance characteristics come from the SOURCE codecs and data applications. Per transport independent H.323 specifications, an enduser express their QOS/performance requirements on end-to-end basis purely from application point of view irrespective of the transport network (e.g., IP, ATM, etc.). Moreover, H.323 is meant for the packet network, not for any circuit-switched network like PSTN or ISDN. Let us NOT go beyond this before we start debating transport layer QOS or service provider requirements. These are NOT the concern of H.323. H.323 is the transport independent application. H.323v2/v3/v4 has also provided mechanisms how RSVP and ATM QOS can be used for H.323 audio, video, and data. So, H.323 QOS that will be defined in H.323 Annex N MUST provide mapping for the backward compatibility. It is a requirement that MUST be met per the norm of ITU-T. So, what is left for mapping? Mapping is simply a by-product of the above requirement. Mapping is simply a table, nothing else. Did I miss anything? Best regards, Radhika R. Roy AT&T -----Original Message----- From: Mike Buckley [mailto:mikebuckley@44COMMS.COM] Sent: Thursday, August 10, 2000 10:19 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: H.323 QOS Radhika, Thanks for the input which I welcome as I will unfortunately not be present at Portland. Let me ask a few questions and make a few comments hopefully with the intent of opening up the debate. 1. I am not sure I understand your concept of a mapping table between the H.323 QOS and the transport layer QoS. My understanding is that QoS is on three levels: a) that specified from a service point of view between the user and service provider (e.g PSTN quality, conference quality etc) This is the domain of the speech experts and can be characterised by Listener Speech Quaklity (MOS), end to end delay, and absolute category rating, R. b) application specific parameters, (e.g. equipment delays, codec choice and performance, codec frame size, packetisation arrangements, jitter buffer design, overall packet loss etc.) Optimisation of all these will determine what can be delivered in a). c) transport parameters for a given choice of application parameters. This boils down only to three parameters as far as I cna see: tranport network delay, packet delay variation in the transport network and packet loss in the transport network. Again these parameters will determine the results in a) for a given choice of the parameters in b). These parameters are generic from the perspective of the transport network. i.e the transport network does not need to know the details of the application. So the sequence of cause and effect and control is: a) User requests QoS class from service provider, b) Service provider determines application specific parameters in conjunction with users equipment and other service providers, c) Service provider requests required delay, delay variation and packet loss from network provider. I see no need for mapping here. The only QoS info flows within the application are specific to the application and those between the application (service provider) and the transport network are generic. i.e. delay, jitter and packet loss. Have I missed something? 2. The issue of bit rate and media stream statistics I think need to be decoupled from QoS. These are specified to enable optimisation of resources within the transport network. They have no QoS significance from an application point of view. i.e the apllication does not care about the media stream bit rate and statistics but the transport network provider does as it eats up his resource. They may be used for policy enforcement however in the transport network so they do need to be agreed between service provider and network operator. i.e the network operator agrees to provide a given QoS level (delay, jitter, packet loss) provided the media properties are within an agreed profile (bit rate, flow statistics). 3. The next point is how can the service provider know the statistics of a particular VBR stream? These can only be specified over a large number of similar calls and will depend, for instance, on who is speaking, the nature of the speech interaction etc etc. They can only be measured not calculated. The service provider is in no better position to measure these than the transport network operator and, in fact, where no gateways are involved, may not be able to. On the other hand the class of signal would have to be signalled to the network operator for him to be able to distinguish which class a particular measurement belonged to. e.g voice/speech/data, codec type, conference, multicast etc. So I see no purpose in trying to exchange statistics between the service provider (application) and transport operator. I think peak bit rate is all that can be meaningfully excanged. The specification of media class is however perhaps worth exploring. 4. The controlled category has always puzzled me. I only see two possibilities. Either the requested QoS level is guaranteed (on a statistical basis e.g 95% of all connections over a specified period) or not guaranteed. Is your controlled category a way of saying guaranteed, not to 95% but to some lower figure? If you can't put a percentage on it then it seems it is plain and simple not guaranteed. Anything that is not guaranteed to some specified statistical level is best effort and you can't say anything more about it. So I only see two categories here. In summary, I think we need to do three things in Annex N. a) Figure out the QoS information to be exchanged within the Application between service providers and end users. This will go in H.225.0 and H.245. b) Figure out how we are going to signal QoS and media information between the application (service providers) and transport domains (IP or ATM networks etc). The info is basically delay, jitter, packet loss requirements and peak bit rate. We need a protocol for this. c) we need to work out the interactions between the application QoS signal flows and the application/transport signal flows. I don't think we need worry about how the transport network mechanisms assure the requested QoS paramerters. RSVP/Intserv, Diffserv, MPLS, ATM, over provisioning are all possibilities. Would welcome comments and views on the above. Mike Mike Buckley +44-1457-877718 (T) +44-1457-877721 (F) mikebuckley(a)44comms.com ----- Original Message ----- From: "Roy, Radhika R, ALCOO" <rrroy(a)ATT.COM> To: <ITU-SG16(a)MAILBAG.INTEL.COM> Sent: Thursday, August 10, 2000 10:15 PM Subject: H.323 QOS Hi, Mike and All: It is time to discuss about H.323 QOS. I believe that we have an agreement as follows: · H.323 QOS MUST be backward compatible to support RSVP and ATM QOS as it exists for H.323v2/v3/v4 · Like H.323 spec, the application level H.323 QOS MUST be independent of the transport layer QOS and should support all transport networks (e.g., IP, ATM) · A mapping table between the H.323 QOS and the transport layer QOS (e.g., IP QOS [DiffServ, RSVP, etc.], ATM QOS [CBR, rt-VBR, nrt-VBR, ABR, etc.]) should be provided. >From the H.323 multimedia application point of view, there are following performance parameters can be used to characterize the traffic characteristics: · Bitrate characteristics: Peak bit rate (PBR) or peak rate (PR), Sustained bit rate (SBR) or average rate (AR), minimum bit rate (MBR) or minimum rate (MR), and mean bust size (MBS) · Delay and loss characteristics: end-to-end delay (EED) or delay, end-to-end delay variation (EEDV) or delay variation (DV), and bit-error-rate (BER) or (packet) loss rate (LR) We can now form a table with all parameters as follows: Table 1: H.323 Multimedia Application Performance Matrix Audio (codecs)--- Video (codecs)--- Data (T.120) PBR/PR Yes/No/Value Yes/No/Value Yes/No/value SBR/AR Yes/No/Value Yes/No/Value Yes/No/value MBR/MR Yes/No/Value Yes/No/Value Yes/No/value MBS Yes/No/Value Yes/No/Value Yes/No/value EED/Delay Yes/No/Value Yes/No/Value Yes/No/value EEDV/DV Yes/No/Value Yes/No/Value Yes/No/value BER/LR Yes/No/Value Yes/No/Value Yes/No/value >From the above table we will have the opportunity to choose each parameter for each medium (audio, video, data) that makes sense from the application's and enduser's point of view. Again, these parameters can be specified as follows: · Guaranteed: The value specified for each parameter MUST be guaranteed. · Controlled: The value specified for each parameter MAY be satisfied as far as practicable (possibly with certain range), but definitely NOT guaranteed. · Best effort: No commitment will be made. Now each medium (e.g., audio, video, or data) will have different categories of performance matrix depending on its selection criteria and this can also be mapped to RSVP, ATM QOS, and others, if needed. Once we agree on this format, the next step is to create H.323 QOS signaling messages. This is my input for discussion in the upcoming Portland Q.13 meeting for H.323 QOS. I like to see the comments from other members as well. Best regards, Radhika R. Roy AT&T +1 732 420 1580 rrroy(a)att.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1

security contributions APC-1907, APC-1908 and APC-1937 uploaded
by Euchner Martin 11 Aug '00

11 Aug '00

Dear SG 16 experts, I've just uploaded the following contributions to the Incoming directory of the avc-site. The files will be moved to the Portland directory ftp://standard.pictel.com/avc-site/0008_Por/ <ftp://standard.pictel.com/avc-site/0008_Por/> after some time. APC-1907 Editor (M Euchner) New Draft H.235 Version 3 APC-1908 Editor (M Euchner) Resolution of an inconsistency in Draft H.235 Version 2 regarding the use of the initial value APC-1937 Siemens AG Security for H.323 Mobile Scenarios - Security for H.323 Annex H/H.235v3 Annex G Please note that APC-1907 provides an embedded word97 attachment within the cover word doc. Regards, Martin. ----------------------------------------------------------------------- | Dipl.-Inf. Phone: +49 89 636-46201 | Martin Euchner Fax : +49 89 636-48000 | Siemens AG | ZT IK 3 mailto:Martin.Euchner@mchp.siemens.de | mailto:martin.euchner@ties.itu.int | Otto-Hahn-Ring 6 Intranet: http://zt-security.mchp.siemens.de/de/Competence/Standardization/ITU-T_SG16/ index.html | D-81730 Muenchen Internet: http://www.siemens.de | __________________ | Germany ----------------------------------------------------------------------- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

APC-1923 uploaded
by John Segers 11 Aug '00

11 Aug '00

Dear SG 16 experts, Editor's contribution APC-1923 (Errors and unclarities in Recommendation H.248) has just been uploaded to the incoming directory on the picturetel ftp server. Best regards, John Segers -- John Segers email: jsegers(a)lucent.com Lucent Technologies Room HE 303 Dept. Forward Looking Work phone: +31 35 687 4724 P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

APC 1876 and 1877
by Horvath Ernst 11 Aug '00

11 Aug '00

APC-1876 (draft H.450.10) and APC-1877 (draft H.450.11) have been placed in the Incoming directory of the ftp site. Regards, Ernst Horvath Siemens AG ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

APC-1922 uploaded
by Michael Fortinsky 11 Aug '00

11 Aug '00

APC-1922.zip ("Correction to H.225.0 Annex G UsageSpecification") has been uploaded to the Incoming directory at the Pictel avc-site. Michael Fortinsky ----------------------------------------------------------------- Senior Program Manager, IP Telephony Group, VocalTec Communications Ltd. Email: mike(a)vocaltec.com Tel: 972 9 9707768 Fax: 972 9 9561867

1 0

Re: H.323 QOS
by Roy, Radhika R, ALCOO 11 Aug '00

11 Aug '00

Hi, Mike: Let me try again. What is the reference point of H.323 QOS? Is it not H.323? If it is so, what do we mean by H.323? The answer is: Audio (different codecs), Video (different codecs), and Data (T.120 applications) that are used by H.323. What are the QOS/performance characteristics of audio, video, and data from the application point of view that is generated by audio codecs, video codecs, and data (T.120) applications? These QOS/performance characteristics come from the SOURCE codecs and data applications. Per transport independent H.323 specifications, an enduser express their QOS/performance requirements on end-to-end basis purely from application point of view irrespective of the transport network (e.g., IP, ATM, etc.). Moreover, H.323 is meant for the packet network, not for any circuit-switched network like PSTN or ISDN. Let us NOT go beyond this before we start debating transport layer QOS or service provider requirements. These are NOT the concern of H.323. H.323 is the transport independent application. H.323v2/v3/v4 has also provided mechanisms how RSVP and ATM QOS can be used for H.323 audio, video, and data. So, H.323 QOS that will be defined in H.323 Annex N MUST provide mapping for the backward compatibility. It is a requirement that MUST be met per the norm of ITU-T. So, what is left for mapping? Mapping is simply a by-product of the above requirement. Mapping is simply a table, nothing else. Did I miss anything? Best regards, Radhika R. Roy AT&T -----Original Message----- From: Mike Buckley [mailto:mikebuckley@44COMMS.COM] Sent: Thursday, August 10, 2000 10:19 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: H.323 QOS Radhika, Thanks for the input which I welcome as I will unfortunately not be present at Portland. Let me ask a few questions and make a few comments hopefully with the intent of opening up the debate. 1. I am not sure I understand your concept of a mapping table between the H.323 QOS and the transport layer QoS. My understanding is that QoS is on three levels: a) that specified from a service point of view between the user and service provider (e.g PSTN quality, conference quality etc) This is the domain of the speech experts and can be characterised by Listener Speech Quaklity (MOS), end to end delay, and absolute category rating, R. b) application specific parameters, (e.g. equipment delays, codec choice and performance, codec frame size, packetisation arrangements, jitter buffer design, overall packet loss etc.) Optimisation of all these will determine what can be delivered in a). c) transport parameters for a given choice of application parameters. This boils down only to three parameters as far as I cna see: tranport network delay, packet delay variation in the transport network and packet loss in the transport network. Again these parameters will determine the results in a) for a given choice of the parameters in b). These parameters are generic from the perspective of the transport network. i.e the transport network does not need to know the details of the application. So the sequence of cause and effect and control is: a) User requests QoS class from service provider, b) Service provider determines application specific parameters in conjunction with users equipment and other service providers, c) Service provider requests required delay, delay variation and packet loss from network provider. I see no need for mapping here. The only QoS info flows within the application are specific to the application and those between the application (service provider) and the transport network are generic. i.e. delay, jitter and packet loss. Have I missed something? 2. The issue of bit rate and media stream statistics I think need to be decoupled from QoS. These are specified to enable optimisation of resources within the transport network. They have no QoS significance from an application point of view. i.e the apllication does not care about the media stream bit rate and statistics but the transport network provider does as it eats up his resource. They may be used for policy enforcement however in the transport network so they do need to be agreed between service provider and network operator. i.e the network operator agrees to provide a given QoS level (delay, jitter, packet loss) provided the media properties are within an agreed profile (bit rate, flow statistics). 3. The next point is how can the service provider know the statistics of a particular VBR stream? These can only be specified over a large number of similar calls and will depend, for instance, on who is speaking, the nature of the speech interaction etc etc. They can only be measured not calculated. The service provider is in no better position to measure these than the transport network operator and, in fact, where no gateways are involved, may not be able to. On the other hand the class of signal would have to be signalled to the network operator for him to be able to distinguish which class a particular measurement belonged to. e.g voice/speech/data, codec type, conference, multicast etc. So I see no purpose in trying to exchange statistics between the service provider (application) and transport operator. I think peak bit rate is all that can be meaningfully excanged. The specification of media class is however perhaps worth exploring. 4. The controlled category has always puzzled me. I only see two possibilities. Either the requested QoS level is guaranteed (on a statistical basis e.g 95% of all connections over a specified period) or not guaranteed. Is your controlled category a way of saying guaranteed, not to 95% but to some lower figure? If you can't put a percentage on it then it seems it is plain and simple not guaranteed. Anything that is not guaranteed to some specified statistical level is best effort and you can't say anything more about it. So I only see two categories here. In summary, I think we need to do three things in Annex N. a) Figure out the QoS information to be exchanged within the Application between service providers and end users. This will go in H.225.0 and H.245. b) Figure out how we are going to signal QoS and media information between the application (service providers) and transport domains (IP or ATM networks etc). The info is basically delay, jitter, packet loss requirements and peak bit rate. We need a protocol for this. c) we need to work out the interactions between the application QoS signal flows and the application/transport signal flows. I don't think we need worry about how the transport network mechanisms assure the requested QoS paramerters. RSVP/Intserv, Diffserv, MPLS, ATM, over provisioning are all possibilities. Would welcome comments and views on the above. Mike Mike Buckley +44-1457-877718 (T) +44-1457-877721 (F) mikebuckley(a)44comms.com ----- Original Message ----- From: "Roy, Radhika R, ALCOO" <rrroy(a)ATT.COM> To: <ITU-SG16(a)MAILBAG.INTEL.COM> Sent: Thursday, August 10, 2000 10:15 PM Subject: H.323 QOS Hi, Mike and All: It is time to discuss about H.323 QOS. I believe that we have an agreement as follows: · H.323 QOS MUST be backward compatible to support RSVP and ATM QOS as it exists for H.323v2/v3/v4 · Like H.323 spec, the application level H.323 QOS MUST be independent of the transport layer QOS and should support all transport networks (e.g., IP, ATM) · A mapping table between the H.323 QOS and the transport layer QOS (e.g., IP QOS [DiffServ, RSVP, etc.], ATM QOS [CBR, rt-VBR, nrt-VBR, ABR, etc.]) should be provided. >From the H.323 multimedia application point of view, there are following performance parameters can be used to characterize the traffic characteristics: · Bitrate characteristics: Peak bit rate (PBR) or peak rate (PR), Sustained bit rate (SBR) or average rate (AR), minimum bit rate (MBR) or minimum rate (MR), and mean bust size (MBS) · Delay and loss characteristics: end-to-end delay (EED) or delay, end-to-end delay variation (EEDV) or delay variation (DV), and bit-error-rate (BER) or (packet) loss rate (LR) We can now form a table with all parameters as follows: Table 1: H.323 Multimedia Application Performance Matrix Audio (codecs)--- Video (codecs)--- Data (T.120) PBR/PR Yes/No/Value Yes/No/Value Yes/No/value SBR/AR Yes/No/Value Yes/No/Value Yes/No/value MBR/MR Yes/No/Value Yes/No/Value Yes/No/value MBS Yes/No/Value Yes/No/Value Yes/No/value EED/Delay Yes/No/Value Yes/No/Value Yes/No/value EEDV/DV Yes/No/Value Yes/No/Value Yes/No/value BER/LR Yes/No/Value Yes/No/Value Yes/No/value >From the above table we will have the opportunity to choose each parameter for each medium (audio, video, data) that makes sense from the application's and enduser's point of view. Again, these parameters can be specified as follows: · Guaranteed: The value specified for each parameter MUST be guaranteed. · Controlled: The value specified for each parameter MAY be satisfied as far as practicable (possibly with certain range), but definitely NOT guaranteed. · Best effort: No commitment will be made. Now each medium (e.g., audio, video, or data) will have different categories of performance matrix depending on its selection criteria and this can also be mapped to RSVP, ATM QOS, and others, if needed. Once we agree on this format, the next step is to create H.323 QOS signaling messages. This is my input for discussion in the upcoming Portland Q.13 meeting for H.323 QOS. I like to see the comments from other members as well. Best regards, Radhika R. Roy AT&T +1 732 420 1580 rrroy(a)att.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1

Re: Contribution APC-1885 from Hughes Software Systems
by Sakae OKUBO 10 Aug '00

10 Aug '00

Dear contributors, At 17:30 +0530 00/08/10, rogupta(a)hss.hns.com wrote: >Please accept out contribution APC-1885 titled "Enabling H.323-based IVRs >in the intelligent network" for the Portland meeting. This has been uploaded to /0008_Por directory. At 09:12 -0400 00/08/10, Roy, Radhika R, ALCOO wrote: >Kindly provide me an APC number for the following contribution: >Comments on H.323 Annex H: User, Terminal and Service Mobility (MTD 101b - >Editor's Contribution) APC-1932 has been allocated. At 14:20 +0100 00/08/10, Pete Cordell wrote: >We have decided that we need to update the ASN.1 names used in APC-1845 >(a document carried over from Osaka on Annex G) to conform with those >used in the white papers. These are minor changes of an editorial >nature, but as we shall be re-submitting the document, please can you >supply us with an additional APC number. > >The new name of the document is: >Apply the Generic Framework to Annex G APC-1933 has been allocated. APC-1845 has been dropped from the contribution list. At 23:58 +0900 00/08/10, Motoaki Ishii wrote: >Kindly provide me an APC number for the following contribution: >Comments to H.323 Annex K APC-1934 has been allocated. At 11:15 -0400 00/08/10, Orit Levin wrote: >I would like to ask you to assign APC numbers for the following >RADVision's contributions: >"Draft of H.323 Annex O" (Editor, Orit Levin) >"Expansion of McuInfo field definition in H.225.0" APC-1935 and APC-1936 have been allocated. At 18:22 +0200 00/08/10, Euchner Martin wrote: > Please assign one APC number for the following Siemens contribution: >* "Security for H.323 Mobile Scenarios - Security for H.323 Annex >H/H.235v3 Annex G" APC-1937 has been allocated. At 16:12 -0400 00/08/10, Dave Walker wrote: >Please allocate an APC number for draft H.323 Annex L Stimulus Signalling >(source: editor). APC-1938 has been allocated. Please find attached an update of the contribution list reflecting the above allocation. Best regards, Sakae OKUBO *********************************************************** Waseda Research Center Telecommunications Advancement Organization of Japan (TAO) 5th Floor, Nishi-Waseda Bldg. 1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan Tel: +81 3 5286 3830 (to be transferred) +81 3 3204 8194 (direct) Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp *********************************************************** Contributions for the Q12-14/16 Rapporteur meeting in Portland (21 -25 August 2000) ------< carried over from the Osaka meeting >------ APC-1765 AT&T Scope of H.323 QOS APC-1766 AT&T Requirements of H.323 QOS APC-1767 AT&T Architecture of H.323 QOS APC-1768 AT&T Specification of H.323 QOS Characteristics APC-1796 Editor (M Fortinsky) H.225.0 Annex G version1 - with corrections ------< registration for the Portland meeting >------ APC-1872 Q22/11 Liaison to SG16 On Interaction Between Intelligent Network Systems and H.248 APC-1873 Q22/11 Liaison to SG16 On Interworking Between H.323 Systems and Intelligent Network Systems APC-1874 Editor (P Jones) Draft H.323 version 4 APC-1875 Editor (P Jones) H.323-series Implementers Guide APC-1876 Editor (K Klaghofer) Draft Call Offer Supplementary Service for H.323 APC-1877 Editor (K Klaghofer) Draft Call Intrusion Supplementary Service for H.323 APC-1878 Editor (T Anderson) Draft H.323 Annex R (Robustness) APC-1879 Lucent Technologies Reference Points for the Use of Annex G APC-1880 Editor (F Audet) H.323 Annex M.1 "Tunnelling of signalling protocols (QSIG) in H.323" APC-1881 Nortel Networks Enforcing symmetric operation in the context of slow start for H.323v4 APC-1882 Nortel Networks Minor correction to H.323 Annex M.1 APC-1883 Columbia University CPL: A Language for User Control of Internet Telephony Services APC-1884 SONUS Decomposition of Gatekeeper Functions inside a Domain APC-1885 Hughes Software Systems { to suggest amendments in the H.323 standard } APC-1886 Columbia University RFC-2824: Call Processing Language Framework and Requirements APC-1887 Siemens AG H.450.12 - Common Information Additional Network Feature for H.323 APC-1888 Siemens AG M.3 - Tunneling of DSS1 in H.323 APC-1889 Q4/8 Voice/fax switching in draft H.323 Annex D v2 APC-1890 Q4/8 Facsimile related work on draft H.248 Annex F APC-1891 Q4/8 Draft T.38 Appendix V H.248 Call Establishment Procedure Examples APC-1892 Q4/8 Proposed Edits to H.248 Annex F APC-1893 PictureTel Proposed H.242/H.245 text for dynamicPictureResizingByFour APC-1894 ALCATEL Modification to H.323 annex H APC-1895 ETSI TIPHON WG8 Liaison statement subject: "H.235 Hybrid Security Profile" APC-1896 BT Use of the Generic Framework during Registration and other RAS Messaging APC-1897 BT Additional Data Types for GenericData APC-1898 BT Clarification on the Handling of Unknown conferenceGoals APC-1899 Lucent Technologies Fast Channel Open for H.245 APC-1900 Editor (P Reddy) H.246 Annex E.1 Interworking between H.225.0 and PLMN's Mobile Application Parts APC-1901 Editor (P Reddy) H.246 Annex E.2 Interworking between H.225.0 and ANSI-41 PLMN Mobile Application Part APC-1902 Intel H.323 Mobility services using IETF's Mobile IP and new extended protocols APC-1903 Editor (M Fortinsky) H.225.0 Annex G version 2 - draft APC-1904 Avaya DES with Output Feedback for Audio Encryption in H.235v3 APC-1905 UCLA Draft text for "Generic Uneven Level Protection (ULP)" for Annex I of H.323 APC-1906 UCLA Simulation results of ULP for transmission over error prone channels APC-1907 Editor (M Euchner) New Draft H.235 Version 3 APC-1908 Editor (M Euchner) Resolution of an inconsistency in Draft H.235 Version 2 regarding the use of the initial value APC-1909 Editor (J Sundquist) H.323 Annex H Draft APC-1910 LM Ericsson Addition to Implementor's guide to H.248 APC-1911 LM Ericsson Change of Capabilities indicated in H.248 ServiceChange APC-1912 LM Ericsson H.248 Annex L - Error Code and Service Change Reason Description APC-1913 LM Ericsson Improved Auditing in H.248 Version 2 APC-1914 LM Ericsson Comments to H.248 Annex K APC-1915 Editor (P Jones) Fast Connect SDLs Issues APC-1916 Editor (P Jones) Corrections to the H.323v4 White Paper Contribution APC-1917 Cisco Systems JAIN APIs for Integrated Networks APC-1918 Cisco Systems Interworking with Different Versions of H.323 Entities APC-1919 Cisco Systems Comments on the Object Extensible Framework APC-1920 Cisco Systems Third Party Re-Routing of a Fast Connect Initiated Call APC-1921 Cisco Systems Early Termination of Fast Connect APC-1922 Trillium Digital Systems, VocalTec Communications Correction to the H.225.0 Annex G UsageSpecification APC-1923 Editor (J Segers) Errors and unclarities in Recommendation H.248 APC-1924 Editor (T Taylor) Draft H.248 Annex M: Advanced Audio Server Packages APC-1925 Megaco Chair (T Taylor) IETF Megaco Comments On H.248 Annexes F, G, and H APC-1926 AT&T H.323 Intra-Zone Mobility Management using AuF and HLF APC-1927 Cisco Systems Reserving Resources for Calls APC-1928 Cisco Systems LRQ Forwarding APC-1929 Cisco Systems Alternate Gatekeeper Clarifications APC-1930 Siemens, Intel H.323 Mobility Service Descriptions APC-1931 Siemens, Intel Interaction of H.323 Mobility with H.450 Supplementary Services APC-1932 AT&T Comments on H.323 Annex H: User, Terminal and Service Mobility (MTD 101b - Editor's Contribution) APC-1933 BT Apply the Generic Framework to Annex G APC-1934 INTEC Web and Genome Informatics Corp. Comments to H.323 Annex K APC-1935 Editor (O Levin) Draft of H.323 Annex O APC-1936 RADVision Expansion of McuInfo field definition in H.225.0 APC-1937 Siemens Security for H.323 Mobile Scenarios - Security for H.323 Annex H/H.235v3 Annex G APC-1938 Editor (D Walker) Draft H.323 Annex L Stimulus Signalling --------------- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

H.323 QOS
by Roy, Radhika R, ALCOO 10 Aug '00

10 Aug '00

Hi, Mike and All: It is time to discuss about H.323 QOS. I believe that we have an agreement as follows: · H.323 QOS MUST be backward compatible to support RSVP and ATM QOS as it exists for H.323v2/v3/v4 · Like H.323 spec, the application level H.323 QOS MUST be independent of the transport layer QOS and should support all transport networks (e.g., IP, ATM) · A mapping table between the H.323 QOS and the transport layer QOS (e.g., IP QOS [DiffServ, RSVP, etc.], ATM QOS [CBR, rt-VBR, nrt-VBR, ABR, etc.]) should be provided. >From the H.323 multimedia application point of view, there are following performance parameters can be used to characterize the traffic characteristics: · Bitrate characteristics: Peak bit rate (PBR) or peak rate (PR), Sustained bit rate (SBR) or average rate (AR), minimum bit rate (MBR) or minimum rate (MR), and mean bust size (MBS) · Delay and loss characteristics: end-to-end delay (EED) or delay, end-to-end delay variation (EEDV) or delay variation (DV), and bit-error-rate (BER) or (packet) loss rate (LR) We can now form a table with all parameters as follows: Table 1: H.323 Multimedia Application Performance Matrix Audio (codecs)--- Video (codecs)--- Data (T.120) PBR/PR Yes/No/Value Yes/No/Value Yes/No/value SBR/AR Yes/No/Value Yes/No/Value Yes/No/value MBR/MR Yes/No/Value Yes/No/Value Yes/No/value MBS Yes/No/Value Yes/No/Value Yes/No/value EED/Delay Yes/No/Value Yes/No/Value Yes/No/value EEDV/DV Yes/No/Value Yes/No/Value Yes/No/value BER/LR Yes/No/Value Yes/No/Value Yes/No/value >From the above table we will have the opportunity to choose each parameter for each medium (audio, video, data) that makes sense from the application's and enduser's point of view. Again, these parameters can be specified as follows: · Guaranteed: The value specified for each parameter MUST be guaranteed. · Controlled: The value specified for each parameter MAY be satisfied as far as practicable (possibly with certain range), but definitely NOT guaranteed. · Best effort: No commitment will be made. Now each medium (e.g., audio, video, or data) will have different categories of performance matrix depending on its selection criteria and this can also be mapped to RSVP, ATM QOS, and others, if needed. Once we agree on this format, the next step is to create H.323 QOS signaling messages. This is my input for discussion in the upcoming Portland Q.13 meeting for H.323 QOS. I like to see the comments from other members as well. Best regards, Radhika R. Roy AT&T +1 732 420 1580 rrroy(a)att.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1

Generic Framework APCs Uploaded
by Pete Cordell 10 Aug '00

10 Aug '00

Dear SG16 members, The following APCs have ben uploaded to the PictureTel Incoming directory: APC-1896 BT Use of the Generic Framework during Registration and other RAS Messaging APC-1897 BT Additional Data Types for GenericData APC-1898 BT Clarification on the Handling of Unknown conferenceGoals Regards, Pete. -- ============================================= Pete Cordell BT Adastral Park pete(a)labyrinth.co.uk (or pete(a)tech-know-ware.com) +44 1473 645411 (or +44 1473 635863) ============================================= ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: message lengths for h.225 & h.245 ?
by Shubha Ramani 10 Aug '00

10 Aug '00

You answered my question. Thanks !! Shubha --- "Paul E. Jones" <paulej(a)PACKETIZER.COM> wrote: > Shubha, > > I'm not sure if I understand your question or not, but are curious > about how > messages are delimited? If that's the case, you can refer to > RFC-1006. The > delimiter is a 4 byte header on the packets referred to as the TPKT > header. > > Messages are restricted in size to about 64K, since the message > length is > given in the last two bytes of the TPKT header. > > Does this answer your question or did I completely misunderstand your > question? > > Best Regards, > Paul > > ----- Original Message ----- > From: "Shubha Ramani" <shubha(a)XYBRIDGE.COM> > To: <ITU-SG16(a)mailbag.cps.intel.com> > Sent: Wednesday, August 09, 2000 6:32 PM > Subject: message lengths for h.225 & h.245 ? > > > > How are application level message lengths handled for H.225 and > H.245 > > messages ? Is there something within the protocol definition that > gives > > guidelines as to how message lengths are computed ? Where in the > standards > > is this procedure described ? > > > > > > Please help ! > > > > Shubha > > > > Shubha D. Ramani > > <mailto:shubha@xybridge.com> or <mailto:shubharamani@yahoo.com> > > 3G/Mobility Product Test & Integration - XYBRIDGE Technologies > > 3400 Waterview Pkwy Ste# 107 > > Richardson, Texas 75080 > > 214-570-8600 x1028, x2056(lab), cell:214-770-2850 > > <http://www.xybridge.com/> > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > For help on this mail list, send "HELP ITU-SG16" in a message to > > listserv(a)mailbag.intel.com > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com > > ===== Shubha D. Ramani <mailto:shubha@xybridge.com> or <mailto:shubharamani@yahoo.com> 3G/Mobility Product Test & Integration - XYBRIDGE Technologies 3400 Waterview Pkwy Ste# 107 Richardson, Texas 75080 214-570-8600 x1028, x2056(lab), cell:214-770-2850 <http://www.xybridge.com/> __________________________________________________ Do You Yahoo!? Kick off your party with Yahoo! Invites. http://invites.yahoo.com/ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Please provide me an APC number ...
by Motoaki Ishii 10 Aug '00

10 Aug '00

Dear Mr. OKUBO: Kindly provide me an APC number for the following contribution: Comments to H.323 Annex K Best regards, --- Motoaki Ishii INTEC Web and Genome Informatics Corp. +81 76 444 8088 motoaki(a)isl.intec.co.jp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

APC-number
by Roy, Radhika R, ALCOO 10 Aug '00

10 Aug '00

Dear Mr. OKUBO: Kindly provide me an APC number for the following contribution: Comments on H.323 Annex H: User, Terminal and Service Mobility (MTD 101b - Editor's Contribution) Best regards, Radhika R. Roy AT&T +1 732 420 1580 rrroy(a)att.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: APC number for Portland
by Sakae OKUBO 10 Aug '00

10 Aug '00

Dear Mr. Roelands, In response to your request, the following APC numbers have been allocated to your two contributions: APC-1930 >Title: H.323 Mobility Service Descriptions >Source: Siemens, Intel APC-1931 >Title: Interaction of H.323 Mobility with H.450 Supplementary Services >Source: Siemens, Intel Best regards, Sakae OKUBO *********************************************************** Waseda Research Center Telecommunications Advancement Organization of Japan (TAO) 5th Floor, Nishi-Waseda Bldg. 1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan Tel: +81 3 5286 3830 (to be transferred) +81 3 3204 8194 (direct) Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp *********************************************************** ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: Request for APC numbers
by Sakae OKUBO 10 Aug '00

10 Aug '00

Dear Mr. Jones, APC numbers have been allocated to your three contributions as follows: APC-1927 Cisco Systems Reserving Resources for Calls APC-1928 Cisco Systems LRQ Forwarding APC-1929 Cisco Systems Alternate Gatekeeper Clarifications Best regards, Sakae OKUBO *********************************************************** Waseda Research Center Telecommunications Advancement Organization of Japan (TAO) 5th Floor, Nishi-Waseda Bldg. 1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan Tel: +81 3 5286 3830 (to be transferred) +81 3 3204 8194 (direct) Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp *********************************************************** ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

message lengths for h.225 & h.245 ?
by Shubha Ramani 10 Aug '00

10 Aug '00

How are application level message lengths handled for H.225 and H.245 messages ? Is there something within the protocol definition that gives guidelines as to how message lengths are computed ? Where in the standards is this procedure described ? Please help ! Shubha Shubha D. Ramani <mailto:shubha@xybridge.com> or <mailto:shubharamani@yahoo.com> 3G/Mobility Product Test & Integration - XYBRIDGE Technologies 3400 Waterview Pkwy Ste# 107 Richardson, Texas 75080 214-570-8600 x1028, x2056(lab), cell:214-770-2850 <http://www.xybridge.com/> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1

Re: New APC Number
by Sakae OKUBO 09 Aug '00

09 Aug '00

Dear Mr. Taylor, Mr. Roy and all, The following APC numbers have been allocated to your contributions: APC-1924 Editor (T Taylor) Draft H.248 Annex M: Advanced Audio Server Packages APC-1925 Megaco Chair (T Taylor) IETF Megaco Comments On H.248 Annexes F, G, and H APC-1926 AT&T H.323 Intra-Zone Mobility Management using AuF and HLF Please find attached an updated list of contributions registered for the Portland meeting. Please note that APC-1781 (from Osaka) has been dropped as APC-1879 supercedes it. Best regards, Sakae OKUBO *********************************************************** Waseda Research Center Telecommunications Advancement Organization of Japan (TAO) 5th Floor, Nishi-Waseda Bldg. 1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan Tel: +81 3 5286 3830 (to be transferred) +81 3 3204 8194 (direct) Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp *********************************************************** Contributions for the Q12-14/16 Rapporteur meeting in Portland (21 -25 August 2000) ------< carried over from the Osaka meeting >------ APC-1765 AT&T Scope of H.323 QOS APC-1766 AT&T Requirements of H.323 QOS APC-1767 AT&T Architecture of H.323 QOS APC-1768 AT&T Specification of H.323 QOS Characteristics APC-1796 Editor (M Fortinsky) H.225.0 Annex G version1 - with corrections APC-1845 BT Applying the Extensible Package Framework to Annex G ------< registration for the Portland meeting >------ APC-1872 Q22/11 Liaison to SG16 On Interaction Between Intelligent Network Systems and H.248 APC-1873 Q22/11 Liaison to SG16 On Interworking Between H.323 Systems and Intelligent Network Systems APC-1874 Editor (P Jones) Draft H.323 version 4 APC-1875 Editor (P Jones) H.323-series Implementers Guide APC-1876 Editor (K Klaghofer) Draft Call Offer Supplementary Service for H.323 APC-1877 Editor (K Klaghofer) Draft Call Intrusion Supplementary Service for H.323 APC-1878 Editor (T Anderson) Draft H.323 Annex R (Robustness) APC-1879 Lucent Technologies Reference Points for the Use of Annex G APC-1880 Editor (F Audet) H.323 Annex M.1 "Tunnelling of signalling protocols (QSIG) in H.323" APC-1881 Nortel Networks Enforcing symmetric operation in the context of slow start for H.323v4 APC-1882 Nortel Networks Minor correction to H.323 Annex M.1 APC-1883 Columbia University CPL: A Language for User Control of Internet Telephony Services APC-1884 SONUS Decomposition of Gatekeeper Functions inside a Domain APC-1885 Hughes Software Systems { to suggest amendments in the H.323 standard } APC-1886 Columbia University RFC-2824: Call Processing Language Framework and Requirements APC-1887 Siemens AG H.450.12 - Common Information Additional Network Feature for H.323 APC-1888 Siemens AG M.3 - Tunneling of DSS1 in H.323 APC-1889 Q4/8 Voice/fax switching in draft H.323 Annex D v2 APC-1890 Q4/8 Facsimile related work on draft H.248 Annex F APC-1891 Q4/8 Draft T.38 Appendix V H.248 Call Establishment Procedure Examples APC-1892 Q4/8 Proposed Edits to H.248 Annex F APC-1893 PictureTel Proposed H.242/H.245 text for dynamicPictureResizingByFour APC-1894 ALCATEL Modification to H.323 annex H APC-1895 ETSI TIPHON WG8 Liaison statement subject: "H.235 Hybrid Security Profile" APC-1896 BT Use of the Generic Framework during Registration and other RAS Messaging APC-1897 BT Additional Data Types for GenericData APC-1898 BT Clarification on the Handling of Unknown conferenceGoals APC-1899 Lucent Technologies Fast Channel Open for H.245 APC-1900 Editor (P Reddy) H.246 Annex E.1 Interworking between H.225.0 and PLMN's Mobile Application Parts APC-1901 Editor (P Reddy) H.246 Annex E.2 Interworking between H.225.0 and ANSI-41 PLMN Mobile Application Part APC-1902 Intel H.323 Mobility services using IETF's Mobile IP and new extended protocols APC-1903 Editor (M Fortinsky) H.225.0 Annex G version 2 - draft APC-1904 Avaya DES with Output Feedback for Audio Encryption in H.235v3 APC-1905 UCLA Draft text for "Generic Uneven Level Protection (ULP)" for Annex I of H.323 APC-1906 UCLA Simulation results of ULP for transmission over error prone channels APC-1907 Editor (M Euchner) New Draft H.235 Version 3 APC-1908 Editor (M Euchner) Resolution of an inconsistency in Draft H.235 Version 2 regarding the use of the initial value APC-1909 Editor (J Sundquist) H.323 Annex H Draft APC-1910 LM Ericsson Addition to Implementor's guide to H.248 APC-1911 LM Ericsson Change of Capabilities indicated in H.248 ServiceChange APC-1912 LM Ericsson H.248 Annex L - Error Code and Service Change Reason Description APC-1913 LM Ericsson Improved Auditing in H.248 Version 2 APC-1914 LM Ericsson Comments to H.248 Annex K APC-1915 Editor (P Jones) Fast Connect SDLs Issues APC-1916 Editor (P Jones) Corrections to the H.323v4 White Paper Contribution APC-1917 Cisco Systems JAIN APIs for Integrated Networks APC-1918 Cisco Systems Interworking with Different Versions of H.323 Entities APC-1919 Cisco Systems Comments on the Object Extensible Framework APC-1920 Cisco Systems Third Party Re-Routing of a Fast Connect Initiated Call APC-1921 Cisco Systems Early Termination of Fast Connect APC-1922 Trillium Digital Systems, VocalTec Communications Correction to the H.225.0 Annex G UsageSpecification APC-1923 Editor (J Segers) Errors and unclarities in Recommendation H.248 APC-1924 Editor (T Taylor) Draft H.248 Annex M: Advanced Audio Server Packages APC-1925 Megaco Chair (T Taylor) IETF Megaco Comments On H.248 Annexes F, G, and H APC-1926 AT&T H.323 Intra-Zone Mobility Management using AuF and HLF --------------- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

APC-number
by Roy, Radhika R, ALCOO 09 Aug '00

09 Aug '00

Dear Mr. OKUBO: Kindly provide me an APC number for the following contribution: H.323 Intra-Zone Mobility Management using AuF and HLF Best regards, Radhika R. Roy AT&T +1 732 420 1580 rrroy(a)att.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Standards for H.320
by Tolle, Steve 09 Aug '00

09 Aug '00

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: Request for APC numbers
by Sakae OKUBO 09 Aug '00

09 Aug '00

Dear Mr. Jones and Mr. Fortinsky, The following APC numbers have been allocated to your contributions: APC-1915 Editor (P Jones) Fast Connect SDLs Issues APC-1916 Editor (P Jones) Corrections to the H.323v4 White Paper Contribution APC-1917 Cisco Systems JAIN APIs for Integrated Networks APC-1918 Cisco Systems Interworking with Different Versions of H.323 Entities APC-1919 Cisco Systems Comments on the Object Extensible Framework APC-1920 Cisco Systems Third Party Re-Routing of a Fast Connect Initiated Call APC-1921 Cisco Systems Early Termination of Fast Connect APC-1922 Trillium Digital Systems, VocalTec Communications Correction to the H.225.0 Annex G UsageSpecification Best regards, Sakae OKUBO *********************************************************** Waseda Research Center Telecommunications Advancement Organization of Japan (TAO) 5th Floor, Nishi-Waseda Bldg. 1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan Tel: +81 3 5286 3830 (to be transferred) +81 3 3204 8194 (direct) Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp *********************************************************** ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: APC Number Request
by Euchner Martin 09 Aug '00

09 Aug '00

Dear FTP adminstrator at PictureTel, When trying to log into the Q12-14 FTP server, it looks like the FTP server is temporarily unavailable. Server Reply: 530-The server standard.pictel.com is temporarily unavailable due to 530-the number of users currently connected. The limit is 50 anonymous 530-users at one time. Please try logging in again; if you believe 530-that there is an issue beyond number of users, please e-mail 530-webberr(a)pictel.com to report the problem. 530- 530 User anonymous access denied. ----------------------------------------------------------------------- | Dipl.-Inf. Phone: +49 89 636-46201 | Martin Euchner Fax : +49 89 636-48000 | Siemens AG | ZT IK 3 mailto:Martin.Euchner@mchp.siemens.de | mailto:martin.euchner@ties.itu.int | Otto-Hahn-Ring 6 Intranet: http://zt-security.mchp.siemens.de/de/Competence/Standardization/ITU-T_SG16/ index.html | D-81730 Muenchen Internet: http://www.siemens.de | __________________ | Germany ----------------------------------------------------------------------- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: APC Number Request
by Sakae OKUBO 08 Aug '00

08 Aug '00

Dear Mr. Groves and all, In response to your request, APC-1910 through 1914 have been allocated to your five contributions. APC-1910 LM Ericsson Addition to Implementor's guide to H.248 APC-1911 LM Ericsson Change of Capabilities indicated in H.248 ServiceChange APC-1912 LM Ericsson H.248 Annex L - Error Code and Service Change Reason Description APC-1913 LM Ericsson Improved Auditing in H.248 Version 2 APC-1914 LM Ericsson Comments to H.248 Annex K Please note that APC-1819, 1820, and 1822, which were carried over from the Osaka meeting, have been dropped from the list according to the contributor's advice that their updated versions would be submitted at the November meeting. The current list is attached at the end of this message. Best regards, Sakae OKUBO *********************************************************** Waseda Research Center Telecommunications Advancement Organization of Japan (TAO) 5th Floor, Nishi-Waseda Bldg. 1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan Tel: +81 3 5286 3830 (to be transferred) +81 3 3204 8194 (direct) Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp *********************************************************** Contributions for the Q12-14/16 Rapporteur meeting in Portland (21 -25 August 2000) ------< carried over from the Osaka meeting >------ APC-1765 AT&T Scope of H.323 QOS APC-1766 AT&T Requirements of H.323 QOS APC-1767 AT&T Architecture of H.323 QOS APC-1768 AT&T Specification of H.323 QOS Characteristics APC-1781 Lucent Technologies Reference Points for the Use of Annex G APC-1796 Editor (M Fortinsky) H.225.0 Annex G version1 - with corrections APC-1845 BT Applying the Extensible Package Framework to Annex G ------< registration for the Portland meeting >------ APC-1872 Q22/11 Liaison to SG16 On Interaction Between Intelligent Network Systems and H.248 APC-1873 Q22/11 Liaison to SG16 On Interworking Between H.323 Systems and Intelligent Network Systems APC-1874 Editor (P Jones) Draft H.323 version 4 APC-1875 Editor (P Jones) H.323-series Implementers Guide APC-1876 Editor (K Klaghofer) Draft Call Offer Supplementary Service for H.323 APC-1877 Editor (K Klaghofer) Draft Call Intrusion Supplementary Service for H.323 APC-1878 Editor (T Anderson) Draft H.323 Annex R (Robustness) APC-1879 Lucent Technologies Reference Points for the Use of Annex G APC-1880 Editor (F Audet) H.323 Annex M.1 "Tunnelling of signalling protocols (QSIG) in H.323" APC-1881 Nortel Networks Enforcing symmetric operation in the context of slow start for H.323v4 APC-1882 Nortel Networks Minor correction to H.323 Annex M.1 APC-1883 Columbia University CPL: A Language for User Control of Internet Telephony Services APC-1884 SONUS Decomposition of Gatekeeper Functions inside a Domain APC-1885 Hughes Software Systems { to suggest amendments in the H.323 standard } APC-1886 Columbia University RFC-2824: Call Processing Language Framework and Requirements APC-1887 Siemens AG H.450.12 - Common Information Additional Network Feature for H.323 APC-1888 Siemens AG M.3 - Tunneling of DSS1 in H.323 APC-1889 Q4/8 Voice/fax switching in draft H.323 Annex D v2 APC-1890 Q4/8 Facsimile related work on draft H.248 Annex F APC-1891 Q4/8 Draft T.38 Appendix V H.248 Call Establishment Procedure Examples APC-1892 Q4/8 Proposed Edits to H.248 Annex F APC-1893 PictureTel Proposed H.242/H.245 text for dynamicPictureResizingByFour APC-1894 ALCATEL Modification to H.323 annex H APC-1895 ETSI TIPHON WG8 Liaison statement subject: "H.235 Hybrid Security Profile" APC-1896 BT Use of the Generic Framework during Registration and other RAS Messaging APC-1897 BT Additional Data Types for GenericData APC-1898 BT Clarification on the Handling of Unknown conferenceGoals APC-1899 Lucent Technologies Fast Channel Open for H.245 APC-1900 Editor (P Reddy) H.246 Annex E.1 Interworking between H.225.0 and PLMN's Mobile Application Parts APC-1901 Editor (P Reddy) H.246 Annex E.2 Interworking between H.225.0 and ANSI-41 PLMN Mobile Application Part APC-1902 Intel H.323 Mobility services using IETF's Mobile IP and new extended protocols APC-1903 Editor (M Fortinsky) H.225.0 Annex G version 2 - draft APC-1904 Avaya DES with Output Feedback for Audio Encryption in H.235v3 APC-1905 UCLA Draft text for "Generic Uneven Level Protection (ULP)" for Annex I of H.323 APC-1906 UCLA Simulation results of ULP for transmission over error prone channels APC-1907 Editor (M Euchner) New Draft H.235 Version 3 APC-1908 Editor (M Euchner) Resolution of an inconsistency in Draft H.235 Version 2 regarding the use of the initial value APC-1909 Editor (J Sundquist) H.323 Annex H Draft APC-1910 LM Ericsson Addition to Implementor's guide to H.248 APC-1911 LM Ericsson Change of Capabilities indicated in H.248 ServiceChange APC-1912 LM Ericsson H.248 Annex L - Error Code and Service Change Reason Description APC-1913 LM Ericsson Improved Auditing in H.248 Version 2 APC-1914 LM Ericsson Comments to H.248 Annex K --------------- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

APC-number request
by Jaakko Sundquist 08 Aug '00

08 Aug '00

Mr Okubo, Could you allocate an APC number for me for the H.323 Annex H Draft. Thank you in advance. ------------------------------------------------ Jaakko Sundquist * +358 50 3598281 * Audere est Facere! jaakko.sundquist(a)nokia.com * ------------------------------------------------ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1

APC-1903 uploaded
by Michael Fortinsky 08 Aug '00

08 Aug '00

APC-1903.zip ("H.225.0 Annex G version 2 - draft") has been uploaded to the Incoming directory at the Pictel avc-site. Michael Fortinsky ----------------------------------------------------------------- Senior Program Manager, IP Telephony Group, VocalTec Communications Ltd. Email: mike(a)vocaltec.com Tel: 972 9 9707768 Fax: 972 9 9561867

1 0

Re: APC number Request
by Sakae OKUBO 07 Aug '00

07 Aug '00

Dear Mr. Gilman, Dear Mr. Li, Dear Mr. Euchner, In response to your requests, APC numbers have been allocated to your contributions as follows: APC-1904 Avaya DES with Output Feedback for Audio Encryption in H.235v3 APC-1905 UCLA Draft text for "Generic Uneven Level Protection (ULP)" for Annex I of H.323 APC-1906 UCLA Simulation results of ULP for transmission over error prone channels APC-1907 Editor (M Euchner) New Draft H.235 Version 3 APC-1908 Editor (M Euchner) Resolution of an inconsistency in Draft H.235 Version 2 regarding the use of the initial value Best regards, Sakae OKUBO *********************************************************** Waseda Research Center Telecommunications Advancement Organization of Japan (TAO) 5th Floor, Nishi-Waseda Bldg. 1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan Tel: +81 3 5286 3830 (to be transferred) +81 3 3204 8194 (direct) Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp *********************************************************** ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0