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@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@radvision.com -----Original Message----- From: Paul E. Jones <paulej@PACKETIZER.COM> To: ITU-SG16@MAILBAG.INTEL.COM <ITU-SG16@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@TECH-KNOW-WARE.COM> To: <ITU-SG16@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@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@mailbag.intel.com >> > >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >For help on this mail list, send "HELP ITU-SG16" in a message to >listserv@mailbag.intel.comFor help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
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@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@mailbag.intel.com
RE: On TD26 - Fast TCS and M/S negotiation in H.323v4Francois, 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 ----- Original Message ----- From: Francois Audet To: ITU-SG16@mailbag.cps.intel.com Sent: Thursday, June 01, 2000 8:33 AM 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. ;^)
-----Original Message----- From: Orit Levin [mailto:orit@RADVISION.COM] Sent: Wednesday, May 31, 2000 8:32 AM To: ITU-SG16@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@radvision.com -----Original Message----- From: Paul E. Jones <paulej@PACKETIZER.COM> To: ITU-SG16@MAILBAG.INTEL.COM <ITU-SG16@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@TECH-KNOW-WARE.COM> To: <ITU-SG16@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@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@mailbag.intel.com >> > >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >For help on this mail list, send "HELP ITU-SG16" in a message to >listserv@mailbag.intel.comFor help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
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@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@mailbag.intel.com
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
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@SMITHMICRO.COM> To: <ITU-SG16@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 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@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@mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
Paul, why do we need "earlyH245" field in the SETUP-UUIE? Technically, just the presence of H245Address in the SETUP H323-UU-PDU has a meaning of "earlyH245". I thought we were trying to resolve an issue with Tunneling and Fast Start - how is this "earlyH245" field will help? Anatoli "Paul E. Jones" wrote:
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@SMITHMICRO.COM> To: <ITU-SG16@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@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@mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
Anatoli, This may be a poor choice for the name of the new field. By "earlyH245," I think Paul means that an encapsulated H.245 message is being conveyed earlier than H.323 would otherwise allow--in a Setup message that also contains fastStart. I don't think he meant "Early H.245" at least as I have been using the term, i.e., establishing a separate H.245 channel through the h245Address field prior to the receipt of Connect. Maybe this means we need to call the field something else. That's why I called it "earlyH245Control" in my response. Any other suggestions? I don't know, how about "alternateH245Control?" Paul Long Smith Micro Software, Inc. -----Original Message----- From: Anatoli Levine [mailto:alevine@RADVISION.COM] Sent: Saturday, June 03, 2000 5:46 PM To: ITU-SG16@MAILBAG.INTEL.COM Subject: Re: On TD26 - Fast TCS and M/S negotiation in H.323v4 Paul, why do we need "earlyH245" field in the SETUP-UUIE? Technically, just the presence of H245Address in the SETUP H323-UU-PDU has a meaning of "earlyH245". I thought we were trying to resolve an issue with Tunneling and Fast Start - how is this "earlyH245" field will help? Anatoli ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
Anatoli,
This may be a poor choice for the name of the new field. By "earlyH245," I think Paul means that an encapsulated H.245 message is being conveyed earlier than H.323 would otherwise allow--in a Setup message that also contains fastStart. I don't think he meant "Early H.245" at least as I have been using the term, i.e., establishing a separate H.245 channel through
Paul and Anatoli, Yes, the intent of this field was to allow H.245 messages to be sent in the Setup in a backward compatible name. The name "earlyH245" has no particular relation to including the H.245 address-- Paul described my intentions correctly. BTW, I apologize for not responding to you earlier-- for some reason, I missed your posting. Paul ----- Original Message ----- From: "Paul Long" <Plong@SMITHMICRO.COM> To: <ITU-SG16@mailbag.cps.intel.com> Sent: Sunday, June 04, 2000 9:52 PM Subject: Re: On TD26 - Fast TCS and M/S negotiation in H.323v4 the
h245Address field prior to the receipt of Connect. Maybe this means we need to call the field something else. That's why I called it "earlyH245Control" in my response. Any other suggestions? I don't know, how about "alternateH245Control?"
Paul Long Smith Micro Software, Inc.
-----Original Message----- From: Anatoli Levine [mailto:alevine@RADVISION.COM] Sent: Saturday, June 03, 2000 5:46 PM To: ITU-SG16@MAILBAG.INTEL.COM Subject: Re: On TD26 - Fast TCS and M/S negotiation in H.323v4
Paul,
why do we need "earlyH245" field in the SETUP-UUIE? Technically, just the presence of H245Address in the SETUP H323-UU-PDU has a meaning of "earlyH245". I thought we were trying to resolve an issue with Tunneling and Fast Start - how is this "earlyH245" field will help?
Anatoli
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
-- ---------------------------------------------------- Bob Gilman rrg@lucent.com +1 303 538 3868 Paul- I like the suggestion of "earlyH245Control", but I believe it should be added to the H323-UU-PDU, not just the setup, so it can be used by the called party to accept fastStart proposal(s) and reply with capabilities and M/S negotiation, etc., in the same message (otherwise we face the same problem we've been talking about.) -Bob "Paul E. Jones" wrote:
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@SMITHMICRO.COM> To: <ITU-SG16@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@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@mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
participants (5)
-
Anatoli Levine -
Bob Gilman -
Francois Audet -
Paul E. Jones -
Paul Long