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