Network Object Reference

All exchange resources can be referenced either by directory numbers, or “physical numbers”. This is a challenge for the data protocol, as directory numbers can vary in size, and some resources have physical addresses with multiple parts. The NET_OBJ_REF is a “variant record” which has a header with byte count plus a type field. The rest of the information is then according to the type field and length. The total length can vary from 1 to 16 bytes.

NOTE:  AlphaCom 08.00 have a fixed size internally of 6 bytes for NET_OBJ_REF fields!

Format

<header> <contents….>

Where:

• <header> UINT1 defines both the length and the format:
  • <length> 4 bits. The length of the representation not including the first byte itself.
  • <format> 4 bits. The format of the representation. See the table below.
• <contents> See the table below.

The following table identifies the data types used in the application data of the AlphaNet Data Protocol:

Format<br\> number	Format name<br\>Object layout / Description
Format 0	NRF_DIGIT_STRING / NRF_GLOBAL_DIRNO Represent digits to be dialed. The interpretation is up to the receiving exchange, and the string may be an incomplete dir.no, a complete dir.no, or a dir.no followed by additional parameters.<br\> <br\><header> <digit string….><br\> <br\>  <digit string>: This format has 0 to 15 bytes of BCD­coded digits. That means that digit strings up to 30 digits may be represented in this format (Max 10 in AMC 08.00).<br\>- Unused nibbles must be set to 15 (0xF / INVALID_DIGIT). <br\>- The extended digits 10-14 (0xA-0xE) are allowed in the format, but not yet supported by AlphaCom. TouchLine MPC may support them to some extent. <br\>- Only 0 or 1 padding nibble will be needed for any digit string, but extra padding bytes (0xFF) may be added if desired to simplify formatting. <br\> The string may either be a directory number as dialed from a station, possibly including an area code for accessing another node, or any other kind of digit string representing phone numbers, dates, etc. <br\> <br\>Example: Hex { 20 10 7F } is digit string “107”.<br\>NULL value : Hex { 00 } A zero­length string.
Format 1	(reserved)
Format 2	NRF_LOCAL_DIRNO <br\>Represents a complete directory number in an exchange.<br\> <br\><header> <node> <digit string….><br\> <br\> <node>: UINT1. The node number specifies in which node the directory number is valid.<br\> - Value 0 (LOCAL_NODE) can be used when one wants to specify the local node, but does not know its node number.<br\> - The value 255 can be used either as an NULL/INVALID value or to signify broadcast. <digit string>: This format has 0 to 14 bytes of BCD­coded digits. See format 0 for details.<br\> <br\> Example: Hex { 32 02 10 2F } is node 2, directory number ``102’’<br\>NULL value: Hex { 12 00 }.
Format 3	NRF_LOCAL_ENTITY <br\>Refer to an intercom object with the internal binary identification.<br\> <br\><header> <node> <entity class> <internal id> [<entity sub­class>]<br\> <br\><node> UINT1 <br\><entity class> UINT1 <br\>What class of intercom object it is referred to. See table below.<br\><internal id> 1­-13 bytes binary. (individ) number.<br\>Only 2 byte (UINT2/SINT2) values are currently supported. <br\><entity sub­-class> UINT1 (Optional)<br\>Omitted unless use of the subclass information is described explicitly for the given message. Provides a more detailed Sub­Classing within the given Entity Class when needed. <br\>- Which of the different subclassing schemes is used for a given message parameter is mentioned in the message parameter description if any subclassing is used at all. <br\>- The value 0 is reserved for internal use and should not be used in a data protocol message. The literals below refer to the AlphaCom/7.2x implementation. Not all classes are useful in the currently defined messages. The valid ranges may differ between exchange types and even SW versions. <br\> <br\>Example: Hex { 43 05 06 00 01 } means node 5, audio program 1<br\>NULL: Hex { 43 00 00 00 00 }<br\>
Format 4	NRF_PHYS_ADDR Refer to an intercom object by physical hardware address. The address is unique within a network of interconnected exchanges.<br\> <br\> <header> <node> <device> <board> <interface number> <interface type> <br\> <br\><node> UINT1 The node number specifies in which node the description is valid. <br\><device> UINT1 Device Number. <br\><board> UINT1 Board Number/Position. Only position 1...26 are supported by HW.<br\><interface number> UINT1 Interface/Entity Individ Number.<br\>Which individ within the given board and type. Individs are by default numbered from 1. Example:<br\>Interface 1--16 on an AGA board, 1 – 32 on AE1, 1 – 6 on ASLT. <br\><interface type> UINT1 Interface/Address Type. <br\>Used for interface/address types not default or implicitly defined by context. <br\>- This field is originally intended for use when there are different types of interfaces/resources on the same board type, like for example a(n imaginary) new board type with both subscriber line interfaces and program feeds on it. <br\>- Type value 0 is reserved for internal use and should not be used externally. Type values 224­255 has been reserved for full Unit Addresses in case this low­level internal addressing will be needed on ACDP some time in the future. <br\> <br\>How many of these fields (from the start) one includes defines the class of physical address: <br\>1 field: Physical Exchange (Node) Address <br\>2 fields: Physical Device Address<br\>3 fields: Physical Board Address. <br\>4 fields: Physical Resource Address (with implicit resource address type). <br\>5 fields: Physical Resource Address with explicit resource address type. No application identified yet. 4 fields is preferred over 5 wherever both are possible. 4 fields will therefore also be used for one of the resource address types (the default / most­used one) in contexts where more than one type can be referred. <br\> <br\>Example: Hex { 44 05 41 09 02 } means node 5, exchange device, board 9, ASLT port 2<br\> <br\>NULL: Hex { 14 00 }
5..14	(reserved)
Format 15	INVALID_NRF <br\>This signifies an invalid value, used internally in a system. Not allowed in a DP message.<br\> <br\><header><br\> <br\>The length field is allowed to be anything but should normally be 0 (1 byte total).<br\>Example: { 0x0F }.<br\>NULL­value: the proper value in a valid format should be used instead.

Entity Classes

Used when referring to an intercom object with internal binary (“physical”) identification.

Type	Name	Value	Null	Comments
0	INVALID_ECL
1	ECL_ABSENT	1-30	0
2	ECL_ANNOUNCEMENT	1-9	0
3	ECL_FEATURE	1-82	255
4	ECL_MAIL	1-32<BR\>see below	0	Call Request may be responsed by<br\>ECL_MAIL_PRIO
5	ECL_ST_GROUP	1-50	0
6	ECL_PROGRAM	1-38	0
7	ECL_PROG_CONF	1-50	0
8	ECL_STATION	1-552	0
9	ECL_USER	1-600	0
10	ECL_MAIL_PRIO	0-511		Values 0-255 represents normal call requests.<br\>Values > 256 represents alternative text call requests, with priority = value - 256.by<br\>ECL_MAIL_PRIO
11	ECL_FEAT_CONN	1-82	255
12	ECL_NODE	0/1 254	255
13	ECL_GLOB_NUMBER
14	ECL_GLOB_GROUP	1-50	0
15	ECL_O_DUPL_CONF	1-20	0
16	ECL_BOARD	1-255<br\>1-26(63)	0<br\>64	Value is UINT2: MSB is device addr LSB is board addr.
17	ECL_DEVICE	1-255	0
18	ECL_AUDIO_RING	1-24	0
19	ECL_AUDIO_LINK	1-138	0
20	ECL_DP_LINK	0-7	255
21-255	--reserved for future use--

Entity Subclasses

Used when very specific information is given, e.g. during error reporting. Subclasses are defined so that they can be used also for future exchange types working in AlphaNet.

<Hege: Sett inn tabell her>

• Different Schemes should use non­overlapping value sets as long as there are enough available values --- Except for the NULL value that is shared by all schemes.
• NULL is represented by missing Entity SubClass field in NET_OBJ_REF value. The value 0 is reserved for representing this value in separate subclass variables internally in software.