- sg16-avd - lists.packetizer.com

Re: XRS RequestSeqNum can't be zero
by Ernst Horvath 06 Mar '98

06 Mar '98

Dear Mr. Long, A clean fix for the problem you discovered would be to allow 0 as a special value in RequestSeqNum: RequestSeqNum ::= INTEGER (0|1..65535) -- 0 reserved for XRS if the received message could not be decoded (A similar problem exists in ROSE where the InvokeID - an INTEGER - is used to associate responses with requests; usually the response contains the same InvokeID as the request, except when the request cannot be decoded. In this case a Reject is sent with InvokeID ::= NULL. The same approach could be used in H.225.0, but this would be a rather drastic change totally incompatible with version 1). Ernst Horvath Siemens AG Paul Long wrote: > Annex H/H.225.0v2 states that "RequestSeqNum ::= INTEGER (1..65535)," > but 7.17/H.225.0v2 says that requestSeqNum in XRS "shall be the > requestSeqNum of the unknown message, if it can be decoded, and zero > otherwise." > > Two problems: > > 1. It can't be set to zero because that value would be out of range, so > H.225.0 contradicts itself here. > > 2. If the requestSeqNum of the unknown message cannot be decoded, there > is no way to indicate this in the XRS. > > The receiver of XRS doesn't know whether the value, let's say 1, > reflects the value of the decoded requestSeqNum of the unknown message > or is a dummy value used in place of an undecodable requestSeqNum. IOW, > to the receiver of the XRS message, the value of the requestSeqNum field > may _or may not_ refer to a message it sent, and therefore the value > cannot be trusted. I don't know of any way to fix this. Maybe we can > just always assume that the value is valid--it was successfully decoded > from the unknown message--and don't worry about the small chance of it > being wrong. > > > Apart from these problems, the passage quoted, above, from > 7.17/H.225.0v2 implies that RequestSeqNum is unique across all outgoing > RAS messages; otherwise, what is the point of providing it in XRS--how > could the receiver of an XRS identify which message was not understood > if it uses a separate requestSeqNum variable for each xRQ? I know that > the scope of RequestSeqNum was discussed several months ago, and I agree > with the consensus that a receiver of an xRQ should not make any > assumptions about the scope. I just wanted to point out that a receiver > of XRS can only reliably use the requestSeqNum field if it uses a global > RequestSeqNum in outgoing xRQs. > > Paul Long > Smith Micro >

1 0

XRS RequestSeqNum can't be zero
by Paul Long 05 Mar '98

05 Mar '98

Annex H/H.225.0v2 states that "RequestSeqNum ::= INTEGER (1..65535)," but 7.17/H.225.0v2 says that requestSeqNum in XRS "shall be the requestSeqNum of the unknown message, if it can be decoded, and zero otherwise." Two problems: 1. It can't be set to zero because that value would be out of range, so H.225.0 contradicts itself here. 2. If the requestSeqNum of the unknown message cannot be decoded, there is no way to indicate this in the XRS. The receiver of XRS doesn't know whether the value, let's say 1, reflects the value of the decoded requestSeqNum of the unknown message or is a dummy value used in place of an undecodable requestSeqNum. IOW, to the receiver of the XRS message, the value of the requestSeqNum field may _or may not_ refer to a message it sent, and therefore the value cannot be trusted. I don't know of any way to fix this. Maybe we can just always assume that the value is valid--it was successfully decoded from the unknown message--and don't worry about the small chance of it being wrong. Apart from these problems, the passage quoted, above, from 7.17/H.225.0v2 implies that RequestSeqNum is unique across all outgoing RAS messages; otherwise, what is the point of providing it in XRS--how could the receiver of an XRS identify which message was not understood if it uses a separate requestSeqNum variable for each xRQ? I know that the scope of RequestSeqNum was discussed several months ago, and I agree with the consensus that a receiver of an xRQ should not make any assumptions about the scope. I just wanted to point out that a receiver of XRS can only reliably use the requestSeqNum field if it uses a global RequestSeqNum in outgoing xRQs. Paul Long Smith Micro

1 0

Notice of the Q.12-14/16 Yokosuka meeting
by Sakae Okubo 05 Mar '98

05 Mar '98

To Experts of ITU-T SG16 Q.12/16, Q.13/16 and Q.14/16 Cc Mr. P-A. Probst, Chairman of SG16 Mr. G. Helder, Vice-Chairman of SG16 Mr. F. Tosco, Chairman of WP2/16 Mr. F. Bigi, ITU-TSB Mr. T. Geary, Rapporteur for Q.11/16 De Sakae OKUBO Rapporteur for Q.12/16 in ITU-T SG16 Graphics Communication Laboratories 6F Annex Toshin Bldg. 4-36-19 Yoyogi Shibuya-ku, Tokyo 151 Japan Tel: +81 3 5351 0181 Fax: +81 3 5351 0184 E-mail: okubo(a)gctech.co.jp Dale SKRAN Rapporteur for Q.13/16 in ITU-T SG16 Ascend Communications, Inc. 621 Shrewsbury Avenue Shrewsbury, NJ 07702 USA Tel: +1 908 450 1635 Fax: +1 908 450 1611 E-mail: Dale.Skran(a)ascend.com Gary Thom Rapporteur for Q.14/16 in ITU-T SG16 Delta Information Systems Inc. Horsham Business Center Bldg. 3 300 Welsh Road, Horsham, PA 19044 Tel: +1 215 657 5270 ex 23 Fax: +1 215 657 5273 E-mail: gthom(a)delta-info.com ------------------------------------------------ Subject: Notice of Q.12-14/16 Rapporteur Meeting Date: 5 March 1998 ------------------------------------------------ Dear SG16 Colleagues, The subject meeting of ITU-T SG16 experts will be held in Yokosuka, Japan at the kind invitation of Group of Interested Organizations in Japan. Please note that Q.11 (system aspects) will meet concurrently at the same place and have joint sessions with Q.12-14/16. 1. Date ^^^^^^^ 14 (Tuesday) - 17 (Friday) April 1998 starting at 9:00 on the first day 2. Venue ^^^^^^^^ Yokosuka Research Park (YRP) YRP Center #1 Building 3-4 Hikarino-oka, Yokosuka-shi 239-0847 Japan Tel: +81 468 47 ???? (to be advised later) Fax: +81 468 47 ???? (to be advised later) 3. Topics (tentative) ^^^^^^^^^^^^^^^^^^^^^ 1) Review of the relevant group meetings 2) Q.12/16 B-ISDN multimedia systems and terminals - Generate white contribution for H.310 V2 - Generate white contribution for H.bmultipoint - Progress in other technical topics 3) Q.13/16 Packet switched multimedia systems and terminals - Liaison to SG8 Q4 re RT fax - H.323 Annex D for RT fax (generate white) - Work with Q.14 on MIBs - Other technical work 4) Q.14/16 Common protocols, MCUs and protocols for interworking with H.300-series terminals - H.235 V2 issues - H.245 V4 for Decision (9/98) - H.245 V5 issues - H.246 Annex B for Determination (9/98) - Other H.246 annexes and issues - H.MediaMIB for Determination (9/98) - Audio and video control - Other technical issues 5) Any other Q.12-14/16 related matters - Interaction with other groups 6) Future work 4. Documents ^^^^^^^^^^^^ /// Registration of the document: by April 3 /// /// Distribution of the document: by April 7 /// /// Use the ftp site or e-mail reflector for distribution. /// 1) When you are going to submit a document, please notify S. Okubo as soon as possible, by April 3 (Friday) at the latest. Document number (APC-1nnn) will be allocated. Early indication of your submission plan is welcome. Note - Prefix "APC" comes from Atm (Q.12/16), Packet based (Q.13/16) and Common protocols (Q.14/16) based on coordination with Q.1 ("Q1City"), Q.3 ("T120"), Q.11 ("Q11"), Q.15 ("Q15") groups. 2) You are advised to include a header as follows: ------------------------------------------------------------------ | | | ITU Telecommunication Standardization Sector Document APC-{1nnn}| | Study Group 16 {Version m if relevant}| | Q.12-14/16 Rapporteur Meeting {Date}| | Yokosuka, 14-17 April 1998 | | | | 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 (by April 7) by posting them at either of the following: - GCL ftp site (please advise S. Okubo of your posting) Site: ftp.gctech.co.jp Login name: itu-t Password: sg15!avc Directory: Incoming - Q.12-14/16 experts reflector e-mail address: itu-sg16(a)mailbag.jf.intel.com Please avoid the use of reflector when your document is voluminous. Use of Word for Windows 2.0 or 6 or pure text is recommended. 4) Input documents can be retrieved from 9804_Yok directory of the ftp site. 5) Please bring 60 copies of your document to Yokosuka. Your cooperation is needed to start the meeting with all the documents at hand; please note that the copying capacity at the meeting site is limited. 5. Logistic information ^^^^^^^^^^^^^^^^^^^^^^^ Please see the invitation which has been provided by the meeting host (/9804_Yok/invitation98.zip at the ftp site). 6. Registration ^^^^^^^^^^^^^^^ Please notify Mr. Harasaki (e-mail: harasaki(a)ccm.CL.nec.co.jp) with copy to Rapporteurs (e-mail: okubo(a)gctech.co.jp, Dale.Skran(a)ascend.com, gthom(a)delta-info.com) as soon as possible if you plan to attend the Yokosuka meeting. 7. Hotel Room Reservation ^^^^^^^^^^^^^^^^^^^^^^^^^ Please directly contact the following hotel using the form contained in the invitation. Yokosuka Prince Hotel 3-27 Hon-cho, Yokosuka 238-0041, Japan Tel: +81 468 21 1111 Fax: +81 468 21 1141 URL: http://www.princehotels.co.jp/yokosuka-e/index.html We are looking forward to meeting with you in Yokosuka. Sincerely yours, Sakae OKUBO Dale SKRAN Gary THOM

1 0

Far End Camera Control in H.323
by Anupama Anantharaman 04 Mar '98

04 Mar '98

Hello all, I have some questions pertaining to Far End Camera Control in H.323. I would appreciate it much if someone could please answer them. Is FECC going to be done through the T.120 channel? If so, then is H.281 encapsulated within t.120 stack? Or has the Standards committee come up with a different scheme to do Far End Camera Control? Thanks in advance, Anupama Phone: 408-922-4785 email: anupama(a)vtel.com

1 0

Invitation to the Yokosuka meeting from the host
by Sakae Okubo 03 Mar '98

03 Mar '98

Dear Q.12-14 colleagues, Sakai> I attached the invitation form (including registration form and Sakai> hotel reservation form) for the Yokosuka meeting in "Word95/6.0" Sakai> compatible format. I have created 9804_Yok directory at the ftp site and stored this zipped file. Best regards, Sakae OKUBO (Mr.) ******************************************************************** Graphics Communication Laboratories Phone: +81 3 5351 0181 6F ANNEX TOSHIN BLDG. Fax: +81 3 5351 0184 4-36-19 Yoyogi, Shibuya-ku, Tokyo e-mail: okubo(a)gctech.co.jp 151-0053 Japan ********************************************************************

1 0

Invitation to the Yokosuka meeting
by Kiyoshi SAKAI 02 Mar '98

02 Mar '98

Dear Q.11-14/16 colleagues, As I noticed earlier, I attached the invitation form (including registration form and hotel reservation form) for the Yokosuka meeting in "Word95/6.0" compatible format. The files I sent to you earlier in "Word97 format" were too big due to the use of "quick save" option. I recommend you to use attached files instead, or open the word97-format files and save them as different name without setting "allow quick saves" in the option tag in "Save" option in Word. If you have problems to read the attached documents, please feel free to access me. Best regards, ********************************************************************** Kiyoshi Sakai Media Processing Laboratory Multimedia Systems Labs. FUJITSU LABORATORIES LTD. Tel. : +81 44 754 2679 Fax. : +81 44 754 2347 E-mail : sakai(a)flab.fujitsu.co.jp **********************************************************************

1 0

Invitation to the Yokosuka meeting
by Kiyoshi SAKAI 02 Mar '98

02 Mar '98

Dear Q.11-14/16 colleagues, Attached please find the invitation for the next experts group meeting in Yokosuka(14-17, April). If you plan to attend the meeting, please register using the attached form as soon as posible. We have reserved a block of rooms at Yokosuka prince hotel at a special rate. If you want to reserve a room at the hotel, please send the attached form directly to the hotel NO LATER THAN March 20. The attached zip file contains three "Word97" documents. Please be careful, the unzipped files reach 20MBytes in size due to lots of bitmaps in them. I will send you the same files in "Word95/6.0" compatible format as soon as possible(Currently, I have difficulty to doing so). Best regards, ********************************************************************** Kiyoshi Sakai Media Processing Laboratory Multimedia Systems Labs. FUJITSU LABORATORIES LTD. Tel. : +81 44 754 2679 Fax. : +81 44 754 2347 E-mail : sakai(a)flab.fujitsu.co.jp **********************************************************************

1 0

H.235 decided clean text
by Sakae Okubo 26 Feb '98

26 Feb '98

Dear Q.12-14/16 colleagues, H.235 decided version is now available at the GCL ftp site: ftp://itu-t:sg15!avc@ftp.gctech.co.jp/9801_Gen/h235fin2.zip some time later at (mirror ftp://standard.pictel.com/video-site/h235fin2.zip ) ( http://standard.pictel.com/ftp/avc-site/h235fin2.zip) Best regards, Sakae OKUBO (Mr.) ******************************************************************** Graphics Communication Laboratories Phone: +81 3 5351 0181 6F ANNEX TOSHIN BLDG. Fax: +81 3 5351 0184 4-36-19 Yoyogi, Shibuya-ku, Tokyo e-mail: okubo(a)gctech.co.jp 151-0053 Japan ********************************************************************

1 0

H.323 integrated in the ftp site
by Sakae Okubo 26 Feb '98

26 Feb '98

Dear Francois Audet, >>Something must have gone wrong, because I just downloaded >>/9801_Gen/H323v2_D.zip and it does NOT have the changes of >>TD72_PLEN integrated in it. com-16-54-w323-chgs-accepted-final.doc >>does have the changes. They are not the same file. Also, on >>the Web page TD72_PLE.zip also points to H323v2nc_6.zip which is >>also not the final H.323. >> >>I am sending it to you again. Thank you again for your help. I have found that link setting was not correct for H.323 decided version and TD72_PLEN. To my surprise, this error happened here and there in 9801_Gen.html. File contents with indicated file names were correct. (This was my first try to use links.) All link errors have now been corrected. Best regards, Sakae OKUBO (Mr.) ******************************************************************** Graphics Communication Laboratories Phone: +81 3 5351 0181 6F ANNEX TOSHIN BLDG. Fax: +81 3 5351 0184 4-36-19 Yoyogi, Shibuya-ku, Tokyo e-mail: okubo(a)gctech.co.jp 151-0053 Japan ********************************************************************

1 0

Re: Addressing information in H.450.1
by Karl Klaghofer 25 Feb '98

25 Feb '98

Pete, Table 6/H.450.1 has not changed in Geneva, i.e. the table within the H.450.1 whitepaper you are referring to is still o.k. Remark: Since the ISDN like concept of Calling / Connected Line Identification Presentation / Restriction is not known in H.323, types like Table 6/H.450.1 PresentedNumberScreened, etc. have not been used within H.450.2, .3 (Only PresentationAllowedIndicator is used within Call Diversion). Once we want to make use of ISDN like Identification Presentation / Restriction concept within Supplementary Services, I would for consistency reasons also see the PartyNumber within types like NumberScreened or Address being replaced by EndpointAddress (which would e.g. enable to request presentation restriction at the destination side of an Alias other than PartyNumber). Karl ============================ Karl Klaghofer Siemens AG, Dpt. PN VS LP 3 D-81359 Munich, Germany Hofmannstr. 51 Tel.: +49 89 722 31488 Fax.: +49 89 722 22909 Mail.: karl.klaghofer(a)pn.siemens.de ============================ -----Original Message----- From: Pete Cordell [SMTP:pete.cordell@BT-SYS.BT.CO.UK] Sent: Mittwoch, 25. Februar 1998 09:04 To: ITU-SG16(a)mailbag.jf.intel.com Subject: Addressing information in H.450.1 Dear Karl (or anybody else who can answer), Please can you assure me that the majority of the partyNumber fields in Table 6/H.450.1 (white) should indeed refer PartyNumber and not to EndpointAddress as I would have first expected!!! Many thanks, Pete ================================= Pete Cordell BT Labs E-Mail: pete.cordell(a)bt-sys.bt.co.uk Tel: +44 1473 646436 Fax: +44 1473 645499 =================================

1 0

H.323 integrated in the ftp site
by Sakae Okubo 25 Feb '98

25 Feb '98

Daer Francois Audet, >>The integrated H.323 referencend in >>ftp://itu-t:sg15!avc@ftp.gctech.co.jp/9801_Gen/9801_Gen.html seem to >>be the wrong version. My understanding is that the file named >>"com-16-54-w323-chgs-accepted-final.doc" contained all the changes >>(including TD72). The file was in the Incoming directory, but seems >>to have been deleted. Thank you for your advice. I should have mentioned this, but the file /9801_Gen/H323v2_D.zip is the same as the one you found in the Incoming directory. Due to its very long file name, my Mac could not unzip the original posting. So I shortened the file name to H323v2_D.doc, zipped and moved it to 9801_Gen directory. Best regards, Sakae OKUBO (Mr.) ******************************************************************** Graphics Communication Laboratories Phone: +81 3 5351 0181 6F ANNEX TOSHIN BLDG. Fax: +81 3 5351 0184 4-36-19 Yoyogi, Shibuya-ku, Tokyo e-mail: okubo(a)gctech.co.jp 151-0053 Japan ********************************************************************

1 0

Edit to Q14 report
by Mark Reid 24 Feb '98

24 Feb '98

In the Question 14 meeting report, In the middle line of clause 3.8.5.2 bullet 3, "TD50 (PLEN)", should be "TD50 (WP2/16)" Thanks to Ken Krechmer for spotting this error. Mark Reid VideoServer Inc 781-505-2368 (tele) mreid(a)videoserver.com

1 0

Technical Corrigendums to ASN.1 (X.680)
by Toby Nixon 24 Feb '98

24 Feb '98

I noticed in ITU Operational Bulletin No. 660 (1 Feb 1998) that two technical corrigenda and a second amendment to X.680 have been adopted. They are described in the Bulletin as follows: - Technical Corrigendum 1 to Amendment 1 of ITU-T Recommendation X.680: Information technology - Abstract Syntax Notation One (ASN.1): Specification of basic notation - Amendment 1: Rules of extensibility - Technical Corrigendum 1 - Technical Corrigendum 2 to ITU-T Recommendation X.680: Information technology - Abstract Syntax Notation One (ASN.1): Specification of basic notation - Technical Corrigendum 2 - Amendment 2 to ITU-T Recommendation X.680: Information technology - Abstract Syntax Notation One (ASN.1): Specification of basic notation - Amendment 2: Remove Definition of Root Arcs of Object Identifier Tree Has anyone checked these changes to X.680 to see if they have any impact on the usage of ASN.1 in Recommendations under the control of SG 16? -- Toby ___________________________________________________________ Toby Nixon, Program Manager - NetMeeting http://www.microsoft.com/netmeeting Microsoft Corporation, Applications and Internet Client Group, Redmond WA USA +1 (425) 936-2792 Fax: +1 (425) 936-7329 mailto:tnixon@microsoft.com

1 0

Geneva outcome at the ftp site - corrected
by Sakae Okubo 24 Feb '98

24 Feb '98

/// Please discard my previous mail; I have found H.323 v2 update /// /// in the /Incoming directory. /// Dear Q.12-14/16 colleagues, I have collected files from the Geneva SG16 meeting at ftp://itu-t:sg15!avc@ftp.gctech.co.jp/9801_Gen/ (mirror ftp://standard.pictel.com/avc-site/9801_Gen/) but the following are missing: H.235 (decided) TD-1/PLEN or more desirably integrated text H.323 Annex D (determined) TD-71/PLEN Please owners of these files upload them at /Incoming directory. For retrieval, please take a look first at 9801_Gen.html. Best regards, Sakae OKUBO (Mr.) ******************************************************************** Graphics Communication Laboratories Phone: +81 3 5351 0181 6F ANNEX TOSHIN BLDG. Fax: +81 3 5351 0184 4-36-19 Yoyogi, Shibuya-ku, Tokyo e-mail: okubo(a)gctech.co.jp 151-0053 Japan ********************************************************************

1 0

Geneva outcome at the ftp site
by Sakae Okubo 24 Feb '98

24 Feb '98

Dear Q.12-14/16 colleagues, I have collected files from the Geneva SG16 meeting at ftp://itu-t:sg15!avc@ftp.gctech.co.jp/9801_Gen/ (mirror ftp://standard.pictel.com/avc-site/9801_Gen/) but the following are missing: H.235 (decided) TD-1/PLEN or more desirably integrated text H.323 (decided) TD-72/PLEN or more desirably integrated text H.323 Annex D (determined) TD-71/PLEN Please owners of these files upload them at /Incoming directory. For retrieval, please take a look first at 9801_Gen.html. Best regards, Sakae OKUBO (Mr.) ******************************************************************** Graphics Communication Laboratories Phone: +81 3 5351 0181 6F ANNEX TOSHIN BLDG. Fax: +81 3 5351 0184 4-36-19 Yoyogi, Shibuya-ku, Tokyo e-mail: okubo(a)gctech.co.jp 151-0053 Japan ********************************************************************

1 0

Addressing information in H.450.1
by Pete Cordell 24 Feb '98

24 Feb '98

Dear Karl (or anybody else who can answer), Please can you assure me that the majority of the partyNumber fields in Table 6/H.450.1 (white) should indeed refer PartyNumber and not to EndpointAddress as I would have first expected!!! Many thanks, Pete ================================= Pete Cordell BT Labs E-Mail: pete.cordell(a)bt-sys.bt.co.uk Tel: +44 1473 646436 Fax: +44 1473 645499 =================================

1 0

Re: User Information or Information in H.225.0
by Callaghan, Robert 23 Feb '98

23 Feb '98

Pete, Just a minor adjustment. H.450.1 specifies the use of call-independent signaling. Bob -------------------------------------- Robert Callaghan Siemens Business Communication Systems Email: Robert.Callaghan(a)Siemenscom.com Tel: +1.561.997.3756 FAX: +1.561.997.3403 >-----Original Message----- >From: Pete Cordell [SMTP:pete.cordell@BT-SYS.BT.CO.UK] >Sent: Friday, February 20, 1998 8:44 AM >To: ITU-SG16(a)MAILBAG.INTEL.COM >Subject: Re: User Information or Information in H.225.0 > >Glen, > >On closer examination there seem to be a few errors in Table 4/H.225.0. >The 6th paragraph of section 7.1/H.225.0 (white paper at least) says >that the "The procedures of Q.931/Section 3.1 for circuit mode >connection setup are followed." According to this section the messages >"User Information" and "Congestion Control" do not apply. They are used >in the call-independent signalling part that we are not using. > >Also "Status Inquiry" is spelt "Status Enquiry" in Q.931 (not that I >would know what is the right form!!!). > >We need to go with option 1 of your suggestions. The Information >message is what we need for overlap sending. The description part of >7.3.6 is correct for the "Information" message (including the reference >to the table in Q.931). > >If we can silently remove "Congestion Control" at the same time so much >the better!!!!! > >Regards, > >Pete >================================= >Pete Cordell >BT Labs >E-Mail: pete.cordell(a)bt-sys.bt.co.uk >Tel: +44 1473 646436 >Fax: +44 1473 645499 >================================= > > >>---------- >>From: Glen Freundlich[SMTP:ggf@LUCENT.COM] >>Sent: 19 February 1998 16:09 >>To: ITU-SG16(a)MAILBAG.INTEL.COM >>Subject: User Information or Information in H.225.0 >> >>In H.225.0 V1, section 7.3.6 describes the User Information message. >>The >>related ASN.1 definition is named UI-UUIE, but the table and caption >>(Table 9) describe the Q.931 Information message. >> >>H.323 V2 describes the use of the Information message (for example, to >>support overlap sending), but H.225.0 V2 contains no section describing >>the Information message and no ASN.1 has been defined specifically for >>use with the Information message. >> >>Possible fixes seem to be: >> >>1 - rename section 7.3.6 from "User Information" to "Information" and >>add some text stating that the Information message is used to support >>overlap sending >> >>2 - correct section 7.3.6 to align with the User Information message >>(correct the table, correct the reference to Q.931) and add a new >>section (and associated ASN.1) for the Information message >> >>3 - other suggestions? >> >>As backward compatibility is a concern, the best approach depends on >>existing implementations and the use of User Information or Information >>messages. So, a vendor that decides to implement might interpret this >>to >>be a User Information message with a different set of information >>elements (not as described in table 9/H225) or an Information message >>with the set of information elements as defined in table 9. >> >>Please comment. >> >>Regards, >>Glen Freundlich (editor H.225.0) >> >> >>-- >>Glen Freundlich ggf(a)lucent.com >>Lucent Technologies office: +1 303 538 2899 >>11900 N. Pecos fax: +1 303 538 3907 >>Westminster, Colorado 80234 USA >>

1 0

unsubscribe/subscribe
by isabelle haignere 23 Feb '98

23 Feb '98

Please, would it be possible to be unregistered with the Email address "isabelle.haignere(a)issy.cnet.fr" ? and to be registered with the new Email address "isabelle.haignere(a)cnet.francetelecom.fr ? I thank you very much. Isabelle Haignere FT/BD - CNET/DSE/SGV 38-40 rue du general Leclerc 92131 Issy-Moulineaux Tel : 33 1 45 29 40 08 Fax : 33 1 45 29 52 94 Email : isabelle.haignere(a)cnet.francetelecom.fr --------------------------------------------------- --------------------------------------------------- Isabelle HAIGNERE FT/BD - CNET/DSE/SGV 38-40 rue du general Leclerc 92131 Issy-Moulineaux Tel : 33 1 45 29 40 08 Fax : 33 1 45 29 52 94 Email : isabelle.haignere(a)cnet.francetelecom.fr ---------------------------------------------------

1 0

Request of uploading
by Sakae Okubo 20 Feb '98

20 Feb '98

Dear Editors, Please upload your decided and determined draft Recommendations at the Incoming directory if not yet done. Best regards, Sakae OKUBO (Mr.) ******************************************************************** Graphics Communication Laboratories Phone: +81 3 5351 0181 6F ANNEX TOSHIN BLDG. Fax: +81 3 5351 0184 4-36-19 Yoyogi, Shibuya-ku, Tokyo e-mail: okubo(a)gctech.co.jp 151-0053 Japan ********************************************************************

1 0

Treatment of Q.931 Shifted Code Sets in H.225.0v2
by Tom Taylor 20 Feb '98

20 Feb '98

In Sec. 7.1 of H.225.0 the following paragraph appears shortly before the table: "Endpoints not supporting Q.931 shifted code sets shall ignore all Q.931 messages using such methods." Was this not supposed to read: "Endpoints not supporting Q.931 shifted code sets shall ignore all IEs using such methods." Background: the latter is the practice in ISDN land. The typical use of shifted code sets in North America is for the end-to-end transport of display information (e.g. caller's name and number). Code set 5 (national information) is used for the purpose.

1 0

Re: Request of uploading
by Kiyoshi SAKAI 20 Feb '98

20 Feb '98

Dear Mr.Okubo, As requested, I have uploaded the determined version of H.310v2 document to the Incoming directory of the GCL ftp site. The file name is; TD66PL_R.ZIP (Word95 document "h310v2DR.doc" is zipped in it) Regards, ********************************************************************** Kiyoshi Sakai Media Processing Laboratory Multimedia Systems Labs. FUJITSU LABORATORIES LTD. Tel. : +81 44 754 2679 Fax. : +81 44 754 2347 E-mail : sakai(a)flab.fujitsu.co.jp **********************************************************************

1 0

Re: User Information or Information in H.225.0
by Pete Cordell 20 Feb '98

20 Feb '98

Glen, On closer examination there seem to be a few errors in Table 4/H.225.0. The 6th paragraph of section 7.1/H.225.0 (white paper at least) says that the "The procedures of Q.931/Section 3.1 for circuit mode connection setup are followed." According to this section the messages "User Information" and "Congestion Control" do not apply. They are used in the call-independent signalling part that we are not using. Also "Status Inquiry" is spelt "Status Enquiry" in Q.931 (not that I would know what is the right form!!!). We need to go with option 1 of your suggestions. The Information message is what we need for overlap sending. The description part of 7.3.6 is correct for the "Information" message (including the reference to the table in Q.931). If we can silently remove "Congestion Control" at the same time so much the better!!!!! Regards, Pete ================================= Pete Cordell BT Labs E-Mail: pete.cordell(a)bt-sys.bt.co.uk Tel: +44 1473 646436 Fax: +44 1473 645499 ================================= >---------- >From: Glen Freundlich[SMTP:ggf@LUCENT.COM] >Sent: 19 February 1998 16:09 >To: ITU-SG16(a)MAILBAG.INTEL.COM >Subject: User Information or Information in H.225.0 > >In H.225.0 V1, section 7.3.6 describes the User Information message. >The >related ASN.1 definition is named UI-UUIE, but the table and caption >(Table 9) describe the Q.931 Information message. > >H.323 V2 describes the use of the Information message (for example, to >support overlap sending), but H.225.0 V2 contains no section describing >the Information message and no ASN.1 has been defined specifically for >use with the Information message. > >Possible fixes seem to be: > >1 - rename section 7.3.6 from "User Information" to "Information" and >add some text stating that the Information message is used to support >overlap sending > >2 - correct section 7.3.6 to align with the User Information message >(correct the table, correct the reference to Q.931) and add a new >section (and associated ASN.1) for the Information message > >3 - other suggestions? > >As backward compatibility is a concern, the best approach depends on >existing implementations and the use of User Information or Information >messages. So, a vendor that decides to implement might interpret this >to >be a User Information message with a different set of information >elements (not as described in table 9/H225) or an Information message >with the set of information elements as defined in table 9. > >Please comment. > >Regards, >Glen Freundlich (editor H.225.0) > > >-- >Glen Freundlich ggf(a)lucent.com >Lucent Technologies office: +1 303 538 2899 >11900 N. Pecos fax: +1 303 538 3907 >Westminster, Colorado 80234 USA >

1 0

User Information or Information in H.225.0
by Glen Freundlich 19 Feb '98

19 Feb '98

In H.225.0 V1, section 7.3.6 describes the User Information message. The related ASN.1 definition is named UI-UUIE, but the table and caption (Table 9) describe the Q.931 Information message. H.323 V2 describes the use of the Information message (for example, to support overlap sending), but H.225.0 V2 contains no section describing the Information message and no ASN.1 has been defined specifically for use with the Information message. Possible fixes seem to be: 1 - rename section 7.3.6 from "User Information" to "Information" and add some text stating that the Information message is used to support overlap sending 2 - correct section 7.3.6 to align with the User Information message (correct the table, correct the reference to Q.931) and add a new section (and associated ASN.1) for the Information message 3 - other suggestions? As backward compatibility is a concern, the best approach depends on existing implementations and the use of User Information or Information messages. So, a vendor that decides to implement might interpret this to be a User Information message with a different set of information elements (not as described in table 9/H225) or an Information message with the set of information elements as defined in table 9. Please comment. Regards, Glen Freundlich (editor H.225.0) -- Glen Freundlich ggf(a)lucent.com Lucent Technologies office: +1 303 538 2899 11900 N. Pecos fax: +1 303 538 3907 Westminster, Colorado 80234 USA

1 0

Re: [Help] Who can anyone tell me email address of Mr. Matsumoto..
by Istvan Sebestyen 19 Feb '98

19 Feb '98

At 10:52 19.02.1998 +0900, Yongmin Choi wrote: >I have questions about holding an ITU meeting. >Please let me know the email address of Dr. Matsumoto. > >Thank you in advance.. > >============================================================= >Yong-Min Choi >Technical Evaluation Center >Korea Telecom R & D Group >e-mail: himrchoi(a)rcunix.kotel.co.kr >============================================================= > > Yes, here it is.... matumoto(a)tom.comm.waseda.ac.jp Sincerely, Istvan SEbestyen ------------------------------------------------------------------ Istvan Sebestyen Siemens AG Standardization, Large Networks PN GS 94, Private Communications Systems Group, Mch H/1760/255 Tel: +49-89-722 47230 Hofmannstr. 51 Fax: +49-89-722 47713 D-81359 Munich, GERMANY Internet: istvan.sebestyen(a)mch.pn.siemens.de (preferred) istvan.sebestyen(a)pn.siemens.de (Fall back only) X.400: c=de;a=dbp;p=scn;o=siemens;ou1=mch;ou2=PN-msmail; s=Sebestyen;g=Istvan Note: Unfortunately - in practice - e-mails sent to me occasionally may get lost or stay unread for a long time due to business trips. So, for very important communication pls. send a "back-up" in fax. ------------------------------------------------------------------

1 0

[Help] Who can anyone tell me email address of Mr. Matsumoto..
by Yongmin Choi 18 Feb '98

18 Feb '98

I have questions about holding an ITU meeting. Please let me know the email address of Dr. Matsumoto. Thank you in advance.. ============================================================= Yong-Min Choi Technical Evaluation Center Korea Telecom R & D Group e-mail: himrchoi(a)rcunix.kotel.co.kr =============================================================

1 0