|
|
| (173 intermediate revisions by 13 users not shown) |
| Line 1: |
Line 1: |
| | + | {{AI}} |
| | {| align="right" | | {| align="right" |
| | | __TOC__ | | | __TOC__ |
| | |} | | |} |
| − | = Introduction =
| + | The '''AlphaNet Data Protocol''' (ACDP protocol) is used for: |
| | + | * Data communication between ICX-AlphaCom servers in AlphaNet |
| | + | * Data communication between ICX-AlphaCom and External Devices such as [[RIO]]s and PC based Control Handlers |
| | + | * Advanced internal control of the ICX-AlphaCom. [[Event Handler]] can use DP messages as general [[Event Handler#Action Commands|Action Commands]]. |
| | | | |
| − | == General ==
| |
| − | The AlphaCom/AlphaNet Data Protocol (ACDP protocol) is used for communication in an AlphaCom Network that may comprise several AlphaCom and [[TouchLine]] exchanges. The ACDP protocol is also used between the AlphaCom exchange and external devices, such as [[RIO|Remote I/O]] boxes, PC based Control Handler systems etc.
| |
| − | The Data Protocol is made generally available from software version AMC 06.00. Previous AMC softwares are NOT compatible with this protocol document.
| |
| − | === Word list ===
| |
| − | The following concepts are commonly used in the document:
| |
| − | * '''Module:''' One AlphaCom “card cage”, contains up to 26 circuit boards (such as [[ASLT]], [[AMC]], [[APC]], [[AGA]]).
| |
| − | * '''Exchange:''' Up to 4 AlphaCom modules interconnected in a master/slave ([[MultiModule]]) configuration. One of the modules plays the role as a master, while the other modules are slaves. Communication with the world outside (if other devices are connected) is via the master.
| |
| − | * '''Node:''' The address of an Exchange. If several exchanges are interconnected (via the AlphaCom Data Protocol), then each exchange will have a unique node number.
| |
| − | * '''Device:''' Examples of device types are AlphaCom module, RIO, AlphaPro, Control Handler. All such devices have a unique device address when interconnected. The AlphaCom and AlphaPro have fixed device address, while the device address of e.g. a RIO is configured (inside the RIO) for the particular application.
| |
| | | | |
| − | == AlphaCom / AlphaNet protocol == | + | === Protocol properties === |
| − | Protocol properties: | + | * '''Binary format''' for speed. Readable ASCII hex format can be used as an alternative for easier debugging |
| − | * '''Binary format''' for speed. Readable ASCII hex format can be used as an alternative for easier debugging. | + | * The '''[[physical layer]]''' of the protocol is RS485, RS422 or RS232. In AlphaCom E the protocol can also be encapsulated in TCP/IP. |
| − | * '''[[Data link layer]]s''' with message checksum for reliability, and with acknowledgment and re-transmission of erroneous messages. | + | * '''[[Data link layer]]s''' with message checksum for reliability, and with acknowledgment and re-transmission of erroneous messages |
| − | * '''Network layer''' for routability when several exchanges are connected. | + | * '''[[Network layer]]''' for routability when several exchanges are connected |
| | * '''Variable length fields''' and optional fields so that the protocol can be used also in future systems with different requirements regarding number of digits in addresses, station numbers etc. | | * '''Variable length fields''' and optional fields so that the protocol can be used also in future systems with different requirements regarding number of digits in addresses, station numbers etc. |
| − | * A systematic way of '''addressing exchange resources''' both as directory numbers and physical addresses. | + | * A systematic way of '''addressing exchange resources''' both as directory numbers and physical addresses |
| − | * '''Addressed messages'''. Commands are addressed to a specific device, and response is returned to the device issuing the command only. In addition, there is a few status broadcast messages. | + | * '''Addressed messages'''. Commands are addressed to a specific [[device]], and response is returned to the device issuing the command only. In addition, there is a few status [[Broadcast messages (ACDP) |broadcast messages]] |
| − | * Addressed messages can be '''routed in a network'''. The input and output messages have identical frame format, and thus can be sent via transit exchanges. The same protocol is used both to control a single exchange, and as the AlphaNet protocol. | + | * Addressed messages can be '''routed in a network'''. The input and output messages have identical frame format, and thus can be sent via transit exchanges. The same protocol is used both to control a single exchange, and as the AlphaNet protocol<br> |
| | | | |
| | === Message example === | | === Message example === |
| | Here is a HEX coded example of a message with network layer header and application data. This is basically what you send to the exchange in the “simple link layer” format. | | Here is a HEX coded example of a message with network layer header and application data. This is basically what you send to the exchange in the “simple link layer” format. |
| | We assume that you use exchange node 01, the PC is device 01, and that there is a station 107 and 102. | | We assume that you use exchange node 01, the PC is device 01, and that there is a station 107 and 102. |
| − | The message DIAL_DIGITS looks like this, with spaces between fields for clarity only: | + | The message [[DIAL_DIGITS]] looks like this, with spaces between fields for clarity only: |
| | | | |
| | Network Application Application Message | | Network Application Application Message |
| − | <u>layer header</u> <u>header </u> <u>parameters _</u> | + | <u>layer header</u> <u>header </u> <u>parameters </u> |
| | <u>0101</u> <u>0141</u> <u>01</u> <u>41</u> <u>1234</u> <u>0050</u> <u>3201107F</u> <u>20102F</u> | | <u>0101</u> <u>0141</u> <u>01</u> <u>41</u> <u>1234</u> <u>0050</u> <u>3201107F</u> <u>20102F</u> |
| | Src Dest Hop Cl Ref Msg P1 P2 | | Src Dest Hop Cl Ref Msg P1 P2 |
| | <u>dev </u> <u>dev </u> <u>cn</u>t <u>ss</u> <u> </u> <u>id </u> <u>Station </u> <u>Digits</u> to dial | | <u>dev </u> <u>dev </u> <u>cn</u>t <u>ss</u> <u> </u> <u>id </u> <u>Station </u> <u>Digits</u> to dial |
| | | | |
| | + | === Message Formats === |
| | + | * [[Message Formats - Grouped by Function]] |
| | + | * [[Message Formats (Sortable)]] |
| | + | * [[Explanation of message format]] |
| | | | |
| | | | |
| − | = Important terms of the data protocol =
| + | [[Category:Protocols]] |
| − | | + | [[Category:ACDP messages]] |
| − | == Nodes - Devices ==
| |
| − | | |
| − | == Access to AlphaCom resources ==
| |
| − | | |
| − | === Directory numbers vs. features ===
| |
| − | | |
| − | === Directory numbers, users and stations ===
| |
| − | | |
| − | = Protocol Layers 1 to 3 =
| |
| − | | |
| − | == Physical Layer ==
| |
| − | | |
| − | == Data Link Layer ==
| |
| − | | |
| − | == Network Layer ==
| |
| − | | |
| − | === Message Format ===
| |
| − | | |
| − | === Handling of Broadcast messages ===
| |
| − | | |
| − | ==== Sequence numbers ====
| |
| − | | |
| − | ==== Alternative Routing Effect ====
| |
| − | | |
| − | = Application Layer =
| |
| − | | |
| − | == Application Data ==
| |
| − | | |
| − | === AlphaCom class messages ===
| |
| − | | |
| − | === TouchLine class messages ===
| |
| − | | |
| − | === SNMP-Like class messages ===
| |
| − | | |
| − | === Site specific (engineering use) class messages ===
| |
| − | | |
| − | == Data Types ==
| |
| − | | |
| − | === Data type: Network_Object_Reference ===
| |
| − | | |
| − | = Message Formats - Grouped by Function =
| |
| − | | |
| − | == Common notes ==
| |
| − | | |
| − | {{stub}}
| |
| − | * '''NET_OBJ_REF parameters''': Where an entity class is given (Example: {ECL_ABSENT}), the parameter must be either a LOCAL_ENTITY format reference of the correct class or a directory number that maps to an entity of the correct class, or a Null value, if allowed.
| |
| − | :Except: ECL_USER and ECL_STATION can be used interchangeably, and will be converted to the other type when needed. As a side effect of this, the returned directory number reference for a ECL_STATION type object may be different from the one in the command message, or even invalid, if the directory number or user reference in the command message is not the one of the default user of the station.
| |
| − | * NET_OBJ_REF parameters are by default output in the '''LOCAL_DIRNO''' format by AlphaCom and TouchLine. Exceptions are noted in each case.
| |
| − | * For the reason above and other reasons, NET_OBJ_REF parameters in command messages can not be relied upon to match the corresponding NET_OBJ_REF parameters in response messages. If one need to sort responses of the same message type from each other, the message reference field in the application header should be used.
| |
| − | :Explanation of table format, explanations are in italic font:
| |
| − | | |
| − | | |
| − | * Over time, more parameters will be added to existing messages. These parameters are often marked “(optional)”, and the AMC version which introduced them is shown to the right in the explanation of each parameter.
| |
| − | :- Note that it’s the exchange that processes the DP message that adds default values when it creates an internal representation of the message. If you send a “short” message to a remote node in AlphaNet, all default fields will be filled in in that exchange. Example: SEND_MAIL without A station name will get the name from the same dir.no in the remote exchange (if existing). See comment under Simple Link Layer, page 70.
| |
| − | * In general, NULL is not allowed as NET_OBJ_REF parameter.
| |
| − | :It’s described explicitly when it can be used, e.g. to switch call forwarding OFF. Hint: Some DP messages works correctly only if you leave the NET_OBJ_REF parameter out, rather than supplying an explicit NULL field.
| |
| − | * Note that all messages may cause the response message ILLEGAL_PARAM, indicating that the exchange has problems recognizing either the message number, or a parameter value of a message. In these cases the documented response message will NOT be returned.
| |
| − | :- ILLEGAL_PARAM refers to the problem parameter using a number from 1 and up. This is the number you will find in to the left of each parameter in the table.
| |
| − | :- In AlphaNet, if you get an ILLEGAL_PARAM from a remote node indicating that an optional parameter is required, remember that the AMC versions indicated for optional parameters refers to the receiving node, not the local node generating the message.
| |
| − | * Some messages may seem to have too few parameters. Keep in mind that:
| |
| − | :- the network layer header contains node and device address for both a source and a destination
| |
| − | :- the reference field is always identical in a “command” and the returned “response”.
| |
| − | * '''AlphaNet:''' To control a station in a network you must address the DP message to that station’s node. Messages are in general ONLY routed according to the network layer header. If you send a message to an exchange, and use a node number as part of the (A) Subscriber field which is different from the addressed node, the command will be ignored or cause an error response. The messages which deviates from this rule is documented explicitly!
| |
| − | | |
| − | == Station Connect Operations ==
| |
| − | | |
| − | | |
| − | {| border="1"
| |
| − | ! style="background:#ffdead;" width="170" |Message
| |
| − | ! style="background:#ffdead;" width="650" |Description
| |
| − | |-
| |
| − | | [[CALL_SETUP]] || Sets up a coversation between two users
| |
| − | |-
| |
| − | | [[CONN_REQUEST]] || Sets up a coversation between two users
| |
| − | |-
| |
| − | | [[CONN_REFERENCE]] || Positive response from the exchange to CONN_REQUEST
| |
| − | |-
| |
| − | | [[CONN_REF_ACK]] || The external application acknowledges the CONN_REFERENCE
| |
| − | |-
| |
| − | | [[STATION_BUSY]] || Negative response to CONN_REQUEST
| |
| − | |-
| |
| − | | [[RESOURCE_BUSY]] || Negative response to CONN_REQUEST
| |
| − | |-
| |
| − | | [[NO_ACCESS]] || Negative response to CONN_REQUEST
| |
| − | |-
| |
| − | | [[STATION_DOWN]] || Negative response to CONN_REQUEST
| |
| − | |-
| |
| − | | [[DISCON_ST]] || Disconnect station from ongoing feature
| |
| − | |-
| |
| − | | [[DISC_REQ]] || Conversation established with CONN_REQUEST: The external application disconnects a conversation.
| |
| − | |-
| |
| − | | [[DISC_REQ_ACK]] || Conversation established with CONN_REQUEST: The AlphaCom acknowledges the DISC_REQ message
| |
| − | |-
| |
| − | | [[DISCONNECTED]] || Conversation established with CONN_REQUEST: Conversation was disconnected, e.g. the user pressed C-key
| |
| − | |-
| |
| − | | [[DISCONNECTED_ACK]] || Conversation established with CONN_REQUEST: Acknowledge of the DISCONNECTED message
| |
| − | |-
| |
| − | | [[CALL_STATUS_BC]] || Broadcast message telling the status of a call
| |
| − | |-
| |
| − | | [[CONN_STATUS_BC]] || Broadcast message telling that a connection is established
| |
| − | |-
| |
| − | | [[DISCON_STATUS_BC]] || Broadcast message telling that a connection is disconnected
| |
| − | |-
| |
| − | | [[PARK_INQ_BROKER]] || Park station from conversation, enter Inquiry call state
| |
| − | |-
| |
| − | | [[UNPARK]] || Unpark station from Inquiry call state station, return to conversation
| |
| − | |-
| |
| − | | [[REQ_TRANSF_CALL]] || Transfer call in an Inquiry Call situation.
| |
| − | |-
| |
| − | |}
| |
| − | | |
| − | <br>
| |
| − | <br>
| |
| − | | |
| − | == Station Keyboard & Display emulation ==
| |
| − | Note that the exchange remembers the M-key state and the handset state forever (it’s not “cleared” e.g. by conversation cancel).
| |
| − | | |
| − | {| border="1"
| |
| − | ! style="background:#ffdead;" width="170" |Message
| |
| − | ! style="background:#ffdead;" width="650" |Description
| |
| − | |-
| |
| − | | [[DIAL_DIGITS]] || Simulate digit dialing from a station
| |
| − | |-
| |
| − | | [[DIAL_DAK]] || Dial DAK on a station
| |
| − | |-
| |
| − | | [[SINGLE_DIGIT]] || Dial one digit on a station
| |
| − | |-
| |
| − | | [[DIGIT_RELEASE]] || The station has released a digit press
| |
| − | |-
| |
| − | | [[M_KEY]] || Order station to press M-key
| |
| − | |-
| |
| − | | [[M_KEY_RELEASE]] || Order station to release M-key
| |
| − | |-
| |
| − | | [[HANDSET_OFF]] || Order station to lift handset
| |
| − | |-
| |
| − | | [[HANDSET_ON]] || Order station to replace handset
| |
| − | |-
| |
| − | | [[C_KEY]] || Order station to press C-key
| |
| − | |-
| |
| − | | [[DISPLAY_TEXT]] || Send text and control characters to a station
| |
| − | |-
| |
| − | | [[ST_BUSY_BC]] || Broadcast message: Intercom station is busy
| |
| − | |-
| |
| − | | [[ST_FREE_BC]] || Broadcast message: Intercom station is free
| |
| − | |-
| |
| − | |}
| |
| − | | |
| − | <br>
| |
| − | <br>
| |
| − | | |
| − | == Station Features and Status ==
| |
| − | | |
| − | {| border="1"
| |
| − | ! style="background:#ffdead;" width="170" |Message
| |
| − | ! style="background:#ffdead;" width="650" |Description
| |
| − | |-
| |
| − | | [[PROGRAM]] || Set audio program for single station or a predefined group of stations
| |
| − | |-
| |
| − | | [[PROGRAM_ACK]] || Positive response to PROGRAM
| |
| − | |-
| |
| − | | [[PROGRAM_NAK]] || Negative response to PROGRAM
| |
| − | |-
| |
| − | | [[PROG_CONF]] || Set Simplex conference for predefined group of stations or a single station
| |
| − | |-
| |
| − | | [[PROG_CONF_ACK]] || Positive response to PROG_CONF
| |
| − | |-
| |
| − | | [[PROG_CONF_NAK]] || Negative response to PROG_CONF
| |
| − | |-
| |
| − | | [[CONF_TALK]] || Set Simplex conference speaker
| |
| − | |-
| |
| − | | [[CONF_TALK_STOP]] || Stop station form feeding Simplex conference
| |
| − | |-
| |
| − | | [[AUDIO_DETECT]] || Triggers the event Simplex_Conference_Audio
| |
| − | |-
| |
| − | | [[O_DUPL_CONF]] || Include/exclude a station or a group into/from an Open Duplex Conference
| |
| − | |-
| |
| − | | [[OD_CONF_ENTERED]] || The participant has entered an Open Duplex Conference
| |
| − | |-
| |
| − | | [[OD_CONF_LEAVE]] || The participant has left the Open Duplex Conference
| |
| − | |-
| |
| − | | [[ALARM_MSG]] || Set up (or disconnect) an ASVP Alarm message to a single station or a predefined group of stations
| |
| − | |-
| |
| − | | [[ALARM_MSG_ACK]] || Positive response to ALARM_MSG
| |
| − | |-
| |
| − | | [[ST_GROUP_DISCON]] || Switch off Group Call audio at a station that receives Group Call audio at the moment
| |
| − | |-
| |
| − | | [[SET_CALL_REQ_MODE]] || Turn on/off message “your call is registered, please wait”, then ringing/flashing at a station
| |
| − | |-
| |
| − | | [[CALL_TRANSFER]] || Set or remove call transfer for a station
| |
| − | |-
| |
| − | | [[CALL_TRANSFER_OK]] || Positive response to CALL_TRANSFER
| |
| − | |-
| |
| − | | [[CALL_TRANSFER_NOK]] || Negative response to CALL_TRANSFER
| |
| − | |-
| |
| − | | [[SET_REQ_TRANSF]] || Set transfer of Call Request for an intercom station
| |
| − | |-
| |
| − | | [[GET_REQ_TRANSF]] || Get the Call Request Transfer status for an intercom station
| |
| − | |-
| |
| − | | [[REQ_TRANSF]] || Response to the SET_REQ_TRANSF and GET_REQ_TRANSF messages
| |
| − | |-
| |
| − | | [[SET_ABSENCE]] || Set absence status for an intercom station
| |
| − | |-
| |
| − | | [[GET_ABSENCE]] || Get absence status for an intercom station
| |
| − | |-
| |
| − | | [[ABSENCE_STATUS]] || Response to SET_ABSENCE and GET_ABSENCE messages
| |
| − | |-
| |
| − | | [[WAKE_UP]] || Register or remove wakeup request
| |
| − | |-
| |
| − | | [[WAKE_UP_ACK]] || Positive response to WAKE_UP
| |
| − | |-
| |
| − | | [[WAKE_UP_NAK]] || Negative response to WAKE_UP
| |
| − | |-
| |
| − | | [[SET_GRP_FILT]] || Set group call filter for a station
| |
| − | |-
| |
| − | | [[GROUP_MEMBERSHIP]] || Set group membership in NVRAM for a station
| |
| − | |-
| |
| − | | [[EXT_FEATURE_BC]] || Broadcast message when a directory number (feature 50) is dialed on a station
| |
| − | |-
| |
| − | | [[SET_STATION_COS]] || Set COS membership in NVRAM for a station
| |
| − | |-
| |
| − | | [[MODIFY_COS_CONTENTS]] || Modify feature membership in COS in NVRAM
| |
| − | |-
| |
| − | |}
| |
| − | | |
| − | <br>
| |
| − | <br>
| |
| − | | |
| − | == Station Mail Operations ==
| |
| − | | |
| − | {| border="1"
| |
| − | ! style="background:#ffdead;" width="170" |Message
| |
| − | ! style="background:#ffdead;" width="650" |Description
| |
| − | |-
| |
| − | | [[SEND_MAIL]] || Send a mail message to an intercom station
| |
| − | |-
| |
| − | | [[SEND_TXT_MAIL]] || Send a mail message with free text to an intercom station
| |
| − | |-
| |
| − | | [[SEND_MAIL_ACK]] || Response to the SEND_MAIL and SEND_TEXT_MAIL messages
| |
| − | |-
| |
| − | | [[CANCEL_MAIL]] || Delete one or more mail/call request/alarm messages queued at a station
| |
| − | |-
| |
| − | | [[SET_MAIL_TIMEOUT]] || Set the timer of a mail queue entry
| |
| − | |-
| |
| − | | [[COPY_MAIL]] || Send a copy of a mail in own queue to a new destination (station or group)
| |
| − | |-
| |
| − | | [[MAILQ_NAVIG]] || Do operation on mail queue, or step current mail in mail queue
| |
| − | |-
| |
| − | | [[DELETE_MAIL]] || Delete a mail entry in the queue for an intercom station
| |
| − | |-
| |
| − | | [[DELETE_MAIL_ACK]] || Response to the DELETE_MAIL message
| |
| − | |-
| |
| − | | [[GET_FIRST_MAIL]] || Get the first mail entry in the queue for an intercom station
| |
| − | |-
| |
| − | | [[GET_LAST_MAIL]] || Get the last mail entry in the queue for an intercom station
| |
| − | |-
| |
| − | | [[GET_NEXT_MAIL]] || Get the next mail entry in the queue for an intercom station
| |
| − | |-
| |
| − | | [[GET_PREV_MAIL]] || Get the previous mail entry in the queue for an intercom station
| |
| − | |-
| |
| − | | [[GET_THIS_MAIL]] || Get the identified mail entry in the queue for an intercom station
| |
| − | |-
| |
| − | | [[EXT_MAIL]] || Response to the GET_x_MAIL messages
| |
| − | |-
| |
| − | | [[Q_ELEM_ADDED]] || Broadcast message. Reports that a mail message has been added to a station’s mail queue
| |
| − | |-
| |
| − | | [[Q_ELEM_REMOVED]] || Broadcast message. Reports that a mail message has been removed from a station’s mail queue
| |
| − | |-
| |
| − | |}
| |
| − | | |
| − | <br>
| |
| − | <br>
| |
| − | | |
| − | == General Exchange Control ==
| |
| − | | |
| − | {| border="1"
| |
| − | ! style="background:#ffdead;" width="170" |Message
| |
| − | ! style="background:#ffdead;" width="650" |Description
| |
| − | |-
| |
| − | | [[SET_SYSTEM_TIME]] || Set the internal clock to the given date and time
| |
| − | |-
| |
| − | | [[GET_SYSTEM_TIME]] || Ask a device (AlphaCom) for date and time
| |
| − | |-
| |
| − | | [[SYSTEM_TIME]] || Response to the GET_SYSTEM_TIME and SET_SYSTEM_TIME message
| |
| − | |-
| |
| − | | [[PUT_STRING]] || Output String to Exchange serial port after adding appropriate framing depending on selected port
| |
| − | |-
| |
| − | | [[LOG_STRING]] || Output String to System Log
| |
| − | |-
| |
| − | | [[EXECUTE_COMMAND]] || Send a command string to the exchange to be executed there
| |
| − | |-
| |
| − | | [[EVENT_REPORT]] || Report an event to the event/action system
| |
| − | |-
| |
| − | | [[SET_TIMER]] || Start or stop a timer
| |
| − | |-
| |
| − | | [[WRITE_USER_DEF_DATA]] || Write User Defined Data (UDD)
| |
| − | |-
| |
| − | | [[SET_DIRNO_TXT]] || Change the display text of a directory number (station or feature)
| |
| − | |-
| |
| − | | [[NAME_EXTENSION]] || Special exchange mode using two line names: Send the second line through AlphaNet
| |
| − | |-
| |
| − | | [[SNV]] || Update specific system settings (NVRAM) values
| |
| − | |-
| |
| − | | [[STATUS_REPORT]] || Report equipment Presence and Error/OK status
| |
| − | |-
| |
| − | | [[COMMAND_RESPONSE]] || General response message to messages
| |
| − | |-
| |
| − | | [[ILLEGAL_PARAM]] || Negative response
| |
| − | |-
| |
| − | | [[DPMT_INVALID]] || Reserved value for internal use
| |
| − | |-
| |
| − | | [[DUMMY]] || Test message: Should be routed, accepted and ignored
| |
| − | |-
| |
| − | |}
| |
| − | | |
| − | <br>
| |
| − | <br>
| |
| − | | |
| − | == Device Control and Status ==
| |
| − | | |
| − | {| border="1"
| |
| − | ! style="background:#ffdead;" width="170" |Message
| |
| − | ! style="background:#ffdead;" width="650" |Description
| |
| − | |-
| |
| − | | [[RESET_TAKEN]] || A device reports that it has done an internal reset
| |
| − | |-
| |
| − | | [[RESET_DEVICE]] || Reset a device
| |
| − | |-
| |
| − | | [[GET_DEVICE]] || Get information from an external device
| |
| − | |-
| |
| − | | [[DEVICE_INFO]] || Response to the GET_DEVICE message
| |
| − | |-
| |
| − | | [[PING]] || Test device: “Are you there?”
| |
| − | |-
| |
| − | | [[PONG]] || Response to the PING message. “Yes, I’m here.”
| |
| − | |-
| |
| − | |}
| |
| − | | |
| − | <br>
| |
| − | <br>
| |
| − | | |
| − | == Remote Control ==
| |
| − | {| border="1"
| |
| − | ! style="background:#ffdead;" width="170" |Message
| |
| − | ! style="background:#ffdead;" width="650" |Description
| |
| − | |-
| |
| − | | [[RESET_TAKEN]] || A device reports that it has done an internal reset
| |
| − | |-
| |
| − | | [[RESET_DEVICE]] || Reset a device
| |
| − | |-
| |
| − | | [[GET_DEVICE]] || Get information from an external device
| |
| − | |-
| |
| − | | [[DEVICE_INFO]] || Response to the GET_DEVICE message
| |
| − | |-
| |
| − | | [[PING]] || Test device: “Are you there?”
| |
| − | |-
| |
| − | | [[PONG]] || Response to the PING message. “Yes, I’m here.”
| |
| − | |-
| |
| − | |}
| |
| − | | |
| − | <br>
| |
| − | <br>
| |
| − | | |
| − | | |
| − | === RIO Protocol ===
| |
| − | | |
| − | There are a number of messages for RIO control. The message sequences, timing and error procedures are described in a separate document.
| |
| − | Note that all inputs or outputs “owned” by the exchange can NOT be controlled in parallel by an external computer. Responses are always returned to the device that controls a pin.
| |
| − | | |
| − | | |
| − | {| border="1"
| |
| − | ! style="background:#ffdead;" width="170" |Message
| |
| − | ! style="background:#ffdead;" width="650" |Description
| |
| − | |-
| |
| − | | [[GET_PIN_COUNTS]] || Query a RIO about number of output and input pins and support for non mandatory features
| |
| − | |-
| |
| − | | [[PIN_COUNTS]] || Response to the GET_PIN_COUNTS message
| |
| − | |-
| |
| − | | [[SET_RCO]] || Turn the given remote control output on
| |
| − | |-
| |
| − | | [[SET_RCO_OK]] || Positive response to the SET_RCO message
| |
| − | |-
| |
| − | | [[SET_RCO_FAILED]] || Negative response to the SET_RCO message
| |
| − | |-
| |
| − | | [[CLEAR_RCO]] || Turn the given remote control output off
| |
| − | |-
| |
| − | | [[CLEAR_RCO_OK]] || Positive response to the CLEAR_RCO message
| |
| − | |-
| |
| − | | [[CLEAR_RCO_FAILED]] || Negative response to the CLEAR_RCO message
| |
| − | |-
| |
| − | | [[PULSE_RCO]] || Generate a pulse with the defined length
| |
| − | |-
| |
| − | | [[PULSE_RCO_OK]] || Positive response to the PULSE_RCO message
| |
| − | |-
| |
| − | | [[PULSE_RCO_FAILED]] || Negative response to the PULSE_RCO message
| |
| − | |-
| |
| − | | [[POLL_RCI]] || Poll the given remote control input once
| |
| − | |-
| |
| − | | [[SCAN_RCI_ONCE]] || Scan input until defined condition is met, then report to exchange
| |
| − | |-
| |
| − | | [[SCAN_RCI_ACK]] || Positive response to the SCAN_RCI_ONCE message
| |
| − | |-
| |
| − | | [[RCI_IS_ON]] || Response to the POLL_RCI and SCAN_RCI_ONCE messages, input pin is on
| |
| − | |-
| |
| − | | [[RCI_IS_OFF]] || Response to the POLL_RCI and SCAN_RCI_ONCE messages, input pin is off
| |
| − | |-
| |
| − | | [[SCAN_END_ACK]] || Acknowledgment to the RCI_IS_OFF and RCI_IS_ON messages
| |
| − | |-
| |
| − | |}
| |
| − | | |
| − | <br>
| |
| − | <br>
| |
| − | | |
| − | == AlphaNet ==
| |
| − | This is messages related to audio control between exchanges.
| |
| − | AlphaNet also uses other messages like station emulation, mails, and system maintenance.
| |
| − | | |
| − | | |
| − | {| border="1"
| |
| − | ! style="background:#ffdead;" width="170" |Message
| |
| − | ! style="background:#ffdead;" width="650" |Description
| |
| − | |-
| |
| − | | [[AUDIO_PATH_SETUP]] || Set up audio path between a source node and a destination node (possibly via transit nodes)
| |
| − | |-
| |
| − | | [[AUDIO_CODEC]] || Message sent in the direction of start node, from end node or trans-coding nodes along the path
| |
| − | |-
| |
| − | | [[AUDIO_PATH_OK]] || End to end message: Audio path is ready
| |
| − | |-
| |
| − | | [[AUDIO_LINK_OK]] || Response to AUDIO_PATH_SETUP. Channel number is OK
| |
| − | |-
| |
| − | | [[AUDIO_PATH_STATE]] || SIP Response to AUDIO_PATH_SETUP
| |
| − | |-
| |
| − | | [[STATION_INFO]] || SIP update of number and display text
| |
| − | |-
| |
| − | | [[AUDIO_LINK_NOT_AVAILABLE]] || Response to AUDIO_PATH_SETUP from next node: Channel not granted
| |
| − | |-
| |
| − | | [[AUDIO_PATH_DISCONNECT]] || Release the endtoend audio path. Normal disconnect from source or destination
| |
| − | |-
| |
| − | | [[AUDIO_LINK_RELEASE]] || Used to release audio path backwards stepwise from node to node when setup meets busy or faulty link
| |
| − | |-
| |
| − | | [[STATION_LISTEN]] || Message from remote exchange. Set station in listen mode. Shut mic
| |
| − | |-
| |
| − | | [[STATION_CONVERSATION]] || Message from remote exchange. Set station in conversation mode. Stop tone and open mic.
| |
| − | |-
| |
| − | | [[STATION_TRANSFER]] || Message from remote exchange: Transfer of B subscriber.
| |
| − | |-
| |
| − | | [[CHECK_AUDIO_PATH]] || Check of established audio path at regular intervals
| |
| − | |-
| |
| − | | [[AUDIO_PATH_CHECK_OK]] || Positive response to CHECK_AUDIO_PATH
| |
| − | |-
| |
| − | | [[AUDIO_CH_LOOPBACK_REQ]] || Request for loopback audio connection. Used by the Audio Channel Testing process
| |
| − | |-
| |
| − | | [[AUDIO_CH_LOOPBACK_ACK]] || Positive acknowledge of AUDIO_CH_LOOPBACK_REQ
| |
| − | |-
| |
| − | | [[AUDIO_CH_FAULTY]] || Response to AUDIO_CH_LOOPBACK_REQ: Requested channel was faulty
| |
| − | |-
| |
| − | | [[LOOPBACK_IMPOSSIBLE]] || Response to AUDIO_CH_LOOPBACK_REQ
| |
| − | |-
| |
| − | | [[AUDIO_CH_DISCON]] || Disconnect a audio channel after loopback test
| |
| − | |-
| |
| − | | [[AUDIO_CH_TONE_REQ]] || Request a peer exchange to put a 500Hz tone on a audio channel
| |
| − | |-
| |
| − | | [[AUDIO_M_PATH_SETUP]] || Communication in a multi-node network
| |
| − | |-
| |
| − | | [[AUDIO_M_PATH_OK]] || Contains statuses for an AUDIO_M_PATH_SETUP from one or more destination exchanges
| |
| − | |-
| |
| − | | [[AUDIO_M_LINK_OK]] || Per hop positive response to AUDIO_M_PATH_SETUP
| |
| − | |-
| |
| − | | [[AUDIO_M_PATH_BACKTRACK]] || AUDIO_M_PATH_SETUP failed
| |
| − | |-
| |
| − | | [[VCP_MEET_REQ]] || Request answer to global group call
| |
| − | |-
| |
| − | | [[BUILD_GLOB_GRP]] || Broadcast message to all exchanges to make them rebuild global group indexes
| |
| − | |-
| |
| − | | [[GLOB_GRP_MEMB]] || A exchange tells which global groups this exchange is member of by broadcasting this to all exchanges
| |
| − | |-
| |
| − | | [[RESET_AUDIO_LINK]] || Reset audio link between nodes. Message not used in current AlphaCom version
| |
| − | |-
| |
| − | | [[CONF_JOIN]] || Exchange wants to join conference, asks root-exchange to setup connection back to sender
| |
| − | |-
| |
| − | | [[CONF_MEMB_CHK]] || Ask whether any neighbor exchange has any ordinary member left in conference
| |
| − | |-
| |
| − | | [[CONF_ORD_MEMB]] || An exchange tells its neighbors that it has ordinary member left in conference
| |
| − | |-
| |
| − | | [[CONF_IS_ROOT]] || Broadcast message. Sender informs that it is root of conference
| |
| − | |-
| |
| − | | [[CONF_NOT_ROOT]] || Broadcast message. Sender informs that it is no longer root of conference
| |
| − | |-
| |
| − | | [[AUDIO_M_FEED_REQ]] || Global Simplex Conference: Some station is pressing the M-key when participating in a conference
| |
| − | |-
| |
| − | | [[AUDIO_M_FEED_STOP]] || Global Simplex Conference: The station is releasing the M-key
| |
| − | |-
| |
| − | | [[AUDIO_PATH_DELAY]] || Set Duplex switch delay
| |
| − | |-
| |
| − | |}
| |
| − | | |
| − | <br>
| |
| − | <br>
| |
| − | | |
| − | == System Maintenance ==
| |
| − | {| border="1"
| |
| − | ! style="background:#ffdead;" width="170" |Message
| |
| − | ! style="background:#ffdead;" width="650" |Description
| |
| − | |-
| |
| − | | [[SET_NODE_NUMBER]] || Change the node number of an exchange
| |
| − | |-
| |
| − | | [[ROUTE_ALPHAPRO_MSG]] || Send AlphaPro message via AlphaNet to/from a remote node
| |
| − | |-
| |
| − | | [[CONSOLE_REQ]] || Log on to system debug console ([[TST]])
| |
| − | |-
| |
| − | | [[CONSOLE_DISC]] || Log off from system debug console ([[TST]])
| |
| − | |-
| |
| − | |}
| |
| − | | |
| − | <br>
| |
| − | <br>
| |
| − | | |
| − | = Appendix: Message Sequences =
| |
| − | | |
| − | == Devices ==
| |
| − | | |
| − | === Device Types ===
| |
| − | | |
| − | === Control Up ===
| |
| − | | |
| − | === Device Up ===
| |
| − | | |
| − | === Device Down ===
| |
| − | | |
| − | === Notes to implementation ===
| |
| − | | |
| − | == Conversation set-up / cancel ==
| |
| − | | |
| − | === General ===
| |
| − | | |
| − | === Dedicated computer control ===
| |
| − | | |
| − | ==== Call Set-up ====
| |
| − | | |
| − | ==== Call Cancel ====
| |
| − | | |
| − | ==== Conversation Disconnected by station ====
| |
| − | | |
| − | ==== Notes to implementation ====
| |
| − | | |
| − | === Station emulation ===
| |
| − | | |
| − | ==== Call Set-up ====
| |
| − | | |
| − | ==== Call Cancel ====
| |
| − | | |
| − | ==== Conversation Disconnected by station ====
| |
| − | | |
| − | ==== Notes to implementation ====
| |
| − | | |
| − | === Rapid cancel/connect sequences ===
| |
| − | | |
| − | === Use of <reference> fields ===
| |
| − | | |
| − | = Appendix: Link layers in detail =
| |
| − | | |
| − | == ISO Data Link Layer ==
| |
| − | | |
| − | === Overview ===
| |
| − | | |
| − | === Transmission Control Characters used ===
| |
| − | | |
| − | The following control characters are used in the protocol:
| |
| − | The first 32 characters, ASCII 0 31 (0x00 0x1F) is not allowed in the payload of an message.
| |
| − | Note that the message’s Block Check Character can have any value, including the reserved transmission control characters!
| |
| − | ==== STX Start of text ====
| |
| − | STX is a transmission control character which precedes a text and which is used to terminate a heading. STX is transmitted by the Master Device.
| |
| − | ==== ETX End of text ====
| |
| − | ETX is a transmission control character which terminates a text. ETX is only transmitted by the Master Device and calls for a reply from the Slave Device. ETX is followed by a BCC, “block check character”.
| |
| − | ==== EOT End of transmission ====
| |
| − | EOT is a transmission control character used to indicate the conclusion of the transmission of one text. EOT may be transmitted by a Control, Master or Slave Device. The Control Device transmits EOT to anticipate the reception of a forward supervisory sequence. The Master Device in the system transmits EOT to relinquish its right to transmit in favor of the Control Device.
| |
| − | ==== ENQ Enquiry ====
| |
| − | ENQ is a transmission control character used as a request for a response from a remote device. ENQ is transmitted by the Control Device during polling and by the Master Device during selecting.
| |
| − | ==== ACK Acknowledge ====
| |
| − | ACK is the transmission character transmitted by a receiver as an affirmative response to the sender.
| |
| − | ==== NAK Negative acknowledge ====
| |
| − | NAK is a transmission control character transmitted by a receiver as a negative response to the sender.
| |
| − | === Device Id ===
| |
| − | The Device Id is an UINT1 value which is unique within an exchange.
| |
| − | ==== Selecting a device in another exchange (Routing) ====
| |
| − | If the Master Device has a message to a device in another exchange, the Router is selected. The Router has device id 204 (0xCC) and answers the enquiry, and receives the message, on behalf of the destination device. This means that each device has to know which AlphaCom module they belong to.
| |
| − | The Master Device has completed its transmission upon receipt of ACK from the Router. Acknowledgment / handshake between devices on different modules must be handled at the application layer.
| |
| − | ==== Broadcast ====
| |
| − | The Master Device uses a broadcast id when selecting for a broadcast message. It is the responsibility of the Master Device to ACK the selecting supervisory by transmitting the positive acknowledge character ACK.
| |
| − | | |
| − | === Polling ===
| |
| − | | |
| − | === Selecting ===
| |
| − | | |
| − | === Messages ===
| |
| − | | |
| − | ==== Replies ====
| |
| − | | |
| − | ==== Broadcast Messages ====
| |
| − |
| |
| − | ==== Termination ====
| |
| − | | |
| − | === Recovery Procedures (Timers) ===
| |
| − | | |
| − | == Stentofon Data Link Layer ==
| |
| − |
| |
| − | === Transmission Control Characters ===
| |
| − | | |
| − | === Frame Structure ===
| |
| − | | |
| − | === Frame Description ===
| |
| − | Encoding type 0 means that the <Data> field is binary data.
| |
| − | - Data needs no reformatting.
| |
| − | Encoding type 1 means that the <Data> field contains hexadecimal data.
| |
| − | - Data is represented by ASCII characters `0’ ... `9’ and `A’ ... `F’.
| |
| − | - Each byte of original binary data is converted to 2 ASCII characters. The data are converted back to binary form before they are sent to the Network Layer.
| |
| − | - If the character ` ‘’ ‘ (double quote, 0x22) is received within a hexadecimal message, the rest of the message is uncoded (ASCII text). The ` ‘’ ‘ is stripped off, and its position is handed over to the Network Layer, so that if the message is to be retransmitted, the double quote is reinserted and the ASCII text part will not be coded to hexadecimal.
| |
| − | - When a hexadecimal encoding type is used, a CR (carriage return) character is added at the end of the <Data> field to increase readability. This character is also stripped off before the data is sent to the Network Layer.
| |
| − | | |
| − | ==== Information/Message Frame ====
| |
| − | The Information/Message Frame type (type 1) typically will have a Network Layer Frame as payload.
| |
| − | | |
| − | ==== Idle Frame ====
| |
| − | A special version of the message frame is the Idle Frame, defined by a <Data> field containing a Network Layer Frame with only the address header (no payload message code and parameters).
| |
| − | When no data are ready for transmission for a given time, idle frames are transmitted at regular intervals to check the quality of the data channel, and also to detect interruption of the channel (watchdog function). Idle frames are also used for resynchronization of sequence numbers. Idle frames are acknowledged in the same way as data messages. The format of the idle frame is as follows, where the size of each field is 1 byte:
| |
| − | '''<Data> = <source node><source device><destinatin node><destination device>'''
| |
| − | ==== Acknowledge Frame ====
| |
| − | The ACK frame (type 2) is used to acknowledge frames that are correctly received. The sequence number is derived from the frame it acknowledges.
| |
| − |
| |
| − | ==== Negative Acknowledge Frame ====
| |
| − | The NAK frame (type 3) is used to request for retransmission of a given message.
| |
| − | ACK and NAK frames will have priority for sending before any other messages.
| |
| − | | |
| − | === Link Control, Supervision and Error Recovery Procedures ===
| |
| − | As the protocol may be used on intercontinental links with long delays (up to 500 600 ms roundtrip delay on a satellite |hop), special precautions must be taken to secure transmission quality without introducing too long delay in the forward path when conditions are good. Therefore, a sliding window mechanism is used to maintain correct sequencing of messages in case of transmission errors.
| |
| − | | |
| − | ==== Sliding Window Protocol ====
| |
| − | A sliding window protocol with sending window size 7 is used. This means that 7 messages may be sent on the link before a response is required for any of them. At the receiving end, window size 1 is used, i.e. if a message is lost, the lost message plus all messages after the lost one must be retransmitted.
| |
| − | | |
| − | At the transmitting end, the Message Frames are numbered with a sequence number and inserted into a window buffer when sent, and removed when acknowledged. Before a new frame is sent, the previous frame must be completed (STOP_FLAG sent). When the buffer is full, transmission of new frames has to wait until an acknowledge is received. The Acknowledge Frame carries the same sequence number as the frame it acknowledges. If an acknowledge is received for a frame that is not the oldest one in the window buffer, it means that an Acknowledge Frame is lost or skipped at the receiving end, and the acknowledged frame and any older frames are removed from the buffer. If a NAK frame is received, the corresponding frame plus the newer frames (if any) are retransmitted, and the older frames are removed from the buffer.
| |
| − | | |
| − | At the receiving end, incoming frames are checked for errors, and if OK, an ACK frame with the same sequence number is transmitted back to the sender. The frame is then decoded to binary form (if necessary) and sent to the Network Router. If an error is detected, either in the current frame or if there is a frame sequence number missing, NAK frame is sent back to the sender with the sequence number of the frame with error or missing. The receiver then discards all received frames until the one with the correct sequence number is received, and normal operation is resumed. Since an Idle Frame is only transmitted when the window buffer is empty, it is used to synchronize sequence numbering at the other end of the link. After a reset, the transmission always starts with at least one Idle Frame.
| |
| − | | |
| − | ==== Link Supervision ====
| |
| − | If there is no response from the other end of a link within a given time (calculated from the normal delay of the link) after the last frame is sent, the contents of the window buffer is retransmitted. If no response is obtained after 2 attempts, the window buffer is cleared, transmitter reset, and Idle frames transmitted with specific intervals. If contact with the other end is reestablished, an OKmessage is sent to the Network Router so that data communication can be resumed.
| |
| − | | |
| − | ==== Simple implementation ====
| |
| − | An external computer can run with a sliding window size of one, i.e. for each message you send you must wait for the acknowledge from the AlphaCom. Sending/receiving NAKs can also be skipped as both ends always must have (fast) timeouts to handle errors.
| |
| − | | |
| − | == Stentofon Simple Link Layer ==
| |
| − | === Link Layer Output Message Format ===
| |
| − | === Link Layer Input Message Syntax ===
| |
| − | ==== Parsing of commands ====
| |
| − | ==== Formatting Specifiers ====
| |
| − | ==== Default values for omitted header fields ====
| |
| − | ==== Format examples ====
| |
| − | ==== Default values for omitted message fields ====
| |
| − | === Encoding of standard parameter types ===
| |
| − | ==== Raw hex ====
| |
| − | ==== Data type encoding ====
| |
| − | === Producing site-specific (engineering use) formatted messages ===
| |
| − | === Simple Link Layer functions for testing ===
| |
| − | ==== Link Layer Startup ====
| |
| − | ==== Link Layer Commands ====
| |
| − | ==== Link Layer Responses ====
| |
| − | ==== Link Layer Message Acknowledgments ====
| |
| − | = Appendix: Messages in Simple Link Layer =
| |
| − | == Station keyboard & display emulation ==
| |
| − | == Station features and status ==
| |
| − | == Station mail operations ==
| |
| − | == General exchange control ==
| |
| − | == General device control and status ==
| |
| − | == Remote Control features ==
| |
| − | = Appendix: Practical debugging =
| |
| − | == AlphaCom configuration ==
| |
| − | === Terminal configuration ===
| |
| − | ==== DP terminal ====
| |
| − | ==== TST terminal ====
| |
| − | === Get going ===
| |
| − | === Start debugging ===
| |
| − | ==== ILLEGAL_PARAM ====
| |
| − | ==== Echo the message back to the terminal ====
| |
| − | == Debugging Event Handler Actions ==
| |
| − | === TST ===
| |
| − | ==== DT - data protocol trace ====
| |
| − | ==== CSI ====
| |
| − | = Appendix: Notes for implementation =
| |
| − | == General ==
| |
| − | === On the use of LOCAL_ENTITY ===
| |
| − | === Strategy for use of formats - automatic translations ===
| |
| − | === On the use of NULL ===
| |
