- sg16-avd - lists.packetizer.com

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