- sg16-avd - lists.packetizer.com

AW: On TD26 - Fast TCS and M/S negotiation in H.323v4
by Klaghofer Karl ICN SIB NL D1 07 Jun '00

07 Jun '00

Osaka contributions like APC-1866 suggested to enhance the Fast Start structures by adding elements like userInputCapability to the fast start structure (to allow e.g. negotiation of the user input caps as early as possible together with fast start for subsequent UserInputCapability messages to be sent). This was rejected since the participants felt that start adding pieces of H.245 to Fast Connect might turn out as a never ending story. Instead, the consensus in Osaka was to allow the complete H.245 tunnel itself together with the fast start in SETUP. The backwards compatibility issue is of course important to consider. I agree with the principles what Paul said. I propose to continue the agreed approach from Osaka and further develop it using a new tunnel field in H323-UU-PDU construct (however, I believe it is saver that this new tunnel field should be used not only in SETUP but also in the other H.225.0 messages). Remark: I do not like the term "earlyH245Control" since "early H.245" in H.323 means something total different, as mentioned alrealy by a previous e-mail. Since this is in fact a new tunnel procedure available with v4, it could be named something like "245V4Control. But this are only names.... Regards, Karl > -----Ursprüngliche Nachricht----- > Von: Paul E. Jones [SMTP:paulej@PACKETIZER.COM] > Gesendet am: Wednesday, June 07, 2000 09:59 > An: ITU-SG16(a)mailbag.cps.intel.com > Betreff: Re: On TD26 - Fast TCS and M/S negotiation in H.323v4 > > Jane, > > I suspect that TD-26 has the procedural issues addressed-- it will just be > a > matter of specifying the usage of a different field. > > I'll have to review what is written there, but the most obvious way to > prevent race conditions is to specify that channels may not be opened via > H.245 until Fast Connect is accepted, explicitly refused, or implicitly > refused by not receiving a fastStart element up to and including CONNECT. > > Paul > > ----- Original Message ----- > From: "Jane Hua" <huajane(a)YAHOO.COM> > To: <ITU-SG16(a)mailbag.cps.intel.com> > Sent: Wednesday, June 07, 2000 2:18 AM > Subject: Re: On TD26 - Fast TCS and M/S negotiation in H.323v4 > > > > Pre Script: Sorry for the previous mail > > > > Hi All, > > > > As far as my understanding goes, the purpose of prohibiting both > > fastStart and H.245 tunnel in SETUP was to avoid race conditions in two > > tunnels (fastStart can also be considered as a H.245 tunnel with > > different procedures). Here we are adding a new tunnel which will lead > > to more such race scenarios until proper care is taken in defining the > > procedures. > > > > The decision on this should not be like a voice vote in Congress. The > > procedures should be clearly documented and circulated over the > > reflector and let people argue on those concrete documented steps. > > > > Let us see, can we fix the problem introduced by introduction of > > fastStart? > > > > Regards, > > Jane Hua > > > > > > Paul- > > The problem is that inclusion of an H.245 message in the tunnel > > terminates > > FastStart according to section 8.2.1 of H.323. This could be > > "satisfied" > > by using the early H.245 element for the replys so that FastStart could > > proceed. > > At least this mechanism would make it easy to know that the responder > > (the > > called endpoint) was able to overlap FastStart and H.245. > > -Bob > > ---------------------------------------------------- > > Bob Gilman rrg(a)lucent.com +1 303 538 3868 > > > > > > Paul Long wrote: > > > > > > Bob, > > > > > > H.323 only says that fastStart and h245Control cannot both be included > in > > > _Setup_, so it could indeed be included in the Setup-UUIE type. > > > > > > Paul Long > > > Smith Micro Software, Inc. > > > > > > -----Original Message----- > > > From: Callaghan, Robert [mailto:Robert.Callaghan@ICN.SIEMENS.COM] > > > Sent: Tuesday, June 06, 2000 10:27 AM > > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > > Subject: Re: On TD26 - Fast TCS and M/S negotiation in H.323v4 > > > > > > Paul, > > > > > > It would be required in the SETUP, CALL PROCeeding, ALERT, FACILITY, > and > > > CONNECT message in that all of these messages can be sent before Fast > > > Start > > > is completed or may not be present with Fast Start elements based on > v2. > > > > > > Bob > > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > For help on this mail list, send "HELP ITU-SG16" in a message to > > > listserv(a)mailbag.intel.com > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > For help on this mail list, send "HELP ITU-SG16" in a message to > > listserv(a)mailbag.intel.com > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > For help on this mail list, send "HELP ITU-SG16" in a message to > > listserv(a)mailbag.intel.com > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > For help on this mail list, send "HELP ITU-SG16" in a message to > > listserv(a)mailbag.intel.com > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

APC-1871 Report of the Osaka meeting
by Sakae OKUBO 07 Jun '00

07 Jun '00

Dear Q12-14/16 experts, I have belatedly edited several materials including TD49 (General report), TD-22 (Q13 report) and TD-21 (Q14 report) into a single report as in the ftp site. ftp://standard.pictel.com/avc-site/Incoming/APC-1871.zip or http://standard.pictel.com/ftp/avc-site/Incoming/APC-1871.zip Some obviously editorial corrections have been made to TD texts without indication. Texts with yellow marker were not in original TDs, but generated by myself. Please review it and return your comments, if any, in a week time. Best regards, Sakae OKUBO *********************************************************** Waseda Research Center Telecommunications Advancement Organization of Japan (TAO) 5th Floor, Nishi-Waseda Bldg. 1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan Tel: +81 3 5286 3830 (to be transferred) +81 3 3204 8194 (direct) Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp *********************************************************** ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

RE: On TD26 - Fast TCS and M/S negotiation in H.323v4
by Callaghan, Robert 07 Jun '00

07 Jun '00

Paul, It would be required in the SETUP, CALL PROCeeding, ALERT, FACILITY, and CONNECT message in that all of these messages can be sent before Fast Start is completed or may not be present with Fast Start elements based on v2. Bob -----Original Message----- From: Paul E. Jones [mailto:paulej@PACKETIZER.COM] Sent: Saturday, June 03, 2000 6:41 AM To: ITU-SG16(a)mailbag.cps.intel.com Subject: Re: On TD26 - Fast TCS and M/S negotiation in H.323v4 Paul, Francois, and others, If we were able to get consensus here, I believe we could add a field to the SETUP-UUIE. I'd rather not put it in the H323-UU-PDU, since it is intended for SETUP only as a means of allowing H.245 to used with fastConnect in a backward compatible manner. We have an entire proposal on verbiage to be added to H.323. I'll have to review that to see what needs changing-- but there's actually a lot of description. Can we agree to introduce a new "earlyH245" field to go along with "fastStart" in the SETUP? Paul ----- Original Message ----- From: "Paul Long" <Plong(a)SMITHMICRO.COM> To: <ITU-SG16(a)mailbag.cps.intel.com> Sent: Friday, June 02, 2000 10:11 PM Subject: Re: On TD26 - Fast TCS and M/S negotiation in H.323v4 > Paul, > > While not ideal (nothing is), that's a safe, workable solution. I like it. > Are you proposing adding the new component to the H323-UU-PDU or the > Setup-UUIE type? Both locations have their merits. This then should be the > new text for section 8.2.1/H.323: "The calling endpoint shall not include > both a fastStart element and encapsulated H.245 messages in h245Control in > the same Setup message. However, the calling endpoint may include both a > fastStart element and encapsulated H.245 messages in earlyH245Control in the > same Setup message." And then explain what the called endpoint is supposed > to do when fastStart and earlyH245Control are present. While we're at it, > maybe we should define a separate type, i.e., > > H245Control ::= SEQUENCE OF OCTET STRING OPTIONAL > -- each octet string may contain exactly > -- one H.245 PDU > > But now how do the two components, h245Control and earlyH245Control > otherwise relate to each other, i.e., when fastStart is not included? Should > we say that if one is present the other shall not be present? That would be > the clearest, IMO. Not much is gained by allowing both. > > > Remember, the first rule of standards revision is (everybody repeat after > me)... > "Primum non nocere" ("First do no harm.") > - the Roman physician, Galen > > Paul Long > Smith Micro Software, Inc. > > -----Original Message----- > From: Paul E. Jones [mailto:paulej@PACKETIZER.COM] > Sent: Friday, June 02, 2000 8:14 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: On TD26 - Fast TCS and M/S negotiation in H.323v4 > > > Francois, > > I agree that the behavior is desirable, but I still argue that it will > break backward compatibility. If we can agree with a new field > "earlyH245" as a special field for SETUP to do essentially the same > thing, but only for V4, I would be quite happy-- we get the same end > result without V3 and V2 compatibility issues. > > I do not want to wait until Portland. The Whitepaper drafts are due > before then and I hope that that meeting will be focused on only > critical issues in H.323 and that most of our time will be spent on > further development of Annexes and perhaps forward thinking on V5 :-) > > Paul > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

6 9

Question on H.225- Annex G
by Archana Nehru 07 Jun '00

07 Jun '00

hi all, I have a question about prefixing TPKT header to Annex-G messages sent over UDP. Refer to section 1.8 of the Annex G specs which states: " In UDP IP implementations, messages shall also be prefixed with TPKT headers, to enable multiple messages per packet. The UDP packet length field shall hold the total length of the payload, including all the messages and their TPKT headers." My interpretation of the above paragraph is the following: 1. ALL Annex-G messages (going over UDP) MUST be prefixed with TPKT headers. 2. One UDP packet can contain multiple Annex-G messages and each one of these messages will have its OWN SEPARATE TPKT HEADER. Is this interpretation correct? I appreciate any help on this. Regards Archana ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1

[H.323 Mobility:] Annex H and I and H.246 Annex E
by Korpi Markku ICN SIB NL D1 07 Jun '00

07 Jun '00

Dear Mobility Subgroup members & interested parties, in order to get the H.323 Mobility ready for determination in November, we need to use the available time for steady progress of the work. Since everything is driven by contributions (not alone by the editor and the chair), I would encourage the mobility subgroup participants to produce contributions, so that we can discuss them over the reflector. As soon as we have enough stuff on the agenda we can organize a telephone conference, too, if there are issues, to be discussed. But I agree with Jaakko's and other peoples' earlier suggestions, that the main work should be done over the reflector. It also helps to increase transparency of our review process. As agreed in Osaka, please write your contributions against the current drafts of Annex H, I and H.246 Annex E. This way you can help us to fill in the gaps we still have in the current drafts. In order to get an MD number for your contribution, please send an email to jaakko.sundquist(a)nokia.com with subject and author of the document. Enjoy working on H.323 Mobility! Markku Korpi, Chair of H.323 Mobility Ad Hoc group -----Original Message----- From: Roy, Radhika R, ALARC [mailto:rrroy@ATT.COM] Sent: Tuesday, June 06, 2000 5:33 AM To: ITU-SG16(a)mailbag.cps.intel.com Subject: H.323 Mobility: Annex H and I and H.246 Annex E Dear Mr. Korpi: I guess that it is the time to hear publicly from you how you want to organize the conference calls and contributions related to above annexes. It is excellent that Mr. Sundquist has produced a draft for H.323 Annex H that has been set as a baseline for discussions and bringing contributions. However, we like to know more about your plan the way you want to proceed: Conference calls, Contributions, Coordination among Annexes, etc. Best regards, Radhika R. Roy H.323 Mobility Ad Hoc group +1 732 420 1580 > -----Original Message----- > From: Jaakko Sundquist [SMTP:jaakko.sundquist@nokia.com] > Sent: Tuesday, June 06, 2000 7:01 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: [H.323 Mobility:] New H.323 Annex H Draft > > Hi folks, > > I have uploaded a new draft of the H.323 Annex H to the following URL: > ftp://standard.pictel.com/avc-site/Incoming/Mobility-AHG/Md-101_H323AnnexH > Dr > aft.zip . > > This draft contains material from the TD-28 of the Osaka meeting in > addition > to the TD-47, which contained the H.323 Annex H Draft produced in the > Osaka > meeting. I suggest that we use this document as the baseline for the work > from now on. > > I will not be very active on this reflector this week, because of other > urgent chores at work, but I will try to produce some new ideas next week > and also encourage you to make contributions as soon as possible. > > ------------------------------------------------ > Jaakko Sundquist * > +358 50 3598281 * Audere est Facere! > jaakko.sundquist(a)nokia.com * > ------------------------------------------------ > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Editorial comments to H.225.0
by Espen Skjæran (ETO) 06 Jun '00

06 Jun '00

Rich, I have noticed that some of the meanings/descriptions has changed merely as the new ASN.1 structures for the ServiceControl has been extended to what was in the original proposal. Unfortunately, there was no time to discuss this in Osaka. As the editor, I hope you would consider making some minor changes before issuing the white paper. I've added a document with change marks which suggests improvements for these. I believe these changes are purely editorial. - The ASN.1 structure, ServiceControlSession, should have change marks for possible extensions. It's my fault, I omitted these in the original proposal. - The definition of the ServiceControlSession structure is placed in the SCI message defintion. It should be placed in the common section. - The examples in the definition for serviceControl in ARJ and ACF are copied directly from other messages, but are not relevant for the call state/model. - How is the structure sent without a URL, for "close"? With a 0-length URL? I propose a separate "null" tag. - The name "ServiceControlAddress" is no longer covering as it also now holds actual content for service control. I propose it should be replaced "ServiceControlResource" or just "ServiceControl" or something? - The textual description of the ServiceControlSession and all messages must be modified to also contain "in-band" content Another, not-so-editorial issue is the addition of the "result" tag in SCR from the 248 packages that was added in Geneva. As the SCI may contain several ServiceControlSession structures, I don't think it is clear what they apply to. The SCR message was originally added just to compensate for packet loss, as an application-level acknowledgement is something very different (and in the case of HTTP and multi-format content, can't really be known until the end.) <<h225changes.zip>> Regards, Espen

2 1

Re: On TD26 - Fast TCS and M/S negotiation in H.323v4
by Francois Audet 06 Jun '00

06 Jun '00

> Francois, > > Woohoo!!!! :-) > > Actually, I suppose earlyH245Control could contain multiple > H.245 messages, > since it will presumably be defined the same as h245Control: Yes, I had meant to make a comment about this yesterday, but I had already disconnect from dial-up. > Given: > H245Control ::= SEQUENCE OF OCTET STRING OPTIONAL > > therefore: > h245Control H245Control, > and: > earlyh245Control H245Control, Looks good to me.

3 4

RE: On TD26 - Fast TCS and M/S negotiation in H.323v4
by Callaghan, Robert 06 Jun '00

06 Jun '00

Paul, I was afraid that this might happen. The changes under discussion were agreed to in Osaka, with the participants understanding the risks. To not include it in v4 would be a substantive change from the agreed content which I challenge as being beyond the discression of the editor to make editorial changes. There is a real problem in that keypad information must be sent before the connect message. This is needed to support network services in the U.S. Because the H.245 rules require the exchange of TSC and master-slave before any other messages may be sent, there is a significate delay after fast connect before keypad digits may be sent. In Osaka, several proposal were submitted to solve this and other needed negotiation problems. The agreed solution was the proposal for which you have reservations. This is needed in the real world. PLEASE! find a solutions that will not remove these changes! Bob -----Original Message----- From: Paul E. Jones [mailto:paulej@PACKETIZER.COM] Sent: Wednesday, May 31, 2000 11:14 PM To: ITU-SG16(a)mailbag.cps.intel.com Subject: Re: On TD26 - Fast TCS and M/S negotiation in H.323v4 Paul, We agreed at the Osaka meeting to allow a SETUP to contain both the fastStart and h245Control, but it has not been officially approved by the ITU. As it stands right now, I don't think I can agree to include it in H.323v4 on the grounds that it breaks backward compatibility with V2-- I just don't see a clean solution here. I'm opening to hearing more suggestions, but as you pointed out, there are two issues: 1) H.323v2 states explicitly that it is illegal 2) There is no way to know what version to destination EP is before sending this illegal message Paul ----- Original Message ----- From: "Paul Long" <Plong(a)SMITHMICRO.COM> To: <ITU-SG16(a)mailbag.cps.intel.com> Sent: Wednesday, May 31, 2000 10:34 AM Subject: Re: On TD26 - Fast TCS and M/S negotiation in H.323v4 > Pete, > > Table 13/H.225.0v3 shows that the User-to-User IE is mandatory. What IEs do > you believe are not mandatory? > > H.323 states that the fastStart and h245Control components cannot both be > present in the Setup message (do I need to quote it again?). A Setup > User-to-User IE containing either or neither component is valid; one > containing both is clearly invalid. Why do you think otherwise? > > H.323, by way of Q.931, requires that the called EP respond with > ReleaseComplete with cause 100. There is no other appropriate cause. > > The feature that should be deprecated is the inclusion of both fastStart and > h245Control in Setup. I was under the impression that either through IGv3 or > H.323v4 this had already made it into the standard. If its not too late, we > should simply remove this feature from any proposed text; if it is too late, > we should deprecate it because it causes insurmountable backward > compatibility problems. > > Paul > > -----Original Message----- > From: Pete Cordell [mailto:pete@TECH-KNOW-WARE.COM] > Sent: Wednesday, May 31, 2000 4:31 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: On TD26 - Fast TCS and M/S negotiation in H.323v4 > > > Paul, > > I don't really believe that the release cause you cite is valid. The > IEs > are not mandatory, and (taken by themselves) they don't have invalid > content. I don't believe it is the intent of this cause code to signal > the > sort of thing that we are talking about here either. > > Are there any other causes and clauses that you think might be more > appropriate? > > Also, when you say "the feature" should be deprecated, what are you > referring to as "the feature"? I'm not quite clear. > > Pete. > > ============================================= > Pete Cordell > pete(a)tech-know-ware.com > ============================================= > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

4 3

Re: On TD26 - Fast TCS and M/S negotiation in H.323v4
by Callaghan, Robert 06 Jun '00

06 Jun '00

Robert, A number of Service Providers, such as AT&T, have a service associated with their 800 service that allows for secondary call routing information. As an example, a person calls a company's 800 service number. AT&T will prompt the caller via an IVR for the particular product requiring service. After prompting, the call is extended to the correct ACD center. Signaling wise, the IVR function comes after CALL PROCeeding and is indicated by a PROGRESS message. When the call is answered by the ACD center, CONNECT is sent. I hope that this helps. Bob -----Original Message----- From: Opiela, Robert [mailto:Robert.Opiela@Aspect.com] Sent: Tuesday, June 06, 2000 12:02 PM To: 'Robert.Callaghan(a)ICN.SIEMENS.COM' Subject: RE: On TD26 - Fast TCS and M/S negotiation in H.323v4 > There is a real problem in that keypad information must be > sent before the > connect message. This is needed to support network services > in the U.S. > Because the H.245 rules require the exchange of TSC and > master-slave before > any other messages may be sent, there is a significate delay > after fast > connect before keypad digits may be sent. In Osaka, several > proposal were > submitted to solve this and other needed negotiation > problems. The agreed > solution was the proposal for which you have reservations. > This is needed > in the real world. > > PLEASE! find a solutions that will not remove these changes! Just out of curiosity, could you explain why the keypad information needs to be sent before the Connect? Why can't this information be sent as an alias in the Setup? Rob -------------------------------------------- Robert Opiela Aspect Communications robert.opiela(a)aspect.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: On TD26 - Fast TCS and M/S negotiation in H.323v4
by Callaghan, Robert 06 Jun '00

06 Jun '00

Pete, Please NO packages! Bob -----Original Message----- From: Pete Cordell [mailto:pete@TECH-KNOW-WARE.COM] Sent: Monday, June 05, 2000 2:54 PM To: ITU-SG16(a)mailbag.cps.intel.com Subject: Re: On TD26 - Fast TCS and M/S negotiation in H.323v4 Well if you want to kick the final bit of life out of H.323 then add another field to H.323 that does much the same as something that's already in there. Heck, we'll probably have to do something similar with a few other features as well, so this change would hardly be noticed. The issue is a bit like the ozone layer and CFCs. A squirt of deodorant in the morning surely didn't make much difference to the ozone layer. But the fact was that it all added up. Fortuneately policy has come in to attempt to address the ozone layer problem, and hopefully we can avoid having to go around covered from head to toe in future. We face much the same issue with H.225, but we already have to wear factor 50 sun cream all the time!!! On the other hand, defining this addition using the packages field would stop this beating a dead horse approach. I've attached a doc that shows what is involved. Note that most of the procedure elements would have to be included with what ever approach is taken and they do not represent a burden of implementing this using packages. Pete. ============================================= Pete Cordell pete(a)tech-know-ware.com ============================================= ----- Original Message ----- From: Francois Audet To: ITU-SG16(a)MAILBAG.INTEL.COM Sent: 05 June 2000 16:39 Subject: Re: On TD26 - Fast TCS and M/S negotiation in H.323v4 > Francois, > > Woohoo!!!! :-) > > Actually, I suppose earlyH245Control could contain multiple > H.245 messages, > since it will presumably be defined the same as h245Control: Yes, I had meant to make a comment about this yesterday, but I had already disconnect from dial-up. > Given: > H245Control ::= SEQUENCE OF OCTET STRING OPTIONAL > > therefore: > h245Control H245Control, > and: > earlyh245Control H245Control, Looks good to me. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1