Specifications

9261-7974 Issue 06
ESFIRECODER - Emergency Services Firecoder
Page 47
www.multitone.com
Transmitter Selection is done whilst the System and User directories are being parsed. In the
case of calls that expand to multiple destinations, each new destination will add to the
transmitter list based on the Selective Paging selection, potentially reinstating a previously
removed transmitter.
• If a destination is +transmitter, then that transmitter will be added to the transmitters used for
this call.
6.54 GD-92 Implementation Notes
These notes define all significant variations between the GD92 Protocol Specification, Issue 2.2 and
the current Multitone implementation of this specification.
6.54.1 Router
To enable reliable communication with the unit using 'unknown' remote node addresses, the
router will initially attempt to send a response message back via the same MTA that received
the message. If this fails, or the MTA is offline, the normal router table is used. This also
avoids the problem of a response message coming back via a different MTA if that had a
higher preference.
The size of some tables (Router, PSTN etc) has been adjusted on some systems from the
standard 200 entries to reflect the likely maximum for each system. The maximum number of
destination ranges for <dest_nodes> is one in all cases.
To ease system set-up and testing, if no password is stored in the level 4 password (the
'contractors' level), the password control system is automatically disabled.
The alerter UA will drive an external MG4 alerter if the agent type is set to Alerter Type 1, and
the internal MG4 compatible alerter if it is set to Alerter Type 2.
6.54.2 Message 02: Mobilise Message
Often, a brigade will have a requirement to define it's own format of mobilise message format.
Message 27 can be used, but loses the priority and repeat print facilities. To accommodate
"user defined" messages, if any of the standard mobilise message fields are left blank, they
and their header will NOT be printed, allowing a free format mobilise message to be sent in
the <text> field. If more than one text field is required, the second <mobilisation_type> field
can be set to an illegal value, which will inhibit any other printing between successive <text>
fields.
6.54.3 Message 09: Peripheral_status_request
This message will normally return the current "real-time" status of the peripheral user agent.
For some applications, a "latched" status is required. These are accessed by including an
additional byte with the message set as follows:
0 - Same as format
1 - Return LATCHED input status
2 - Return LATCHED input status and reset latches.