AMQP 1.0 messaging

AMQP 1.0 defines messaging, delivery state and flow control. Map its settlement behaviour to how your application stores, processes and acknowledges security events.

Overview#

AMQP 1.0 is a standardised binary messaging protocol. It defines interoperable peers, connections, sessions, links, message sections, flow control, delivery state, settlement, transactions, and security layers. It doesn't prescribe a universal broker topology, address language, management API, event schema, or physical security outcome model. AMQP AMQP OVERVIEW

Version boundary#

Treat the version number as part of the wire contract.

Don't infer AMQP 1.0 support from the presence of an “AMQP” checkbox, port, URI, or client library name. Record the negotiated protocol version and the exact product profile.

Protocol model#

container
  -> connection
      -> session
          -> sender link -> node
          <- receiver link <- node

• A container is an AMQP node hosting or messaging process with a stable identity in its deployment context.
• A connection is the long lived AMQP relationship carried by a transport.
• A session multiplexes ordered transfer work over a connection and has its own flow windows.
• A link is a unidirectional sender to receiver path. Bidirectional application exchange uses multiple links.
• A node is an addressable source or target, such as a queue, topic like endpoint, or service defined terminus.
• A delivery is one message transfer tracked for outcome and settlement; a large message can span multiple transfer frames.

Broker products add queues, exchanges, subscriptions, filters, dead lettering, retention, and administration models. Those names and semantics aren't automatically portable merely because the wire protocol is AMQP 1.0.

Messages and domain contracts#

An AMQP message can carry header, delivery annotations, message annotations, properties, application properties, body, and footer sections. Define which sections an application may set and which only trusted infrastructure may add.

For a physical security event profile, define at least:

• media type and schema identifier/version;
• event identity, native source identity, tenant/site, occurrence time, receive time, and clock quality;
• correlation and causation identifiers;
• canonical and native event types without erasing source meaning;
• sensitivity, retention, ordering key, expiry, and replay treatment;
• maximum encoded and decoded size, collection counts, and nesting depth;
• behaviour for unknown fields, unknown event types, invalid timestamps, and duplicate identifiers.

AMQP application properties aren't a trusted identity channel by default. A publisher can often set them. Establish authenticated publisher identity at the connection/link layer and apply authorisation independently of asserted tenant, site, device, role, or user fields.

Delivery state and settlement#

AMQP distinguishes transfer from delivery outcome and settlement. Common terminal outcomes include accepted, rejected, released, and modified; unsettled deliveries may require state reconciliation after interruption. AMQP TRANSPORT

Settlement mode changes who tracks an unsettled delivery and when. “At most once,” “at least once,” or stronger application claims require an end to end profile covering producer persistence, broker durability, consumer transaction boundaries, deduplication, recovery and expiry.

Use a scoped immutable event or operation ID for deduplication. Bind it to authenticated producer, tenant, target, operation type, and request fingerprint; retain deduplication state for the full retry/replay window.

Flow control and resource bounds#

AMQP link credit tells a sender how many deliveries a receiver is prepared to accept. Sessions also use incoming and outgoing windows. Credit is protocol backpressure, not a complete capacity policy.

• Grant credit according to bounded queue count, bytes, processing latency, and downstream health.
• Bound frame size, message bytes before and after decompression, section counts, map/list entries, symbol/string/binary lengths, link/session count, unsettled deliveries, and idle lifetime.
• Reduce or stop credit before memory or durable storage is exhausted.
• Monitor queue age and oldest event, not only message count.
• Define expiry and dead letter/quarantine handling; never silently discard a safety relevant alarm because a generic time to live elapsed.
• Keep priority bounded and governed so one noisy publisher can't starve restoration, health, or audit traffic.

Transport flow control can't prevent a fast consumer from overwhelming a database, rules engine, case platform, or physical security adapter after it accepts a delivery.

Addressing, filters, and topology#

The AMQP base specification doesn't provide one universal address syntax. Broker URLs, virtual hosts, dynamic nodes, durable subscriptions, shared subscriptions, selectors, wildcard rules, and dead letter targets are commonly product defined or supplied by extension specifications.

Document:

1. source and target address syntax, normalisation, and tenant boundary;
2. who may create, delete, bind, browse, or consume from a node;
3. durable versus temporary lifetime and expiry behaviour;
4. competing consumer and ordering behaviour;
5. filter language, validation, complexity limits, and unsupported field behaviour;
6. disaster recovery topology and duplicate/loss window;
7. whether replay uses the production address or an isolated replay path.

Never place credentials, bearer tokens, personal identifiers, or sensitive site details in a URI that may enter logs or diagnostics.

Authentication, transport security, and authorisation#

AMQP 1.0 defines SASL and TLS related protocol layers, but a deployment still has to choose and enforce a security profile. AMQP SECURITY

• Require a protected transport across untrusted networks; validate server identity and trust path.
• Where mutual TLS is used, map the authenticated certificate identity to a narrowly scoped messaging principal; possession of a certificate doesn't authorise every address.
• Allowlist SASL mechanisms appropriate to the protected transport and credential type. Reject silent downgrade to anonymous or cleartext password mechanisms.
• Separate publish, consume, browse, manage, and dynamic node permissions by tenant/site and address.
• Reauthorize link attachment and dynamic node creation; connection authentication alone is insufficient.
• Rotate credentials and trust anchors without requiring a fail open window.
• Protect broker management, metrics, tracing, schema registries, and dead letter stores as separate surfaces.

The registered ports commonly associated with AMQP are 5672/TCP and 5671/TCP, but a port number neither proves protocol identity nor guarantees TLS. Use an explicit URI/profile and confirm negotiation. IANA PORTS

Reconnect, failover, and replay#

AMQP describes protocol state; product specific clients often add reconnect and failover behaviour. Make that behaviour visible in the integration contract.

• Use backoff, jitter, a retry budget, and a total recovery deadline.
• Distinguish DNS/connect/TLS/SASL/open/session/link/attach failures in telemetry.
• Treat an interrupted unsettled delivery as uncertain until state is reconciled or safely deduplicated.
• Don't reset sequence or deduplication state merely because the TCP connection changed.
• Define whether alternate endpoints share durable state or are independent brokers.
• Bound offline spooling by count, bytes, age, sensitivity, and encryption at rest requirements.
• Quarantine incompatible schema versions instead of repeatedly redelivering them into a hot loop.

Transactions and physical actions#

AMQP transactions can coordinate AMQP resource operations within the supported transaction model. They don't create an atomic transaction with a PACS controller, door contact, video recorder, dispatch process, or emergency communication system.

For high impact requests, keep separate states such as:

created -> authorized -> published -> AMQP accepted
        -> adapter accepted -> downstream dispatched
        -> target acknowledged -> observed outcome | failed | uncertain

Require fresh authorisation and an operation specific policy at the adapter. Don't let a generic event consumer translate arbitrary message fields into unlock, lockdown, relay, alarm reset, camera control, or notification actions.

Observability and evidence#

Record the AMQP endpoint identity, authenticated principal, connection/session/link identifiers where useful, source/target address, delivery tag in bounded form, settlement outcome, redelivery indicator, schema/mapping version, retry count, queue age, correlation ID, and downstream outcome. Avoid logging bodies or application properties wholesale.

Useful measures include connection and authentication failures, link attach denials, credit exhaustion, unsettled count, accepted/rejected/released deliveries, redelivery, expired/quarantined messages, queue bytes/age, parser failures, tenant policy denials, and end to end freshness.

Review checklist#

• AMQP 1.0 distinguished from AMQP 0-9-1 and vendor APIs
• Exact broker/client versions, URI profile, SASL mechanisms, TLS policy, and endpoint identity documented
• Address syntax, node lifetime, topology, ordering, filtering, and failover behaviour pinned
• Publish/consume/manage authorisation isolated by tenant, site, and address
• Frame, message, decompression, collection, link, session, queue, and spool limits enforced
• Link credit connected to bounded downstream capacity
• Settlement and recovery semantics mapped to application deduplication and transactions
• Schema evolution, provenance, invalid event quarantine, expiry, and replay defined
• AMQP acceptance kept distinct from consumer, workflow, and physical outcomes
• High impact subscribers use a separate authorisation and safety boundary

Sources#

• AMQP, AMQP Version 1.0 OASIS Standard, OASIS, October 2012.
• AMQP ISO, ISO/IEC 19464:2014: Advanced Message Queuing Protocol (AMQP) v1.0 specification, ISO/IEC; last reviewed and confirmed in 2025.
• AMQP OVERVIEW, AMQP Version 1.0, Part 0: Overview, OASIS.
• AMQP TRANSPORT, AMQP Version 1.0, Part 2: Transport, OASIS.
• AMQP MESSAGING, AMQP Version 1.0, Part 3: Messaging, OASIS.
• AMQP SECURITY, AMQP Version 1.0, Part 5: Security, OASIS.
• IANA PORTS, Service Name and Transport Protocol Port Number Registry, IANA, amqp and amqps entries, accessed 25 August 2026.

Section overview · Wiki home