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

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 24 Jan '01

24 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

Re: Rapporteur for Q5/16
by Reddy, Paul K 22 Jan '01

22 Jan '01

Dear Radhika Roy, Thanks for your support. I am looking forward to working with you and resolving any current issues on H.323 Mobility and setting up new objectives and work plan for Q.5/16. regards, Paul Paul K. Reddy ITU-T SG16 WP2 Q.5 Rapporteur, Intel Corporation, USA -----Original Message----- From: Roy, Radhika R, ALCOO [mailto:rrroy@ATT.COM] Sent: Thursday, January 18, 2001 9:34 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: Rapporteur for Q5/16 Hi, Everyone: It is a good news that we now got a Rapp. for Q5/16 mobility. Earlier, we also got an editor and this makes our mobility team complete. Given the fact, Paul Reddy has been associated with the mobility work from the very beginning, it is hoped that things will go forward resolving all potential issues that we have discussing for a long time. Let us welcome Mr. Reddy for taking this responsibility and Mr. Tosco for finding the right person in this position. Best regards, Radhika R. Roy AT&T -----Original Message----- From: OKUBO Sakae [mailto:okubo@GITI.WASEDA.AC.JP] Sent: Wednesday, January 17, 2001 9:28 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Rapporteur for Q5/16 Dear SG16 WP2/16 experts, Mr. F Tosco, Chairman of WP2/16, has advised us that Mr. Paul K Reddy, Intel <paul.k.reddy(a)intel.com> has been appointed as Rapporteur for Q5/16 - Mobility for Multimedia Systems and Services. 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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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: Rapporteur for Q5/16
by Reddy, Paul K 22 Jan '01

22 Jan '01

Dear Mr. Samou, I am looking forward to working with you. Please email me any of your thoughts on the new objectives for Q.5/16 other than H.323 Mobility work. regards, Paul Paul K. Reddy ITU-T SG16 WP2 Q.5 Rapporteur, Intel Corporation, USA -----Original Message----- From: SAMOU Jean-claude FTRD/DAC/ISS [mailto:jeanclaude.samou@RD.FRANCETELECOM.FR] Sent: Friday, January 19, 2001 6:54 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: Rapporteur for Q5/16 Hi, Paul: All my congragulations to you for your appointment as Q5/16 Rapporteur. And be the force with our mobility team in Q5/16 to progress substantially our work. Best regards, Jean-Claude Samou ================================================= Dr. Jean-Claude Samou France Telecom R&D 38-40, rue du General Leclerc 92131 Issy les moulineaux France Tel: + 33 1 45 29 58 40 Fax: + 33 1 46 29 31 62 -----Original Message----- From: OKUBO Sakae [mailto:okubo@GITI.WASEDA.AC.JP] Sent: Wednesday, January 17, 2001 9:28 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Rapporteur for Q5/16 Dear SG16 WP2/16 experts, Mr. F Tosco, Chairman of WP2/16, has advised us that Mr. Paul K Reddy, Intel <paul.k.reddy(a)intel.com> has been appointed as Rapporteur for Q5/16 - Mobility for Multimedia Systems and Services. 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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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