H.323v4 and the Implementers Guide

[Paul E. Jones]

Paul,

It would be very easy to define a package for use in the H323-UU-PDU to
contain H.245 that could be tunnelled in parallel with fastConnect.

It would simply involve a package that included a single parameter of the
raw type.

For simplicity, I would suggest that an endpoint can indicate support for
the feature by sending a parallel H.245 package in the fastConnect message,
even if they are empty ones.

If it was successfully determined that the parallel H.245 tunnel was
supported by both endpoints, then you would use the package based H.245
tunnel from then on in preference to the existing H.245 tunnel (this is to
avoid any sequencing issues that may result if both tunnels were used.
Alternatively you could say 'you may use one or the other channel, but not
both at the same time.')

I would then suggest that the tunnel thus negotiated would be controlled by
the same boolean flags that control the continuing existence of the existing
H.245 tunnel.  This is very efficient, and allows re-use of the existing
procedures.

Personally I would prefer this to adding a new parallel H.245 tunnel in the
H323-UU-PDU.

If other people will let me have their comments on the principle I can
refine the ideas, and perhaps in collaboration with other, define some text.

Pete.

=============================================
Pete Cordell
pete at tech-know-ware.com
=============================================

----- Original Message -----
From: Paul E. Jones <paulej at packetizer.com>
To: Mailing list for parties associated with ITU-T Study Group 16
<ITU-SG16 at mailbag.cps.intel.com>
Cc: <pete at TECH-KNOW-WARE.COM>
Sent: 03 June 2000 02:33
Subject: Re: Re: On TD26 - Fast TCS and M/S negotiation in H.323v4


> Paul,
>
> > BTW, relying on version-specific behavior creates insurmountable
problems
> > with GKs that use the routed model, i.e., all GKs. Over time, as there
are
> > more and more entities of different versions out in the field, and the
> > versioning-GW aspect of a GK becomes more critical, we will find that we
> > have painted ourselves into a corner unless we address the problem now.
> The
> > only solution I can see is to _never_ define purely version-specific
> > behavior--always signal/negotiate it. (Paul?)
>
> Routing the call signaling through a GK can be a problem.  For example, if
a
> V1 devices calls a V3 GK to connect to a V2 endpoint, what version does
the
> GK use when it sends messages to either the V1 or V2 endpoint?  I would
> argue that the only safe thing to do is for the GK to report the
> min(other_ep_version, gatekeeper_version) to the endpoint.  The Gatekeeper
> must then concern itself with properly populating fields mandatory for the
> version of the protocol it reported to the other endpoint.
>
> I often see people use the GK version.  That's bad, because in this case
the
> V2 endpoint might send an empty capability set (TCS=0) to the V1 endpoint
> and there's nothing the GK can do to gracefully handle this problem.
There
> may be other examples of problems like this, but this is the most notable.
>
> I completely agree that some "generic" mechanism for capability exchange
is
> necessary.  Fortunately, we now have such a feature on H.323v4!  I have
not
> looked at it to see how it might be utilized for "early H.245", but I
> suspect it could be used.
>
> Perhaps somebody might want to propose how we might use this new mechanism
> of H.323v4 to allow for early H.245?  Pete, would you like to address this
> option?
>
> Paul
>
>

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