- sg16-avd - lists.packetizer.com

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

H.323 Mobility: Annex H and I and H.246 Annex E
by Roy, Radhika R, ALARC 06 Jun '00

06 Jun '00

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

1 0

[H.323 Mobility:] New H.323 Annex H Draft
by Jaakko Sundquist 06 Jun '00

06 Jun '00

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_H323AnnexHDr 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

1 0

AW: H.450-3
by Klaghofer Karl ICN SIB NL D1 06 Jun '00

06 Jun '00

Wolfgang, The Remote Activation procedures (activateDiversionQ.inv) were intended to be used for remote activation. For local activation of diversion at the endpoint, activation is of local significance only and is thus out of the scope of the recommendation. However, the Remote Activation procedures may be used for activation of diversion from a activating/served endpoint at its lokal GK. This has been introduced in the late phase of H.450.3 standardization within clause 9.2.2. >From the signalling point of view it is a regular H.450 non call related SETUP including the activateDiversionQ.inv that is sent from the activating/served EP to the GK. Regards, Karl Klaghofer > -----Ursprüngliche Nachricht----- > Von: Wolfgang Bandow [SMTP:wolfgang.bandow@DETEWE.DE] > Gesendet am: Monday, June 05, 2000 15:24 > An: ITU-SG16(a)mailbag.cps.intel.com > Betreff: H.450-3 > > Hello H.450-Experts! > > I've got a question concerning the activation of call forwarding in > cases when the served endpoint > shall be represented by a gatekeeper. > > The standard distinguishes between the activating and the served > endpoint but does not give sufficient > information for the case that activating and served endpoint are both > the same. > Is there any message flow when activating call forwarding by the served > user (locally)? > Is the corresponding gatekeeper somehow informed about this activation? > > Thanks a lot for your reply. > > Regards, > Wolfgang Bandow CT-B / Berlin > << Datei: Visitenkarte f|r Wolfgang Bandow >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: White paper deadline
by Sakae OKUBO 06 Jun '00

06 Jun '00

Dear Mike, >Could you please tell me when the white paper deadline is for SG16 >decision documents for the November meeting. The report of SG16 meeting last February is available as COM16-R61 at http://www.itu.int/itudoc/itu-t/com16/reports and its Section 3.8.2 (determined draft Recs) states as follows: The final edited texts of these draft revised and new Recommendations should be provided by the editor/rapporteurs as a normal contribution to reach TSB prior 15 July 2000 for consideration at the November meeting of SG 16. It should be noted that the planned meeting of WP1/16 at the end of June 2000 will very likely determine other Recommendations, in accordance with their work programme. 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

Your Big Chance #78A6
by Sonny Herkoe 05 Jun '00

05 Jun '00

Do you play the lottery? We can't guarantee you will win, but with today's technology and the internet we can drastically improve your odds. Did you know 1/3 of all lotterys are won by groups or clubs!! If you are already a player or would like to start playing within a club please reply to: mailto:bb209b@yahoo.com?subject=more_info with the following "info" Name: _________________________________________ Email Address: __________________________________ Address __________________________________________ City ________________________ ST _____ ZIP __________ Phone (_______) __________________________ Best time to call The above information is required to receive the requested information. ***************************************************************** This message is sent in compliance of the new email bill section 301. Per Section 301, Paragraph (a)(2)(C) of S. 1618, further transmissions to you by the sender of this email may be stopped at no cost to you. This message is not intended for residents in the State of WA, CA & VA Screening of addresses has been done to the best of our technical ability.If you are a Washington, Virginia, or California resident please remove yourself. ========================================= If you wish to be removed from future mailings, please Reply to: mailto:drisck@netscape.net?subject=remove ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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 Francois Audet 05 Jun '00

05 Jun '00

I fully agree with Orit. So far, I haven't heard of anybody that actually implemented clearing the call if both fastStart and h245Control are present in SETUP. I would argue, it would be a very bad implementation, regardless of what they interpreted the spec saying. This being said, it seems that it will not create any interoperability problems. The *worst* case scenario (here again, I haven't heard of anybody that actually implemented it that way) is that the call would proceed as fast tunnelling (as per the spec) and ignore the fast start. The benefits of doing the fastStart and the fast tunnelling at the same time far outweight the theoretical backward compatibility problems. If anybody wants to revoke the Osaka agreement, contributions in Portland are welcomed. ;^) > -----Original Message----- > From: Orit Levin [mailto:orit@RADVISION.COM] > Sent: Wednesday, May 31, 2000 8:32 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: On TD26 - Fast TCS and M/S negotiation in H.323v4 > > > Hi Paul and all the others! > Here it is (and it is not surprising for those, participated in Osaka > meeting). > I believe, that it is the last moment to clear the confusion > in the least > harmful way (even on the expense of THEORETICAL H.323v.2 "strict" > implementations). > RADVision definitely votes for allowing Fast Connect and > H.245 tunneling in > Setup, supporting by that TD-26. > Best Regards, > Orit Levin > RADVision Inc. > 575 Corporate Drive Suite 420 > Mahwah, NJ 07430 > Tel: 1 201 529 4300 (230) > Fax: 1 201 529 3516 > www.radvision.com > orit(a)radvision.com > -----Original Message----- > From: Paul E. Jones <paulej(a)PACKETIZER.COM> > To: ITU-SG16(a)MAILBAG.INTEL.COM <ITU-SG16(a)MAILBAG.INTEL.COM> > Date: Wednesday, May 31, 2000 1:46 AM > Subject: Re: On TD26 - Fast TCS and M/S negotiation in H.323v4 > > > >Pete, > > > >If we could follow such logic, I would agree that this > procedure would be > >worth perusing. Unfortunately, the inclusion of fastStart > and tunneled > >H.245 messages in the SETUP message is not defined. There > is no way to > >predict how a V2 device will behave when receiving these > messages. I like > >the idea, but I'm afraid we will compromise backward compatibility by > >including it. > > > >Let's assume a V2 device does *not* recognize the tunneled > H.245 in SETUP > >(ignores it), but accepts the Fast Connect proposal. > Assume, also, that in > >the CONNECT message, the endpoint includes the fastStart > element *and* a > >tunneled TCS message. What could the calling endpoint > *safely* assume? > > > >Assume that CONNECT was the first message received following > the SETUP if > >that helps complicate matters further for you. :-) > > > >I just need further convincing. > > > >Paul > > > >----- Original Message ----- > >From: "Pete Cordell" <pete(a)TECH-KNOW-WARE.COM> > >To: <ITU-SG16(a)mailbag.cps.intel.com> > >Sent: Tuesday, May 30, 2000 2:40 PM > >Subject: Re: On TD26 - Fast TCS and M/S negotiation in H.323v4 > > > > > >> RE: On TD26 - Fast TCS and M/S negotiation in H.323v4Hi > Paul, Francois, > >and > >> others, > >> > >> I think it is important that we make it work, but as you > say, it has to > be > >> reliable and any burden of insuring backwards > compatibility has to be > >placed > >> on the newer EP. In this case it is primarily an issue > for the calling > >EP. > >> > >> As I see it, (and I'm sure you'll correct me if I'm not > seeing it right!) > >> when there is H.245 in the SETUP message, then the called > endpoint can > >> either ignore the H.245, or accept it. (It could clear > the call, but > I'll > >> ignore that one for the time being.) There is also the > case where it > >> decides that the H.245 takes precedence over fast start. > >> > >> Knowing whether fast start has been accepted is fairly > straight forward. > >> > >> I think the called endpoint has a very good idea of what > decision was > >taken > >> with regard to the H.245 based on the reply from the > called endpoint. > >> > >> - If the reply message in which the fast start information > is contained > >> contains H.245, then it can assume that the called EP > accepted the H.245. > >> The H.245 state about which channels are open will be > updated according > to > >> the fast start parameters. > >> > >> - If the reply message in which the fast start information > is contained > >> contains no H.245, then it has probably ignored the H.245. > >> > >> --- If H.245 tunneling is enabled, but the calling > endpoint believes that > >> the called endpoint ignored its H.245 in the SETUP > message, then it can > >> re-transmit its capability set when it becomes OK to do so > under the > >normal > >> fast start/H.245 rules. (It should probably modify the > sequence number > >> before doing this.) > >> > >> --- In the case where the called EP actually did accept > the H.245 but did > >> not reply as expected, the called EP will receive a second > capability > set. > >> However, endpoints should be able to handle this as this > is a standard > >H.245 > >> procedure. > >> > >> So as long as V4 endpoints use this kind of logic then I > think it is safe > >> for them to combine both H.245 and fast start. > >> > >> Perhaps we should document the above more formally for V4, > and maybe say > >> that if a V4 EP wants to accept both fast start and H.245 > Cap tunnelling > >at > >> the same time then it SHALL put the fast start and H.245 > in the same > >> message. > >> > >> Does this sound in any way reasonable? > >> > >> Pete. > >> > >> ============================================= > >> Pete Cordell > >> pete(a)tech-know-ware.com > >> ============================================= > >> > >> ----- Original Message ----- > >> From: Paul E. Jones > >> To: Francois Audet ; Mailing list for parties associated > with ITU-T Study > >> Group 16 ; pete > >> Cc: Alexander (Sasha) Ruditsky ; Dale Skran > >> Sent: 30 May 2000 08:20 > >> Subject: Re: On TD26 - Fast TCS and M/S negotiation in H.323v4 > >> > >> > >> Francois, > >> > >> But the possibility exists that a V2 device may accept > both, reject one > or > >> the other, or reject both since a SETUP containing > fastStart and tunneled > >> H.245 is "illegal". Heck, a "strict" endpoint may even > drop the call, > but > >I > >> suspect that nobody would go that far. > >> > >> If fastStart was accepted and the remote end returns the > tunneling flag > >set > >> to TRUE, how do you know if it did or did not process the > H.245 message > in > >> the SETUP? I'm not convinced that this procedure is going to make > >everybody > >> happy. (Same could be said if fastStart is not accepted, > I suppose.) > >> > >> My concern is that this issue is potentially damaging to some > >> implementations. If all of the vendors have no problem > with this change, > >> then I can live with it. Cisco has no objection, but I > would like to > >> solicit the input of others-- changes like this, even as > good as they > are, > >> could cause serious problems. > >> > >> It appears that we've already made a similar "mistake" by > allowing H.245 > >> procedures to be done in parallel to fastConnect by > removing the clause > >that > >> says that if we start H.245, fast connect is terminated. > That text was > >> removed, because there was a race condition that could > occur, which could > >> result in interoperability problems. The right solution > probably should > >> have been to document the race condition and tell people > "don't do that". > >> However, we made the change and now some manufacturers have serious > >backward > >> compatibility problems. I don't want to make the same > mistake again. > >> > >> Comments? > >> > >> Paul > >> > >> ----- Original Message ----- > >> From: Francois Audet > >> To: 'Paul E. Jones' ; Mailing list for parties associated > with ITU-T > Study > >> Group 16 ; pete > >> Cc: Alexander (Sasha) Ruditsky ; Dale Skran > >> Sent: Monday, May 29, 2000 11:00 PM > >> Subject: RE: On TD26 - Fast TCS and M/S negotiation in H.323v4 > >> > >> > >> Yes, a few comments: > >> 1 It seems that all current implementations that we could think of > >> would simply ignore the tunnelling information if the fastStart > >> element is present. This means, that there would be no > >> interoperability problems. Fast start would be > sucessfull, but not > >> tunnelling, which would mean that tunnelling would have to happen > >> after the SETUP message, as per H.323v2 and v3. > >> 2 There is a small possibility that an implementation > would acutally > >> give priority to the tunnelling information instead of > the fastStart > >> element (v2 and v3 don't say what would happen if they > are present, > they > >> just say not to do it). In that particular case, the > fastStart would > >fail > >> but the tunnelling would be successful. So the worst > case scenario is > >that > >> fastStart fails, but "fast tunnelling" is successful. > This doesn't seem > >to > >> me to be a real interoperability problem. In any case, > it seems that > >case > >> 1 is much more likely. > >> > >> > >> > -----Original Message----- > >> > From: Paul E. Jones [mailto:paulej@packetizer.com] > >> > Sent: Monday, May 29, 2000 7:46 PM > >> > To: Mailing list for parties associated with ITU-T Study > >> > Group 16; pete > >> > Cc: Audet, Francois [SC9:4K02:EXCH]; Alexander (Sasha) > Ruditsky; Dale > >> > Skran > >> > Subject: Re: On TD26 - Fast TCS and M/S negotiation in H.323v4 > >> > > >> > > >> > Pete, Sasha, Francois, Dale, et al, > >> > > >> > I have concerns about this document that differ from Pete's. > >> > However, since > >> > discussion on this document has started, I thought I might as > >> > well express > >> > my concerns now while the material is fresh on people's minds. > >> > > >> > The issue has to do with the very first sentence of the > >> > proposal, which says > >> > to strike "shall not" and replace it with "may". So, V2 > >> > devices shall not > >> > send a fastStart element and an H.245 message in SETUP, but > >> > V4 may. This > >> > seems to be a serious backward compatibility issue. If a V2 > >> > device were to > >> > receive a SETUP containing fastStart and an encapsulated > >> > H.245 message, what > >> > would it do? I believe the behavior is not defined. > >> > > >> > Would somebody like to comment? > >> > > >> > Paul > >> > > >> ... cut ... > >> > >> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > >> 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 >

5 8

H.450-3
by Wolfgang Bandow 05 Jun '00

05 Jun '00

Hello H.450-Experts! I've got a question concerning the activation of call forwarding in cases when the served endpoint shall be represented by a gatekeeper. The standard distinguishes between the activating and the served endpoint but does not give sufficient information for the case that activating and served endpoint are both the same. Is there any message flow when activating call forwarding by the served user (locally)? Is the corresponding gatekeeper somehow informed about this activation? Thanks a lot for your reply. Regards, Wolfgang Bandow CT-B / Berlin

1 0

ASN.1 Changes in H.225.0v3
by Paul E. Jones 05 Jun '00

05 Jun '00

Folks, While talking with people recently about some features in H.323 version 3, I discovered that a couple of fields in H.225.0v3 contained an error. Specifically: o "useAnnexECallSignalling" in RCF was supposed to be OPTIONAL o "useAnnexECallSignalling" in ACF was supposed to be OPTIONAL o "supportsAnnexECallSignalling" in LCF was supposed to be OPTIONAL The field descriptions in the H.225.0 document correctly describe the fields as if they were OPTIONAL, which followed the agreed text from TD-23 in the Monterey meeting. In order to correct these errors, I brought a contribution to the Osaka meeting proposing to make these three fields OPTIONAL by making a correction to the Implementers Guide. Participants at the meeting were in agreement to make these corrections, especially since H.225.0v3 has not been published yet. However, since a change such as this will break backward compatibility anyway, the attendees decided to go beyond simply making these 3 small editorial corrections. Instead, a proposal was made to replace these fields with new fields that have an expanded scope. It will now be possible to provide "AlternateTransportAddresses" for various transports: Annex E, SCTP, or something else (currently, only Annex E is defined). In addition, the Gatekeeper, knowing what is supported, may specify which transport an endpoint shall use. I did not object to this proposed change because it looks reasonable and, given that H.225.0v3 is so new, I did not expect it to have a serious impact. However, I have been made aware that a few vendors have or are in the process of implementing H.323v3. This means that we must solidify this ASN.1 change. The participants in Osaka agreed to the proposed changes (attached as a Word document). I believe they are reasonable, but we cannot wait until November, which is when the official vote will be made by the various world governments, to approve those fields: by that time, H.225.0v3 will be published and will have been in a Decided state for 14 months! So, I want to hear people's comments: are all of the vendors comfortable with these changes? I do not believe that any vendor would be put in an uncomfortable position today, so I want to get agreement that we will accept these ASN.1 changes now. I do not want to see a contribution in the November meeting proposing to change these structures in any way-- hopefully what we agreed to in Osaka is acceptable to everybody and we will have no objections. If there are objections, I want to hear them now. It will be too late in November, based on what I have been hearing from various companies. Please give your comments to me and/or post them publicly here. Best Regards, Paul E. Jones Editor, H.323 and the H.323 Implementers Guide

3 3

Conference: Implementing H.323
by Paul E. Jones 04 Jun '00

04 Jun '00

Folks, This may be old news to some, but I know that many people have not heard that Upper Side will be hosting a conference called "Implementing H.323" in Paris October 10-13, 2000. If you would like to attend as a speaker, they are now accepting proposals (a list of suggested topics are in their web page). The deadline for proposals is June 15, 2000. Here's the official web site: http://www.upperside.fr/bah323.htm Best Regards, Paul ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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 Francois Audet 04 Jun '00

04 Jun '00

Guys, I was travelling, so I couldn't respond to this thread earlier. I think I like this idea of the earlyH245Control containing the first H.245 message (i.e., a TCS), in the SETUP message, instead of the h245Control. You have my blessings. ;^)

3 2

H.323v4 and the Implementers Guide
by Paul E. Jones 04 Jun '00

04 Jun '00

Folks, I know that a number of you are eagerly awaiting for the H.323v4 and IG draft documents. Unfortunately, I was traveling for a week and then busy with a project at work, so I have had little time to get those documents updated. However, I will be devoting more time to those documents this week, so hopefully I can get them out for review early next week. I apologize for the delay. Best Regards, Paul ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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 Francois Audet 04 Jun '00

04 Jun '00

> 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. It doesn't "break" anything. The call will still proceed. > 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 There are a lot of things that changed from v2 to v4. That's the role of versions. > 2) There is no way to know what version to destination EP is before > sending this illegal message That would apply to any single change that we do on H.225.0 and H.245.

5 6

Re: H.248 change document
by Sakae OKUBO 04 Jun '00

04 Jun '00

Dear Mr. Fortinsky, >You have a small "copy and paste" error in your message about the H.248 >document. You specify both documents (the one with change marks and the >clean one) as having the same name: H248-for-decision-wcm.zip > >The clean document should be called H248-for-decision-ncm.zip Thank you for your advice. The list now reads: H248-for-decision-changes-wsynt.zip H248-for-decision-wcm.zip H248-for-decision-ncm.zip Using this opportunity, let me correct the list of TDs for debriefing the Osaka meeting: TD-59a General ==> TD-49a TD-22c Q13 TD-21b Q14 The final list of participants is in TD-00. I am now belatedly integrating these and other materials into APC-1871. 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

H.450.9 draft white updated
by Klaghofer Karl ICN SIB NL D1 04 Jun '00

04 Jun '00

I have uploaded the updated draft White document for H.450.9 (i.e. an updated version of TD-55 Osaka) to the pictel incoming directory for your review. ftp://standard.pictel.com/avc-site/Incoming/h4509WhiteDraft.zip Compared to TD-55, I have made minor modifications related to H.323 references as requested by meeting participants in the sections Summary 9.2.8, and 9.3.8. Please note that I will send the document to Mr. Bigi already on June 15 for translation (as agreed in Osaka). So, if you have any comments please provide them to me during the next two weeks. Regards, Karl Klaghofer Siemens > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1

H.248 change document
by Glen Freundlich 04 Jun '00

04 Jun '00

Greetings, I have placed 3 files in the Incoming directory of the pictel ftp site: H248-for-decision-changes-wsynt.zip - The change document showing the specific modifications to the determined H.248 as finalized at the Osaka meeting. H248-for-decision-wcm.zip - The entire H.248 document with changes to the determined document highlighted. H248-for-decision-wcm.zip - H.248 with all changes accepted (the clean document). Regards, Glen -- 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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1

Get One #5143
by Dory Steiner 03 Jun '00

03 Jun '00

FREE E-COMMERCE WHEN YOU HOST WITH US!! Tired of expensive e-commerce software, set up fees and leasing contracts? Here is the deal: Sign up for our E-Commerce Package and get a free merchant account + a $200 cash coupon. WE MEAN IT! THIS IS A REAL CASH COUPON! YOU PAY IN FACT $200 DOLLARS LESS DURING THIS SPECIAL PROMOTION. THIS OFFER IS ONLY GOOD FOR 7 DAYS. DON'T MISS THIS OPORTUNITY. NOBODY BEATS OUR PRICE! While others charge you hundreds of dollars to get a merchant account or put you on a 48 months non-cancelable lease agreement we charge you NOTHING for your merchant account when you sign up for one of our e -commerce hosting plans. If you wish to stay with your current hosting company or have already a merchant account our offer is even better. We have 7 different E-Commerce plans to suit your individual needs. We have a solution for U.S. beased merchants and international merchants. Wherever you are on this planet, we get your online store up and running within a few days. Check it out first and make an informed decision. You have never seen a package deal like this before: * Your own merchant account with one of the lowest rates in the industry * Real-Time software to accept VISA, MASTERCARD, AMEX, DISCOVER/NOVUS , DINERSCLUB/CARTE BLANCHE, JCB * Direct deposit within 48 hrs into your checking account * Shopping Cart store front software with an easy to use web based interface * Real-Time Credit Card Processing software * Virtual terminal for phone/fax/mail orders * Automated E-mail receipts to your clients * Recurring billing feature with batch uploads * Automatic batch closing * Address verification system (AVS) * Back office to 24/7 access account history * 75 MB (megabytes) of disk space * 30 GB (gigabyte) of data transfer per month * 25 POP3 E-mail accounts * Unlimited alias E-mail addresses * Live web site statistics * Unlimited FTP uploads * Anonymous FTP * CGI directory for your own scripts * Site control panel * Installation included * Tech support included All this and more when you sign up for our E-Commerce Hosting plan for ONLY $69.95 per month and a one time set up fee of $199.00. That 's right. NO ADDITIONAL SET UP FEES or application fees for your merchant account, real-time software or shopping cart storefront. A one-stop E-Commerce solution. And the best is: NO LEASING, NO LONG TERM COMMITMENT. YOU CAN CANCEL ANYTIME. In addition you get a FREE listing in our mall and FREE advertising to promote your store. We drive traffic to your site and help you to become a successful .com business. REQUEST OUR FREE E-MAIL INFORMATION IMMEDIATELY! REMEMBER: THIS SPECIAL OFFER IS ONLY GOOD FOR 7 DAYS! Please reply to: mailto:jjkent23@email.com?subject=INFO-PLEASE to receive our FREE e -mail information package without obligations. ********************************************************* Remove at mailto:ben28xx@netscape.net?subject=remove ********************************************************* ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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 Paul Long 02 Jun '00

02 Jun '00

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

3 4

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

02 Jun '00

This has been discussed at lenght many times. Q.931 is in direct conflict with H.225.0 on many points, including mundate tasks like clearing a call. DISCONNECT and RELEASE messages for example are mandatory in Q.931 and forbitten in H.225.0. That is a trivial example. The bottom line, is that there is some sort of common understanding that Q.931-like procedures are used, with a lot of implied exceptions and divergences. The "call control" procedures are not formally described in H.225.0. There was even a suggestion to add them to a further version of H.323. Be my guess... > -----Original Message----- > From: Dave Walker [mailto:drwalker@SS8NETWORKS.COM] > Sent: Thursday, June 01, 2000 11:49 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: On TD26 - Fast TCS and M/S negotiation in H.323v4 > > > I'm not sure this is correct. H.323 section 7.3.1 mandates the use of > Q.931 Annex D procedures. In turn, that Annex uses Q.931 clause 5. > So *that* is what applies in the absence of any overriding provisions > in H.323. So I think that Q.931/5.8.6.2 *should* apply. > > But to re-iterate what Paul asked earlier, if we had a description of > the problem that this was intended to solve, perhaps a less > contentious > solution could be found. > > Regards, > > Dave Walker > SS8 Networks > Ottawa, Canada > > > > Francois Audet wrote: > > > > Except that the section that Paul quotes is in Q.931 and > NOT in H.225.0. > > It has nothing to do with H.225.0. In fact, it talks about a message > > that is not even supported in H.225.0 (i.e., RELEASE). > > > > To reiterate: H.323v2 does not describe how an endpoint > receiving both > > elements shall behave themselves. It just says that the > sender shall not > > include both since it would cancel fast start. This > particular case (wich > > apparently is not supported by any implementation) would > result (if you > > follow the logic of H.323v2) in ignoring fast start and > proceeding with > > H.245 tunnelling. That is NOT a backward compatibility > problem, and it > > does't break anything. > > > > Rejecting the call with cause value 100 is definitively NOT > what H.323v2 says. > > > > > In Q.931, the user-user IE is typically optional, so the > clause that > > > Paul Long's been quoting wouldn't apply. However, since > H.323 makes > > > the UUIE mandatory, it *does* apply in the case under discussion. > > > I think that the statement contained in TD-26, that it preserves > > > backwards compatibility, is completely wrong. The > correct statement > > > should have been that it doesn't break implementations > known to the > > > authors. I agree with Paul that we should try to develop a better > > > solution. > > > > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com >

2 1

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

01 Jun '00

Except that the section that Paul quotes is in Q.931 and NOT in H.225.0. It has nothing to do with H.225.0. In fact, it talks about a message that is not even supported in H.225.0 (i.e., RELEASE). To reiterate: H.323v2 does not describe how an endpoint receiving both elements shall behave themselves. It just says that the sender shall not include both since it would cancel fast start. This particular case (wich apparently is not supported by any implementation) would result (if you follow the logic of H.323v2) in ignoring fast start and proceeding with H.245 tunnelling. That is NOT a backward compatibility problem, and it does't break anything. Rejecting the call with cause value 100 is definitively NOT what H.323v2 says. > In Q.931, the user-user IE is typically optional, so the clause that > Paul Long's been quoting wouldn't apply. However, since H.323 makes > the UUIE mandatory, it *does* apply in the case under discussion. > I think that the statement contained in TD-26, that it preserves > backwards compatibility, is completely wrong. The correct statement > should have been that it doesn't break implementations known to the > authors. I agree with Paul that we should try to develop a better > solution. > >

2 1

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

01 Jun '00

If they reject the call with cause 100, then it is their implementation that is broken. > -----Original Message----- > From: Paul Long [mailto:Plong@SMITHMICRO.COM] > Sent: Thursday, June 01, 2000 8:04 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: On TD26 - Fast TCS and M/S negotiation in H.323v4 > > > Francois, > > We should not be taking a poll as to whether something would > break existing > implementations. What about vendors that we don't ask, that > don't respond, > or are out of the loop for some reason? A standard is a > contract of sorts. > Breaking contracts is a bad thing in part because future > contracts cannot be > depended on. > > Paul Long > Smith Micro Software, Inc. > > -----Original Message----- > From: Francois Audet [mailto:audet@NORTELNETWORKS.COM] > Sent: Thursday, June 01, 2000 7:34 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: On TD26 - Fast TCS and M/S negotiation in H.323v4 > > > I fully agree with Orit. > > So far, I haven't heard of anybody that actually implemented clearing > the call > if both fastStart and h245Control are present in SETUP. I would argue, > it would > be a very bad implementation, regardless of what they interpreted the > spec > saying. > > This being said, it seems that it will not create any interoperability > problems. > The *worst* case scenario (here again, I haven't heard of anybody that > actually implemented it that way) is that the call would > proceed as fast > > tunnelling (as per the spec) and ignore the fast start. > > The benefits of doing the fastStart and the fast tunnelling > at the same > time > far outweight the theoretical backward compatibility problems. > > If anybody wants to revoke the Osaka agreement, contributions in > Portland are > welcomed. ;^) > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com >

2 1