Expediting H.245

Pete Cordell pete at TECH-KNOW-WARE.COM
Thu Jul 27 17:18:18 EDT 2000


Bob,

My ears pricked up when you mentioned "migration path".

Do you see more additions to fast start/ quicker start/ flexible start?  It
would be nice to know what your thoughts are.

Pete.

=============================================
Pete Cordell
Tech-Know-Ware
pete at tech-know-ware.com
+44 1473 635863
=============================================

----- Original Message -----
From: Callaghan, Robert <Robert.Callaghan at ICN.SIEMENS.COM>
To: <ITU-SG16 at mailbag.cps.intel.com>
Sent: 27 July 2000 18:48
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
>

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



More information about the sg16-avd mailing list