Clarification of H.245 MTSE

Paul Long plong at SMITHMICRO.COM
Fri Oct 10 17:00:55 EDT 1997

(I posted this to the sg16.lbc reflector, but Tom Geary suggested that I also post it
here. Sorry for the cross-posting. I believe this only affects H.324, so all you H.323, et
al., people can continue with whatever you were doing. :-) )

Here is the text for a proposal I submitted back in Portland and that was supposed to have
been discussed in Sunriver. Since it wasn't, we need to discuss this on the reflector
before the next meeting in Geneva. If you have any problem at all with this proposed "fix"
to the MTSE, please speak up now.

This contribution 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.

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.

2. Text Modifications

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

Replace the out_SQ definition in with these two variables and their

This state variable is used to indicate the most recently sent MultiplexEntrySend message
for this MTSE instance. It is mapped to the MultiplexEntrySend message sequenceNumber
field before transmission of a MultiplexEntrySend message.

This state variable is used to indicate the most recently sent MultiplexEntrySend message
for any MTSE instance. It is incremented by one and assigned to out_SQ before out_SQ is
mapped to the MultiplexEntrySend message sequenceNumber field. Arithmetic performed on
global_out_SQ is module 256.

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

global_out_SQ := global_out_SQ + 1
out_SQ := global_out_SQ

3. Proposal

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


Paul Long___________________________
Smith Micro Software, Inc.__________

More information about the sg16-avd mailing list