H.323 Annex E

Yoav Medan MEDAN at HAIFA.VNET.IBM.COM
Sat Nov 21 10:51:58 EST 1998


Kishore,

IMHO this is more than just an interesting approach. I can see a backward
compatibility problem only when endpoints are trying to engage in a
peer-to-peer call setup (no GK, thank you). But in a GK routed call setup,
why not negotiate UDP or TCP as part of the initial caps exchange? This
applies to both endpoint-GK and to GK-GK communications, as you cleverly
pointed out.

I think we ought to design Internet "Green" (i.e. friendly) protocols that
do not flood the network with redundant information unnecessarily. Let's be
clever about it rather than smart.

Regards
Yoav Medan
IBM Research, Haifa Lab, Israel




Kishore Ramisetty <kish at TRILLIUM.COM> on 20-11-98 09:57:50 PM

Please respond to Mailing list for parties associated with ITU-T Study
      Group 16 <ITU-SG16 at MAILBAG.INTEL.COM>

To:   ITU-SG16 at MAILBAG.INTEL.COM
cc:    (bcc: Yoav Medan/IBMHAIFA)
Subject:  H.323 Annex E




H.323 Annex E proposes using simultaneous (or a little later)
TCP and UDP transport connections to provide seamless
interoperability with non-Annex E devices. This results in
inefficiencies because we now have to transmit two kinds of
PDUs for the same call. (Q.931 headers are present for TCP
transport and they are absent for UDP). This again has the
unfortunate consequence of mandating higher layers to be aware
of the transport because upper layers have to deal with
duplicates arriving from TCP and UDP connections.
(Section E.5.3 para 4 and 5)

A simpler solution to this problem is, Annex E compliant
end points should register with gatekeeper about their
capability of supporting Annex E in RRQ message and
gatekeeper propogates this in ACF messages. So, it is
easy to determine apriori whether to attempt UDP/TCP
connection to the destination end points (because non
Annex E devices won't register anything with gatekeepers).
This will also require some additions to GK-GK communication
so that such kinds of profiles can be communicated across
zones.

This solution of course requires V3 GKs. If a V3 GK (or
GK itself) is absent, then end points could have the
option of trying simultaneous connections or simply falling
back to TCP. This solution would make sure that going
forward to V3 we can get rid of this simultaneous connection
establishment procedures.

I would like some comments from the group.

Thanks,
-Kishore.




More information about the sg16-avd mailing list