[Robustness] GenericData (was:Minutes of the 7/20 call)
Terry L Anderson
tla at LUCENT.COM
Fri Jul 28 13:51:39 EDT 2000
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 at mailbag.intel.com
> >
> > --
> > ------------------------------------------------------------
> > Terry L Anderson mailto:tla at lucent.com
> > Tel:908.582.7013 Fax:908.582.6729
> > Pager:800.759.8352 pin 1704572 1704572 at 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 at mailbag.intel.com
--
------------------------------------------------------------
Terry L Anderson mailto:tla at lucent.com
Tel:908.582.7013 Fax:908.582.6729
Pager:800.759.8352 pin 1704572 1704572 at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tla.vcf
Type: text/x-vcard
Size: 548 bytes
Desc: Card for Terry L Anderson
URL: <https://lists.packetizer.com/pipermail/sg16-avd/attachments/20000728/f624575b/attachment-0004.vcf>
More information about the sg16-avd
mailing list