Packetizer

Signaling Temporal/Spatial Tradeoff in H.245 (Q63)


The information in this article applies to: H.245, H.323, H.324

This article describes the proper use of the video capability, temporalSpatialTradeOffCapability, and the videoTemporalSpatialTradeOff command and indication messages.

1. Introduction

As implementations of H.324 terminals mature and vendors move past core and required functionality and on to optional features, one feature in particular, signaling video temporal/spatial tradeoff in H.245, has been--and continues to be--the cause of a fair amount of confusion and interoperability problems for H.324 terminals. It is also anticipated that vendors of H.323 terminals will experience the same confusion. This document describes, in one place, the requirements imposed on an H.324 and H.323 endpoint with respect to signaling temporal/spatial tradeoff.

Because opening an H.324 bi-directional video logical channel is slightly more complex in this regard than opening an H.323 uni-directional video logical channel, there is a special section devoted to it. The other sections apply to both systems.

2. Signaling Temporal/Spatial Tradeoff

This section describes how temporal/spatial tradeoff is signaled in H.245. It starts out by warning about a trap into which implementors can easily fall. Note that an endpoint is typically, but not necessarily, a receiver and transmitter of video signals simultaneously, so the "sender" and "receiver" roles, described below, typically apply to the same endpoint.

2.1 The Trap

The component, temporalSpatialTradeOffCapability, of the H261VideoCapability and H263VideoCapability H.245 ASN.1 types, has no meaning when used in a TerminalCapabilitySet message. This is because, first of all, it is a capability of the transmitter of a video signal, not the receiver. It therefore has no meaning when used as a receive capability.

Second, like other capabilities, when used as a transmit capability, it indicates that a transmitter is capable of supporting temporal/spatial tradeoff but not that it necessarily will. As such, the transmit capabilities are just intended to provide a menu to the remote terminal for future mode requests, but since support for temporal/spatial tradeoff cannot be requested by a RequestMode message, there is no reason to indicate support for it in transmit capabilities. Therefore, it has no meaning when used in any capacity in a TerminalCapabilitySet message, and do not assume that just because an endpoint indicates support for temporal/spatial tradeoff in its transmit capabilities that it will send videoTemporalSpatialTradeOff indications or otherwise respond to any videoTemporalSpatialTradeOff commands that are sent to it.

2.2 Common Salvation

This section applies to both H.324 and H.323. Because video is transmitted on a uni-directional logical channel in H.323, this section is sufficient to describe how to use video temporal/spatial tradeoff in H.323 systems. H.324, however, transmits video on a bi-directional logical channel, so the section that follows this one is necessary to explain the additional requirements imposed on an H.324 system.

The only use for the temporalSpatialTradeOffCapability component is in an OpenLogicalChannel request. In the forwardLogicalChannelParameters.dataType component, it informs the receiver that the sender supports video temporal/spatial tradeoff for this forward logical channel.

Other than parsing incoming videoTemporalSpatialTradeOff indications, there are no H.245 requirements imposed on the receiver, although the receiver may want to indicate the current tradeoff value to the user in some way. There is, therefore, no reason for a receiver to reject an open request based solely on the value of this component. However, if a transmitter indicates support for temporal/spatial tradeoff in the forwardLogicalChannelParameters of its OpenLogicalChannel request and the receiver sends back an OpenLogicalChannelAck response, the transmitter shall, upon receipt of the response, send a videoTemporalSpatialTradeOff indication containing its initial tradeoff value. This is so that the receiver can subsequently modify the sender's tradeoff, relative to the initial value, with the videoTemporalSpatialTradeOff command.

Once the logical channel is open and the initial videoTemporalSpatialTradeOff indication has been sent, the transmitter of the video signal shall send the videoTemporalSpatialTradeOff indication whenever its tradeoff value changes, caused by one of two types of events. One is when the transmitter receives a videoTemporalSpatialTradeOff command. It shall respond by sending a videoTemporalSpatialTradeOff indication containing its current tradeoff value, which has typically changed as a result of the command. Note that the value in the indication may be different than the value in the command. Reasons include a difference in granularity or a difference in range. For example, the transmitter may only support the values 0, 10, 20, and 31, or the range 1 through 18, respectively. The other event is when the tradeoff value has changed due to some local cause such as the user adjusting the value through the system's user interface. In this case, the transmitter sends a videoTemporalSpatialTradeOff indication containing its current tradeoff value as a result of the local change.

2.3 H.324-specific requirements

Unlike the OpenLogicalChannel request used by H.323 for video uni-directional logical channels, the request used by H.324 for opening video bi-directional logical channels specifies the temporalSpatialTradeOffCapability in both the forward and reverse directions--in the forwardLogicalChannelParameters.dataType and reverseLogicalChannelParameters.dataType components, respectively. The semantics of temporalSpatialTradeOffCapability used in forwardLogicalChannelParameters.dataType is described in the previous section. The semantics for its presence in the reverse direction is described in this section.

Whereas temporalSpatialTradeOffCapability in the forward direction informs the receiver that the sender supports video temporal/spatial tradeoff, in the reverse direction it requests that the receiver of the OpenLogicalChannel message support video temporal/spatial tradeoff for the reverse logical channel. If the receiver cannot or simply chooses not to support video temporal/spatial tradeoff for the reverse logical channel (its out-going logical channel), it must respond by sending an OpenLogicalChannelReject message back to the sender with cause equal to unsuitableReverseParameters. The receiver must then initiate another open request with the contents of the forward and reverse logical channel parameters in the OpenLogicalChannel request switched and the now forward parameters set to something more to its liking, i.e., with forwardLogicalChannelParameters.dataType.temporalSpatialTradeOffCapability set to FALSE. Since the reverse parameters were originally sent by the sender as its forward parameters, the receiver is (reasonably) assured that the sender will not reject this new open request.

Let us reiterate that even if an H.324 endpoint does not support video temporal/spatial tradeoff at all--as a matter of fact, especially if it does not--it is required to check the value of the temporalSpatialTradeOffCapability component in the reverseLogicalChannelParameters.dataType component of the OpenLogicalChannel message. If set to TRUE, the endpoint must reject the open request since it does not support this feature and initiate another open dialogue, as described above.