Expediting H.245
Callaghan, Robert
Robert.Callaghan at ICN.SIEMENS.COM
Fri Jul 28 07:52:47 EDT 2000
Pete,
I do not foresee further enhancements H.323 basic call. There will be
enhancements for various "add ons."
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: Pete Cordell [mailto:pete at TECH-KNOW-WARE.COM]
Sent: Thursday, July 27, 2000 5:18 PM
To: ITU-SG16 at mailbag.cps.intel.com
Subject: Re: Expediting H.245
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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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