cc:Mail SMTPLINK Undeliverable Message

Mon Oct 13 18:55:52 EDT 1997

Message undeliverable at this time
           Original text follows
>From ITU-SG16 at
X-Envelope-From: ITU-SG16 at
Received: (from mail at localhost) by (8.6.12/8.7.3) id QAA09586; Fri, 10 Oct 1997 16:11:29 -0400
Received: from by woody via smap (V1.3)
        id sma009584; Fri Oct 10 16:11:11 1997
Received: from ( [])
        by (8.8.6/8.8.5) with ESMTP id OAA13919;
        Fri, 10 Oct 1997 14:03:18 -0700 (PDT)
          1.8c) with spool id 142404 for ITU-SG16 at MAILBAG.INTEL.COM; Fri, 10
          Oct 1997 14:03:15 -0700
Received: from ( []) by
 (8.8.6/8.8.5) with ESMTP id OAA13897 for
          <ITU-SG16 at>; Fri, 10 Oct 1997 14:03:13 -0700 (PDT)
Received: from ( [])
          by (8.8.6/8.8.5) with ESMTP id PAA19922 for
          <ITU-SG16 at>; Fri, 10 Oct 1997 15:59:52 -0500
X-Mailer: Mozilla 4.03 [en] (Win95; U)
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Message-ID:  <343E9787.2C343992 at>
Date:         Fri, 10 Oct 1997 14:00:55 -0700
Reply-To: Mailing list for parties associated with ITU-T Study Group 16
              <ITU-SG16 at>
Sender: Mailing list for parties associated with ITU-T Study Group 16
              <ITU-SG16 at>
From: Paul Long <plong at SMITHMICRO.COM>
Organization: Smith Micro Software, Inc.
Subject:      Clarification of H.245 MTSE
To: ITU-SG16 at
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by id OAA13919

(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 t=
he reflector
before the next meeting in Geneva. If you have any problem at all with th=
is 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 modi=
fications allow
an implementation to use the MultiplexEntrySend message as it was intende=
d=97-with multiple
multiplex entries.

1. Introduction

There is a flaw in the H.245 MTSE SDL that precludes sending the Multiple=
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=
MultiplexEntrySend message, they all share the same value in the sequence=
Number field, yet
each out-going MTSE maintains its own, per-entry sequence number in out_S=
Q. 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 cau=
ses 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 fir=
st one. The first
MultiplexEntrySend message may or may not contain multiple entries. The d=
ownside 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 M=
message containing a single entry and the associated time loss, e.g., dur=
ing 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 f=
or determining
what sequence number to use for out-going MultiplexEntrySend messages. Ea=
ch 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 o=
f H.245 because
there is no requirement in the in-coming MTSE that the values of
MultiplexEntrySend.sequenceNumber be contiguous from one message to anoth=
er for a given
MTSE instance. In effect, sequenceNumber is used as a somewhat unique han=
dle for a brief
transaction, not as something that must increase by one each time. The re=
sult is that this
allows all out-going MultiplexEntrySend messages to contain multiple entr=

2. Text Modifications

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

Replace the out_SQ definition in with these two variables a=
nd their

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

This state variable is used to indicate the most recently sent MultiplexE=
ntrySend message
for any MTSE instance. It is incremented by one and assigned to out_SQ be=
fore 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 :=3D out_SQ
+ 1" with this:

global_out_SQ :=3D global_out_SQ + 1
out_SQ :=3D 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