- sg16-avd - lists.packetizer.com

Directory 9801_Gen at the ftp site
by Sakae Okubo 25 Sep '97

25 Sep '97

Dear SG16 colleagues, As suggested at the Sunriver meeting, I have created the subject directory at the GCL ftp site. This is for the moment to place white contributions for decision at the January 1998 meeting of SG16. Later other files will also be placed here such as input and output TDs. Currently the followings are available; H222AM34.doc, H262AM34.zip, H321v2wh.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 Japan ********************************************************************

1 0

Re: Corrections for H.225.0 V2.
by Euchner Martin ZT IK 3 25 Sep '97

25 Sep '97

Dear Glen, Attached is a word document that shows the additions and changes I made to the H.225 ASN.1. Could you please review and let me know if it is now correct, or what needs to change? I need to send the document in today (Thursday), so please reply as soon as possible. Perhaps you can help me understand something. The GRQ has an integrity field (SEQUENCE OF IntegrityMechanism) which I assume is used by the sender to indicate the algorithms available to the sender. meu>: That's right. Sender and receiver negotiate during GRQ/GFC whether to apply integrity on RAS messages and if yes, which integrity mechanism they choose; see IntegrityMechanism (digital signature, ISO9797, HMAC-xxx or non-standard). The ICV includes an algorithmOID (OBJECT IDENTIFIER), which I'm guessing indicates the algorithm used to compute the integrity check value. But, it looks to me that the possible algorithms under IntegrityMechanism are not represented in algorithmOID. For example, how can I represent hMAC-MD5 or nonStandard in ICV? Can you explain this to me? meu>: This is not quite correct. The algorithmID within the ICV structure is only used when the digital signature is applied as integrity mechanism. In this case, the algorithmOID tells the receiver by which digital signature algorithm the sender has computed the enclosed digital signature (e.g. RSA or DSS and applied hash functions etc.). However, this algorithmID is not used at all when the ICV is computed using symmetric techniques such as the HMAC methods or ISO9797. As both involved entities have agreed already on the integrity mechanism during GRQ/GCF there is no further need to indicate the applied integrity method within each RAS message; thus, it is not possible to change the integrity mechanism between RAS messages on the same RAS channel. I reviewed also the attached Word document which you sent me and recommend the following change to the ICV structure: I made the following changes: 1.) replaced the dash by a blank between OBJECT and IDENTIFIER 2.) replaced icv by signature in the comment. 3.) replaced the underscore _ by a blank between BIT and STRING. ICV ::= SEQUENCE { algorithmOID OBJECT IDENTIFIER, -- the algorithm used to compute the signature icv BIT STRING -- the computed cryptographic integrity check value -- or signature } That's all. I hope this helps and clarified your questions and allows you to complete and close H.225.0 V2! I will post this message also to our ITU-T reflector; however as round-trip time is very long - about one day for me - you will also get a direct mail from me which should get through much faster. Martin. ----------------------------------------------------------------------- | Dipl.-Inf. Phone: +49 89 636-46201 | Martin Euchner Fax : +49 89 636-48000 | Siemens AG | ZT IK 3 e-mail: Martin.Euchner(a)mchp.siemens.de | | Otto-Hahn-Ring 6 | 81730 Muenchen | __________________ | Germany -----------------------------------------------------------------------

1 0

"flowControlToZero message?"
by Paul Long 25 Sep '97

25 Sep '97

7.3.2/H.245v3 mentions the FlowControlToZero field of the H2250LogicalChannelAckParameters type and a "flowControlToZero message" (see quote below). However, I cannot find a definition for such a message in the H.245 ASN.1 syntax. Is this _not_ an H.245 message, has it just not been defined yet, or should this be a reference to the _FlowControl_ message with scope set to logicalChannelNumber? Regardless of the answer, this needs to be explained better in the Recommendation. "FlowControlToZero indicates whether the transmitter is allowed to start transmitting on the logical channel. If set to true, it indicates that the transmitter should not transmit on the logical channel until receiving a subsequent flowControlToZero message allowing it to do so. If set to false, or absent, the transmitter is allowed to begin transmitting immediately the channel is established." -- Paul Long___________________________http://www.cmpu.net/public/plong Smith Micro Software, Inc.__________http://www.smithmicro.com/

1 1

Whither userInputSupportIndication?
by Paul Long 24 Sep '97

24 Sep '97

With the addition of UserInputCapability to H.245v3, the H.245v2 userInputSupportIndication choice of UserInputIndication is redundant and could cause interoperability problems due to the resulting ambiguity. Since H.245v2 is Decided, we cannot remove userInputSupportIndication from the H.245 ASN.1 syntax. Therefore, how shall we resolve there being two ways to signal whether a terminal is able to transmit the nonStandard, basicString, iA5String, or generalString forms of the alphanumeric choice of UserInputIndication? We could just "ignore" the problem and deprecate the use of the userInputSupportIndication choice either formally, i.e., written down, or informally. Or we could hope that referencing Recommendations do not require or allow userInputSupportIndication. -- Paul Long___________________________http://www.cmpu.net/public/plong Smith Micro Software, Inc.__________http://www.smithmicro.com/

1 0

Corrections for H.245V3
by Euchner Martin ZT IK 3 24 Sep '97

24 Sep '97

Dear Mike, I checked H.245 V.3 from a security point of view and found out that the following issues have to be corrected: Subsection Conference Response definitions is missing definition of ReturnSig which should be as follows: ReturnSig ::= SEQUENCE { alias AliasAddress, responseRandom RandomVal, requestRandom RandomVal OPTIONAL, certificate TypedCertificate OPTIONAL - requested certificate } EncodedReturnSig ::= TYPE-IDENTIFIER.&Type (ReturnSig) The following definition seems not to be used by any H.245 ASN.1 and looks rather redundant; thus it should be removed: ChallengeString ::=OCTET STRING (SIZE(8..16)) Please incorporate these changes to the text. Thank you. Martin. ----------------------------------------------------------------------- | Dipl.-Inf. Phone: +49 89 636-46201 | Martin Euchner Fax : +49 89 636-48000 | Siemens AG | ZT IK 3 e-mail: Martin.Euchner(a)mchp.siemens.de | | Otto-Hahn-Ring 6 | 81730 Muenchen | __________________ | Germany ----------------------------------------------------------------------- ----------------------------------------------------------------------- | Dipl.-Inf. Phone: +49 89 636-46201 | Martin Euchner Fax : +49 89 636-48000 | Siemens AG | ZT IK 3 e-mail: Martin.Euchner(a)mchp.siemens.de | | Otto-Hahn-Ring 6 | 81730 Muenchen | __________________ | Germany -----------------------------------------------------------------------

1 0

White contribution for H.321 v2
by Sakae Okubo 24 Sep '97

24 Sep '97

Dear Mr. Gates, I have reviewed your three documents contained in H321v2.zip and slightly modified them as follows: 1) H321v2.doc - clean version I have added a cover sheet for the white contribution with Rapporteur as the source and Editor as the contact point. The draft Recommendation is kept intact except for adding 5.9 in CONTENT. New file is named as H321v2wh.doc. 2) H321dlta.doc - revised version with change marks I tried to remove redundant parts such as striking out the original text and adding a new text (like Section 3 Definitions and Abbreviations) by using the material in the list of changes. I also tried to remove the change marks for unchanged figures. I found new 5.9 was missing in CONTENTS. New file is named as H321v2wc.doc. 3) H321chng.doc - list of changes - new 5.9 has been added in CONTENTS. - replacement of Figure 3 has been added. - renumbering of the items New file is named as H321dltr.doc. Updated three files and their zipped file (H321v2wh.zip) are plcaed in the Incoming directory of the GCL ftp site. I would appreciate if you have time to take a look at it. In any case I will send it to Geneva tomorrow (25th, Tokyo time). Could you please help TSBEDH if anything is wrong as I am going to travel from next Friday for a week without access to the Internet? 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 Japan ********************************************************************

1 0

Corrections for H.235
by Euchner Martin ZT IK 3 24 Sep '97

24 Sep '97

Dear Jim, all the following comments concern the H.235 white paper on the reflector. I tried to check the remaining stuff very quickly in the document and found the following items: 1. Page 7: goal no. 7 should end with H.235. 2. page 12: device is missing in the sentence ... not simply the physical device. 3. page 14: Section 6.6 does not mention that MCUs as well as intermediate GW/GKs are considered as trusted elements. Thus, the reference in section 9.1 is misleading and should point at least to section 3 in the appendix A instead. Why don't you include that section also to section 6.6? 4. Page 17: Section 10.2: Headline should read Diffie-... instead of Diffe. 5. Page 17: Section 10.2: Figure A: the request is missing the SeqNum and should look like ... XOR randomb XOR SeqNum ... 6. page 19: Section 10.3.4: I would change exchanged to assigned in the 2nd sentence with would read then: This protocol is based on ISO 9798-3, (5.2.1), it is assumed that an identifier and associated certificate are assigned during subscription. 7. page 19: Section 10.3.4: The figure should allow also optional certificate exchange. 8. Page 22: In AuthenticationMechanism one-way has to be deleted in the comment - Diffie-Hellman. 9. certificate key protection stuff within H.245 seems not to be complete, this needs some more inspections..... Martin. ----------------------------------------------------------------------- | Dipl.-Inf. Phone: +49 89 636-46201 | Martin Euchner Fax : +49 89 636-48000 | Siemens AG | ZT IK 3 e-mail: Martin.Euchner(a)mchp.siemens.de | | Otto-Hahn-Ring 6 | 81730 Muenchen | __________________ | Germany -----------------------------------------------------------------------

1 0

Re: H.235 Draft
by Corey Gates 24 Sep '97

24 Sep '97

Jim, Some mostly editorial comments on the H.235 Draft: - (Page 12) Section 6.2, 2nd paragraph, 3rd sentence ends with "...not simply the physical."; do you mean to say "physical terminal"? I'm not sure. - (Page 13) Section 6.2.1, 2nd paragraph, 1st sentence "... requires the endpoints..." should be changed to "...the endpoints are required..." - (Page 14) Section 6.6, 1st paragraph, last sentence: remove the "," between "...an element" and "is the confidence...". - (Page 16) Section 8.4, the last sentence is enclosed in braces; is there a reason for this? It seems that the statement about the MC is valid and should be included in the text. This is re-stated in section 9.2 I believe. - (Page 16) Section 8.5, 3rd paragraph: It seems that this should only apply when the H.245 channel is secure; in fact the document allows for the encryption key to be passed in other places beside the OpenLogicalChannelAck. Perhaps we need to add a sentence saying that "When the H.245 channel is operated in secure mode..." or something like that. Section 11.1appears to fill this out. - (Page 17) Section 10.2, Figure A, Phase 2: Shouldn't this be a cryptoToken, because it is encrypted via the DH key? Maybe I don't understand the token usage correctly. Also, should we include a Note descibing the meaing of { }E DH-secret ? The other figures seem to have note to this effect. Finally, the last sentence of this sections indicates that EPB knows GeneralIDa, but I believe this will only be true if Phase 1 includes the optional cryptoToken. - (Page 21) Section 11.1, last bullet point of last paragraph: encryptionUpdate should be in bold type. - (Page 22) Annex A: Is there a reason why ChallengeString is limited to only 16 OCTETs? It seems that this may want to get larger in the future. Also, do the BIT STRINGS in the DHset need to have MSB/LSB ordering specified? A comment would probably suffice and clear up future implementation problems. - (Page 32 and 38) Appendix A to D: Should these be numbered Appendix I to IV so as not to be confused with Annexes? Corey Gates corey(a)fvc.com Tel: +1.408.567.7214 Fax: +1.408.988.7077

2 1

Corrections for H.225.0 V.2
by Euchner Martin ZT IK 3 24 Sep '97

24 Sep '97

Dear Glen, I just checked H.225.0 V.2 as H.235 no longer contains security ASN.1. Thanks for including the ICV fields from APC-1271 in all the RAS messages. Unfortunately, you forgot to include the following ASN.1 signaling elements shown below which are necessary to signal the integrity mechanism to be used during the GRQ and GCF to the recipient. Sections 7.8.1 and 7.8.2 about GRQ and GCF should include the following description: integrity - indicates to the recipient which integrity mechanism is to be applied on the RAS messages. All the following stuff goes into section 15 - Annex H: EncryptIntAlg ::= CHOICE { -- core encryption algorithms for H.225.0 message integrity nonStandard NonStandardParameter, isoAlgorithm OBJECT IDENTIFIER , -- defined in ISO/IEC 9979 } NonIsoIntegrityMechanisms ::= CHOICE { -- HMAC mechanism used, no truncation, tagging may be necessary! hMAC-MD5 NULL OPTIONAL, -- MD5 as hash function hMAC-iso10118-2-s EncryptIntAlg OPTIONAL, -- according to ISO/IEC 10118-2 using -- EncryptIntAlg as core block encryption algorithm (short 64-bit MAC) hMAC-iso10118-2-l EncryptIntAlg OPTIONAL, -- according to ISO/IEC 10118-2 using -- EncryptIntAlg as core block encryption algorithm (long 128-bit MAC) hMAC-iso10118-3 OBJECT IDENTIFIER OPTIONAL, -- according to ISO/IEC 10118-3 -- using OID as hash function (OID is SHA-1, RIPE-MD160, RIPE-MD128) } IntegrityMechanism ::= CHOICE { -- for H.225.0 RAS message integrity nonStandard NonStandardParameter, digSig NULL OPTIONAL, -- indicates to apply a digital signature iso9797 OBJECT IDENTIFIER OPTIONAL, -- according to ISO/IEC 9797 using OID as -- core encryption algorithm (X-CBC MAC) nonIsoIM NonIsoIntegrityMechanism } Thus GRQ and GCR should read as follows (integrity entry added): GatekeeperRequest ::= SEQUENCE --(GRQ) { requestSeqNum RequestSeqNum, protocolIdentifier ProtocolIdentifier, nonStandardData NonStandardParameter OPTIONAL, rasAddress TransportAddress, endpointType EndpointType, gatekeeperIdentifier GatekeeperIdentifier OPTIONAL, callServices QseriesOptions OPTIONAL, endpointAlias SEQUENCE OF AliasAddress OPTIONAL, ..., alternateEndpoints SEQUENCE OF Endpoint OPTIONAL, tokens SEQUENCE OF ClearToken OPTIONAL, cryptoTokens SEQUENCE OF CryptoH323Token OPTIONAL, integrity SEQUENCE OF IntegrityMechanism OPTIONAL, authenticationCapability SEQUENCE OF AuthenticationMechanism OPTIONAL, algorithmOIDs SEQUENCE OF OBJECT IDENTIFIER OPTIONAL, integrityCheckValue ICV OPTIONAL } GatekeeperConfirm ::= SEQUENCE --(GCF) { requestSeqNum RequestSeqNum, protocolIdentifier ProtocolIdentifier, nonStandardData NonStandardParameter OPTIONAL, gatekeeperIdentifier GatekeeperIdentifier OPTIONAL, rasAddress TransportAddress, ..., alternateGatekeeper SEQUENCE OF AlternateGK OPTIONAL, authenticationMode AuthenticationMechanism OPTIONAL, tokens SEQUENCE OF ClearToken OPTIONAL, integrity SEQUENCE OF IntegrityMechanism OPTIONAL, cryptoTokens SEQUENCE OF CryptoH323Token OPTIONAL, algorithmOID OBJECT IDENTIFIER OPTIONAL, integrityCheckValue ICV OPTIONAL } I'm sorry for the late discovery. Please include the above changes to the document text. Martin. ----------------------------------------------------------------------- | Dipl.-Inf. Phone: +49 89 636-46201 | Martin Euchner Fax : +49 89 636-48000 | Siemens AG | ZT IK 3 e-mail: Martin.Euchner(a)mchp.siemens.de | | Otto-Hahn-Ring 6 | 81730 Muenchen | __________________ | Germany -----------------------------------------------------------------------

1 0

H.225.0V2 comment
by Karl Klaghofer 24 Sep '97

24 Sep '97

Glen, Joerg, Pete, Amotz and others, In the Sunriver Meeting, the type for the element h4501SupplementaryService in the H323-UU-PDU was changed from "SEQUENCE OF H4501SupplementaryService OPTIONAL" to "OCTET STRING OPTIONAL". We request to modify the current definition in H.225.0V2 Draft as follows (including a short comment): ******** "h4501SupplementaryService SEQUENCE OF OCTET STRING OPTIONAL" -- each sequence of octet string is defined as one H4501SupplementaryService APDU -- as defined in TABLE3/H.450.1 ******** Reason for change: With the previous definition (SEQUENCE OF H450SupplementaryService) it was possible to signal multiple H450SupplementaryService APDUs within one User-user information element. This is required if APDUs which require different NetworkFacilityExtension and/or EntityType encoding have to be sent within one single message. With just using "OCTET STRING", we see compatibility problems between different vendors Supplementary Service implementations in case of multiple H4501SupplementaryService APDUs beeing used. Remark: The alternative - to change the H.4501SupplementaryService APDU structure - should be avoided at this stage. The comment "-- each sequence ....." as proposed above shall give at least textual linkage between H.225.0V2 and the corresponding H.450.1 module. Regards, Karl Klaghofer //////////////////////////////////////////////////////////////// Siemens AG Munich Hofmannstr. 51, D-81359 Munich, Germany Tel.: +49 89 722 31488 Fax.: +49 89 722 23977 email: karl.klaghofer(a)mch.pn.siemens.de ////////////////////////////////////////////////////////////////

2 1

H.235 Draft
by Jim Toga 23 Sep '97

23 Sep '97

Greetings, I have placed the latest version of H.235 White paper at the Incoming directory of the ITU-T ftp site. (H235White.zip) any comments appreciated. Regards, jimt. ************************************************************************* *** +1-503-264-8816(voice) +1-503-264-3485(fax) *** *** jtoga(a)ibeam.intel.com Intel - Hillsboro, OR. *** *** PGP keyID 36 07 86 49 7D 74 DF 57 50 CB BA 32 08 9C 7C 41*** *************************************************************************

1 0

Re: H.323V2 draft
by Lior Moscovici 23 Sep '97

23 Sep '97

Gary, There is a slight misunderstanding with the responses to IRR: in H.323 they are called ICF & IRJ, while in H.225.0 they are called IACK & INAK respectively. I don't care how they are called, as long as it is consistent... Lior Moscovici -------- On 09/22/97 12:06 PM MST gthom(a)DELTA-INFO.COM wrote: All, H323v2i.doc has been uploaded to the gctech ftp site. It is complete except for the text on empty capability sets (TD-27) and Annex C on H.323 over ATM. Let me know if any of your changes have been missed, or have not been incorporated properly. Gary ------------------------------------- Name: Gary Thom Company: Delta Information Systems, Inc. Phone: +1-215-657-5270 x23 Fax : +1-215-657-5273 E-mail: gthom(a)delta-info.com Date: 09/22/97 Time: 08:57:14 -------------------------------------

1 0

Re: Req: Clarification on fast setup
by Jim Toga 23 Sep '97

23 Sep '97

Pete, My comments are interspersed below.... Regards, jimt. At 05:27 PM 9/23/97 +0100, you wrote: >Jim, > >Looking at the fast start stuff, I'm confused about the format of the >FastCap field and how it is used. Is the intention to allow multiple >multiplexCapbility fields in the SETUP? How would this be used as H.245 >allows only one instance of the field? Perhaps the encoding below would Good point, your representation is marginally better.... although I think simply stating that it is only relevant once per FastCap entry is enough. I'm not sure that removing the OPTIONAL from Capabilty lends that much. >describe the intended use better. > >FastCap ::= SEQUENCE >{ > caps SEQUENCE OF Capability, > multiplexCap multiplexCapability OPTIONAL, > ... >} > >Setup-UUIE ::= SEQUENCE >{ > -- deleted fields > cryptoTokens SEQUENCE OF CryptoH323Token OPTIONAL, > fastStart SEQUENCE OF OpenLogicalChannel OPTIONAL, > fastCap FastCap OPTIONAL, > canOverlapSend BOOLEAN >} > >Perhaps the semantics could describe this better if this is the case. > >I also have a few questions: > >In Glen's text it mentions that the OpenLogicalChannel parameters in the >SETUP message indicate parameters to be used in the callee to caller >direction, i.e. the reverse sense to an H.245 OpenLogicalChannel. As >the text in H.323 says that these are the parameters "that would >normally be passed later in the H.245 OpenLogicalChannel" I'm wondering >if the statement is correct. If the sense truly is reversed, then this >should be brought out more in the text in H.323. The point is that 'normally' one shouldn't radically change their capabilites from the FastStart mechanism to the regular H.245 cap exchange.... > >Also, what I am not clear on is if a terminal can receive and transmit >G.723 and G.729 how it should indicate this in the fast channel mode. They would simply do this as with H.245 - by including a set of receive and transmit caps that indicate G.723 and G.729.....? >Negotiation is important for this as G.723 might be the safer bet, but >G.729 might be better for delivery of in-band DTMF tones (or simply have >lower delay). Also, future codecs that are better tailored to the >Internet may be developed, and you want to be able to use these as soon >as possible. Could you supply an example of this? I'm really not sure what you're getting at here? Any codepoints that are defined in H.245 can be utilized (along with nonStandard...) > >How well do you see the scheme working when MCs are involved. Is it the >case that MCs will have to use slow start, or have I missed something? In so far as MCs are callable entities which 'look like' endpoints it works fine. As soon as any multipoint operations are commenced, the expectation at this point, is that H.245 is utilized. >MCs won't be able to use communicationModeCommand so I guess they won't >be able to instruct endpoints what to do in any forcible way. Is this >correct? As we have much special text in H.323/H.225 on making MCs >work, perhaps some text on how MCs and fast start interwork should be >included. The original intent of this mechanism was not to provide a seamless solution in all situations - it was to provide a fast connection sequence for pt-pt calls. > >Perhaps some annotated ladder diagrams would be useful. I appreciate >that you haven't had much time though. As a question to the wider >community (Dale!), would it be possible to add extra clarifying text of >this nature in January if it was felt to be useful? > >Best regards, > >Pete >================================= >Pete Cordell >BT Labs >E-Mail: pete.cordell(a)bt-sys.bt.co.uk >Tel: +44 1473 646436 >Fax: +44 1473 645499 >================================= > > ************************************************************************* *** +1-503-264-8816(voice) +1-503-264-3485(fax) *** *** jtoga(a)ibeam.intel.com Intel - Hillsboro, OR. *** *** PGP keyID 36 07 86 49 7D 74 DF 57 50 CB BA 32 08 9C 7C 41*** *************************************************************************

1 0

Req: Clarification on fast setup
by Pete Cordell 23 Sep '97

23 Sep '97

Jim, Looking at the fast start stuff, I'm confused about the format of the FastCap field and how it is used. Is the intention to allow multiple multiplexCapbility fields in the SETUP? How would this be used as H.245 allows only one instance of the field? Perhaps the encoding below would describe the intended use better. FastCap ::= SEQUENCE { caps SEQUENCE OF Capability, multiplexCap multiplexCapability OPTIONAL, ... } Setup-UUIE ::= SEQUENCE { -- deleted fields cryptoTokens SEQUENCE OF CryptoH323Token OPTIONAL, fastStart SEQUENCE OF OpenLogicalChannel OPTIONAL, fastCap FastCap OPTIONAL, canOverlapSend BOOLEAN } Perhaps the semantics could describe this better if this is the case. I also have a few questions: In Glen's text it mentions that the OpenLogicalChannel parameters in the SETUP message indicate parameters to be used in the callee to caller direction, i.e. the reverse sense to an H.245 OpenLogicalChannel. As the text in H.323 says that these are the parameters "that would normally be passed later in the H.245 OpenLogicalChannel" I'm wondering if the statement is correct. If the sense truly is reversed, then this should be brought out more in the text in H.323. Also, what I am not clear on is if a terminal can receive and transmit G.723 and G.729 how it should indicate this in the fast channel mode. Negotiation is important for this as G.723 might be the safer bet, but G.729 might be better for delivery of in-band DTMF tones (or simply have lower delay). Also, future codecs that are better tailored to the Internet may be developed, and you want to be able to use these as soon as possible. Could you supply an example of this? How well do you see the scheme working when MCs are involved. Is it the case that MCs will have to use slow start, or have I missed something? MCs won't be able to use communicationModeCommand so I guess they won't be able to instruct endpoints what to do in any forcible way. Is this correct? As we have much special text in H.323/H.225 on making MCs work, perhaps some text on how MCs and fast start interwork should be included. Perhaps some annotated ladder diagrams would be useful. I appreciate that you haven't had much time though. As a question to the wider community (Dale!), would it be possible to add extra clarifying text of this nature in January if it was felt to be useful? Best regards, 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: reRouteIndication
by Callaghan, Robert 23 Sep '97

23 Sep '97

Pete, Not to judge the merits of your argument, but I think that there is a procedure problem. H.245, H.225.0, and the H.450.x series of specification were closed based on the input from Sun River. I consider the introduction of new feature requirement at this time is not acceptable. Major additions without a public hearing is not acceptable. This mail exploder does not constitute a public hearing. These proposals should be for the next version. Yes, minor editorial changes can be made in the January Geneva meeting. What you are proposing involves a major philosophical question, the level of support for features outside of H.450. Bob -------------------------------------- Robert Callaghan Siemens Business Communication Systems Email: Robert.Callaghan(a)Siemenscom.com Tel: +1.561.997.3756 >-----Original Message----- >From: Pete Cordell [SMTP:pete.cordell@BT-SYS.BT.CO.UK] >Sent: Friday, September 19, 1997 1:17 PM >To: ITU-SG16(a)mailbag.jf.intel.com >Subject: Re: reRouteIndication > >Ernst, Glen, > >I was working on a TD in Sunriver to suggest that Notify should be used, >but I was advised that this was not the right message. It may be that >Notify is the closest message to what is required and so I have no >objections to it being used. > >Glen has also suggested that additional fields such as reRouteReason, >endpointAlias, originalDestination, and reRouteCounter should be added. >The first two I agree with. The second one I'm not sure of what it >means so don't know whether I agree with it or not. On reRouteCounter, >I'm not sure what it would be counting. For the Facility-UUIE based >re-route this is used so that the endpoint can check for infinite loops. > As this would be used as a notify that a re-route had already been >done, then the usefulness of this information is limited. > >As to whether we include an indication of this sort, I am very wary of >feature creep also. However, to me this seems such a fundamental call >control feature that it shouldn't require supplementary service support. > It should also be emphasized that this is not a replacement for >anything in H.450.2, and ctComplete should be used when H.450.2 is in >use. It is also light weight to implement; endpoints would not have to >process it on reception, and re-routers should generate it, but it >shouldn't be mandatory for them to generate it (for reasons such a >anonymity in security and things like that). > >Given these suggestions, a revised PDU might be: > >H323-UU-PDU ::= SEQUENCE >{ > h323-message-body CHOICE > { > setup Setup-UUIE, > callProceeding CallProceeding-UUIE, > connect Connect-UUIE, > alerting Alerting-UUIE, > userInformation UI-UUIE, > releaseComplete ReleaseComplete-UUIE, > facility Facility-UUIE, > ..., > progress Progress-UUIE, > dummy NULL, > notify CHOICE > { > reRouteIndication >ReRouteIndication, > ... > } > }, > nonStandardData NonStandardParameter OPTIONAL, > ..., >h4501SupplementaryService SEQUENCE OF H4501SupplementaryService >OPTIONAL >} > >ReRouteIndication ::= SEQUENCE >{ > -- display no longer needed as this is in Notify message > reRouteReason CHOICE > { > h4502Proxy NULL, > thirdPartyService NULL, > secondaryDialling NULL, > qSIGInterworking NULL, > ... > } > endpointAlias SEQUENCE OF AliasAddress, > endpointInfo EndpointType, > ... >} > >Pete > >================================= >Pete Cordell >BT Labs >E-Mail: pete.cordell(a)bt-sys.bt.co.uk >Tel: +44 1473 646436 >Fax: +44 1473 645499 >================================= > > >>---------- >>From: Ernst Horvath[SMTP:Ernst.Horvath@SIEMENS.AT] >>Sent: 19 September 1997 10:40 >>To: ITU-SG16(a)mailbag.jf.intel.com >>Subject: Re: reRouteIndication >> >>Dear Pete, >> >>some observations on your mail: >> >>> It has been mentioned that when a gatekeeper performs a re-route it >>> would be good for the client to know about it. After much >>> investigation, there seems to be no message in Q.931 that handles this >>> case. >> >>The Notify message could be used for that purpose (as an alternative to >>Facility), but again, its use is supplementary-service specific (and >>was >>removed from H.450.1). In QSIG we use Facility whenever the information >>is to be processed by the endpoint, which is nearly always the case. >>Notify is restricted to situations where (less important) information >>is >>passed to the user without acting on it, and loss of the information >>would not be of great concern for the overall working of a feature. >> >>> In the text that I proposed in Sunriver I suggested that a >>> Facility message with a H.450 ctComplete should be sent. >>> However, this is not much use to an entity that does >>> not support supplementary services. >> >>The same situation can arise in the ISDN and QSIG case. But that does >>not prevent the re-routing from taking place, it only means that this >>terminal cannot display the information. >> >>> Therefore it might be useful to add can extra case to the >>> H323-UU-PDU to cover this, e.g.: >>> >>> H323-UU-PDU ::= SEQUENCE >>> { >>> h323-message-body CHOICE >>> { >>> setup Setup-UUIE, >>> callProceeding CallProceeding-UUIE, >>> connect Connect-UUIE, >>> alerting Alerting-UUIE, >>> userInformation UI-UUIE, >>> releaseComplete ReleaseComplete-UUIE, >>> facility Facility-UUIE, >>> ..., >>> progress Progress-UUIE, >>> dummy NULL, >>> reRouteIndication ReRouteIndication >>> }, >>> nonStandardData NonStandardParameter OPTIONAL, >>> ..., >>> h4501SupplementaryService SEQUENCE OF H4501SupplementaryService >>OPTIONAL >>> } >>> >>> ReRouteIndication ::= SEQUENCE >>> { >>> display IA5String (SIZE( 0..255) ), >>> endpointInfo EndpointType, >>> ... >>> } >>> >>> This could then be sent by a gatekeeper when a re-route has been done. >>> >> >>Your proposal does not say which message you would use. If it is >>Facility, then the Facility-UUIE could be enhanced instead. >> >>However, I have a more general concern with this new proposal: >>An endpoint would still have to be upgraded to understand this coding. >>The only advantage compared to your original proposal (i.e. using an >>operation) might be slightly less complex coding. However, it goes >>against the intention of H.450.x. The idea behind the approach in H.450 >>is *not* to add new coding in H.225.0 whenever new functionality is >>created, but to use the *generic* container 'H4501 Supplementary >>Service >>APDU' and confine all new functionality plus coding to the >>supplementary >>service recommendation. This allows a neat modular approach where you >>tailor your system by choosing the right building blocks. >>Therefore I prefer using operations wherever possible. >> >>Kind Regards, >>Ernst >>================================ >>Ernst Horvath >>Siemens AG >>Tel: +43 1 1707 45897 >>Fax: +43 1 1707 56992 >>Email: ernst.horvath(a)siemens.at >>================================ >>

1 0

[Federico.Tosco@CSELT.IT: SG 16 future meetings]
by Sakae Okubo 23 Sep '97

23 Sep '97

Return-Path: <Federico.Tosco(a)CSELT.IT> Return-Receipt-To: Tosco Federico <Federico.Tosco(a)CSELT.IT> Date: Fri, 19 Sep 1997 17:30:30 +0200 From: Tosco Federico <Federico.Tosco(a)CSELT.IT> Subject: SG 16 future meetings To: "Blaschitz, Michael" <michael.blaschitz(a)infonova.at>, "DeGrasse, Bruce" <b.degrasse(a)mci2000.com>, "Geary, Tom" <tom.geary(a)nb.rockwell.com>, "Okubo, Sakae" <okubo(a)gctech.co.jp>, "Robin-Champigneul, Yves" <yves.robin-champigneul(a)issy.cnet.fr>, "Skran, Dale" <Dale.Skran(a)ascend.com>, "Thom, Gary" <gthom(a)delta-info.com> X-Envelope-To: okubo(a)gctech.co.jp Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Content-Transfer-Encoding: 7BIT X-Priority: 3 Dear colleagues, During the SG 16 coordination meeting in Sunriver Mr. Bigi has given the tentative dates of the future meetings of SG 16 in 1999 and 2000: March 1999 February 2000 The delay between the two meetings is very long. It would be good if we could have an invitation for a SG 16 (or Joint WPs) meeting in between. As you know the 1998 meetings are scheduled as follows: 26 January - 6 February 14-25 September Best regards Federico

1 0

Re: TD-27 text for h.323
by Pete Cordell 23 Sep '97

23 Sep '97

Gary, I forgot to mention where I thought TD-27 text should go. I think the best place for it would be 8.4.6 (a new section in the Sunriver version) after the MC cascading part. This brings it in as part of Phase D: Call Services. Of the other options you mentioned, the first seems a bit tutorially, and the second is too early in the sequence of events. 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: gthom[SMTP:gthom@DELTA-INFO.COM] >Sent: 19 September 1997 19:47 >To: ITU-SG16(a)mailbag.jf.intel.com >Subject: TD-27 text for h.323 > >Pete and others, > >I took some editorial liberty with the text of TD-27. It is contained >below. I expect >to put this in 6.2.8.1 Capability Exchange. Alternatively, I could put >it into 8.2. >Any suggestions, changes, clarifications??? > >Thanks > Gary > >****************************************** > >"To allow gatekeepers to re-route connections from endpoints that do >not support >supplementary services, endpoints shall support the reception of empty >capability >sets (i.e. Terminal Capability sets that indicate that the endpoint >sending the >message has no receive capabilities). This feature also allows >'network' elements >such as PBXs, call centers, and IVR systems to re-route connections >independent >of supplementary services and facilitates pre-connect announcements. >It can also >be used to delay H.245 media establishment when features such as >Gatekeeper >based user location is being used. It is also highly recommended that >Version 1 >endpoints support this feature. > >On reception of an empty capability set an endpoint shall enter a >paused state. If >media stream or data logical channels were previously opened by the >endpoint, >they should be closed. In this state an endpoint shall accept the >opening of logical >channels from the remote end based on the usual rules and continue to >receive >media from open logical channels from the remote end. This allows >endpoints to >receive announcements (e.g. pre-connect call progress) where the >announcing >entity does not wish to receive media from the endpoint. > >On reception of a non-empty capability set in this paused state an >endpoint shall >reset its H.245 state to that which it was in prior to entering the >paused state. >This allows an endpoint to be connected to a different endpoint when it >is >released from the paused state. Note that the non-empty capability set >shall not >be sent to an endpoint until all its transmit and receive logical >channels have been >closed. A switching entity should also send an H.450 redirection >indication Facility >message if the endpoint is being re-routed. The endpoint shall then >proceed with >normal H.245 connection establishment signalling. When leaving the >paused state >an endpoint shall take part in master/slave determination signalling, >and may >proceed with normal open logical channel signalling procedures. When >an MC >receives a release from the paused state it shall act as if a new >endpoint has >entered the conference. > >Unless its capabilities have changed, an endpoint need not resend a >capability set >as the gatekeeper will have supplied this to remove any paused state in >the >remote endpoint. This option of not sending a capability set enables >faster >reconnection. > >------------------------------------- >Name: Gary Thom >Company: Delta Information Systems, Inc. >Phone: +1-215-657-5270 x23 >Fax : +1-215-657-5273 >E-mail: gthom(a)delta-info.com >Date: 09/19/97 >Time: 11:47:19 >------------------------------------- >

1 0

Re: reRouteIndication
by Scott Petrack 23 Sep '97

23 Sep '97

I think I understand, thanks for the clarification. (Of course maybe the next sentence will prove that I don't understand ;-)): I did not want to change anything about either the dummy/empty issue nor the *content* of the reRouteIndication issue. I was just saying that IF {there are possibilities for the h323-message-body that don't appear in the UUIEs-requested structure in TD-28a} then {these new types should be added to the UUIEs-requested structure mentioned in TD-28a} We agreed to allow a GK to monitor what an endpoint does in this way, and I just wanted it to be complete. Please let me know if this doesn't make sense (and I didn't understand). Scott pete.cordell(a)BT-SYS.BT.CO.UK on 09/22/97 12:56:49 PM Please respond to ITU-SG16(a)mailbag.jf.intel.com To: ITU-SG16(a)mailbag.jf.intel.com cc: (bcc: Scott Petrack) Subject: Re: reRouteIndication Joerg, Scott, To clarify, dummy is a Hertzliya addition and nothing to do with reRouteIndication. It's needed because if you send a supplementary service message in a FACILITY you may not want to invoke the Facility-UUIE. The optimum case would be to make the UUIE h323-body-message part OPTIONAL, but this is not possible at this stage. Hence adding the dummy field. As to the name.... dummy, empty, emptyChoice, noChoice, blankChoice, void,... would be OK with me (I'm sure we have bigger sins than this!). As for text to describe the field, maybe... empty - This option is used when a FACILITY message is sent, but the Facility-UUIE is not to be invoked. This may occur when transporting supplementary service messages. reRouteIndication is a different issue. As re-routing can take place independent of supp services, it seems reasonable that an endpoint should be able to get notification of this event independent of supp services. Pete ================================= Pete Cordell BT Labs E-Mail: pete.cordell(a)bt-sys.bt.co.uk Tel: +44 1473 646436 Fax: +44 1473 645499 ================================= >---------- >From: Joerg Ott[SMTP:jo@TZI.ORG] >Sent: 20 September 1997 08:54 >To: ITU-SG16(a)mailbag.jf.intel.com >Subject: Re: reRouteIndication > >Pete and all, > >two comments on this mail: >> >> It has been mentioned that when a gatekeeper performs a re-route it >> would be good for the client to know about it. After much >> investigation, there seems to be no message in Q.931 that handles this >> case. In the text that I proposed in Sunriver I suggested that a >> Facility message with a H.450 ctComplete should be sent. However, this >> is not much use to an entity that does not support supplementary >> services. Therefore it might be useful to add can extra case to the >> H323-UU-PDU to cover this, e.g.: >> >> H323-UU-PDU ::= SEQUENCE >> { >> h323-message-body CHOICE >> { >> setup Setup-UUIE, >> callProceeding CallProceeding-UUIE, >> connect Connect-UUIE, >> alerting Alerting-UUIE, >> userInformation UI-UUIE, >> releaseComplete ReleaseComplete-UUIE, >> facility Facility-UUIE, >> ..., >> progress Progress-UUIE, >> dummy NULL, > >First: > >I must have missed the "dummy" parameter before. I assume the need for >an empty parameter comes from supplementary services, and I suggest to >call >it "empty NULL" (this is not an implementation but a standard after >all) >and to describe it somewhere in H.225.0. Searching through the >document, >the ASN.1 was the only place where "dummy" was used. >(Should I be saying something about puzzles right now? :-) >> reRouteIndication ReRouteIndication >> }, >> nonStandardData NonStandardParameter OPTIONAL, >> ..., >> h4501SupplementaryService SEQUENCE OF H4501SupplementaryService >OPTIONAL >> } >> >> ReRouteIndication ::= SEQUENCE >> { >> display IA5String (SIZE( 0..255) ), >> endpointInfo EndpointType, >> ... >> } >> >> This could then be sent by a gatekeeper when a re-route has been done. >> > >Second: > >Overall, I agree with the mail from Ernst Horvath on this issue: we >should >not add such functionality to H.225.0, not even to version two. > >Joerg >

1 0

New Mailing List for H323-URLs
by Scott Petrack 22 Sep '97

22 Sep '97

As discussed at the recent rapporteurs meeting in SunRiver, we have opened a new mailing list (reflector) to be devoted to the subject H.323 URLs. It is called h323-url(a)vocaltec.com. To subscribe, you send mail to: h323-url-request(a)vocaltec.com and put subscribe in a line of the message. It makes no difference what the subject line is. 2. If you want to subscribe to a different address than the return address, you put subscribe userid(a)domain.name on a line of the body of the letter. It is a usual majordomo server. Sincerely, Scott Petrack

1 0

Re: H.450.x ASN.1 Modules
by Corey Gates 22 Sep '97

22 Sep '97

Karl, > There is one remaining error on line 142 in a module copied from original > X.880. For some reason the ASN.1 compiler complains that the "opcode" is > not defined, even though the same construct does not have an error on line > 109. > In order to get the H.450 ASN.1 code to compile we commented this reference > temporarily. > In order to test the code take the comment on line 142 out. > If somebody has an idea what causes this problem please report to me as > soon as possible. Did you apply to corrigendum to X.880 first? The syntax you attached did not contain the X.880 syntax you used, so I couldn't tell. One of the changes is the following: < ({Operations} {@opcode} --- > ({Operations} {@.opcode} which should fix your problem. The corrigendum is available at http://www.itu.ch/itudoc/itu-t/rec/x/x500up/x880c1_31931.html (it's free to download). If you could run the syntax by Bancroft Scott, the ASN.1 editor, he can double check any issues that you have with the syntax. He can be contacted at baos(a)oss.com. Corey Gates corey(a)fvc.com Tel: +1.408.567.7214 Fax: +1.408.988.7077

1 0

Re: New draft of H.245
by Corey Gates 22 Sep '97

22 Sep '97

Dear Colleagues, Below are some comments on the latest draft H.245, ordered by page number, not importance: - (Page 8) Should we add some clarification about extension to the description of the Capability Exchange? Here is some text that could be added to the end of the first paragraph: "When a capability is received which contains extensions not understood by the terminal, the capability shall be accepted as if it did not contain the extensions." What do people think? - (Page 29) Since we are importing elements from H.235 that are required to compile the syntax, should we not put the IMPORTS statement at the beginning of the syntax? Or at least at the beginning of the Encryption section? This is not a big issue, but it is kind of buried in the syntax and an implementor needs to know that the imported types are required to build a correct implementation. - (Page 39 and 92) Should there be "cause" codes in the OpenLogicalChannelReject message for bad "encryptionSync", "transportCapability" and "redundancyEncoding"? It seems that there should be more information about why the channel is being rejected. - (Page 88, 3rd paragraph, 3rd sentence) "logical channel" should be capitalized to "Logical channel" because it starts the sentence. - (Page 91) In the text concerning "FlowControlToZero", it indicates that the transmitter should not transmit on a logical channel until receiving a subsequent "FlowControlToZero" message. However, this message is only contained in the OpenLogicalChannelAck. Shouldn't this be a subsequent "FlowControl" command? - (Pages 96 and 43) In the text concerning ModeElement, it refers to an element called "EncryptedMode"; however, in the ASN.1 syntax there is only an element called "h235Mode". I think the text needs to be changed to say "h235Mode". - (Page 113) RequestForFloor is described twice, the first one should be removed. - (Page 237) In Appendix IV, regarding the extension procedure, should we add some text clarifying the capability issue? Here is some proposed text that could be added to the fourth paragraph: "Specifically, when an H.245 Capability is extended, the extension shall not change the meaning of the original capability in such a way that a terminal which does not understand the extension would need to modify its operation to use the capability without the extension." What to people think? Corey Gates corey(a)fvc.com Tel: +1.408.567.7214 Fax: +1.408.988.7077

2 1

Re: reRouteIndication
by Pete Cordell 22 Sep '97

22 Sep '97

Joerg, Scott, To clarify, dummy is a Hertzliya addition and nothing to do with reRouteIndication. It's needed because if you send a supplementary service message in a FACILITY you may not want to invoke the Facility-UUIE. The optimum case would be to make the UUIE h323-body-message part OPTIONAL, but this is not possible at this stage. Hence adding the dummy field. As to the name.... dummy, empty, emptyChoice, noChoice, blankChoice, void,... would be OK with me (I'm sure we have bigger sins than this!). As for text to describe the field, maybe... empty - This option is used when a FACILITY message is sent, but the Facility-UUIE is not to be invoked. This may occur when transporting supplementary service messages. reRouteIndication is a different issue. As re-routing can take place independent of supp services, it seems reasonable that an endpoint should be able to get notification of this event independent of supp services. Pete ================================= Pete Cordell BT Labs E-Mail: pete.cordell(a)bt-sys.bt.co.uk Tel: +44 1473 646436 Fax: +44 1473 645499 ================================= >---------- >From: Joerg Ott[SMTP:jo@TZI.ORG] >Sent: 20 September 1997 08:54 >To: ITU-SG16(a)mailbag.jf.intel.com >Subject: Re: reRouteIndication > >Pete and all, > >two comments on this mail: >> >> It has been mentioned that when a gatekeeper performs a re-route it >> would be good for the client to know about it. After much >> investigation, there seems to be no message in Q.931 that handles this >> case. In the text that I proposed in Sunriver I suggested that a >> Facility message with a H.450 ctComplete should be sent. However, this >> is not much use to an entity that does not support supplementary >> services. Therefore it might be useful to add can extra case to the >> H323-UU-PDU to cover this, e.g.: >> >> H323-UU-PDU ::= SEQUENCE >> { >> h323-message-body CHOICE >> { >> setup Setup-UUIE, >> callProceeding CallProceeding-UUIE, >> connect Connect-UUIE, >> alerting Alerting-UUIE, >> userInformation UI-UUIE, >> releaseComplete ReleaseComplete-UUIE, >> facility Facility-UUIE, >> ..., >> progress Progress-UUIE, >> dummy NULL, > >First: > >I must have missed the "dummy" parameter before. I assume the need for >an empty parameter comes from supplementary services, and I suggest to >call >it "empty NULL" (this is not an implementation but a standard after >all) >and to describe it somewhere in H.225.0. Searching through the >document, >the ASN.1 was the only place where "dummy" was used. >(Should I be saying something about puzzles right now? :-) >> reRouteIndication ReRouteIndication >> }, >> nonStandardData NonStandardParameter OPTIONAL, >> ..., >> h4501SupplementaryService SEQUENCE OF H4501SupplementaryService >OPTIONAL >> } >> >> ReRouteIndication ::= SEQUENCE >> { >> display IA5String (SIZE( 0..255) ), >> endpointInfo EndpointType, >> ... >> } >> >> This could then be sent by a gatekeeper when a re-route has been done. >> > >Second: > >Overall, I agree with the mail from Ernst Horvath on this issue: we >should >not add such functionality to H.225.0, not even to version two. > >Joerg >

3 2

H.323V2 draft
by gthom 22 Sep '97

22 Sep '97

All, H323v2i.doc has been uploaded to the gctech ftp site. It is complete except for the text on empty capability sets (TD-27) and Annex C on H.323 over ATM. Let me know if any of your changes have been missed, or have not been incorporated properly. Gary ------------------------------------- Name: Gary Thom Company: Delta Information Systems, Inc. Phone: +1-215-657-5270 x23 Fax : +1-215-657-5273 E-mail: gthom(a)delta-info.com Date: 09/22/97 Time: 08:57:14 -------------------------------------

1 0

Re: TD-27 text for h.323
by Pete Cordell 22 Sep '97

22 Sep '97

Gary, Generally I think your editorial intervention has been good. However, the state reset to when an non-empty capability set is received should be the state that H.245 is in after H.245 is originally established, NOT the state before the pause is invoked. This flushes out any H.245 state so that you have a known state to which to connect to a new endpoint. Some attempt at words is: On reception of a non-empty capability set in this paused state an endpoint shall reset its H.245 state to that which it is in just after the H.245 transport connection is made at call establishment time (i.e. the beginning of phase B). Hope this helps, Pete ================================= Pete Cordell BT Labs E-Mail: pete.cordell(a)bt-sys.bt.co.uk Tel: +44 1473 646436 Fax: +44 1473 645499 ================================= >---------- >From: gthom[SMTP:gthom@DELTA-INFO.COM] >Sent: 19 September 1997 19:47 >To: ITU-SG16(a)mailbag.jf.intel.com >Subject: TD-27 text for h.323 > >Pete and others, > >I took some editorial liberty with the text of TD-27. It is contained >below. I expect >to put this in 6.2.8.1 Capability Exchange. Alternatively, I could put >it into 8.2. >Any suggestions, changes, clarifications??? > >Thanks > Gary > >****************************************** > >"To allow gatekeepers to re-route connections from endpoints that do >not support >supplementary services, endpoints shall support the reception of empty >capability >sets (i.e. Terminal Capability sets that indicate that the endpoint >sending the >message has no receive capabilities). This feature also allows >'network' elements >such as PBXs, call centers, and IVR systems to re-route connections >independent >of supplementary services and facilitates pre-connect announcements. >It can also >be used to delay H.245 media establishment when features such as >Gatekeeper >based user location is being used. It is also highly recommended that >Version 1 >endpoints support this feature. > >On reception of an empty capability set an endpoint shall enter a >paused state. If >media stream or data logical channels were previously opened by the >endpoint, >they should be closed. In this state an endpoint shall accept the >opening of logical >channels from the remote end based on the usual rules and continue to >receive >media from open logical channels from the remote end. This allows >endpoints to >receive announcements (e.g. pre-connect call progress) where the >announcing >entity does not wish to receive media from the endpoint. > >On reception of a non-empty capability set in this paused state an >endpoint shall >reset its H.245 state to that which it was in prior to entering the >paused state. >This allows an endpoint to be connected to a different endpoint when it >is >released from the paused state. Note that the non-empty capability set >shall not >be sent to an endpoint until all its transmit and receive logical >channels have been >closed. A switching entity should also send an H.450 redirection >indication Facility >message if the endpoint is being re-routed. The endpoint shall then >proceed with >normal H.245 connection establishment signalling. When leaving the >paused state >an endpoint shall take part in master/slave determination signalling, >and may >proceed with normal open logical channel signalling procedures. When >an MC >receives a release from the paused state it shall act as if a new >endpoint has >entered the conference. > >Unless its capabilities have changed, an endpoint need not resend a >capability set >as the gatekeeper will have supplied this to remove any paused state in >the >remote endpoint. This option of not sending a capability set enables >faster >reconnection. > >------------------------------------- >Name: Gary Thom >Company: Delta Information Systems, Inc. >Phone: +1-215-657-5270 x23 >Fax : +1-215-657-5273 >E-mail: gthom(a)delta-info.com >Date: 09/19/97 >Time: 11:47:19 >------------------------------------- >

1 0

List of Sunriver meeting participants
by Sakae Okubo 21 Sep '97

21 Sep '97

Dear Q.12-14/16 Sunriver meeting participants, Attached please find the list of participants for the Q.12-14/16 Rapporteur meeting in Sunriver. This has been made according to the sheet left at the meeting site and my recollection. Please advise me if your name is missing or anything is wrong with your entry. It will be included in the meeting report APC-1327. 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 Japan ******************************************************************** Country Company Name E-Mail Germany Siemens Robert robert.callaghan(a)siemenscom.co Callaghan m Germany Siemens Istvan istvan.sebestyen(a)mch.pn.siemen Sebestyen s.de Germany Siemens Karl karl.klaghofer(a)mch.pn.siemens. Klaghofer de Germany Siemens Wolfgang Wofgang.Klasen@mchp. Klasen siemens.de Germany Siemens Markku korpim(a)scn.de Korpi Germany Siemens Martin.Euch martin.euchner(a)mchp.siemens.de ner Germany Teles Joerg Ott jo(a)teles.de Canada Mitel Terry Tam tamt(a)software.mitel.com Canada Mitel Dave Walker dave_walker(a)mitel.com Canada Nortel Nancy ngreenet(a)nortel.ca Greene Canada Nortel Tom Taylor taylor(a)nortel.com Canada Nortel Vahe balabani(a)nortel.ca Balabanian Korea ETRI Dong-Bum dbjung(a)winky.etri.re.kr Jung Korea Korea Sang-Gil sgk(a)ktweb.kotel.co.kr Telecom Kim Korea Korea Jung-Ja Roh jjroh(a)rcunix.kotel.co.kr Telecom USA 8*8 Hardish hardish(a)8x8.com Singh USA Ascend Dale Skran Dale.Skran(a)ascend.com USA AT&T Baldine- baldine(a)reserach.att.com Brunel Paul USA Cisco Greg ggoodkni(a)cisco.com Systems Goodknight USA DataBeam Bill Quinn bquinn(a)databeam.com USA DataBeam Pat Galvin pgalvin(a)DataBeam.com USA Delta Inf. Gary Thom GTHOM(a)DELTA-INFO.COM Systems USA FVC Corey Gates corey(a)fvc.com USA Intel Narjala narjala-bhasker@ Bhaske ccm.jf.intel.com USA Intel Chris Chris_Hansen@ ccm.jf.intel.com Hansen USA Intel Vineet vineet_kuman(a)ccm.jf.intel.com Kumar USA Intel Jim Toga jtoga(a)ibeam.intel.com USA Intel John H. john_h_wilson(a)ccm.jf.intel.com Wilson USA Lucent Andy adfranklin(a)lucent.com Technologies Franklin USA Lucent Glen ggf(a)lucent.com Technologies Freundlich USA Lucent Li Yan lyan(a)lucent.com Technologies USA Lucent Zhongjin zjyang(a)lucent.com Technologies Yang USA Microsoft Toby Nixon tnixon(a)microsoft.com USA PictureTel Kaynam knedayat(a)pictel.com Hedayat USA PictureTel Mark Reid reid(a)pictel.com USA STARVISION Don Piercy dpiercy(a)starvision.com USA VideoServer George gkajos(a)videoserver.com Kajos USA VTEL Michael cpchen(a)vtel.com Chen Finland Nokia Frank Fu frank.fu(a)nmp.nokia,com France Alcatel Bahman Mobasser France France Isabelle haiqnere(a)cnet.francetelecom.fr Telecom/CNET Haiqnere France France Jean-Pierre jean.pierre.blin@ Telecom/CNET Bin cnet.francetelecom.fr France France Christian christian.wipliez@ Telecom/CNET Wipliez cnet.francetelecom.fr Israel Accord Roni Even roni_e(a)accord.co.il Israel RADVision Amotz Shemi amotz(a)radvision.rad.co.il Israel RADvision Orit Levin orit(a)radvision.ard.co.il Israel Vocaltec Scott petrack(a)vocaltec.com Petrack Israel Vocaltec Gur Kimchi gur(a)vocaltec.com Japan Fujitsu Yoshitsugu yn(a)marvel.ts.fujitsu.co.jp Nishizawa Japan GCL Sakae Okubo okubo(a)gctech.co.jp Japan KDD R&D Labs Shigeyuki sakazawa(a)lab.kdd.co.jp Sakazawa Japan KDD R&D Labs Hideaki hd-yamada(a)kdd.co.jp Yamsda Japan NEC Hidenobu harasaki(a)dsp.cl.nec.co.jp Corporation Harasaki Japan NTT Hiroshi koyano(a)nttvdt.hil.ntt.co.jp Koyano Netherl KPN Jeroen de j.h.demuijnck(a)research.kpn.com ands Muijnck Norway Telenor Helge Helge.Sandgrind(a)fou.telnor.no Sandgrind UK BT Labs John J.boucher(a)bt-web.bt.co.uk Boucher UK BT Labs Pete Pete.Cordell(a)bt-sys.bt.uk Cordell UK BT Labs Mike nilsson_m_e(a)BT-WEB.BT.CO.UK Nilsson Sweden Ericsson Anders anders.svennevik(a)ebc.ericsson. Svennevik se Switzer IBM H. Linh hlt(a)zurich.ibm.com land Truong

1 0