Expediting H.245

[Francois Audet]

Me too.

Unless it really improves anything, I think these last minute changes to the

White document are pretty dangerous.

> -----Original Message-----
> From: Callaghan, Robert [mailto:Robert.Callaghan at ICN.SIEMENS.COM]
> Sent: Thursday, July 27, 2000 10:49 AM
> To: ITU-SG16 at MAILBAG.INTEL.COM
> Subject: Re: Expediting H.245
>
>
> Paul,
>
> Actually I like the procedure for early H.245 tunneling that
> is in H.323 v4.
> It allows for an incremental addition to the Fast Connect
> procedure of v4
> with a reasonable migration path.  The additional field in SETUP that
> eliminates the conflict with the requirements of V2 is
> minimal.  I see no
> need to create a new procedure that then requires administration or
> negotiation.
>
> Bob
>
> ------------------------------------------------------------------
> Robert Callaghan
> Siemens Enterprise Networks
> Tel: +1.561.923.1756    Fax: +1.561.923.1403
> Email:  Robert.Callaghan at ICN.Siemens.com
> ------------------------------------------------------------------
>
>  -----Original Message-----
> From:   Bob Gilman [mailto:rrg at LUCENT.COM]
> Sent:   Thursday, July 27, 2000 12:52 PM
> To:     ITU-SG16 at mailbag.cps.intel.com
> Subject:        Re: Expediting H.245
>
> Paul-
> I didn't say anything about the possiblity of offering
> both Fast Connect and Fast Open.  It seems to me that
> doing so would present the same problems that TD-26
> encountered: we'd need a new tunnel to hide H.245 in the
> SETUP message and we'd need to abandon the statement that
> starting H.245 terminated Fast Connect (or use the same
> tunnel to continue to hide H.245).  The only reason
> to offer Fast Connect from an endpoint that supports
> Fast Open is to work with earlier-version endpoints -
> and they're the ones that can't tolerate starting H.245
> before Fast Connect is completed.
> I'd rather specify that an endpoint could offer either
> Fast Connect or Fast Open (or accept the one offered)
> at its option.  The question is: how does a calling
> endpoint know which to do?  It could be done by out-of-
> band means (administration), but it could also be done
> by looking at the RAS protocolIdentifier which requires
> a relationship between H.225.0 and H.245 versions.  Isn't
> that usually the case anyway?
> Again, the advantages of Fast Open over Fast Connect and
> early H.245 include:
> 1. More compact messaging;
>    - multiple caps, one OLC;
> 2. can be used anytime, not just call establishment;
>    - no need to switch from one protocol to another,
>      or from one tunnel to another, especially going
>      forward;
>    - uses current cap set;
>    - just as fast as Fast Connect;
> 3. backward compatible with Fast Connect;
>    - Fast Open "callee" can accept Fast Start from an
>      earlier version, knows not to use Fast Open;
>    - but Fast Open caller should not offer Both Fast Open
>      and Fast Connect - needs to know which to do;
>    - processing is very similar to Fast Connect;
>    - no need to modify historical H.225.0 restrictions.
>    - Fast Open offered to older version endpoint results
>      in H.245 operation.
> The problem of backward compatibility is a sticky one, given
> the existing restrictions on simultaneous operation and early
> switching to H.245.  The sooner we remove these restrictions
> from H.225.0, the better off we will be, but I think we've
> actually backed ourselves into a corner, unless we effectively
> change v2.  I would note that the cases for which TD-26 would
> work would also work for simultaneous Fast Connect and Fast
> Open - but there's no way around the fact that some v2 endpoints
> will object in either case.
> -Bob
> ----------------------------------------------------
> Bob Gilman       rrg at avaya.com      +1 303 538 3868
>
>
> "Paul E. Jones" wrote:
> >
> > Bob,
> >
> > This looks quite reasonable to me.
> >
> > I may have missed it in here, but do you say anything about
> including both
> > fastStart and these new fields.  Proponents of TD-26 wanted
> to ensure that
> > the devices could still take advantage of Fast Connect for
> those devices
> > that support the procedure.
> >
> > However, I'm not sure that I understand exactly what the
> advantage is over
> > the combined usage of the existing Fast Connect procedure +
> Early H.245.
> > Can you clarify that for me?
> >
> > 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 --------------
An HTML attachment was scrubbed...
URL: <https://lists.packetizer.com/pipermail/sg16-avd/attachments/20000727/ab7842b0/attachment-0001.htm>