Re: The meaning of the reception of a "new" capability set
Paul, Um, the more e-mail I see on this the more painfully 'obvious' it seems to me that the shortened form was probably not the right way to go!!! I'm not sure what to do about that. Maybe as you say we just have to put it down to experience. On the acknowledgement front, we wait for the CLCs to come in. If they don't appear in time we assume it's not going to work. We also planned to keep a list of endpoints that we knew don't work (keying off Vendor ID or whatever field it is). We don't do that at the moment though as we don't have enough information about which EPs support it. Pete ============================================= Pete Cordell pete@tech-know-ware.com ============================================= -----Original Message----- From: Paul Long <plong@SMITHMICRO.COM> To: ITU-SG16@MAILBAG.INTEL.COM <ITU-SG16@MAILBAG.INTEL.COM> Date: 02 November 1999 16:56 Subject: Re: The meaning of the reception of a "new" capability set
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@TECH-KNOW-WARE.COM] Sent: Tuesday, November 02, 1999 5:44 AM To: ITU-SG16@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@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
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@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
Paul,
Um, the more e-mail I see on this the more painfully 'obvious' it seems to me that the shortened form was probably not the right way to go!!! I'm not sure what to do about that. Maybe as you say we just have to put it down to experience.
On the acknowledgement front, we wait for the CLCs to come in. If they don't appear in time we assume it's not going to work. We also planned to keep a list of endpoints that we knew don't work (keying off Vendor ID or whatever field it is). We don't do that at the moment though as we don't have enough information about which EPs support it.
Pete
============================================= Pete Cordell pete@tech-know-ware.com =============================================
-----Original Message----- From: Paul Long <plong@SMITHMICRO.COM> To: ITU-SG16@MAILBAG.INTEL.COM <ITU-SG16@MAILBAG.INTEL.COM> Date: 02 November 1999 16:56 Subject: Re: The meaning of the reception of a "new" capability set
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
Paul and Pete, The text in V3 and the Implementers Guide to be approved in February against V2 has changed the wording relating to the reception of the TCS=0 (I believe this was your contribution, Pete): ``On entering this [transmitter-side pause] state, the endpoint shall stop transmitting on established logical channels, and shall close all logical channels that it previously opened, including bi-directional logical channels.'' That should clarify this one issue, anyway. Paul ----- Original Message ----- From: Pete Cordell <pete@TECH-KNOW-WARE.COM> To: <ITU-SG16@mailbag.cps.intel.com> Sent: Tuesday, November 02, 1999 6:09 PM Subject: Re: The meaning of the reception of a "new" capability set 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@TECH-KNOW-WARE.COM] Sent: Tuesday, November 02, 1999 5:44 AM To: ITU-SG16@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@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
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@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
participants (2)
-
Paul E. Jones -
Pete Cordell