Clarification of H.245 MTSE

[Paul Long]

(I just 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 solution.

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

out_SQ
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.

global_out_SQ
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.

[end]


--
Paul Long___________________________http://www.cmpu.net/public/plong
Smith Micro Software, Inc.__________http://www.smithmicro.com/