Re: [Robustness] GenericData (was:Minutes of the 7/20 call)

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 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

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