H.323v4 and the Implementers Guide

Paul E. Jones paulej at PACKETIZER.COM
Sun Jun 4 20:41:01 EDT 2000


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

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

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 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
> > with GKs that use the routed model, i.e., all GKs. Over time, as there
> > 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
> V1 devices calls a V3 GK to connect to a V2 endpoint, what version does
> 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
> 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.
> may be other examples of problems like this, but this is the most notable.
> I completely agree that some "generic" mechanism for capability exchange
> necessary.  Fortunately, we now have such a feature on H.323v4!  I have
> 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

More information about the sg16-avd mailing list