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, 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 PDUBut 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 PDUBut 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.comFor 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
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
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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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 PDUBut 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.comFor 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