AlphaNet Data Protocol
From Zenitel Wiki
Introduction
The AlphaCom/AlphaNet Data Protocol (ACDP protocol) is used for:
- Data communication between AlphaCom Exchanges in AlphaNet, including other types of exchanges such as TouchLine MPC
- Data communication between AlphaCom Exchanges and External Devices such as RIOs and PC based Control Handlers
- Advanced internal control of the AlphaCom. Event Handler can use DP messages as general Action Commands.
The Data Protocol is made generally available from software version AMC 06.00. Previous AMC softwares are NOT compatible with this protocol descriptions.
Protocol properties
- 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
- Data link layers with message checksum for reliability, and with acknowledgment and re-transmission of erroneous messages
- 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.
- 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 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
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. 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:
Network Application Application Message layer header header parameters _ 0101 0141 01 41 1234 0050 3201107F 20102F Src Dest Hop Cl Ref Msg P1 P2 dev dev cnt ss id Station Digits to dial
Important terms of the data protocol
Access to AlphaCom resources
Directory numbers vs. features
Directory numbers, users and stations
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
- 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
Message | 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. |
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).
Message | 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 |
Station Features and Status
Message | 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 |
Station Mail Operations
Message | 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 |
General Exchange Control
Message | 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 |
Device Control and Status
A device shall not respond to any message before it’s operative except RESET_DEVICE and GET_DEVICE.
Message | 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.” |
Remote Control
Message | Description |
---|---|
SET_LOGICAL_RCO | Set or clear a logical RCO |
RCO_CHANGED | New RCO state reported from the exchange |
RCI_CHANGED | New RCI state reported from the exchange |
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.
Message | 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 |
AlphaNet
This is messages related to audio control between exchanges. AlphaNet also uses other messages like station emulation, mails, and system maintenance.
Message | 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 |
System Maintenance
Message | 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) |
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 field is binary data. - Data needs no reformatting. Encoding type 1 means that the 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 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 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:
= <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.