cc:Mail SMTPLINK Undeliverable Message
Bob_Bean at MULTILINK.COM
Bob_Bean at MULTILINK.COM
Mon Oct 13 18:55:52 EDT 1997
Message undeliverable at this time
Original text follows
-----------------------------------------
>From ITU-SG16 at mailbag.jf.intel.com
X-Envelope-From: ITU-SG16 at mailbag.jf.intel.com
Received: (from mail at localhost) by woody.multilink.com (8.6.12/8.7.3) id QAA09586; Fri, 10 Oct 1997 16:11:29 -0400
Received: from mailbag.jf.intel.com(134.134.248.7) by woody via smap (V1.3)
id sma009584; Fri Oct 10 16:11:11 1997
Received: from mailbag.jf.intel.com (mailbag.jf.intel.com [134.134.248.7])
by mailbag.jf.intel.com (8.8.6/8.8.5) with ESMTP id OAA13919;
Fri, 10 Oct 1997 14:03:18 -0700 (PDT)
Received: from MAILBAG.INTEL.COM by MAILBAG.INTEL.COM (LISTSERV-TCP/IP release
1.8c) with spool id 142404 for ITU-SG16 at MAILBAG.INTEL.COM; Fri, 10
Oct 1997 14:03:15 -0700
Received: from axp.cmpu.net (axp.cmpu.net [204.96.11.17]) by
mailbag.jf.intel.com (8.8.6/8.8.5) with ESMTP id OAA13897 for
<ITU-SG16 at mailbag.jf.intel.com>; Fri, 10 Oct 1997 14:03:13 -0700 (PDT)
Received: from smithmicro.com (C1123-111.dialup.autonet.net [206.88.153.111])
by axp.cmpu.net (8.8.6/8.8.5) with ESMTP id PAA19922 for
<ITU-SG16 at mailbag.jf.intel.com>; 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 smithmicro.com>
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 mailbag.jf.intel.com>
Sender: Mailing list for parties associated with ITU-T Study Group 16
<ITU-SG16 at mailbag.jf.intel.com>
From: Paul Long <plong at SMITHMICRO.COM>
Organization: Smith Micro Software, Inc.
Subject: Clarification of H.245 MTSE
To: ITU-SG16 at mailbag.jf.intel.com
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by mailbag.jf.intel.com 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=
xEntrySend
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 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=
ultiplexEntrySend
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=
ies.
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 a=
nd their
descriptions.
out_SQ
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=
quenceNumber
field before transmission of a MultiplexEntrySend message.
global_out_SQ
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.
[end]
--
Paul Long___________________________http://www.cmpu.net/public/plong
Smith Micro Software, Inc.__________http://www.smithmicro.com/
More information about the sg16-avd
mailing list