Pete,
I am having difficulty with what it is that you are trying to convey. Let me try to summarise:
- An empty CS is transmitted "as a TCS message" containing only a sequence number and a protocol identifier.
- The effect of receiving such a message does not effect the stored caps of the sending EP at the receiving EP
- You (and the team you're working with) would have liked the effect to have been that all caps are removed.
I do not think that I understand your statement on "Re-cap" providing 90% of the functionality in the case that you do not understand empty CSs, could you elaborate on that?
Frank
Mailing list for parties associated with ITU-T Study Group 16 <ITU-SG16@MAILBAG.INTEL.COM> on 02/11/99 13:05:18
Please respond to Mailing list for parties associated with ITU-T Study Group 16 <ITU-SG16@MAILBAG.INTEL.COM> @ SMTP
To: ITU-SG16 <ITU-SG16@MAILBAG.INTEL.COM> @ SMTP
cc:
Subject: Re: The meaning of the reception of a "new" capability set
Classification: Restricted
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@tech-know-ware.com
=============================================
-----Original Message-----
From: frank.derks@PHILIPS.COM <frank.derks@PHILIPS.COM>
To: ITU-SG16@MAILBAG.INTEL.COM <ITU-SG16@MAILBAG.INTEL.COM>
Date: 02 November 1999 09:16
Subject: Re: The meaning of the reception of a "new" capability set
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@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@MAILBAG.INTEL.COM> @ SMTP
To: ITU-SG16 <ITU-SG16@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@VIDEOSERVER.COM]
Sent: Monday, November 01, 1999 8:57 AM
To: ITU-SG16@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@PHILIPS.COM
[mailto:frank.derks@PHILIPS.COM]
Sent: Monday, November 01, 1999 8:31 AM
To: ITU-SG16@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
frank.derks＠PHILIPS.COM