January 2001 - sg16-avd - lists.packetizer.com

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