On TD26 - Fast TCS and M/S negotiation in H.323v4

Anatoli Levine alevine at RADVISION.COM
Sat Jun 3 18:45:47 EDT 2000


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 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: alevine.vcf
Type: text/x-vcard
Size: 306 bytes
Desc: Card for Anatoli Levine
URL: <https://lists.packetizer.com/pipermail/sg16-avd/attachments/20000603/1febe2d1/attachment-0004.vcf>


More information about the sg16-avd mailing list