I would second this proposal. The exchange of signalling transport requirements belongs in a CAPS type exchange.
-----Original Message----- From: Yoav Medan [mailto:MEDAN@HAIFA.VNET.IBM.COM] Sent: Saturday, November 21, 1998 9:52 AM To: ITU-SG16@MAILBAG.INTEL.COM Subject: Re: H.323 Annex E
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@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@MAILBAG.INTEL.COM
To: ITU-SG16@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.
------------------------------------------------------------------ This message was spam-checked by an evaluation copy of MailShield. See http://www.mailshield.com for more information.