RE: On TD26 - Fast TCS and M/S negotiation in H.323v4
Paul,
It would be required in the SETUP, CALL PROCeeding, ALERT, FACILITY, and CONNECT message in that all of these messages can be sent before Fast Start is completed or may not be present with Fast Start elements based on v2.
Bob
-----Original Message----- From: Paul E. Jones [mailto:paulej@PACKETIZER.COM] Sent: Saturday, June 03, 2000 6:41 AM To: ITU-SG16@mailbag.cps.intel.com Subject: Re: On TD26 - Fast TCS and M/S negotiation in H.323v4
Paul, Francois, and others,
If we were able to get consensus here, I believe we could add a field to the SETUP-UUIE. I'd rather not put it in the H323-UU-PDU, since it is intended for SETUP only as a means of allowing H.245 to used with fastConnect in a backward compatible manner.
We have an entire proposal on verbiage to be added to H.323. I'll have to review that to see what needs changing-- but there's actually a lot of description.
Can we agree to introduce a new "earlyH245" field to go along with "fastStart" in the SETUP?
Paul
----- Original Message ----- From: "Paul Long" Plong@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
Bob,
H.323 only says that fastStart and h245Control cannot both be included in _Setup_, so it could indeed be included in the Setup-UUIE type.
Paul Long Smith Micro Software, Inc.
-----Original Message----- From: Callaghan, Robert [mailto:Robert.Callaghan@ICN.SIEMENS.COM] Sent: Tuesday, June 06, 2000 10:27 AM To: ITU-SG16@MAILBAG.INTEL.COM Subject: Re: On TD26 - Fast TCS and M/S negotiation in H.323v4
Paul,
It would be required in the SETUP, CALL PROCeeding, ALERT, FACILITY, and CONNECT message in that all of these messages can be sent before Fast Start is completed or may not be present with Fast Start elements based on v2.
Bob
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
Paul- The problem is that inclusion of an H.245 message in the tunnel terminates FastStart according to section 8.2.1 of H.323. This could be "satisfied" by using the early H.245 element for the replys so that FastStart could proceed. At least this mechanism would make it easy to know that the responder (the called endpoint) was able to overlap FastStart and H.245. -Bob ---------------------------------------------------- Bob Gilman rrg@lucent.com +1 303 538 3868
Paul Long wrote:
Bob,
H.323 only says that fastStart and h245Control cannot both be included in _Setup_, so it could indeed be included in the Setup-UUIE type.
Paul Long Smith Micro Software, Inc.
-----Original Message----- From: Callaghan, Robert [mailto:Robert.Callaghan@ICN.SIEMENS.COM] Sent: Tuesday, June 06, 2000 10:27 AM To: ITU-SG16@MAILBAG.INTEL.COM Subject: Re: On TD26 - Fast TCS and M/S negotiation in H.323v4
Paul,
It would be required in the SETUP, CALL PROCeeding, ALERT, FACILITY, and CONNECT message in that all of these messages can be sent before Fast Start is completed or may not be present with Fast Start elements based on v2.
Bob
For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
Bob,
That text in section 8.2.1 has been removed via the Implementers Guide. There were a few issues with the text as it was, with a "race condition" being the most notable.
If an aggressive endpoint sends a SETUP w/ fastStart and the other end returns Alerting without fastStart, the calling endpoint may assume that FC was rejected, so it sends a Facility with H.245 messages. Then (perhaps at the same time), the called endpoint returns CONNECT with fastStart... now, what state are things in? The caller thought that it terminated FC and the called party thinks that FC was accepted.
One could say "the caller should then recognize that FC was indeed accepted", but it defeats the purpose of "terminating FC". The reason for that text was so that the calling EP could do its best to try to get the H.245 tunnel up and channels open before CONNECT-- we could get into a terrible mess.
Now, there could be work-arounds to this issue, but I believe that the procedural explanation to work-around the race condition may be far worse. However, I am not opposed to a work-around. Apparently, the removal of that text has caused some confusion, so it may be worth reinstating that text and defining some general guidelines.
However, we need to think through this carefully. Contributions are definitely solicited :-) We could leave the text as it is in the IG (which I believe fixes the issues) or we could reinstate the text and provide some guiding text (which may reduce incompatibilities with V2 equipment).
Paul
----- Original Message ----- From: "Bob Gilman" rrg@LUCENT.COM To: ITU-SG16@mailbag.cps.intel.com Sent: Tuesday, June 06, 2000 7:17 PM Subject: Re: On TD26 - Fast TCS and M/S negotiation in H.323v4
Paul- The problem is that inclusion of an H.245 message in the tunnel terminates FastStart according to section 8.2.1 of H.323. This could be "satisfied" by using the early H.245 element for the replys so that FastStart could
proceed.
At least this mechanism would make it easy to know that the responder (the called endpoint) was able to overlap FastStart and H.245.
-Bob
Bob Gilman rrg@lucent.com +1 303 538 3868
Paul Long wrote:
Bob,
H.323 only says that fastStart and h245Control cannot both be included
in
_Setup_, so it could indeed be included in the Setup-UUIE type.
Paul Long Smith Micro Software, Inc.
-----Original Message----- From: Callaghan, Robert [mailto:Robert.Callaghan@ICN.SIEMENS.COM] Sent: Tuesday, June 06, 2000 10:27 AM To: ITU-SG16@MAILBAG.INTEL.COM Subject: Re: On TD26 - Fast TCS and M/S negotiation in H.323v4
Paul,
It would be required in the SETUP, CALL PROCeeding, ALERT, FACILITY, and CONNECT message in that all of these messages can be sent before Fast Start is completed or may not be present with Fast Start elements based on v2.
Bob
For help on this mail list, send "HELP ITU-SG16" in a message to listserv@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
Paul,
An EP that thinks that Alerting-without-fastStart indicates FC has been rejected is clearly making a false assumption.
You know, if EPs would just start using an empty fastStart component in all responses up to Connect to indicate rejection of FC, we'd solve this problem once and for all. No more waiting until Connect to determine if FC is supported. No more worrying about terminating FC by using H.245. It is already inherent in H.323 that an empty fastStart essentially indicates rejection of FC, so we just need to add words to v4 and the v3IG admonishing an EP to encode an empty fastStart if it doesn't support FC (or knows that it will eventually reject FC) instead of waiting until Connect to not encode fastStart.
Paul Long Smith Micro Software, Inc. "Primum non nocere"
-----Original Message----- From: Paul E. Jones [mailto:paulej@PACKETIZER.COM] Sent: Wednesday, June 07, 2000 1:44 AM To: ITU-SG16@MAILBAG.INTEL.COM Subject: Re: On TD26 - Fast TCS and M/S negotiation in H.323v4
Bob,
That text in section 8.2.1 has been removed via the Implementers Guide. There were a few issues with the text as it was, with a "race condition" being the most notable.
If an aggressive endpoint sends a SETUP w/ fastStart and the other end returns Alerting without fastStart, the calling endpoint may assume that FC was rejected, so it sends a Facility with H.245 messages. Then (perhaps at the same time), the called endpoint returns CONNECT with fastStart... now, what state are things in? The caller thought that it terminated FC and the called party thinks that FC was accepted.
One could say "the caller should then recognize that FC was indeed accepted", but it defeats the purpose of "terminating FC". The reason for that text was so that the calling EP could do its best to try to get the H.245 tunnel up and channels open before CONNECT-- we could get into a terrible mess.
Now, there could be work-arounds to this issue, but I believe that the procedural explanation to work-around the race condition may be far worse. However, I am not opposed to a work-around. Apparently, the removal of that text has caused some confusion, so it may be worth reinstating that text and defining some general guidelines.
However, we need to think through this carefully. Contributions are definitely solicited :-) We could leave the text as it is in the IG (which I believe fixes the issues) or we could reinstate the text and provide some guiding text (which may reduce incompatibilities with V2 equipment).
Paul
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
Paul,
I completely agree that we could probably solve a number (or all of these) issues with the empty fastStart. However, we have an issue: the Implementers Guide for v3 now has a "fast connect refused" field (I forget the exact field name).
Somebody proposed this as a mechanism, but it was rejected-- why I cannot recall now. I am recalling less and less and this morning wears on...
Paul
----- Original Message ----- From: "Paul Long" Plong@SMITHMICRO.COM To: ITU-SG16@mailbag.cps.intel.com Sent: Wednesday, June 07, 2000 3:51 AM Subject: Re: On TD26 - Fast TCS and M/S negotiation in H.323v4
Paul,
An EP that thinks that Alerting-without-fastStart indicates FC has been rejected is clearly making a false assumption.
You know, if EPs would just start using an empty fastStart component in
all
responses up to Connect to indicate rejection of FC, we'd solve this
problem
once and for all. No more waiting until Connect to determine if FC is supported. No more worrying about terminating FC by using H.245. It is already inherent in H.323 that an empty fastStart essentially indicates rejection of FC, so we just need to add words to v4 and the v3IG
admonishing
an EP to encode an empty fastStart if it doesn't support FC (or knows that it will eventually reject FC) instead of waiting until Connect to not
encode
fastStart.
Paul Long Smith Micro Software, Inc. "Primum non nocere"
-----Original Message----- From: Paul E. Jones [mailto:paulej@PACKETIZER.COM] Sent: Wednesday, June 07, 2000 1:44 AM To: ITU-SG16@MAILBAG.INTEL.COM Subject: Re: On TD26 - Fast TCS and M/S negotiation in H.323v4
Bob,
That text in section 8.2.1 has been removed via the Implementers Guide. There were a few issues with the text as it was, with a "race condition" being the most notable.
If an aggressive endpoint sends a SETUP w/ fastStart and the other end returns Alerting without fastStart, the calling endpoint may assume that FC was rejected, so it sends a Facility with H.245 messages. Then (perhaps at the same time), the called endpoint returns CONNECT with fastStart... now, what state are things in? The caller thought that it terminated FC and the called party thinks that FC was accepted.
One could say "the caller should then recognize that FC was indeed accepted", but it defeats the purpose of "terminating FC". The reason for that text was so that the calling EP could do its best to try to get the H.245 tunnel up and channels open before CONNECT-- we could get into a terrible mess.
Now, there could be work-arounds to this issue, but I believe that the procedural explanation to work-around the race condition may be far worse. However, I am not opposed to a work-around. Apparently, the removal of that text has caused some confusion, so it may be worth reinstating that text and defining some general guidelines.
However, we need to think through this carefully. Contributions are definitely solicited :-) We could leave the text as it is in the IG (which I believe fixes the issues) or we could reinstate the text and provide some guiding text (which may reduce incompatibilities with V2 equipment).
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
Bob,
For messages other than SETUP, I was assuming we could use the existing h245Control field for H.245 message exchange-- only the SETUP message is a special case, since it was explicitly disallowed in H.323v2 when fastStart was also present.
Paul
----- Original Message ----- From: "Callaghan, Robert" Robert.Callaghan@icn.siemens.com To: "'Paul E. Jones'" paulej@PACKETIZER.COM Cc: "'Mailing list for parties associated with ITU-T Study Group 16'" ITU-SG16@mailbag.cps.intel.com Sent: Tuesday, June 06, 2000 11:27 AM Subject: RE: On TD26 - Fast TCS and M/S negotiation in H.323v4
Paul,
It would be required in the SETUP, CALL PROCeeding, ALERT, FACILITY, and CONNECT message in that all of these messages can be sent before Fast
Start
is completed or may not be present with Fast Start elements based on v2.
Bob
-----Original Message----- From: Paul E. Jones [mailto:paulej@PACKETIZER.COM] Sent: Saturday, June 03, 2000 6:41 AM To: ITU-SG16@mailbag.cps.intel.com Subject: Re: On TD26 - Fast TCS and M/S negotiation in H.323v4
Paul, Francois, and others,
If we were able to get consensus here, I believe we could add a field to
the
SETUP-UUIE. I'd rather not put it in the H323-UU-PDU, since it is
intended
for SETUP only as a means of allowing H.245 to used with fastConnect in a backward compatible manner.
We have an entire proposal on verbiage to be added to H.323. I'll have to review that to see what needs changing-- but there's actually a lot of description.
Can we agree to introduce a new "earlyH245" field to go along with "fastStart" in the SETUP?
Paul
----- Original Message ----- From: "Paul Long" Plong@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
Paul, why are we even doing this? I'd just tell Bob to use the Keypad Facility IE if he really needs DTMF signalling. You must realize how ridiculous this'll look to advocates of other solutions: the ITU screwed up H.245 tunneling, and now they're adding a new tunnel to fix it - yech.
Dave.
"Paul E. Jones" wrote:
Bob,
For messages other than SETUP, I was assuming we could use the existing h245Control field for H.245 message exchange-- only the SETUP message is a special case, since it was explicitly disallowed in H.323v2 when fastStart was also present.
Paul
----- Original Message ----- From: "Callaghan, Robert" Robert.Callaghan@icn.siemens.com To: "'Paul E. Jones'" paulej@PACKETIZER.COM Cc: "'Mailing list for parties associated with ITU-T Study Group 16'" ITU-SG16@mailbag.cps.intel.com Sent: Tuesday, June 06, 2000 11:27 AM Subject: RE: On TD26 - Fast TCS and M/S negotiation in H.323v4
Paul,
It would be required in the SETUP, CALL PROCeeding, ALERT, FACILITY, and CONNECT message in that all of these messages can be sent before Fast
Start
is completed or may not be present with Fast Start elements based on v2.
Bob
-----Original Message----- From: Paul E. Jones [mailto:paulej@PACKETIZER.COM] Sent: Saturday, June 03, 2000 6:41 AM To: ITU-SG16@mailbag.cps.intel.com Subject: Re: On TD26 - Fast TCS and M/S negotiation in H.323v4
Paul, Francois, and others,
If we were able to get consensus here, I believe we could add a field to
the
SETUP-UUIE. I'd rather not put it in the H323-UU-PDU, since it is
intended
for SETUP only as a means of allowing H.245 to used with fastConnect in a backward compatible manner.
We have an entire proposal on verbiage to be added to H.323. I'll have to review that to see what needs changing-- but there's actually a lot of description.
Can we agree to introduce a new "earlyH245" field to go along with "fastStart" in the SETUP?
Paul
----- Original Message ----- From: "Paul Long" Plong@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.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
Dave,
Arguably (and yes, I've heard plenty), this little feature has a few benefits-- notably, prevention of media clipping and call handling with the involvement of an ACD system.
Advocates of "other solutions" will have similar problems when their solutions reach a similar level of maturity. I believe that any system has pros and cons and we cannot necessarily say we "screwed it up" in this case. It's a matter of wanting to extend current functionality, while preserving backward compatibility. Should we have allowed FC and tunneling? Perhaps, but I am sure that time constraints were an unavoidable factor in that decision.
With previous releases of H.323, such strict policies on backward compatibility was not such a big deal, as there were not nearly so many implementations. Today, this is a serious issue-- we have to preserve backward compatibility with V2 with no exceptions, as it is widely deployed in production networks.
Paul
----- Original Message ----- From: "Dave Walker" drwalker@ss8networks.com To: ITU-SG16@mailbag.cps.intel.com Sent: Tuesday, June 06, 2000 4:44 PM Subject: Re: On TD26 - Fast TCS and M/S negotiation in H.323v4
Paul, why are we even doing this? I'd just tell Bob to use the Keypad Facility IE if he really needs DTMF signalling. You must realize how ridiculous this'll look to advocates of other solutions: the ITU screwed up H.245 tunneling, and now they're adding a new tunnel to fix it - yech.
Dave.
"Paul E. Jones" wrote:
Bob,
For messages other than SETUP, I was assuming we could use the existing h245Control field for H.245 message exchange-- only the SETUP message is
a
special case, since it was explicitly disallowed in H.323v2 when
fastStart
was also present.
Paul
----- Original Message ----- From: "Callaghan, Robert" Robert.Callaghan@icn.siemens.com To: "'Paul E. Jones'" paulej@PACKETIZER.COM Cc: "'Mailing list for parties associated with ITU-T Study Group 16'" ITU-SG16@mailbag.cps.intel.com Sent: Tuesday, June 06, 2000 11:27 AM Subject: RE: On TD26 - Fast TCS and M/S negotiation in H.323v4
Paul,
It would be required in the SETUP, CALL PROCeeding, ALERT, FACILITY,
and
CONNECT message in that all of these messages can be sent before Fast
Start
is completed or may not be present with Fast Start elements based on
v2.
Bob
-----Original Message----- From: Paul E. Jones [mailto:paulej@PACKETIZER.COM] Sent: Saturday, June 03, 2000 6:41 AM To: ITU-SG16@mailbag.cps.intel.com Subject: Re: On TD26 - Fast TCS and M/S negotiation in H.323v4
Paul, Francois, and others,
If we were able to get consensus here, I believe we could add a field
to
the
SETUP-UUIE. I'd rather not put it in the H323-UU-PDU, since it is
intended
for SETUP only as a means of allowing H.245 to used with fastConnect
in a
backward compatible manner.
We have an entire proposal on verbiage to be added to H.323. I'll
have to
review that to see what needs changing-- but there's actually a lot of description.
Can we agree to introduce a new "earlyH245" field to go along with "fastStart" in the SETUP?
Paul
----- Original Message ----- From: "Paul Long" Plong@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.comFor 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
Dave, Paul etc.,
In terms of cleanliness, it seems to me that now H.323 has matured, the original design goal of fastConnect is no longer sufficient for our needs. Perhaps we should be looking to deprecate fastConnect in a orderly fashion rather than trying to enhance it.
This would need to be managed in an orderly way so that we still allow interworking with as many entities as possible.
One strategy to do this would be:
1) Introduce an early H.245 tunnel as a package (it's important to be a package as you will see later)
2) Formally bless Dave and mine's H.245 pre-opened channels proposal (APC-1524). This achieves the same setup time as fast connect, and is ready to be used today. (The only real requirement needed is to give it an officially sanctioned identifier rather than a GUID.)
3) Declare that it is intended for fast connect to be deprecated.
4) Obviously fast connect will still be around for a long time to come, but, if they desire, people will have the chance to use pre-opened channels in preference to fast connect when they are both used in parallel, thus allowing a smooth migration.
5) When its deemed suitable, don't use fast connect, and just use tunnelled H.245 with pre-opened channels in the existing tunnel. This decision point could be made by vendors on an individual basis.
6) Deprecate the early H.245 package, thus leaving the base syntax blemish free(-ish).
I think this slightly longer term view is required to enhance the future viability of 323. It was a short term fix that got us into this mess; let's not rely on a short term fix to try and get us out. If I've learnt anything from this, it is that <short term fix> = <long term pain>!
Pete.
============================================= Pete Cordell Tech-Know-Ware pete@tech-know-ware.com +44 1473 635863 =============================================
----- Original Message ----- From: Paul E. Jones paulej@PACKETIZER.COM To: ITU-SG16@MAILBAG.INTEL.COM Sent: 07 June 2000 07:18 Subject: Re: On TD26 - Fast TCS and M/S negotiation in H.323v4
Dave,
Arguably (and yes, I've heard plenty), this little feature has a few benefits-- notably, prevention of media clipping and call handling with
the
involvement of an ACD system.
Advocates of "other solutions" will have similar problems when their solutions reach a similar level of maturity. I believe that any system
has
pros and cons and we cannot necessarily say we "screwed it up" in this
case.
It's a matter of wanting to extend current functionality, while preserving backward compatibility. Should we have allowed FC and tunneling?
Perhaps,
but I am sure that time constraints were an unavoidable factor in that decision.
With previous releases of H.323, such strict policies on backward compatibility was not such a big deal, as there were not nearly so many implementations. Today, this is a serious issue-- we have to preserve backward compatibility with V2 with no exceptions, as it is widely
deployed
in production networks.
Paul
----- Original Message ----- From: "Dave Walker" drwalker@ss8networks.com To: ITU-SG16@mailbag.cps.intel.com Sent: Tuesday, June 06, 2000 4:44 PM Subject: Re: On TD26 - Fast TCS and M/S negotiation in H.323v4
Paul, why are we even doing this? I'd just tell Bob to use the Keypad Facility IE if he really needs DTMF signalling. You must realize how ridiculous this'll look to advocates of other solutions: the ITU screwed up H.245 tunneling, and now they're adding a new tunnel to fix it - yech.
Dave.
"Paul E. Jones" wrote:
Bob,
For messages other than SETUP, I was assuming we could use the
existing
h245Control field for H.245 message exchange-- only the SETUP message
is
a
special case, since it was explicitly disallowed in H.323v2 when
fastStart
was also present.
Paul
----- Original Message ----- From: "Callaghan, Robert" Robert.Callaghan@icn.siemens.com To: "'Paul E. Jones'" paulej@PACKETIZER.COM Cc: "'Mailing list for parties associated with ITU-T Study Group 16'" ITU-SG16@mailbag.cps.intel.com Sent: Tuesday, June 06, 2000 11:27 AM Subject: RE: On TD26 - Fast TCS and M/S negotiation in H.323v4
Paul,
It would be required in the SETUP, CALL PROCeeding, ALERT, FACILITY,
and
CONNECT message in that all of these messages can be sent before
Fast
Start
is completed or may not be present with Fast Start elements based on
v2.
Bob
-----Original Message----- From: Paul E. Jones [mailto:paulej@PACKETIZER.COM] Sent: Saturday, June 03, 2000 6:41 AM To: ITU-SG16@mailbag.cps.intel.com Subject: Re: On TD26 - Fast TCS and M/S negotiation in H.323v4
Paul, Francois, and others,
If we were able to get consensus here, I believe we could add a
field
to
the
SETUP-UUIE. I'd rather not put it in the H323-UU-PDU, since it is
intended
for SETUP only as a means of allowing H.245 to used with fastConnect
in a
backward compatible manner.
We have an entire proposal on verbiage to be added to H.323. I'll
have to
review that to see what needs changing-- but there's actually a lot
of
description.
Can we agree to introduce a new "earlyH245" field to go along with "fastStart" in the SETUP?
Paul
----- Original Message ----- From: "Paul Long" Plong@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
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.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 (6)
-
Bob Gilman -
Callaghan, Robert -
Dave Walker -
Paul E. Jones -
Paul Long -
Pete Cordell