- sg16-avd - lists.packetizer.com

H.323 Annex I
by Baese Gero 06 Feb '01

06 Feb '01

Dear Mr. Li, experts, it is quite discouraging that our questions remaining unanswered and the positive signs we were sending are ignored still. We repeated our technical concerns for the UCLA proposal several times. Please be so kind to let everybody know what is needed to implement the proposal. So far provided documents are not sufficient. The simulation scenario document exists for three months now. We were asking you several times to raise your objections for the provided simulation conditions. We were incorporating your favorite test values in the document. What are the reasons to defer the start of the tests still ? The next meeting is approaching and results are needed as basis for the decision. For both of us it would be harmful to fight for details in front of the group again. We are soliciting you to co-operate - it is of mutual interest and the best for the standard. Best Wishes Gero Bäse ----------------------------------------------------------- Gero Bäse Siemens AG Tel.: +49 89 636 53193 Corporate Technology Fax: +49 89 636 52393 Networks and Multimediacommunication CT IC 2 ----------------------------------------------------------- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

3 2

Re: Interoperability Problems due to Open Type encoding of Null t ypes (fwd)
by Paul, Manoj 03 Feb '01

03 Feb '01

Hi All, I am resending this mail as there does not seem to be a consensus on the defintion of "outermost" value as defined in X.691 specification. Any additional information which would help solve this issue is appreciated. It will help to mitigate one of the important issues affecting the interoperability across H.323 implementations. thanks Manoj. -----Original Message----- From: Paul, Manoj [mailto:mpaul@TRILLIUM.COM] Sent: Friday, January 19, 2001 10:21 AM To: ITU-SG16(a)mailbag.cps.intel.com Subject: Re: Interoperability Problems due to Open Type encoding of Null t ypes (fwd) Hi Scott, We agree to your interpretation for case (1). However, for case (2) we believe that only Foo SEQUENCE should be considered the outermost value. And since it would not generate an empty bit string, no additional 0x00 octet should be added to the field-list. Why should v (NULL element) also considered as outermost value in this context since it appears within the extension root of Foo, isn't it? -Manoj -----Original Message----- From: Bancroft Scott [mailto:baos@OSS.COM] Sent: Wednesday, January 17, 2001 8:58 PM To: ITU-SG16(a)mailbag.cps.intel.com Subject: Re: Interoperability Problems due to Open Type encoding of Null types (fwd) On Wed, 17 Jan 2001, Manoj Paul wrote: > Experts, > > We have come across a specific problem which has been the root > cause of interoperability failures across different implementations > of H.323 stack. The problem is related to the > 1) Encoding and decoding of NULL data types when they appear as > extension IEs. > 2) Encoding and decoding of extension IEs which have NULL as the > outermost ASN type. > > There have been different interpretations of the PER rules that apply > to the above conditions causing interop failures at encode/decode level. > Although the implementations would encode/decode (1) and (2) according > to Open Type elements, some subtle differences come as mentioned below: > > In case of (1), some implementations would not encode an extra 0x00 > octet for NULL data type and would just encode the length of the open type > element as 0x00. This idea probably stems from the fact that a NULL > data type has no encoding when they appear in the root of the ASN.1 type. > However, as per 10.1.3 and 10.2.1 of X.691, the correct encoding for > such a case would be 0x01 0x00, where 0x01 is the uncosntrained length > of the NULL data type encoding and 0x00 is the value of NULL data type in > extension. Your understanding of the encoding is correct. > In case of (2), some implementations would encode the extension IE as per > it's rules (e.g as a Choice/Sequence etc.), but would not add a 0x00 for > the outermost NULL data type in it's encode tree. This would change the > value of length field to be appended to this open type. Whereas some > implementations do add 0x00 octet for the outermost NULL data type. > > There appears to be a confusion as to what is meant by the "outermost" > value in 10.1.3 of X.691. I would appreciate clarification on this > clause as it would save a lot of interop overhead at encode/decode level. "outermost" value refers to a value of a type that is either directly nested in an open type or is a complete application message unto itself. For example, if you had: Foo ::= SEQUENCE { b BOOLEAN, v TYPE-IDENTIFIER.&Type, ..., i NULL } bar Foo ::= {b TRUE, v NULL : NULL, i NULL} The value of Foo, bar, is an outermost value. The value of v (NULL : NULL) is encoded as an outermost value, so in this case since NULL encodes to 0 bits it is replaced with eight 0-bits, and this is prefixed with a length of 1. Similarly, the value of i is encoded as an outermost value, so the resulting encoding in this case will have a length of 1 followed by eight 0-bits. ------------------------------------------------------------------------- Bancroft Scott Toll Free :1-888-OSS-ASN1 OSS Nokalva International:1-732-302-0750 baos(a)oss.com Tech Support :1-732-302-9669 x-1 1-732-302-9669 x-200 Fax :1-732-302-0023 http://www.oss.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

5 4

Re: Interoperability Problems due to Open Type encoding of Null t ypes (fwd)
by Paul, Manoj 02 Feb '01

02 Feb '01

Bancroft: Does your input to ITU-T ASN.1 Meeting defines outermost value as value of a type that is either directly nested in an open type or is a complete application message unto itself. Or does your input refers outermost value only to the value of the open type IE and not the IEs nested within it? Thanks Manoj. On Fri, 2 Feb 2001, Paul E. Jones wrote: > Manoj, > > Given Bancroft's role in the development of ASN.1, I'd say that whatever he > says is probably true and most likely the intent if the text is not clear. I have inputted this to the ASN.1 meeting that was held at the ITU-T in Geneva January 22 - February 2, and this will be clarified in an upcoming corrigendum. > In any case, I would venture to guess that OSS is more widely used than any > other ASN.1 PER encoder/decoder on the market. While it may not be > appropriate to call their tools the "de facto" standard, they very much are > (no disrespect intended to anyone). I would suggest that the text be > clarified according to Bancroft's recommendation and that Implementers > follow his advise, as I believe it would result in the widest possible > interoperability. I'm cc'ing the ITU-T ASN.1 Rapporteur, Olivier Dubuisson, and the ISO/IEC ASN.1 Rapporteur, John Larmouth, in case they have anything to add. Bancroft ______________________________________________________ > > ----- Original Message ----- > From: "Paul, Manoj" <mpaul(a)TRILLIUM.COM> > To: <ITU-SG16(a)mailbag.cps.intel.com> > Sent: Thursday, February 01, 2001 3:34 PM > Subject: Re: Interoperability Problems due to Open Type encoding of Null t > ypes (fwd) > > > > Hi All, > > > > I am resending this mail as there does not seem to be a consensus on > > the defintion of "outermost" value as defined in X.691 specification. > > Any additional information which would help solve this issue is > > appreciated. It will help to mitigate one of the important issues > > affecting the interoperability across H.323 implementations. > > thanks > > Manoj. > > > > -----Original Message----- > > From: Paul, Manoj [mailto:mpaul@TRILLIUM.COM] > > Sent: Friday, January 19, 2001 10:21 AM > > To: ITU-SG16(a)mailbag.cps.intel.com > > Subject: Re: Interoperability Problems due to Open Type encoding of Null > > t ypes (fwd) > > > > > > Hi Scott, > > > > We agree to your interpretation for case (1). However, for case (2) > > we believe that only Foo SEQUENCE should be considered the outermost > > value. And since it would not generate an empty bit string, no additional > > 0x00 octet should be added to the field-list. Why should v (NULL element) > > also considered as outermost value in this context since it appears > > within the extension root of Foo, isn't it? > > -Manoj > > > > -----Original Message----- > > From: Bancroft Scott [mailto:baos@OSS.COM] > > Sent: Wednesday, January 17, 2001 8:58 PM > > To: ITU-SG16(a)mailbag.cps.intel.com > > Subject: Re: Interoperability Problems due to Open Type encoding of Null > > types (fwd) > > > > > > On Wed, 17 Jan 2001, Manoj Paul wrote: > > > > > Experts, > > > > > > We have come across a specific problem which has been the root > > > cause of interoperability failures across different implementations > > > of H.323 stack. The problem is related to the > > > 1) Encoding and decoding of NULL data types when they appear as > > > extension IEs. > > > 2) Encoding and decoding of extension IEs which have NULL as the > > > outermost ASN type. > > > > > > There have been different interpretations of the PER rules that apply > > > to the above conditions causing interop failures at encode/decode level. > > > Although the implementations would encode/decode (1) and (2) according > > > to Open Type elements, some subtle differences come as mentioned below: > > > > > > In case of (1), some implementations would not encode an extra 0x00 > > > octet for NULL data type and would just encode the length of the open > type > > > element as 0x00. This idea probably stems from the fact that a NULL > > > data type has no encoding when they appear in the root of the ASN.1 > type. > > > However, as per 10.1.3 and 10.2.1 of X.691, the correct encoding for > > > such a case would be 0x01 0x00, where 0x01 is the uncosntrained length > > > of the NULL data type encoding and 0x00 is the value of NULL data type > in > > > extension. > > > > Your understanding of the encoding is correct. > > > > > In case of (2), some implementations would encode the extension IE as > per > > > it's rules (e.g as a Choice/Sequence etc.), but would not add a 0x00 for > > > the outermost NULL data type in it's encode tree. This would change the > > > value of length field to be appended to this open type. Whereas some > > > implementations do add 0x00 octet for the outermost NULL data type. > > > > > > There appears to be a confusion as to what is meant by the "outermost" > > > value in 10.1.3 of X.691. I would appreciate clarification on this > > > clause as it would save a lot of interop overhead at encode/decode > level. > > > > "outermost" value refers to a value of a type that is either directly > > nested in an open type or is a complete application message unto itself. > > For example, if you had: > > > > Foo ::= SEQUENCE { > > b BOOLEAN, > > v TYPE-IDENTIFIER.&Type, > > ..., > > i NULL > > } > > > > bar Foo ::= {b TRUE, v NULL : NULL, i NULL} > > > > The value of Foo, bar, is an outermost value. The value of v (NULL : NULL) > > is encoded as an outermost value, so in this case since NULL encodes to 0 > > bits it is replaced with eight 0-bits, and this is prefixed with a length > > of 1. Similarly, the value of i is encoded as an outermost value, so the > > resulting encoding in this case will have a length of 1 followed by eight > > 0-bits. > > > > ------------------------------------------------------------------------- > > Bancroft Scott Toll Free :1-888-OSS-ASN1 > > OSS Nokalva International:1-732-302-0750 > > baos(a)oss.com Tech Support :1-732-302-9669 > > x-1 > > 1-732-302-9669 x-200 Fax :1-732-302-0023 > > http://www.oss.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

1 0

ARQ/ACF/ARJ between Gatekeepers?
by Frank Derks 02 Feb '01

02 Feb '01

Dear all, since the first version of H.323, the call signalling procedures have been explained through a series of examples. Although examples do help to get the idea on how things should work, they remain examples and are therefore (usually) incomplete. Take the example from Figure2/H.323v2 (or Figure 40/H.323v4): GK1 sends the SETUP message without first initiating the admission control procedure. If GK2 expects the admission control procedure to take place prior to the call setup, then this will fail unless GK2 makes an exception for certain "EPs" (GK1 in this case) to place calls without an admission control procedure. Are there any visions on this scenario? Frank ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1

Re: ARQ/ACF/ARJ between Gatekeepers?
by Nagesh Kumar 02 Feb '01

02 Feb '01

Hi! I guess the receiving GK should have a policy to accept calls from other GKs. May be it can have a list of GKs from where it will accept calls. GK will not do ARQ/ACF while contacting the other GK as it may not know that it actaully talking to another GK or to an EP. regards, Nagesh. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Best New Trade Show Display by Opera Portables, Inc. adv
by opera＠localhost.net 01 Feb '01

01 Feb '01

1 0

Work From Home! Guaranteed monthly INCOME
by ccbat＠GTE.NET 31 Jan '01

31 Jan '01

2 1

H.323 query
by Jan Van Geel 31 Jan '01

31 Jan '01

Hello, I'm new in the domain of H.323 and have a rather basic question. In § 6.4 of H.323 it is stated that communication between gatekeepers is done in an unspecified fashion. Does this mean that there is no standardised protocol for this communication ? If the answer is "indeed there is no protocol defined", is there any common practice ? any comment/help is welcome kind regards Jan Van Geel Signalling Specialist Belgacom /NTS/TPM/NGN Tel : 32 2 202 1035 Email : jan.van.geel(a)belgacom.be **** DISCLAIMER **** "This e-mail and any attachments thereto may contain information which is confidential and/or protected by intellectual property rights and are intended for the sole use of the recipient(s) named above. Any use of the information contained herein (including, but not limited to, total or partial reproduction, communication or distribution in any form) by persons other than the designated recipient(s) is prohibited. If you have received this e-mail in error, please notify the sender either by telephone or by e-mail and delete the material from any computer. Thank you for your cooperation." ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

3 2

avd documents
by Agboh, Charles 31 Jan '01

31 Jan '01

Hi, Does anyone know where the AVD documents are uploaded? I can't get access to the standards.pictel.com/avc-site. Best Regards, Charles ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

RE: H.323 Annex I Progress
by Adam Li 30 Jan '01

30 Jan '01

Mr. Jones, Thank you for your email and your concerns. We are trying to make progress on an agreed simulation condition. We just got the response from Mr. Baese on the simulation conditions we sent on 12/21/2000. It appears there are still several controversial issues (please see my other email). It does take quite some time to run the simulation, and we understand the meeting deadline is approaching. We will do our best to work it out with the Siemens team and hope we can resolve the issues and reach an agreement as early as possible. I will keep everyone updated on the progress. If you (or any other interested parties) have any comments on the issues, we would love to hear your opinions and suggestions. Adam Li > -----Original Message----- > From: Paul E. Jones [mailto:paulej@packetizer.com] > Sent: Sunday, January 28, 2001 12:36 PM > To: Baese Gero; adamli(a)ICSL.UCLA.EDU > Subject: Re: H.323 Annex I > > > Mr. Bäse and Mr. Li, > > You will have to refresh my memory on this, but was Mr. Skran's > request that > you produce test results before the meeting in March or produce a > test plan > by that time? > > I would guess that, since I see these postings to the SG16 mailing list, > that little cooperation is taking place between the two sides on Annex I. > Is that an accurate assumption? > > I hope that we can reach some agreements on this before and during that > meeting. I'd like to see some of the scenery in Tasmania :-) > > Paul > > ----- Original Message ----- > From: "Baese Gero" <Gero.X.Baese(a)MCHP.SIEMENS.DE> > To: <ITU-SG16(a)mailbag.cps.intel.com> > Sent: Friday, January 26, 2001 11:18 AM > Subject: H.323 Annex I > > > Dear Mr. Li, experts, > > > as you wished we kindly reviewed your paper. Here are our conclusions: > * it does not incorporate both the conditions used in your > simulation > and the scenario we proposed in APC-1993 correctly > * it does not incorporate the decisions of the group at the Geneva > meeting > * relations to practical usage are missing > To replenish this paper with all the necessary information would take to > long. > > We are running out of time. Therefor we completed APC-1993 with the few > missing values out of your paper. An additional section with the proposed > internet tests is now included. Please be so kind to supplement > this section > with your suggestions. We hope you can finally agree on that > joint scenario > document. Again, it is very important to have a complete scenario > instead of > > a collection of values to make our work tangible for everybody within the > group. > > A few points are still under discussion. Using a rate control for example > does > not make much sense in our case. It is not part of any standard and can be > optimized to support one or the other method. > To regiment the length of slices is only in favour of the UCLA proposal. > Therefore > we don't want to see this restriction within the test scenario. > > It is still impossible to implement the UCLA proposal with the documents > available. > We were asking you several times concerning technical obscurities but your > answer > is still missing. > > We are supposed to use the standard ITU-T code of H.263 for the tests. As > far > as we aware there is no official version including all necessary parts of > H.263. > That is to say only H.26L can be used for the tests. If you know a place > where > the appropriate software is available please provide us with the link. > > Best Wishes > Gero Baese > > ----------------------------------------------------------- > Gero Bäse > Siemens AG Tel.: +49 89 636 53193 > Corporate Technology Fax: +49 89 636 52393 > Networks and Multimediacommunication CT IC 2 > ----------------------------------------------------------- > > > <<APC-1993r2.doc>> > > >

1 0

H.323 Annex I
by Baese Gero 30 Jan '01

30 Jan '01

Dear Mr. Li, experts, as you wished we kindly reviewed your paper. Here are our conclusions: * it does not incorporate both the conditions used in your simulation and the scenario we proposed in APC-1993 correctly * it does not incorporate the decisions of the group at the Geneva meeting * relations to practical usage are missing To replenish this paper with all the necessary information would take to long. We are running out of time. Therefor we completed APC-1993 with the few missing values out of your paper. An additional section with the proposed internet tests is now included. Please be so kind to supplement this section with your suggestions. We hope you can finally agree on that joint scenario document. Again, it is very important to have a complete scenario instead of a collection of values to make our work tangible for everybody within the group. A few points are still under discussion. Using a rate control for example does not make much sense in our case. It is not part of any standard and can be optimized to support one or the other method. To regiment the length of slices is only in favour of the UCLA proposal. Therefore we don't want to see this restriction within the test scenario. It is still impossible to implement the UCLA proposal with the documents available. We were asking you several times concerning technical obscurities but your answer is still missing. We are supposed to use the standard ITU-T code of H.263 for the tests. As far as we aware there is no official version including all necessary parts of H.263. That is to say only H.26L can be used for the tests. If you know a place where the appropriate software is available please provide us with the link. Best Wishes Gero Baese ----------------------------------------------------------- Gero Bäse Siemens AG Tel.: +49 89 636 53193 Corporate Technology Fax: +49 89 636 52393 Networks and Multimediacommunication CT IC 2 ----------------------------------------------------------- <<APC-1993r2.doc>>

2 1

H.323's "keepAlive" mechanism
by Frank Derks 29 Jan '01

29 Jan '01

According to the text in section 7.2.2.1 of H.323v4 (11/2000), as a response to a RRQ, a GK may respond with an RCF containing a timeToLive that is equal to or less than the timeToLive from the RRQ. This raises two questions: 1) Why isn't it allowed for a GK to respond with a greater value, or any value for that matter? 2) If the EP does not specify a timeToLive, should this be treated as a value of "0" and does this make it impossible for a GK to impose any timeToLive value? Frank ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

4 3

Rapporteur meeting of Q1/16 in Launceston
by Patrick_Luthi＠PICTEL.COM 29 Jan '01

29 Jan '01

To Experts of ITU-T SG16 Question 1/16 Cc Mr. P-A. Probst, Chairman of SG16 <probst-pa(a)bluewin.ch> Mr. G. Wreikat, Vice-Chairman of SG16 <wreikat(a)hotmail.com> Mr. F. Tosco, Chairman of WP2/16 <Federico.Tosco(a)CSELT.IT> Mr. F. Bigi, ITU-TSB <Fabio.Bigi(a)itu.int> Mr. C. Grooves, Ericsson <Christian.Groves(a)ericsson.com> De Mr. P. Luthi, Rapporteur for Q.1/16 <Patrick_Luthi(a)pictel.com> --------------------------------------------------------- Subject: Notice of Joint Rapporteur Meeting in Launceston Date: 29 January 2001 --------------------------------------------------------- Dear experts of Question 1/16, The subject meeting of ITU-T SG16 experts will be held in Launceston, Australia at the kind invitation of L. M. Ericsson. Please note that Q.D, F, G, 2-5/16 will meet concurrently at the same place and has joint session(s) with Q.1/16. 1. Date ^^^^^^^ 7 (Wednesday) - 8 (Thursday) March 2001 starting at 9:00 on the first day closing around 18:00 on the final day 2. Venue ^^^^^^^^ Novotel Launceston, Tasmania 29 Cameron Street Launceston Tasmania 7250 Australia Tel: +61 03 6334 3434 Fax: +61 03 6331 7347 3. Topics (tentative) ^^^^^^^^^^^^^^^^^^^^^ 1) Review of the relevant group activities 2) Q.1/16 Multimedia systems, terminals and data - Review of the items relative to H.324 - Progress the work to revise H.324 Annex D - Progress the work on H.324 Annex Security ? Review of final text of H.324 Annex I (HTTP) ? Review of the items relative to H.320 ? Align H.320 with new H.263 Annex X - Review of the items relative to T.120 - Identify and organize the activities of Q.1 for the 2001-2004 Study Period (Revision of H.320, H.324, H.223, etc) 3) Coordination with Q.D, F, G, 2-5/16 - System aspects - Interoperability - Security 4) Interaction with other groups 5) Future work plan 4. Documents ^^^^^^^^^^^^ /// Registration of the document: by 23:59 UTC, 26 February /// /// Distribution of the document: by 23:59 UTC, 28 February /// /// Use the ftp site (or e-mail reflector) for distribution /// 1) When you are going to submit a document, please notify P. Luthi as soon as possible, by 23:59 UTC, Monday 26 February at the latest at <luthip(a)pictel.com>. Document number (Q1-Ann) will be allocated. Early indication of your submission plan is welcome and encouraged. 2) You are advised to include a header as follows: ------------------------------------------------------------------ | | | ITU Telecommunication Standardization Sector Document Q1-A{nn}| | Study Group 16 {Version m if relevant}| | Q.1/16 Rapporteur Meeting {Date}| | Launceston, 8-7 March 2001 | | | | SOURCE*: { } | | TITLE : { } | | PURPOSE: {Proposal, Discussion, Information, Report, etc.} | | | | _________________________ | | | | | | | | *Contact: Name, e-mail | ------------------------------------------------------------------ 3) All the contributors are requested to distribute their documents as early as possible, at least 7 calendar days in advance of the meeting (23:59 UTC, Wednesday 28 February or before) by posting them at either of the following: - PictureTel ftp site (please advise Mr. P. Luthi of your posting) Site: standard.pictel.com/lbc-site Login name: anonymous Directory: dropbox - Q.1/16 experts reflector e-mail address: tsg16q1(a)itu.int (http://www.itu.int/ITUT/com16/edh/subscribe.html) Please avoid the use of reflector when your document is voluminous. 4) Input documents can be retrieved from /0103_Lauceston directory of the ftp site. 5) The document distribution / presentation at the meeting will be all electronic. Participants must bring along their laptop, 10BASE-T card and cord according to the host's guidance. 5. Logistic information ^^^^^^^^^^^^^^^^^^^^^^^ Please see the attached document provided by the meeting host (http://standard.pictel.com/ftp/avc-site/0103_Lau/Launceston_info_a.zip) 6. Registration ^^^^^^^^^^^^^^^ To register your meeting attendance, please send the attached form to the meeting secretariat by 19 February 2001: Nicole Crook Ericsson Australia C/- MP Events, PO Box 2182, Kew, 3101 Victoria, Australia Tel: +61 3 9852 9941 Fax: +61 3 9852 9961 Email: nicole(a)mpevents.com.au AND advise the Rapporteur of your attendance by e-mail: To: luthip(a)pictel.com Subject: Launceston Q1 meeting attendance Name: Company: Arrival: Departure: 7. Hotel Room Reservation ^^^^^^^^^^^^^^^^^^^^^^^^^ Please send the attached form to the meeting secretariat together with the meeting registration by 19 February 2001. The room rate is $A135 per night including breakfast I am looking forward to meeting with you in Launceston. Sincerely yours, Patrick Luthi (See attached file: Ericsson_invitation_a.zip)

1 0

None
by Baese Gero 29 Jan '01

29 Jan '01

Dear Mr. Jones, unfortunately the progress we are making is slow-going. But there is progress still and the positions converging step by step. Behind the scenes much work is being done. We are expecting to show simulation results on a agreed on basis in Tasmania as Mr. Scran requested. Best Wishes Gero Baese ----------------------------------------------------------- Gero Bäse Siemens AG Tel.: +49 89 636 53193 Corporate Technology Fax: +49 89 636 52393 Networks and Multimediacommunication CT IC 2 ----------------------------------------------------------- > -----Ursprüngliche Nachricht----- > Von: Paul E. Jones [mailto:paulej@packetizer.com] > Gesendet am: Sonntag, 28. Januar 2001 21:36 > An: Baese Gero; adamli(a)ICSL.UCLA.EDU > Betreff: Re: H.323 Annex I > > Mr. Bäse and Mr. Li, > > You will have to refresh my memory on this, but was Mr. > Skran's request that > you produce test results before the meeting in March or > produce a test plan > by that time? > > I would guess that, since I see these postings to the SG16 > mailing list, > that little cooperation is taking place between the two sides > on Annex I. > Is that an accurate assumption? > > I hope that we can reach some agreements on this before and > during that > meeting. I'd like to see some of the scenery in Tasmania :-) > > Paul > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: Re: The meaning of "mode" in the H.323 Recommendation?
by frank.derks＠philips.com 29 Jan '01

29 Jan '01

Paul, yes. Reading through the definitions section of H.323 (again;-)), made me realize that it states that the definitions from H.225.0 and H.245 also apply to the H.323 Recommendation. I suppose that things are covered this way. Nevertheless, to improve readability, it wouldn't hurt to add explicit references to definitions for things that are rather important. Frank paulej(a)packetizer.com on 28/01/2001 21:48:30 To: ITU-SG16@mailbag.cps.intel.com@SMTP Frank Derks/HVS/BE/PHILIPS@EMEA2 cc: Subject: Re: Re: The meaning of "mode" in the H.323 Recommendation? Classification: Frank, I trust that Mike's answer to "mode" addresses your concerns. With respect to "H.225.0 logical channel signalling", yes.. that should be H.245. Paul ----- Original Message ----- From: "Frank Derks" <frank.derks(a)PHILIPS.COM> To: <ITU-SG16(a)mailbag.cps.intel.com> Sent: Friday, January 26, 2001 8:04 AM Subject: Re: The meaning of "mode" in the H.323 Recommendation? > Paul, > > the sections I was referring to are the following: > > - 6.2.8.1, 5th paragraph: "The transmitting terminal assigns each individual mode ..." > - 6.2.8.1, 6th paragraph: "... audio modes ..." > - 6.2.8.1, 7th paragraph: "... indicates a set of modes ..." > - 6.2.8.1, 1st paragraph after the notes: "... dependencies between operating modes ...", "...different sets of modes ..." > - 6.2.8.2, 3rd paragraph: "... certain symmetrical modes ...", " ... using a particular mode ..." > > Undoubtedly it appears in more places. > > Something else that struck as strange, was section 6.2.8.6. It mentions H.225.0 logical signalling procedures and > H.225.0 logical channels. I would assume that these should read "H.245". > > Frank > > > > > > paulej@PACKETIZER.COM@SMTP@MAILBAG.INTEL.COM on 26-01-2001 11:03:30 > Please respond to paulej@PACKETIZER.COM@SMTP > Sent by: ITU-SG16(a)MAILBAG.INTEL.COM > To: ITU-SG16@MAILBAG.INTEL.COM@SMTP > cc: > Subject: Re: The meaning of "mode" in the H.323 Recommendation? > Classification: > > Frank, > > I would need to look at the particular section of text or sections :-), but > I if it isn't clear, I'd agree that it should be clarified. Unfortunately, > it's too late to get such text into H.323 version 4. > > If it is a short list of sections, post them here and I suspect folks will > be able to get an answer to you before I get back into the office (I'm > currently on the road). If the list is lengthy, just send it to me and I'll > look at the sections when I get a chance. Do you think this is something > that needs clarification in the implementers guide or something to try to > get into v5? > > Paul > > ----- Original Message ----- > From: "Frank Derks" <frank.derks(a)PHILIPS.COM> > To: <ITU-SG16(a)mailbag.cps.intel.com> > Sent: Tuesday, January 23, 2001 7:33 AM > Subject: The meaning of "mode" in the H.323 Recommendation? > > > > Paul, > > > > as I was reading through the latest draft of H.323v4, I came across > something that has > > been in the recommendation for a long time, but that I never quite > grasped: "mode". > > The recommendation talks about "mode" and there is a (H.245) message to > request > > a terminal to use a certain "mode" (requestMode), but there is no > explanation of what > > "mode" actually means. Shouldn't there be a definition of "mode" in the > Definitions > > section? > > > > Regards, > > > > Frank > > > > ----------------------------------------------------- > > Frank Derks |Tel +31 35 6893238 | > > Advanced Development |Fax +31 35 6891030 | > > Philips Business Communications|P.O. Box 32 | > > |1200 JD Hilversum | > > |The Netherlands | > > ----------------------------------------------------| > > E-mail: mailto:frank.derks@philips.com | > > WWW: http://www.sopho.philips.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 >

1 0

Re: The meaning of "mode" in the H.323 Recommendation?
by Frank Derks 28 Jan '01

28 Jan '01

Paul, the sections I was referring to are the following: - 6.2.8.1, 5th paragraph: "The transmitting terminal assigns each individual mode ..." - 6.2.8.1, 6th paragraph: "... audio modes ..." - 6.2.8.1, 7th paragraph: "... indicates a set of modes ..." - 6.2.8.1, 1st paragraph after the notes: "... dependencies between operating modes ...", "...different sets of modes ..." - 6.2.8.2, 3rd paragraph: "... certain symmetrical modes ...", " ... using a particular mode ..." Undoubtedly it appears in more places. Something else that struck as strange, was section 6.2.8.6. It mentions H.225.0 logical signalling procedures and H.225.0 logical channels. I would assume that these should read "H.245". Frank paulej@PACKETIZER.COM@SMTP@MAILBAG.INTEL.COM on 26-01-2001 11:03:30 Please respond to paulej@PACKETIZER.COM@SMTP Sent by: ITU-SG16(a)MAILBAG.INTEL.COM To: ITU-SG16@MAILBAG.INTEL.COM@SMTP cc: Subject: Re: The meaning of "mode" in the H.323 Recommendation? Classification: Frank, I would need to look at the particular section of text or sections :-), but I if it isn't clear, I'd agree that it should be clarified. Unfortunately, it's too late to get such text into H.323 version 4. If it is a short list of sections, post them here and I suspect folks will be able to get an answer to you before I get back into the office (I'm currently on the road). If the list is lengthy, just send it to me and I'll look at the sections when I get a chance. Do you think this is something that needs clarification in the implementers guide or something to try to get into v5? Paul ----- Original Message ----- From: "Frank Derks" <frank.derks(a)PHILIPS.COM> To: <ITU-SG16(a)mailbag.cps.intel.com> Sent: Tuesday, January 23, 2001 7:33 AM Subject: The meaning of "mode" in the H.323 Recommendation? > Paul, > > as I was reading through the latest draft of H.323v4, I came across something that has > been in the recommendation for a long time, but that I never quite grasped: "mode". > The recommendation talks about "mode" and there is a (H.245) message to request > a terminal to use a certain "mode" (requestMode), but there is no explanation of what > "mode" actually means. Shouldn't there be a definition of "mode" in the Definitions > section? > > Regards, > > Frank > > ----------------------------------------------------- > Frank Derks |Tel +31 35 6893238 | > Advanced Development |Fax +31 35 6891030 | > Philips Business Communications|P.O. Box 32 | > |1200 JD Hilversum | > |The Netherlands | > ----------------------------------------------------| > E-mail: mailto:frank.derks@philips.com | > WWW: http://www.sopho.philips.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: The meaning of "mode" in the H.323 Recommendation?
by Mike Nilsson 26 Jan '01

26 Jan '01

Frank, Paul, Mode is defined in H.245 as: Mode: A mode is a set of elementary streams that a terminal is transmitting, intends to transmit, or would like to receive. and elementary stream is defined as: Elementary Stream: Elementary Stream is a generic term for a coded video, coded audio or other coded bitstream. Best regards Mike -------------------- Mike Nilsson Advanced Video Services B81 Room 102 pp14 BT Advanced Communications Technology Centre Adastral Park, Martlesham Heath, Ipswich, IP5 3RE, UK Tel: +44 1473 645413 Mobile: +44 7808 635412 Fax: +44 1473 646589 Email: mike.nilsson(a)bt.com > -----Original Message----- > From: Frank Derks [SMTP:frank.derks@PHILIPS.COM] > Sent: Friday, January 26, 2001 1:04 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: The meaning of "mode" in the H.323 Recommendation? > > Paul, > > the sections I was referring to are the following: > > - 6.2.8.1, 5th paragraph: "The transmitting terminal assigns each > individual mode ..." > - 6.2.8.1, 6th paragraph: "... audio modes ..." > - 6.2.8.1, 7th paragraph: "... indicates a set of modes ..." > - 6.2.8.1, 1st paragraph after the notes: "... dependencies between > operating modes ...", "...different sets of modes ..." > - 6.2.8.2, 3rd paragraph: "... certain symmetrical modes ...", " ... > using a particular mode ..." > > Undoubtedly it appears in more places. > > Something else that struck as strange, was section 6.2.8.6. It mentions > H.225.0 logical signalling procedures and > H.225.0 logical channels. I would assume that these should read "H.245". > > Frank > > > > > > paulej@PACKETIZER.COM@SMTP@MAILBAG.INTEL.COM on 26-01-2001 11:03:30 > Please respond to paulej@PACKETIZER.COM@SMTP > Sent by: ITU-SG16(a)MAILBAG.INTEL.COM > To: ITU-SG16@MAILBAG.INTEL.COM@SMTP > cc: > Subject: Re: The meaning of "mode" in the H.323 Recommendation? > Classification: > > Frank, > > I would need to look at the particular section of text or sections :-), > but > I if it isn't clear, I'd agree that it should be clarified. > Unfortunately, > it's too late to get such text into H.323 version 4. > > If it is a short list of sections, post them here and I suspect folks will > be able to get an answer to you before I get back into the office (I'm > currently on the road). If the list is lengthy, just send it to me and > I'll > look at the sections when I get a chance. Do you think this is something > that needs clarification in the implementers guide or something to try to > get into v5? > > Paul > > ----- Original Message ----- > From: "Frank Derks" <frank.derks(a)PHILIPS.COM> > To: <ITU-SG16(a)mailbag.cps.intel.com> > Sent: Tuesday, January 23, 2001 7:33 AM > Subject: The meaning of "mode" in the H.323 Recommendation? > > > > Paul, > > > > as I was reading through the latest draft of H.323v4, I came across > something that has > > been in the recommendation for a long time, but that I never quite > grasped: "mode". > > The recommendation talks about "mode" and there is a (H.245) message to > request > > a terminal to use a certain "mode" (requestMode), but there is no > explanation of what > > "mode" actually means. Shouldn't there be a definition of "mode" in the > Definitions > > section? > > > > Regards, > > > > Frank > > > > ----------------------------------------------------- > > Frank Derks |Tel +31 35 6893238 | > > Advanced Development |Fax +31 35 6891030 | > > Philips Business Communications|P.O. Box 32 | > > |1200 JD Hilversum | > > |The Netherlands | > > ----------------------------------------------------| > > E-mail: mailto:frank.derks@philips.com | > > WWW: http://www.sopho.philips.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

1 0

The meaning of "mode" in the H.323 Recommendation?
by Frank Derks 26 Jan '01

26 Jan '01

Paul, as I was reading through the latest draft of H.323v4, I came across something that has been in the recommendation for a long time, but that I never quite grasped: "mode". The recommendation talks about "mode" and there is a (H.245) message to request a terminal to use a certain "mode" (requestMode), but there is no explanation of what "mode" actually means. Shouldn't there be a definition of "mode" in the Definitions section? Regards, Frank ----------------------------------------------------- Frank Derks |Tel +31 35 6893238 | Advanced Development |Fax +31 35 6891030 | Philips Business Communications|P.O. Box 32 | |1200 JD Hilversum | |The Netherlands | ----------------------------------------------------| E-mail: mailto:frank.derks@philips.com | WWW: http://www.sopho.philips.com | ----------------------------------------------------- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1

AW: Understanding the ROS{} type (from X.880)
by Horvath Ernst 25 Jan '01

25 Jan '01

Frank, in ASN.1 notation parameters are enclosed in curly brackets. In the particular case of the ROS type, each parameter represents a "value set", which itself is indicated by curly brackets. Therefore the nesting of 2 (or more) sets of brackets. The parameters in the ROS type are used as constraints - indicated by round brackets further down in the module. The meaning is actually quite straightforward: the invoke ID must be within the limits of InvokeIdSet, the operation value must be from the "Invokable" set, and only operations listed also in the "Returnable" set can report a result or error. Valid error values must further belong to the defined set "Errors", which itself is constrained to apply only to the "Returnable" operations. I admit that the notation is clumsy, but it allows you to declare your application environment (i.e. the operations, or supplementary services, that your software will support) in a formal way which is suitable for processing by tools. Ernst Horvath Siemens AG > -----Ursprüngliche Nachricht----- > Von: Frank Derks [mailto:frank.derks@PHILIPS.COM] > Gesendet am: Mittwoch, 24. Jänner 2001 19:06 > An: ITU-SG16(a)mailbag.cps.intel.com > Betreff: Understanding the ROS{} type (from X.880) > > When reading through H.450.1, I came across the definition > for the ROS type > (as defined in X.880): > > ROS {InvokeId:InvokeIdSet, OPERATION:Invokable, > OPERATION:Returnable) ::= CHOICE > { > invoke [1] Invoke {{InvokeIdSet},{Invokable}}, > returnResult [2] ReturnResult {{Returnable}}, > returnError [3] ReturnError {{Errors{{Returnable}}}}, > reject [4] Reject > } > > I think I understand the lines with the "invoke" and the > "returnResult" > (apart from the fact that two curly braces are used in the > latter, but I > assume that this is just the way things are with the notation). Both > Invoke and ReturnResult are parameterized sequences and their > respective > parameters are simply being "passed in". > > The line that follows beats me, however. How should I read: > > "{{Errors{{Returnable}}}}" > > First of all, I would expect a parameter of type "ERROR" to > be "passed in", > but it would seem that "Errors" is the name of the parameter for the > parameterized "ReturnError" sequence and "Returnable" is of > the "OPERATION" > type. So what does that line actually mean? > > Regards, > > Frank > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > 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

1 0

Understanding the ROS{} type (from X.880)
by Frank Derks 24 Jan '01

24 Jan '01

When reading through H.450.1, I came across the definition for the ROS type (as defined in X.880): ROS {InvokeId:InvokeIdSet, OPERATION:Invokable, OPERATION:Returnable) ::= CHOICE { invoke [1] Invoke {{InvokeIdSet},{Invokable}}, returnResult [2] ReturnResult {{Returnable}}, returnError [3] ReturnError {{Errors{{Returnable}}}}, reject [4] Reject } I think I understand the lines with the "invoke" and the "returnResult" (apart from the fact that two curly braces are used in the latter, but I assume that this is just the way things are with the notation). Both Invoke and ReturnResult are parameterized sequences and their respective parameters are simply being "passed in". The line that follows beats me, however. How should I read: "{{Errors{{Returnable}}}}" First of all, I would expect a parameter of type "ERROR" to be "passed in", but it would seem that "Errors" is the name of the parameter for the parameterized "ReturnError" sequence and "Returnable" is of the "OPERATION" type. So what does that line actually mean? Regards, Frank ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Rapporteur meeting of Q.D, F, G, 2-5/16 in Launceston
by OKUBO Sakae 23 Jan '01

23 Jan '01

/// Please note that the invitation has been updated /// /// with addition of visa requirement to Australia. /// To Experts of ITU-T SG16 Questions D, F, G, 2, 3, 4 and 5/16 Cc Mr. P-A. Probst, Chairman of SG16 <pierre-andre.probst(a)swisscom.com> Mr. G. Wreikat, Vice-Chairman of SG16 <wreikat(a)hotmail.com> Mr. F. Tosco, Chairman of WP2/16 <Federico.Tosco(a)CSELT.IT> Mr. F. Bigi, ITU-TSB <Fabio.Bigi(a)itu.int> Mr. P. Luthi, Rapporteur for Q.1/16 <Patrick_Luthi(a)pictel.com> Mr. C. Groves, Ericsson <Christian.Groves(a)ericsson.com> De T Taylor Rapporteur for Q.D/16 <taylor(a)nortel.com> M Buckley Rapporteur for Q.F/16 <mikebuckley(a)44comms.com> M Euchner Rapporteur for Q.G/16 <Martin.Euchner(a)icn.siemens.de> P Jones Rapporteur for Q.2/16 <paulej(a)packetizer.com> G Freundlich Rapporteur for Q.3/16 <ggf(a)avaya.com> S Okubo Rapporteur for Q.4/16 <okubo(a)giti.waseda.ac.jp> P Reddy Rapporteur for Q.5/16 <paul.k.reddy(a)intel.com> --------------------------------------------------------- Subject: Notice of Joint Rapporteur Meeting in Launceston Date: 24 January 2001 --------------------------------------------------------- Dear experts of Questions D, F, G, 2-5/16, The subject meeting of ITU-T SG16 experts will be held in Launceston, Australia at the kind invitation of L. M. Ericsson. Please note that Q.1/16 will meet concurrently at the same place and has joint session(s) with Q.D, F, G, 2-5/16. 1. Date ^^^^^^^ 5 (Monday) - 9 (Friday) March 2001 starting at 9:00 (registration) and 9:30 (session) on the first day closing around 18:00 on the final day 2. Venue ^^^^^^^^ Novotel Launceston, Tasmania 29 Cameron Street Launceston Tasmania 7250 Australia Tel: +61 03 6334 3434 Fax: +61 03 6331 7347 3. Topics (tentative) ^^^^^^^^^^^^^^^^^^^^^ 1) Review of the relevant group activities 2) Q.2/16 Multimedia over packet networks using H.323 systems Q.F/16 Quality of Service and End-to-end Performance in Multimedia Systems - Progress work for * H.323 Annex N QoS * H.323 Annex H Mobility * H.323 Annex I Error prone channels * H.225.0 Annex Gv2 * H.323 Annex P "Modem Relay" * H.323 Annex R "Robustness" * H.323 Annex M.3 "DSS1 Tunneling" * H.450.x new recommendations * SS7 interworking * H.GEF.x guidelines and new recommendations - Other works that may arise 3) Q.3/16 Infrastructure and interoperability for Multimedia over packet networks - Revise Implementer $B%f (Bs Guide - Advance H.248 Annexes L, M, N, O - Progress H.248 V2 - Progress work on new packages and annexes - Progress work on new annexes to H.246 - Revise H.245 to support new features - Set additional objectives and develop work plan 4) Q.4/16 Video and data conferencing using Internet-supported services - Set objectives and develop work plan 5) Q.5/16 Mobility for Multimedia Systems and Services - Set objectives and develop work plan - Transfer the Mobility work under Q.2 to Q.5 - Progress of H.323 Annex H Mobility 6) Q.D/16 Interoperability of Multimedia Systems and Services - Develop work plan - Progress work on new annexes to H.246 7) Q.G/16 - Progress work on H.235 V3 - Progress work on new annexes to H.235 - Develop work plan for Q.G - Revise H.233, H.234, H.235 as needed 8) Interaction with other groups 9) Future work plan 4. Documents ^^^^^^^^^^^^ /// Registration of the document: by 23:59 UTC, 23 February /// /// Distribution of the document: by 23:59 UTC, 26 February /// /// Use the ftp site (or e-mail reflector) for distribution /// 1) When you are going to submit a document, please notify P Jones <paulej(a)packetizer.com>, document manager of this meeting, as soon as possible, by 23:59 UTC, Friday 23 February at the latest. Document number AVD-nnnn will be allocated. Early indication of your submission plan is welcome and encouraged. Note - Prefix "AVD" comes from Audio, Video and Data. 2) You are advised to include a header as follows: ------------------------------------------------------------------ | | | ITU Telecommunication Standardization Sector Document AVD-{nnnn}| | Study Group 16 {Version m if relevant}| | Q.D, F, G, 2-5/16 Rapporteur Meeting {Date}| | Launceston, 5-9 March 2001 | | | | SOURCE*: { } | | TITLE : { } | | PURPOSE: {Proposal, Discussion, Information, Report, etc.} | | | | _________________________ | | | | | | | | *Contact: Name, e-mail | ------------------------------------------------------------------ 3) All the contributors are requested to distribute their documents as early as possible, at least 7 calendar days in advance of the meeting (23:59 UTC, Monday 26 February or before) by posting them at either of the following: - PictureTel ftp site (please advise P Jones of your posting) Site: standard.pictel.com/avc-site Login name: anonymous Directory: Incoming - Intel e-mail reflector e-mail address: itu-sg16(a)mailbag.intel.com Please avoid the use of reflector when your document is voluminous. 4) Input documents can be retrieved from /0103_Lau directory of the ftp site. 5) The document distribution / presentation at the meeting will be all electronic. Participants must bring along their laptop, 10BASE-T card and cord according to the host's guidance. 5. Logistic information ^^^^^^^^^^^^^^^^^^^^^^^ Please see the attached document provided by the meeting host (http://standard.pictel.com/ftp/avc-site/0103_Lau/Ericsson_invitation_a.zip) . 6. Registration ^^^^^^^^^^^^^^^ To register your meeting attendance, please send the attached form to the meeting secretariat by 19 February 2001: Nicole Crook Ericsson Australia C/- MP Events, PO Box 2182, Kew, 3101 Victoria, Australia Tel: +61 3 9852 9941 Fax: +61 3 9852 9961 Email: nicole(a)mpevents.com.au 7. Hotel Room Reservation ^^^^^^^^^^^^^^^^^^^^^^^^^ Please send the attached form to the meeting secretariat together with the meeting registration by 19 February 2001. The room rate is $A135 per night including breakfast We are looking forward to meeting with you in Launceston. Sincerely yours, Tom TAYLOR Mike BUCKLEY Martin EUCHNER Paul JONES Glen FREUNDLICH Sakae OKUBO (meeting manager of this meeting) Paul REDDY ----------

1 0

Re: H248 imported ASN syntax in H.323
by Callaghan, Robert 23 Jan '01

23 Jan '01

Paul, The changes currently on the packetizer site currently reflect agreed changes that were not properly represented in the H.323v4 or H.225.0v4 text. The correctness of these changes can be reconstructed from the agreed contributions and meeting minutes. These changes do not represent anything new. You are proposing an "enhancement." This is something new. (I agree that it is a good enhancement; but this discussion has to do with process.) The ASN.1 that you object to was previously agreed to through contributions at a rapporteur meeting. Based on that agreement, the document was accepted at the study group 16 plenary meeting with formal approval of the various national representatives. (Yes, a member of the U.S. state department actually participated in the approval.) In a way, this is saying that the objection may be too late; but there are ways. It is not possible to change the specification solely based on a discussion on a mailing list. Although such a discussion is good in order to refine and clarify a solution. If you think that your change should be made, a contribution should be submitted to the rapporteur meeting that take place during 5-9 March 2001. Based on agreement in this meeting, the change can be incorporated into the Implementer's Guide or into H.225.0v5. The final agreement for anything currently being added to the implementer's guide will be during the working party meeting that takes place as part of the study group 16 meeting on 4-15 June 2001. A single objection at this time will block any change proposed for the implementer's guide. To be part of the H.225.0v5 changes only a consensus is required. H.225.0v5 will probably be approved in 2003. With these processes in mind, I hope that you understand the options available to you. I do hope that you succeed, because I do like your proposal and the isolation that it accommodates. Bob -------------------------------------------------------------- Robert Callaghan Siemens Enterprise Networks 5500 Broken Sound Blvd, Boca Raton, Fl 33487 Tel: +1 561 923-1756 Fax: +1 561 923-1403 Email: Robert.Callaghan(a)ICN.Siemens.com ----------------------------------------------------------------- -----Original Message----- From: Paul, Manoj [mailto:mpaul@TRILLIUM.COM] Sent: Tuesday, January 23, 2001 1:08 PM To: ITU-SG16(a)mailbag.cps.intel.com Subject: Re: H248 imported ASN syntax in H.323 Hi Paul, Since it is expected to have an Implementor's Guide for V4 of H.323, I believe it should still be possible to incorporate this change (making h248 context information to Octet Strings). The H.225 ASN.1 change log at Packetizer site reflects a few changes that were recently made to it. Is it not possible to incorporate this change the same way. Guess it would reduce lot of overhead of importing H248 ASN.1 syntax. -Manoj -----Original Message----- From: Paul E. Jones [mailto:paulej@PACKETIZER.COM] Sent: Monday, January 22, 2001 10:38 AM To: ITU-SG16(a)mailbag.cps.intel.com Subject: Re: H248 imported ASN syntax in H.323 Bob, I agree that it's potentially too late.. I say "potentially", because if we find so much as one real error in the ASN.1 (other than those already listed on Packetizer), it opens the door to making such a change. If no textual changes are required to the approved documents, just the data type, we could think about it. Of course, we might be opening the door for more problems :-) Paul ----- Original Message ----- From: "Callaghan, Robert" <Robert.Callaghan(a)icn.siemens.com> To: "'Paul E. Jones'" <paulej(a)PACKETIZER.COM>; <ITU-SG16(a)mailbag.cps.intel.com> Sent: Monday, January 22, 2001 8:11 AM Subject: RE: H248 imported ASN syntax in H.323 > Paul, > > At this point the question is not one of supporting a desirable change. > > The proposed change is clearly intended as an improvement. It is not a > correction of an error. This change applies to a decided (approved) > document. Therefore any change must be made in a backwards compatible > manner in the next release of the document. > > I, personally, like the change. But, it is too late. > > Bob > > -------------------------------------------------------------- > Robert Callaghan > Siemens Enterprise Networks > 5500 Broken Sound Blvd, Boca Raton, Fl 33487 > Tel: +1 561 923-1756 Fax: +1 561 923-1403 > Email: Robert.Callaghan(a)ICN.Siemens.com > ----------------------------------------------------------------- > > -----Original Message----- > From: Paul E. Jones [mailto:paulej@PACKETIZER.COM] > Sent: Sunday, January 21, 2001 7:51 PM > To: ITU-SG16(a)mailbag.cps.intel.com > Subject: Re: H248 imported ASN syntax in H.323 > > Manoj, > > I suppose the argument is that it makes it clearer to the implementer what > those fields are used for and how they should be completed. We've had > confusion in the past over what is supposed to go inside a fastStart > element, for example. It's almost worth considering replaying: > > h248Message OCTET STRING OPTIONAL > with > h248Message MegacoMessage OPTIONAL > > but people may have had a good reason not to want to do that. Perhaps it > was felt that that would require importing too much :-) > > I am fairly indifferent on the matter, though I'd prefer not to make changes > to the ASN.1 that are not errors. However, if we find errors in the ASN.1 > file, I'd consider changing other cosmetic items like this one. My hope is > that the ASN.1 file here: > http://www.packetizer.com/iptel/h323/h2250v4.asn > > is complete and without errors :-) > > (Note that it was last updated 18-Jan-2001.) > > Paul > > ----- Original Message ----- > From: "Paul, Manoj" <mpaul(a)TRILLIUM.COM> > To: <ITU-SG16(a)mailbag.cps.intel.com> > Sent: Friday, January 19, 2001 7:53 PM > Subject: H248 imported ASN syntax in H.323 > > > > Hi All, > > > > Would it not be useful to replace the following ASN.1 syntaxes > > in H.323 V4: > > > > 1) "SEQUENCE OF H248PackagesDescriptor" in RRQ with "SEQUENCE OF OCTET > > STRING" > > 2) H248SignalDescriptor by OCTET STRING in ServiceControlDescriptor > Choice. > > > > This would save importing the complete ASN.1 syntax of H248PackageDesc > > and H248SignalDesc from H.248. It's like representing H.245 tunneled > > messages in H.225 as OCTET STRINGS and hence saving the need to > > import of H.245 syntax. The usage of (1) and (2) as PackageDesc and > > SignalDesc would be clear from the context. > > > > -Manoj Paul. > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > 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

1 0

Re: H248 imported ASN syntax in H.323
by Paul, Manoj 23 Jan '01

23 Jan '01

Hi Paul, Since it is expected to have an Implementor's Guide for V4 of H.323, I believe it should still be possible to incorporate this change (making h248 context information to Octet Strings). The H.225 ASN.1 change log at Packetizer site reflects a few changes that were recently made to it. Is it not possible to incorporate this change the same way. Guess it would reduce lot of overhead of importing H248 ASN.1 syntax. -Manoj -----Original Message----- From: Paul E. Jones [mailto:paulej@PACKETIZER.COM] Sent: Monday, January 22, 2001 10:38 AM To: ITU-SG16(a)mailbag.cps.intel.com Subject: Re: H248 imported ASN syntax in H.323 Bob, I agree that it's potentially too late.. I say "potentially", because if we find so much as one real error in the ASN.1 (other than those already listed on Packetizer), it opens the door to making such a change. If no textual changes are required to the approved documents, just the data type, we could think about it. Of course, we might be opening the door for more problems :-) Paul ----- Original Message ----- From: "Callaghan, Robert" <Robert.Callaghan(a)icn.siemens.com> To: "'Paul E. Jones'" <paulej(a)PACKETIZER.COM>; <ITU-SG16(a)mailbag.cps.intel.com> Sent: Monday, January 22, 2001 8:11 AM Subject: RE: H248 imported ASN syntax in H.323 > Paul, > > At this point the question is not one of supporting a desirable change. > > The proposed change is clearly intended as an improvement. It is not a > correction of an error. This change applies to a decided (approved) > document. Therefore any change must be made in a backwards compatible > manner in the next release of the document. > > I, personally, like the change. But, it is too late. > > Bob > > -------------------------------------------------------------- > Robert Callaghan > Siemens Enterprise Networks > 5500 Broken Sound Blvd, Boca Raton, Fl 33487 > Tel: +1 561 923-1756 Fax: +1 561 923-1403 > Email: Robert.Callaghan(a)ICN.Siemens.com > ----------------------------------------------------------------- > > -----Original Message----- > From: Paul E. Jones [mailto:paulej@PACKETIZER.COM] > Sent: Sunday, January 21, 2001 7:51 PM > To: ITU-SG16(a)mailbag.cps.intel.com > Subject: Re: H248 imported ASN syntax in H.323 > > Manoj, > > I suppose the argument is that it makes it clearer to the implementer what > those fields are used for and how they should be completed. We've had > confusion in the past over what is supposed to go inside a fastStart > element, for example. It's almost worth considering replaying: > > h248Message OCTET STRING OPTIONAL > with > h248Message MegacoMessage OPTIONAL > > but people may have had a good reason not to want to do that. Perhaps it > was felt that that would require importing too much :-) > > I am fairly indifferent on the matter, though I'd prefer not to make changes > to the ASN.1 that are not errors. However, if we find errors in the ASN.1 > file, I'd consider changing other cosmetic items like this one. My hope is > that the ASN.1 file here: > http://www.packetizer.com/iptel/h323/h2250v4.asn > > is complete and without errors :-) > > (Note that it was last updated 18-Jan-2001.) > > Paul > > ----- Original Message ----- > From: "Paul, Manoj" <mpaul(a)TRILLIUM.COM> > To: <ITU-SG16(a)mailbag.cps.intel.com> > Sent: Friday, January 19, 2001 7:53 PM > Subject: H248 imported ASN syntax in H.323 > > > > Hi All, > > > > Would it not be useful to replace the following ASN.1 syntaxes > > in H.323 V4: > > > > 1) "SEQUENCE OF H248PackagesDescriptor" in RRQ with "SEQUENCE OF OCTET > > STRING" > > 2) H248SignalDescriptor by OCTET STRING in ServiceControlDescriptor > Choice. > > > > This would save importing the complete ASN.1 syntax of H248PackageDesc > > and H248SignalDesc from H.248. It's like representing H.245 tunneled > > messages in H.225 as OCTET STRINGS and hence saving the need to > > import of H.245 syntax. The usage of (1) and (2) as PackageDesc and > > SignalDesc would be clear from the context. > > > > -Manoj Paul. > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > 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

1 0

Re: H248 imported ASN syntax in H.323
by Callaghan, Robert 22 Jan '01

22 Jan '01

Paul, At this point the question is not one of supporting a desirable change. The proposed change is clearly intended as an improvement. It is not a correction of an error. This change applies to a decided (approved) document. Therefore any change must be made in a backwards compatible manner in the next release of the document. I, personally, like the change. But, it is too late. Bob -------------------------------------------------------------- Robert Callaghan Siemens Enterprise Networks 5500 Broken Sound Blvd, Boca Raton, Fl 33487 Tel: +1 561 923-1756 Fax: +1 561 923-1403 Email: Robert.Callaghan(a)ICN.Siemens.com ----------------------------------------------------------------- -----Original Message----- From: Paul E. Jones [mailto:paulej@PACKETIZER.COM] Sent: Sunday, January 21, 2001 7:51 PM To: ITU-SG16(a)mailbag.cps.intel.com Subject: Re: H248 imported ASN syntax in H.323 Manoj, I suppose the argument is that it makes it clearer to the implementer what those fields are used for and how they should be completed. We've had confusion in the past over what is supposed to go inside a fastStart element, for example. It's almost worth considering replaying: h248Message OCTET STRING OPTIONAL with h248Message MegacoMessage OPTIONAL but people may have had a good reason not to want to do that. Perhaps it was felt that that would require importing too much :-) I am fairly indifferent on the matter, though I'd prefer not to make changes to the ASN.1 that are not errors. However, if we find errors in the ASN.1 file, I'd consider changing other cosmetic items like this one. My hope is that the ASN.1 file here: http://www.packetizer.com/iptel/h323/h2250v4.asn is complete and without errors :-) (Note that it was last updated 18-Jan-2001.) Paul ----- Original Message ----- From: "Paul, Manoj" <mpaul(a)TRILLIUM.COM> To: <ITU-SG16(a)mailbag.cps.intel.com> Sent: Friday, January 19, 2001 7:53 PM Subject: H248 imported ASN syntax in H.323 > Hi All, > > Would it not be useful to replace the following ASN.1 syntaxes > in H.323 V4: > > 1) "SEQUENCE OF H248PackagesDescriptor" in RRQ with "SEQUENCE OF OCTET > STRING" > 2) H248SignalDescriptor by OCTET STRING in ServiceControlDescriptor Choice. > > This would save importing the complete ASN.1 syntax of H248PackageDesc > and H248SignalDesc from H.248. It's like representing H.245 tunneled > messages in H.225 as OCTET STRINGS and hence saving the need to > import of H.245 syntax. The usage of (1) and (2) as PackageDesc and > SignalDesc would be clear from the context. > > -Manoj Paul. > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > 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

Meeting date - correction
by OKUBO Sakae 22 Jan '01

22 Jan '01

Dear SG16 experts, I mistakenly wrote: >[...] for the joint Rapporteur meeting of Questions D, F, G, 1, 2, 3, 4 >and 5 that will be held in Launceston, Tasmania during 3-5 March 2001. The correct date is 5-9 March as written in the host's invitation. Apologies for the confusion and thank you Glen for your advice. Best regards, OKUBO Sakae *********************************************************** 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