H.323 Mobility Ad Hoc Group Activity Report

Roy, Radhika R, ALARC rrroy at ATT.COM
Tue Nov 2 12:19:15 EST 1999


Pete,

This is how the delta concept is described:

B.2.2.1/H.245v5: "At the start, no table entries are defined. When a
CapabilityTableEntry is received, it replaces the previously received
CapabilityTableEntry with the same CapabilityTableEntryNumber. A
CapabilityTableEntry without a Capability may be used to remove the
previously received CapabilityTableEntry with the same
CapabilityTableEntryNumber."

I think this passage makes it clear that TCS is a "delta" mechanism,
although it does not use this or a similar term.

By the way, due to the apparently inadvertent use of "should" rather than
"shall" in the normative text of v2 and v3, the crucial step of closing
channels upon receipt of an empty cap set is not mandatory. 8.4.6/H.323v3:
"If media stream or data logical channels were previously opened by the
endpoint, they should be closed." Is v4 our earliest possible opportunity to
make this mandatory? At that point, there will be three meanings of an empty
cap set.

I agree with your team that the initiating EP should have been required to
explicitly remove all receive caps in the remote EP. Having the meaning of
an empty cap set change from one version to another is asking for trouble,
trouble that we are already seeing. Also, having a special rule for the
empty cap set is bad design. This is analogous to having a special, or
reserved, value for a field, e.g., "9/9/99". :-} Pick up any book on
software or database design, and it will mention this issue.

Regarding the use of RequestMode, since we were adding a fair amount of
normative text for pause anyway, we could have just as easily said that a
RequestMode containing a null mode _shall_ be accepted, regardless of
whether the EP is in receipt of a multipointModeCommand. This would have
used the existing mechanism in H.245 for doing this, required less normative
text, and been clearer, IMO, than to introduce the new concept of "empty cap
set."

Also, if we had used RequestMode, we would know whether the remote EP was
actually going to close all the channels. Many (all?) v2 EPs on the market
now do not support pause, but they all accept an empty TCS. This effectively
makes pause useless because it is not dependably supported--the initiating
EP does not have positive feedback as to whether the remote EP is actually
going to pause--even though it is required.

BTW, I'm not blaming you or anyone else for this. I just hope that we learn
from our mistakes.

Paul Long
Smith Micro Software, Inc.

-----Original Message-----
From: Pete Cordell [mailto:pete at TECH-KNOW-WARE.COM]
Sent: Tuesday, November 02, 1999 5:44 AM
To: ITU-SG16 at MAILBAG.INTEL.COM
Subject: Re: The meaning of the reception of a "new" capability set


I think H.245 covers the delta aspects, although it goes on more about
how
to add caps and how to delete caps rather than explicitly saying that
the
caps are a delta.

The definition of an empty cap set is defined in the revised text in the
"Third party pause..." section.  Basically its only seqNum and
protocolIdentifier.  I think the team I'm working with would have
preferred
to have an empty cap set as one that explicitly removed all the existing
caps.  Even if you don't know about empty cap sets, as long as you can
re-cap, you get 90% of the functionality this way.  That was the
originally
intended method when the text said something like "a cap set that
indicates
that there are no more receive caps".  (It seemed obvious to me what it
was!!!)  However, it became clear that this wasn't clear to everybody
and
hence consensus from the list moved to the revised text which adopts the
other definition.  The 'initial' method is also much more complex to
explain, which I felt could also lead to interoperability issues.  (Even
if
you don't like the method chosen, you will probably prefer it to the
other
solution we came up with which was for an endpoint to accept both
methods!!!)

And another note, you only have to comply with RequestMode when under
control of an MC.  Without an MC it's optional.  We assumed that that
would
be a big enough excuse for implementors not to implement anything to do
with
RequestMode!

Pete

=============================================
Pete Cordell
pete at tech-know-ware.com
=============================================

-----Original Message-----
From: frank.derks at PHILIPS.COM <frank.derks at PHILIPS.COM>
To: ITU-SG16 at MAILBAG.INTEL.COM <ITU-SG16 at MAILBAG.INTEL.COM>
Date: 02 November 1999 09:16
Subject: Re: The meaning of the reception of a "new" capability set


>Hi Paul,
>
>thanks for the reply. Is there any work going on to more clearly
describe
that "delta" is the desired behaviour? The next question that this
brings
is: "what is an "empty CS", because I can see several ways of achieving
this. Again I do not see a clear
>specification on what an empty CS looks like.
>
>I fully agree with your statement about the third-party initiated pause
and
re-routing, but at the moment it is the only "lightweight" method of
achieving certain behaviours that would otherwise require H.450.
>
>Frank
>
>
>
>
>
>Mailing list for parties associated with ITU-T Study Group 16
<ITU-SG16 at MAILBAG.INTEL.COM> on 01/11/99 17:29:54
>Please respond to Mailing list for parties associated with ITU-T Study
Group 16 <ITU-SG16 at MAILBAG.INTEL.COM> @ SMTP
>To:     ITU-SG16 <ITU-SG16 at MAILBAG.INTEL.COM> @ SMTP
>cc:
>Subject:        Re: The meaning of the reception of a "new" capability
set
>Classification: Restricted
>Ilya,
>
>No, no, no!!! :-) Each TCS message is a _delta_ to be applied to the
remote
>EP's current capability set stored in the EP. This issue was discussed
a
few
>months ago on the reflector. My reply follows my signature.
>
>BTW, the pause feature added to H.323v2 redefines the meaning of an
empty
>TCS. In H.323v1, an empty TCS causes no change to the current cap
set--a
>NO-OP, so to speak. As of v2, however, an empty TCS means close all
outgoing
>channels, assume that the remote EP has no receive or transmit caps
(flush
>the current capapbility set for the remote EP), and upon receipt of the
next
>presumably non-empty TCS, re-open outgoing channels based on the
possibly
>new set of receive caps. From what I've heard, though, many if not all
v2
>EPs still exhibit v1 behavior in this regard. I doubt whether "pause"
will
>ever be a dependable feature. IMO, overloading a message like this is
just
>asking for trouble. The same thing could have been better accomplished
with
>RequestMode.
>
>Paul Long
>Smith Micro Software, Inc.
>
>
>>>>>>>>>> My reply from July 1, 1999
>Ramana, Chris, et al.:
>
>An incoming terminalCapabilitySet message _modifies_ the current
capability
>set in the receiving EP. The entire set is not necessarily transmitted
>within every message. This has been true since H.245v1. In fact, H.245
says
>that one should not transmit unchanged capabilities. One starts out
with an
>empty set of descriptors. Incoming descriptors replace any extant ones
with
>the same descriptor number. If one does not already exist with the same
>number, this adds a new descriptor; if one does exist, the new one
replaces
>the old one; if the new descriptor does not contain
>simultaneousCapabilities, this removes any existing descriptor for the
given
>number. (This is the same scheme used to modify the capability table.)
Here
>is an illustrative chronological scenario:
>
>        Current capability set:
>        <empty>
>
>Incoming termCapSet 1
>0: {{H.261qcif},{G.711}}
>1: {{H.261cif},{G.711}}
>
>        Current capability set:
>        0: {{H.261qcif},{G.711}}
>        1: {{H.261cif},{G.711}}
>
>Incoming termCapSet 2
>1: {}
>
>        Current capability set:
>        0: {{H.261qcif},{G.711}}
>
>Incoming termCapSet 3
>1: {{H.261cif},{G.711}}
>2: {{H.263sqcif&qcif&cif},{G.723,G.711}}
>
>        Current capability set:
>        0: {{H.261qcif},{G.711}}
>        1: {{H.261cif},{G.711}}
>        2: {{H.263sqcif&qcif&cif},{G.723,G.711}}
>
>Incoming termCapSet 4
>1: {}
>0: {{H.261qcif&cif},{G.723.1,G.711)}
>
>        Current capability set:
>        0: {{H.261qcif&cif},{G.723.1,G.711)}
>        2: {{H.263sqcif&qcif&cif},{G.723,G.711}}
>
>Paul Long
>Smith Micro Software, Inc.
><<<<<<<<<
>
>-----Original Message-----
>From: Ilya Freytsis [mailto:IFREYTSIS at VIDEOSERVER.COM]
>Sent: Monday, November 01, 1999 8:57 AM
>To: ITU-SG16 at MAILBAG.INTEL.COM
>Subject: Re: The meaning of the reception of a "new" capability set
>
>
>I believe every new capability set should be treated as a complete
>replacement for the previously received one.  Otherwise conferencing
>servers
>(MCS) and Gateways will not be able exercise enough control over the
>media
>modes of the multipoint conferences and gateway sessions.
>
>Ilya Freytsis
>
>
>                -----Original Message-----
>                From:   frank.derks at PHILIPS.COM
>[mailto:frank.derks at PHILIPS.COM]
>                Sent:   Monday, November 01, 1999 8:31 AM
>                To:     ITU-SG16 at mailbag.cps.intel.com
>                Subject:        The meaning of the reception of a "new"
>capability set
>
>                Neither H.323 nor H.245 are too clear about what it
>means
>when an endpoint receives another set of capabilities after having
>already
>received one. In previous E-mail messages on this list, I have read
that
>capability sets are cumulative, i.e. anything
>                "new" received in a TCS message adds to the
capabilities
>transmitted in a previous TCS message. I have, however, found nothing
in
>the
>recommendations that backs this up.
>
>                So what is the intended procedure? Does a newly
received
>set
>of capabilities replace the previously received set? Do capabilities
>received in a TCS message add to the already received capabilities? How
>are
>capabilities removed? What constitutes an "empty
>                capability set" etc.
>
>                I would appreciate it if somebody could point me in the
>right direction.
>
>                Regards,
>
>                Frank
>



More information about the sg16-avd mailing list