Expediting H.245

[Callaghan, Robert]

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