[Robustness] Minutes of the 7/20 call
Attendence (correct me if I missed anyone): Terry Anderson - Lucent Maureen Stillman - Nokia Sasha Ruditsky - Radvision Archana Nehru (and another?) - Trillium
We discussed the 7/11 draft and the following points were made: 10.1 Detecting Failure - KeepAlive - callIdentifier should be optional - for multiplexed channels, CRV should be set to 0 and callIdentifier omitted. - the need for keepAlive in Method B may be unclear
10.2 Transport Address and ... -the new fields are not needed in Alerting and Call Proceeding.
10.3 Sychnronizing State -section is not needed.
11.3.1.4 An old TCP Connection Closure - I may have missed a point in this section. If you raised an issue here, please bring it up again.
ASN.1 changes - RecoveryCallSignalPoint should be SEQUENCE OF SEQUENCE [The current white draft of H.225.0v4 has only SEQUENCE of has SEQUENCE OF RecoveryCallSignalPoint in each message so I believe we do NOT need a change] [I also want to change the name to BackupCallSignalAddress to better match our text]
11.5 - we need a similar SDL for Method B.
12 Method B: State Recovery... - clarify lack of need for KeepAlives
12.3 - detecting failure for case where backup establishes connection to a neighbor that has not yet detected failure.
I also changed all instances of "Fault Tolerant Repository" to "Shared Repository" "element" or "component" to "entity" "IE" or "element" when referring to a part of the ASN.1 structure to "field" to be consistent with the language H.323 and H.225 are trying to move to.
I checked our changes in the white draft of H.225.0v4 and removed all our ASN.1 that has already been incorporated. I now show only changes that are still needed. I have not yet done the similar check with H.323v4.
A new draft, addressing most of the above, is available at:
ftp://standard.pictel.com/avc-site/Incoming/Robustness-AHG/AnnexRdraft0720.doc
We will continue our discussion at our future calls: Thursday: July 27, Aug 3 11:00 EDT (15:00 UT) for 2 hr Phone: 1 888 559 7255 (calling from US) Phone: 1 908 860 0000 (calling from outside US) code: 531480
-- ------------------------------------------------------------ Terry L Anderson mailto:tla@lucent.com Tel:908.582.7013 Fax:908.582.6729 Pager:800.759.8352 pin 1704572 1704572@skytel.com Lucent Technologies/ Voice Over IP Access Networks/ Applications Grp Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla
Terry,
Just one comment -
Terry L Anderson wrote:
I checked our changes in the white draft of H.225.0v4 and removed all our ASN.1 that has already been incorporated. I now show only changes that are still needed. I have not yet done the similar check with H.323v4.
I think we should consider whether to keep these fields in H.225.0 v4 since Annex R is not yet determined. We might want to keep the door open for further refinement of these fields before Annex R is decided. Maybe we should add these in H.225.0 v5, or we could add them between H.323 versions via the new genericData fields.
Regards, Rich
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
Rich Bowen wrote:
Terry,
Just one comment -
Terry L Anderson wrote:
I checked our changes in the white draft of H.225.0v4 and removed all our ASN.1 that has already been incorporated. I now show only changes that are still needed. I have not yet done the similar check with H.323v4.
I think we should consider whether to keep these fields in H.225.0 v4 since Annex R is not yet determined. We might want to keep the door open for further refinement of these fields before Annex R is decided. Maybe we should add these in H.225.0 v5, or we could add them between H.323 versions via the new genericData fields.
The discussion in Osaka was to add them but not be specific about their use ("for further study") which is what you added in the "white". Are you now questioning that?
The problem is one of timing. Annex R is planned for determination in November but would depend on these fields. Annex R's decision would occur much before H.225.0v5. So the intent was to include in v4 those fields we know we need and have the two current Annex R procedures (Method A and Method B) stable for determination in November. We would have some flexibility in describing their usage in the Annex but could not add more fields until v5.
I am reluctant to use "genericData" unless we view that as permanent. Otherwise we end up having to exchange Annex R version numbers to decide where to put data, etc.
Regards, Rich
For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
-- ------------------------------------------------------------ Terry L Anderson mailto:tla@lucent.com Tel:908.582.7013 Fax:908.582.6729 Pager:800.759.8352 pin 1704572 1704572@skytel.com Lucent Technologies/ Voice Over IP Access Networks/ Applications Grp Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla
Terry,
One option that would be reasonable (and we have done this before) is to add those new fields via the Implementers Guide when Annex R is decided.
Paul
----- Original Message ----- From: "Terry L Anderson" tla@LUCENT.COM To: ITU-SG16@mailbag.cps.intel.com Sent: Tuesday, July 25, 2000 11:20 AM Subject: Re: [Robustness] Minutes of the 7/20 call
Rich Bowen wrote:
Terry,
Just one comment -
Terry L Anderson wrote:
I checked our changes in the white draft of H.225.0v4 and removed all our ASN.1 that has already been incorporated. I now show only changes that are still needed. I have not yet done the similar check with H.323v4.
I think we should consider whether to keep these fields in H.225.0 v4 since Annex R is not yet determined. We might want to keep the door open for further refinement of these fields before Annex R is decided. Maybe we should add these in H.225.0 v5, or we could add them between H.323 versions via the new genericData fields.
The discussion in Osaka was to add them but not be specific about their
use
("for further study") which is what you added in the "white". Are you now questioning that?
The problem is one of timing. Annex R is planned for determination in November but would depend on these fields. Annex R's decision would occur much before H.225.0v5. So the intent was to include in v4 those fields we know we need and have the two current Annex R procedures (Method A and Method B) stable for determination in November. We would have some flexibility in describing their usage in the Annex but could not add more fields until v5.
I am reluctant to use "genericData" unless we view that as permanent. Otherwise we end up having to exchange Annex R version numbers to decide where to put data, etc.
Regards, Rich
For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com--
Terry L Anderson mailto:tla@lucent.com Tel:908.582.7013 Fax:908.582.6729 Pager:800.759.8352 pin 1704572 1704572@skytel.com Lucent Technologies/ Voice Over IP Access Networks/ Applications Grp Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
Terry L Anderson wrote:
Rich Bowen wrote:
Terry,
Just one comment -
Terry L Anderson wrote:
I checked our changes in the white draft of H.225.0v4 and removed all our ASN.1 that has already been incorporated. I now show only changes that are still needed. I have not yet done the similar check with H.323v4.
I think we should consider whether to keep these fields in H.225.0 v4 since Annex R is not yet determined. We might want to keep the door open for further refinement of these fields before Annex R is decided. Maybe we should add these in H.225.0 v5, or we could add them between H.323 versions via the new genericData fields.
The discussion in Osaka was to add them but not be specific about their use ("for further study") which is what you added in the "white". Are you now questioning that?
What I'm thinking is that after "further study" we may decide that one or more of these fields are unnecessary or have the incorrect structure. The former useAnnexECallSignalling field is a recent painful reminder that these things happen.
The problem is one of timing. Annex R is planned for determination in November but would depend on these fields. Annex R's decision would occur much before H.225.0v5. So the intent was to include in v4 those fields we know we need and have the two current Annex R procedures (Method A and Method B) stable for determination in November. We would have some flexibility in describing their usage in the Annex but could not add more fields until v5.
I am reluctant to use "genericData" unless we view that as permanent. Otherwise we end up having to exchange Annex R version numbers to decide where to put data, etc.
I'm not aware of any proposal to remove generic features. Another advantage of using generic data is that systems that don't need the robustness features (e.g. simple endpoints) would not have to compile the ASN.1 for them. This exemplifies one of the primary motivations for generic features -- H.225.0 becomes modular so that you only have to include the fundamental signalling structures plus whatever particular features your system needs. Perhaps you could even define the two robustness options as independent generic features if there are likely to be systems that would use one option and not the other.
Regards, Rich
Regards, Rich
For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com--
Terry L Anderson mailto:tla@lucent.com Tel:908.582.7013 Fax:908.582.6729 Pager:800.759.8352 pin 1704572 1704572@skytel.com Lucent Technologies/ Voice Over IP Access Networks/ Applications Grp Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
Ok, Rich. You've convinced me. Let's see how we would do this GenericData.
We had the following fields: supportsRobustnessProcedures NULL OPTIONAL (RRQ, RCF, Setup, Connect)
backupCallSignalAddress SEQUENCE OF BackupCallSignalAddress (or recoveryCallSignalPoint) (Setup, Connect) which is: a SEQENCE OF TransportAddress
hasSharedRepository NULL OPTIONAL (or hasFaultTolerantRepository) (Setup, Connect)
Then we added Status-UUIE and StatusInquiry-UUIE with:
protocolIdentifier ProtocolIdentifier (Status, StatusInquiry) callIdentifier OPTIONAL (Status, StatusInquiry) fastStart SEQUENCE OF OCTET STRING OPTIONAL (Status) includeFastStart BOOLEAN (StatusInquiry) h245Address TransportAddress OPTIONAL (Status)
Let's see if I understand the right way to use the GenericData stuff (Rich or others correct me if I have misunderstood).
I believe that we can get the equivalent of "supportsRobustnessProcedures" by the existence of the GenericData field with our Id. It can be empty in RRQ and RCF where nothing but the NULL OPTIONAL was used and can contain the other necessary fields in Setup and Connect.
I don't think we need protocolIdentifier. It was just added because all UUIE's have it. Using GenericData we will avoid adding UUIEs for Status and StatusInquiry (note that GenericData is not in the UUIE but in the H323-UU-PDU and so available for messages without a UUIE.
[Question: GenericData contains a GenericIdentifier that can be a "standard" (integer), OBJECT IDENTIFIER or a nonStandard. When used at the top H323-UU-PDU level, this would identify the GenericData "package". Does the editor intend to issue "standard" values for widely used GenericData's like ours or is "standard" only intended for the lower level use of GenericIdentifier specifying a particular parameter in the "package", with the top level always being OIDs?]
[note that this is a descriptive structure - not quite compilable ASN.1. We might well define named substructures to make this easier to read.]
So we would have a genericData ::= SEQUENCE { id ::= CHOICE { standard = <our value> -- or oid = <our oid> } parameters ::= SEQUENCE OF SEQUENCE { { -- for hasSharedRepository id ::= CHOICE { id = 1 -- for hasSharedRepository } content ::= CHOICE { bool = <true or false> } } OPTIONAL - used in Setup and Connect entity has a SharedRepository
{ -- for backupCallSignalAddress id ::= CHOICE { id = 2 -- for backupCallSignalAddress } content ::= CHOICE { compound ::= SEQUENCE - this gives us the sequence of backupCallSignalAddress { id ::= CHOICE { id = 1 - this is just a sequence enumerator and since nested I guess can duplicate values used above?? } content ::= CHOICE { compound ::= SEQUENCE - this gives the sequence of Transport Address + ... { id ::= CHOICE { id = 1 - at this level it means the transport address } content ::= CHOICE { ??ok here is the hard part we need to duplicate the structure of a TransportAddress unless folks agree that TransportAddresses are common enough to be added to the CHOICE list This is one disadvantage of the current GenericData approach - it is hard to use structures defined else where in the ASN.1 } } } } -- repeat for more backupCallSignalAddress instances } } OPTIONAL - used in Setup and Connect
{ -- for callIdentifier id ::= CHOICE { id = 3 -- for callIdentifier } content ::= CHOICE { -- here we go again duplicating the CallIdentifier though its not as complex compound ::= SEQUENCE { id := CHOICE { id = 1 -for guid } content ::= CHOICE { raw = <guid-octet-string> } } -- no others needed until ... is expanded } } OPTIONAL -- used optionally in Status and StatusInquiry - omit for multiplexed channels and set CRV=0
{ -- for fastStart id ::= CHOICE { id = 4 -- for fastStart } content ::= CHOICE { compound ::= SEQUENCE -- to allow sequence of octet string { id ::= CHOICE { id = 1 - for first octet string } contents ::= CHOICE { raw = <an octet string> } } -- repeat for more octet strings } } OPTIONAL - used in Status
{ -- for includeFastStart id ::= CHOICE { id = 5 -- for includeFastStart } content ::= CHOICE { bool = <true or false> } } OPTIONAL -- used in StatusInquiry
{ -- for h245Address id ::= CHOICE { id = 6 -- for h245Address } content ::= CHOICE { --again we have to duplicate the structure of a TransportAddress unless this is added as a content type. } } OPTIONAL -- used in Status } } -- wheeoo
We could break this into more than one GenericData but since they share a lot this doesn't gain much. We could separate out the ones used in RRQ,RCF,Setup and Connect from those used in Status and StatusInquiry. These two sets are disjoint. But since everything is optional it may not save much.
?? This is a lot more complex than the previous method without GenericData. Will parsing all this extra depth hurt performance? Is anyone going to get this nesting right? I guess if we publish the ASN.1 in the Annex folks can feed it to their ASN.1 compiler to generate the right stuff.
Robustness group - consider this approach. Reply to this email or we will discuss it at our next call on 8/3.
As Rich pointed out: - we avoid tying down the ASN.1 in November when H.225v2 is approved (later binding) - we package everything together so it can all be omitted by non-robust entities - we can easily use a different top level id to have a different "robustness protocolId", that is, an additional robustness method or new version of an old one.
but - it is nested a bit more deeply in ASN.1 - it is less self documenting (genericData's and their fields are not named by strings, only numberic ids) - we have to duplicate structures already defined elsewhere in H.225's ASN.1 since we cannot directly use it and will have to keep changes in synch.
Rich Bowen wrote:
Terry L Anderson wrote:
Rich Bowen wrote:
Terry,
Just one comment -
Terry L Anderson wrote:
I checked our changes in the white draft of H.225.0v4 and removed all our ASN.1 that has already been incorporated. I now show only changes that are still needed. I have not yet done the similar check with H.323v4.
I think we should consider whether to keep these fields in H.225.0 v4 since Annex R is not yet determined. We might want to keep the door open for further refinement of these fields before Annex R is decided. Maybe we should add these in H.225.0 v5, or we could add them between H.323 versions via the new genericData fields.
The discussion in Osaka was to add them but not be specific about their use ("for further study") which is what you added in the "white". Are you now questioning that?
What I'm thinking is that after "further study" we may decide that one or more of these fields are unnecessary or have the incorrect structure. The former useAnnexECallSignalling field is a recent painful reminder that these things happen.
The problem is one of timing. Annex R is planned for determination in November but would depend on these fields. Annex R's decision would occur much before H.225.0v5. So the intent was to include in v4 those fields we know we need and have the two current Annex R procedures (Method A and Method B) stable for determination in November. We would have some flexibility in describing their usage in the Annex but could not add more fields until v5.
I am reluctant to use "genericData" unless we view that as permanent. Otherwise we end up having to exchange Annex R version numbers to decide where to put data, etc.
I'm not aware of any proposal to remove generic features. Another advantage of using generic data is that systems that don't need the robustness features (e.g. simple endpoints) would not have to compile the ASN.1 for them. This exemplifies one of the primary motivations for generic features -- H.225.0 becomes modular so that you only have to include the fundamental signalling structures plus whatever particular features your system needs. Perhaps you could even define the two robustness options as independent generic features if there are likely to be systems that would use one option and not the other.
Regards, Rich
Regards, Rich
For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com--
Terry L Anderson mailto:tla@lucent.com Tel:908.582.7013 Fax:908.582.6729 Pager:800.759.8352 pin 1704572 1704572@skytel.com Lucent Technologies/ Voice Over IP Access Networks/ Applications Grp Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla
For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
-- ------------------------------------------------------------ Terry L Anderson mailto:tla@lucent.com Tel:908.582.7013 Fax:908.582.6729 Pager:800.759.8352 pin 1704572 1704572@skytel.com Lucent Technologies/ Voice Over IP Access Networks/ Applications Grp Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla
Terry,
I haven't tracked the robustness work, so these comments might be slightly off beam.
But from a genericData point of view, please see my comments below...
----- Original Message ----- From: Terry L Anderson tla@LUCENT.COM To: ITU-SG16@mailbag.cps.intel.com Sent: 28 July 2000 18:51 Subject: Re: [Robustness] GenericData (was:Minutes of the 7/20 call)
Ok, Rich. You've convinced me. Let's see how we would do this
GenericData.
We had the following fields: supportsRobustnessProcedures NULL OPTIONAL (RRQ, RCF, Setup,
Connect)
backupCallSignalAddress SEQUENCE OF BackupCallSignalAddress (or recoveryCallSignalPoint) (Setup, Connect) which is: a SEQENCE OF TransportAddress
We are hoping to add TransportAddress as a data type in content. Een if we are not successful in that, an IPv4 address is fairly easy to represent in OCTET STRINGs etc.
hasSharedRepository NULL OPTIONAL (or hasFaultTolerantRepository)
(Setup,
Connect)
Then we added Status-UUIE and StatusInquiry-UUIE with:
protocolIdentifier ProtocolIdentifier (Status, StatusInquiry) callIdentifier OPTIONAL (Status, StatusInquiry) fastStart SEQUENCE OF OCTET STRING OPTIONAL (Status) includeFastStart BOOLEAN (StatusInquiry) h245Address TransportAddress OPTIONAL (Status)
Let's see if I understand the right way to use the GenericData stuff (Rich
or
others correct me if I have misunderstood).
I believe that we can get the equivalent of "supportsRobustnessProcedures"
by the
existence of the GenericData field with our Id. It can be empty in RRQ
and RCF
where nothing but the NULL OPTIONAL was used and can contain the other
necessary
fields in Setup and Connect.
I don't think we need protocolIdentifier. It was just added because all
UUIE's
have it. Using GenericData we will avoid adding UUIEs for Status and StatusInquiry (note that GenericData is not in the UUIE but in the
H323-UU-PDU
and so available for messages without a UUIE.
If we add ASN.1 for the status and status-enguiry messages, it seems reasonable to give them a basic definition that is compatible with the other messages. i.e. they could easily contain:
protocolIdentifier ProtocolIdentifier (Status, StatusInquiry) callIdentifier OPTIONAL (Status, StatusInquiry) fastStart SEQUENCE OF OCTET STRING OPTIONAL (Status)
and maybe:
h245Address TransportAddress OPTIONAL (Status)
I'm not sure what the following is intended to do, so can't comment on that. Still, being a boolean, it is easy to do as generic data if it is specific to robustness.
includeFastStart BOOLEAN (StatusInquiry)
[Question: GenericData contains a GenericIdentifier that can be a
"standard"
(integer), OBJECT IDENTIFIER or a nonStandard. When used at the top
H323-UU-PDU
level, this would identify the GenericData "package". Does the editor
intend to
issue "standard" values for widely used GenericData's like ours or is
"standard"
only intended for the lower level use of GenericIdentifier specifying a particular parameter in the "package", with the top level always being
OIDs?]
MY intention is that commen packages should use the standard identifier. This is a LOT more efficient on the wire, and a LOT easier to implement in code. (OIDs are a bit of a pain with our purchased compiler.)
[note that this is a descriptive structure - not quite compilable ASN.1.
We
might well define named substructures to make this easier to read.]
So we would have a genericData ::= SEQUENCE { id ::= CHOICE { standard = <our value> -- or oid = <our oid> } parameters ::= SEQUENCE OF SEQUENCE { { -- for hasSharedRepository id ::= CHOICE { id = 1 -- for hasSharedRepository } content ::= CHOICE { bool = <true or false> }
Alternatative emulate the NULL OPTIONAL method where the quantity is TRUE if present and FALSE otherwise.
} OPTIONAL - used in Setup and Connect entity has a
SharedRepository
{ -- for backupCallSignalAddress id ::= CHOICE { id = 2 -- for backupCallSignalAddress } content ::= CHOICE { compound ::= SEQUENCE - this gives us the sequence ofbackupCallSignalAddress { id ::= CHOICE { id = 1 - this is just a sequence enumerator and
since
nested I guess can duplicate values used above?? } content ::= CHOICE { compound ::= SEQUENCE - this gives the sequence of Transport Address + ... { id ::= CHOICE { id = 1 - at this level it means the
transport
address } content ::= CHOICE { ??ok here is the hard part we need to
duplicate
the structure of a TransportAddress unless folks agree that TransportAddresses
are
common enough to be added to the CHOICE list This is one disadvantage of the current GenericData approach - it is hard to use structures defined else where in the ASN.1
Hopefully this will be fixed by adding TransportAddress and AliasAddress to the Content structure.
} } } } -- repeat for more backupCallSignalAddress instances } } OPTIONAL - used in Setup and Connect { -- for callIdentifier id ::= CHOICE { id = 3 -- for callIdentifier } content ::= CHOICE { -- here we go again duplicating the CallIdentifier though
its not
as complex compound ::= SEQUENCE { id := CHOICE { id = 1 -for guid } content ::= CHOICE { raw = <guid-octet-string> } } -- no others needed until ... is expanded } } OPTIONAL -- used optionally in Status and StatusInquiry - omit
for
multiplexed channels and set CRV=0
{ -- for fastStart id ::= CHOICE { id = 4 -- for fastStart } content ::= CHOICE { compound ::= SEQUENCE -- to allow sequence of octet
string
{ id ::= CHOICE { id = 1 - for first octet string } contents ::= CHOICE { raw = <an octet string> } } -- repeat for more octet strings } } OPTIONAL - used in Status
You don't really need to have the extra level of nesting. Just have multiple parameter 4s in the package.
{ -- for includeFastStart id ::= CHOICE { id = 5 -- for includeFastStart } content ::= CHOICE { bool = <true or false> } } OPTIONAL -- used in StatusInquiry { -- for h245Address id ::= CHOICE { id = 6 -- for h245Address } content ::= CHOICE { --again we have to duplicate the structure of a
TransportAddress
unless this is added as a content type. } } OPTIONAL -- used in Status } } -- wheeoo
We could break this into more than one GenericData but since they share a
lot
this doesn't gain much. We could separate out the ones used in
RRQ,RCF,Setup and
Connect from those used in Status and StatusInquiry. These two sets are disjoint. But since everything is optional it may not save much.
The other option is to have a slab of ASN.1 coding into a raw encoded parameter 1 and have done with it. This is really how genericData was expected to be used for complex structures. That's really a decision for the editor.
?? This is a lot more complex than the previous method without
GenericData. Will
parsing all this extra depth hurt performance? Is anyone going to get
this
nesting right? I guess if we publish the ASN.1 in the Annex folks can
feed it to
their ASN.1 compiler to generate the right stuff.
Robustness group - consider this approach. Reply to this email or we will discuss it at our next call on 8/3.
As Rich pointed out: - we avoid tying down the ASN.1 in November when H.225v2 is approved
(later
binding) - we package everything together so it can all be omitted by
non-robust
entities - we can easily use a different top level id to have a different
"robustness
protocolId", that is, an additional robustness method or new version of an
old
one.
but - it is nested a bit more deeply in ASN.1 - it is less self documenting (genericData's and their fields are not
named
by strings, only numberic ids)
On this point, at least everything will be documented together rather than being splatted across a number of parts of the Annex, 323 and 225. I think this makes up slight loss of self documentation (also, I think people have relied on the so called self documentation too much in the past.)
- we have to duplicate structures already defined elsewhere in H.225's
ASN.1
since we cannot directly use it and will have to keep changes in synch.
Rich Bowen wrote:
-- snip --
Pete.
============================================= Pete Cordell Tech-Know-Ware pete@tech-know-ware.com +44 1473 635863 =============================================
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
See comments
Pete Cordell wrote:
Terry,
I haven't tracked the robustness work, so these comments might be slightly off beam.
But from a genericData point of view, please see my comments below...
----- Original Message ----- From: Terry L Anderson tla@LUCENT.COM To: ITU-SG16@mailbag.cps.intel.com Sent: 28 July 2000 18:51 Subject: Re: [Robustness] GenericData (was:Minutes of the 7/20 call)
Ok, Rich. You've convinced me. Let's see how we would do this
GenericData.
We had the following fields: supportsRobustnessProcedures NULL OPTIONAL (RRQ, RCF, Setup,
Connect)
backupCallSignalAddress SEQUENCE OF BackupCallSignalAddress (or recoveryCallSignalPoint) (Setup, Connect) which is: a SEQENCE OF TransportAddress
We are hoping to add TransportAddress as a data type in content. Een if we are not successful in that, an IPv4 address is fairly easy to represent in OCTET STRINGs etc.
Adding TransportAddress would be my choice. The problem is that a TransportAddress is not just an IPv4 address. Even for "ipAddress" it includes a port, but there are also a number of other choices (though less commonly used).
hasSharedRepository NULL OPTIONAL (or hasFaultTolerantRepository)
(Setup,
Connect)
Then we added Status-UUIE and StatusInquiry-UUIE with:
protocolIdentifier ProtocolIdentifier (Status, StatusInquiry) callIdentifier OPTIONAL (Status, StatusInquiry) fastStart SEQUENCE OF OCTET STRING OPTIONAL (Status) includeFastStart BOOLEAN (StatusInquiry) h245Address TransportAddress OPTIONAL (Status)
Let's see if I understand the right way to use the GenericData stuff (Rich
or
others correct me if I have misunderstood).
I believe that we can get the equivalent of "supportsRobustnessProcedures"
by the
existence of the GenericData field with our Id. It can be empty in RRQ
and RCF
where nothing but the NULL OPTIONAL was used and can contain the other
necessary
fields in Setup and Connect.
I don't think we need protocolIdentifier. It was just added because all
UUIE's
have it. Using GenericData we will avoid adding UUIEs for Status and StatusInquiry (note that GenericData is not in the UUIE but in the
H323-UU-PDU
and so available for messages without a UUIE.
If we add ASN.1 for the status and status-enguiry messages, it seems reasonable to give them a basic definition that is compatible with the other messages. i.e. they could easily contain:
protocolIdentifier ProtocolIdentifier (Status, StatusInquiry) callIdentifier OPTIONAL (Status, StatusInquiry) fastStart SEQUENCE OF OCTET STRING OPTIONAL (Status)
and maybe:
h245Address TransportAddress OPTIONAL (Status)
This is what is in the current white draft, but there is a suggestion of removing anything being added for only Robustness and so we would return to Status and StatusInquiry having NO UUIE.
I'm not sure what the following is intended to do, so can't comment on that. Still, being a boolean, it is easy to do as generic data if it is specific to robustness.
includeFastStart BOOLEAN (StatusInquiry)
[Question: GenericData contains a GenericIdentifier that can be a
"standard"
(integer), OBJECT IDENTIFIER or a nonStandard. When used at the top
H323-UU-PDU
level, this would identify the GenericData "package". Does the editor
intend to
issue "standard" values for widely used GenericData's like ours or is
"standard"
only intended for the lower level use of GenericIdentifier specifying a particular parameter in the "package", with the top level always being
OIDs?]
MY intention is that commen packages should use the standard identifier. This is a LOT more efficient on the wire, and a LOT easier to implement in code. (OIDs are a bit of a pain with our purchased compiler.)
[note that this is a descriptive structure - not quite compilable ASN.1.
We
might well define named substructures to make this easier to read.]
So we would have a genericData ::= SEQUENCE { id ::= CHOICE { standard = <our value> -- or oid = <our oid> } parameters ::= SEQUENCE OF SEQUENCE { { -- for hasSharedRepository id ::= CHOICE { id = 1 -- for hasSharedRepository } content ::= CHOICE { bool = <true or false> }
Alternatative emulate the NULL OPTIONAL method where the quantity is TRUE if present and FALSE otherwise.
Unfortunately since False cannot be prohibited in the ASN.1 BOOLEAN gives us a tri-valued field. Even if only True/False or True/omit is intended one needs to state what the recipient should do if the other value is received.
} OPTIONAL - used in Setup and Connect entity has aSharedRepository
{ -- for backupCallSignalAddress id ::= CHOICE { id = 2 -- for backupCallSignalAddress } content ::= CHOICE { compound ::= SEQUENCE - this gives us the sequence ofbackupCallSignalAddress { id ::= CHOICE { id = 1 - this is just a sequence enumerator and
since
nested I guess can duplicate values used above?? } content ::= CHOICE { compound ::= SEQUENCE - this gives the sequence of Transport Address + ... { id ::= CHOICE { id = 1 - at this level it means the
transport
address } content ::= CHOICE { ??ok here is the hard part we need to
duplicate
the structure of a TransportAddress unless folks agree that TransportAddresses
are
common enough to be added to the CHOICE list This is one disadvantage of the current GenericData approach - it is hard to use structures defined else where in the ASN.1
Hopefully this will be fixed by adding TransportAddress and AliasAddress to the Content structure.
} } } } -- repeat for more backupCallSignalAddress instances } } OPTIONAL - used in Setup and Connect { -- for callIdentifier id ::= CHOICE { id = 3 -- for callIdentifier } content ::= CHOICE { -- here we go again duplicating the CallIdentifier thoughits not
as complex compound ::= SEQUENCE { id := CHOICE { id = 1 -for guid } content ::= CHOICE { raw = <guid-octet-string> } } -- no others needed until ... is expanded } } OPTIONAL -- used optionally in Status and StatusInquiry - omit
for
multiplexed channels and set CRV=0
{ -- for fastStart id ::= CHOICE { id = 4 -- for fastStart } content ::= CHOICE { compound ::= SEQUENCE -- to allow sequence of octetstring
{ id ::= CHOICE { id = 1 - for first octet string } contents ::= CHOICE { raw = <an octet string> } } -- repeat for more octet strings } } OPTIONAL - used in StatusYou don't really need to have the extra level of nesting. Just have multiple parameter 4s in the package.
{ -- for includeFastStart id ::= CHOICE { id = 5 -- for includeFastStart } content ::= CHOICE { bool = <true or false> } } OPTIONAL -- used in StatusInquiry { -- for h245Address id ::= CHOICE { id = 6 -- for h245Address } content ::= CHOICE { --again we have to duplicate the structure of aTransportAddress
unless this is added as a content type. } } OPTIONAL -- used in Status } } -- wheeoo
We could break this into more than one GenericData but since they share a
lot
this doesn't gain much. We could separate out the ones used in
RRQ,RCF,Setup and
Connect from those used in Status and StatusInquiry. These two sets are disjoint. But since everything is optional it may not save much.
The other option is to have a slab of ASN.1 coding into a raw encoded parameter 1 and have done with it. This is really how genericData was expected to be used for complex structures. That's really a decision for the editor.
I guess that is essentially what gets done in some of the cryptoToken options, but our stack folks hate this. It requires calling the ASN.1 encoder twice (once to encode the "slab", then insert into message and encode again). With some stack interfaces this is hard and at a minimum it costs more time. BUT it is the most flexible, allowing any structure defined in another message to be included in GenericData. (this is one of the disadvantages of ASN.1 encoding in my view).
?? This is a lot more complex than the previous method without
GenericData. Will
parsing all this extra depth hurt performance? Is anyone going to get
this
nesting right? I guess if we publish the ASN.1 in the Annex folks can
feed it to
their ASN.1 compiler to generate the right stuff.
Robustness group - consider this approach. Reply to this email or we will discuss it at our next call on 8/3.
As Rich pointed out: - we avoid tying down the ASN.1 in November when H.225v2 is approved
(later
binding) - we package everything together so it can all be omitted by
non-robust
entities - we can easily use a different top level id to have a different
"robustness
protocolId", that is, an additional robustness method or new version of an
old
one.
but - it is nested a bit more deeply in ASN.1 - it is less self documenting (genericData's and their fields are not
named
by strings, only numberic ids)
On this point, at least everything will be documented together rather than being splatted across a number of parts of the Annex, 323 and 225. I think this makes up slight loss of self documentation (also, I think people have relied on the so called self documentation too much in the past.)
I agree. It may even be that the specifications on how to use GenericData for a specific feature can use named structures, e.g., BackupCallSignalAddress defined as an instance of EnumeratedParameter.
- we have to duplicate structures already defined elsewhere in H.225'sASN.1
since we cannot directly use it and will have to keep changes in synch.
Rich Bowen wrote:
-- snip --
Thanks for the comments.
Pete.
============================================= Pete Cordell Tech-Know-Ware pete@tech-know-ware.com
+44 1473 635863
For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
-- ------------------------------------------------------------ Terry L Anderson mailto:tla@lucent.com Tel:908.582.7013 Fax:908.582.6729 Pager:800.759.8352 pin 1704572 1704572@skytel.com Lucent Technologies/ Voice Over IP Access Networks/ Applications Grp Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla
participants (4)
-
Paul E. Jones -
Pete Cordell -
Rich Bowen -
Terry L Anderson