[H.323 Mobility:] Annex H and I and H.246 Annex E

Wed Jun 7 02:06:43 EDT 2000

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 at ss8networks.com>
To: <ITU-SG16 at 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 at icn.siemens.com>
> > To: "'Paul E. Jones'" <paulej at PACKETIZER.COM>
> > Cc: "'Mailing list for parties associated with ITU-T Study Group 16'"
> > <ITU-SG16 at 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 at PACKETIZER.COM]
> > > Sent: Saturday, June 03, 2000 6:41 AM
> > > To: ITU-SG16 at 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 at SMITHMICRO.COM>
> > > To: <ITU-SG16 at 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 at PACKETIZER.COM]
> > > > Sent: Friday, June 02, 2000 8:14 PM
> > > > To: ITU-SG16 at 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 at mailbag.intel.com
> > > >
> > >
> > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > For help on this mail list, send "HELP ITU-SG16" in a message to
> > > listserv at mailbag.intel.com
> > >
> >
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > For help on this mail list, send "HELP ITU-SG16" in a message to
> > listserv at mailbag.intel.com
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> For help on this mail list, send "HELP ITU-SG16" in a message to
> listserv at mailbag.intel.com
>

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv at mailbag.intel.com