(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/