Pete,
This solution was proposed in Santiago de Chile, and was rejected.
Your proposal, as I understand it, requires 2 round trip. Faststart only
requires 1. I need the faster connect.
As to Dave Walkers proposal, Keypad digits do not solve the problems needed
to solve DTMF transmission; such as long "#" used to indicate a new credit
card call.
Bob
-----Original Message-----
From: Pete Cordell [mailto:pete@TECH-KNOW-WARE.COM]
Sent: Wednesday, June 07, 2000 5:32 AM
To: ITU-SG16(a)mailbag.cps.intel.com
Subject: Re: On TD26 - Fast TCS and M/S negotiation in H.323v4
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(a)tech-know-ware.com
+44 1473 635863
=============================================
----- Original Message -----
From: Paul E. Jones <paulej(a)PACKETIZER.COM>
To: <ITU-SG16(a)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(a)ss8networks.com>
> To: <ITU-SG16(a)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(a)icn.siemens.com>
> > > To: "'Paul E. Jones'" <paulej(a)PACKETIZER.COM>
> > > Cc: "'Mailing list for parties associated with ITU-T Study Group 16'"
> > > <ITU-SG16(a)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(a)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(a)SMITHMICRO.COM>
> > > > To: <ITU-SG16(a)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(a)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(a)mailbag.intel.com
> > > > >
> > > >
> > > >
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > > For help on this mail list, send "HELP ITU-SG16" in a message to
> > > > listserv(a)mailbag.intel.com
> > > >
> > >
> > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > For help on this mail list, send "HELP ITU-SG16" in a message to
> > > listserv(a)mailbag.intel.com
> >
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > For help on this mail list, send "HELP ITU-SG16" in a message to
> > listserv(a)mailbag.intel.com
> >
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> For help on this mail list, send "HELP ITU-SG16" in a message to
> listserv(a)mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
