GK As a "Version GW" (Q102)

The information in this article applies to:

A GK that provides GK routing is free to modify any and all messages it routes as long as it presents a coherent set of messages to the receiving EP and does not misrepresent the transmitter to the point of confusion. As the saying goes, "A wink is as good as a nod to a blind horse," so as long as an EP thinks it is talking to a compliant EP, a GK should be able to get away with anything. But in order to provide the aforementioned coherency, a GK must act as a "version GW" for GK-routed calls. For example, if a v2 GK routes a call between a v1 and a v3 EP, it must modify routed messages in both directions so that the streams appear to be coming from v2 devices. The industry hasn’t encountered much of a problem yet, because virtually all entities are currently based on a single version of H.323, version 2. Think of the future, though, when, for example, a v2 GK has to cope with v2, v3, v4, v5, etc. EPs. What if one or more of the new messages added to call signaling or call control after v2 contains transport addresses or other fields that need to be replaced or modified by a GK? A v2 GK will not "see" these additions, so it will pass them on unchanged while changing the ones that it does see. The result is an incoherent set of routed messages.

A GK-routing GK must therefore perform these two operations on the H.245 and call-signaling message streams:

1. Downgrade a more recent version to the version that the GK supports. Modify all protocolIdentifiers to indicate the version that the GK is capable of routing, ignore all unrecognized sequence extension additions, and map all unrecognized choice extension additions to something that the GK can encode.
2. Upgrade an earlier version to the version that the GK supports. Modify all protocolIdentifiers to indicate the version that the GK is capable of routing, and synthesize all sequence extension additions that are missing in the earlier version but present in the version the GK is capable of encoding.

There are a couple of dangers with this, though. When downgrading, one may change the semantics dramatically and unintentionally by replacing an unrecognized choice extension addition with a recognized one. For example, with what could one replace the callIndependentSupplementaryService choice in Setup-UUIE.conferenceGoal? When upgrading, one may not be able to synthesize some components while maintaining the same semantics. Vendor’s will have to look at the components on a case-by-case basis.