Packetizer

Clarification of H.245 MTSE (Q51)


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

This note proposes backward-compatible modifications to the H.245 Multiplex Table Signaling Entity (MTSE) in order to fix an apparent oversight. These modifications allow an implementation to use the MultiplexEntrySend message as it was intended--with multiple multiplex entries. (For editorial reasons, this was not adopted, but since it is compatible with the existing MTSE, an implementor would be safe in using this approach. At least two vendors independently arrived at the same solution, so it has been proven in interoperability tests many times over.)

1. Introduction

There is a flaw in the H.245 MTSE SDL that precludes sending the MultiplexEntrySend message with multiple entries if there are any entries in common between it and any of the preceeding MultiplexEntrySend messages. When multiple entries are sent in a MultiplexEntrySend message, they all share the same value in the sequenceNumber field, yet each out-going MTSE maintains its own, per-entry sequence number in out_SQ. Therefore, only those entries whose MTSE coincidentally have the same value for out_SQ can be combined in a subsequent MultiplexEntrySend message. The trouble this causes during implementation has resulted in some vendors deciding to not send multiple entries in a MultiplexEntrySend message.

2. Solutions

There are two solutions to this problem.

2.1 Avoid multiple entries

Never send multiple entries in a MultiplexEntrySend message after the first one. The first MultiplexEntrySend message may or may not contain multiple entries. The downside is that one is not using the MultiplexEntrySend message as it was intended to be used, thus wasting a small amount of bandwidth due to duplicated overhead for each MultiplexEntrySend message containing a single entry and the associated time loss, e.g., during session startup, as the sender waits for responses to each request.

2.2 Use a common sequence-number variable

Have all of the out-going MTSEs share a single sequence-number variable for determining what sequence number to use for out-going MultiplexEntrySend messages. Each MTSE continues to use its existing, MTSE-specific sequence-number variable for recording the sequence number used in the MultiplexEntrySend message. This is so that responses can be identified as belonging to the same dialogue as the MultiplexEntrySend request.

This is backwards compatible with the MTSE defined in previous versions of H.245 because there is no requirement in the in-coming MTSE that the values of MultiplexEntrySend.sequenceNumber be contiguous from one message to another for a given MTSE instance. In effect, sequenceNumber is used as a somewhat unique handle for a brief transaction, not as something that must increase by one each time. The result is that this allows all out-going MultiplexEntrySend messages to contain multiple entries.

3. Text Modifications

Here are the required text modifications for the second, common-sequence-number-variable solution.

Replace the out_SQ definition in 8.7.3.2/H.245 with these two variables and their descriptions.

Replace the contents of the task symbol in Figure 28(i)/H.245 containing "out_SQ := out_SQ + 1" with this:

4. Proposal

That the text modifications described above be applied to H.245 version 3 to allow all MultiplexEntrySend messages to contain multiple multiplex entries.