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
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
it. 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
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 like 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
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 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