Network Object Reference

In the AlphaNet Data Protocol 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.

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

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.

NET_OBJ_REF: 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\>Mail message number	0	Call Request may be responsed by 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.
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--

NET_OBJ_REF: 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.

Scheme	Entity Subclass		Description
generic	NULL<br\>1 - 255<br\>0	INVALID_ESC<br\>---reserved for future use---<br\>---reserved for internal use---	Unspecified SubClass / Not Applicable<br\> <br\>---illegal in NET_OBJ_REF value---
interface<br\>types	NULL<br\>1<br\>2<br\>3<br\>	ESC_ANY_IF<br\>ESC_TL_ABCD_IF<br\>ESC_ANALOG_PHONE_IF<br\>ESC_AUDIO_0DB_IF	Unspecified Interface Type<br\>TouchLine ABCD Station Interface <br\>Interface to Plain Old Analog Telephone <br\>4(2) wire 0dB Analog Audio Interface	<br\>(e.g. ASLT)<br\>(e.g. ATLB)<br\>(e.g. AGA)

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