June 2000 - sg16-avd - lists.packetizer.com

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