Milestone XProtect
Face recognition for Milestone XProtect
Put face matches in front of the operator inside Smart Client, attached to the camera and the recorded video — instead of in a second application on a second screen.
- Uses the documented MIP SDK analytics event protocol
- Events map to XProtect cameras
- Alarms raised through alarm definitions
- No certification or marketplace status is claimed
In short
Ayonix delivers face recognition results into Milestone XProtect as analytics events through the documented MIP SDK protocol, so a match appears in Smart Client attached to its camera and recorded video. Operators acknowledge alarms where they already work rather than in a second application.
This page is written from Milestone's own published documentation for the MIP SDK analytics event protocol, which is linked below. It describes the mechanism Ayonix uses and the prerequisites that have to be in place for it to work — including the one that silently defeats most first attempts.
It does not claim certification, marketplace listing or partner status with Milestone. Using a vendor's public integration interface is a statement about how software works, not about a commercial relationship, and the difference matters in a procurement document.
What a disconnected analytics deployment costs
Every one of these is a consequence of face recognition living outside the VMS the control room actually watches.
Operators switch between the VMS and a separate analytics application.
Matches arrive as XProtect events, so the operator stays in Smart Client. The context switch that loses seconds during an incident is removed.
A face match is disconnected from the live and recorded video that shows it.
The event names the XProtect camera, so the match carries the route to both the live view and the recording around that timestamp.
Reviewing an alert means finding the right camera and the right time manually.
The event carries both. The operator opens the video from the alarm rather than reconstructing where to look.
Analytics camera identifiers have to be mapped to VMS cameras by hand.
Mapping is configured once, per camera, using either the device address or a fully qualified XProtect identifier. After that the event resolves itself.
Alarms cannot be acknowledged in one place, so the audit trail is split.
Where the event matches an alarm definition, it becomes an XProtect alarm with the platform’s own acknowledgement, ownership and state model.
Incident evidence is assembled from two systems after the fact.
The alarm, the analytics event and the recorded video are one record in one system, which is what an investigation and an export actually need.
Deployment and health status are invisible until something has already failed.
Connection and stream health are monitored and surfaced, so a stopped analytics service is noticed before an incident rather than during one.
How it works
From a match to an acknowledged alarm in Smart Client
Four steps, all through Milestone's documented interfaces. The prerequisites in step three are the ones most often missed and the reason an integration appears to do nothing.
-
Ayonix recognises
Recognition runs against authorised camera video on Ayonix infrastructure — a server or an edge appliance — and produces a match with its evidence.
Fails when: The analytics service is reading a different stream profile from the one the operator watches, and the two disagree about what was visible.
-
Event is composed
An AnalyticsEvent XML document is built, carrying the event header, the message that will match the alarm definition, the source camera and any object bounding boxes.
Fails when: The Message value does not exactly match the alarm definition, so the event is accepted and no alarm ever appears.
-
Sent to the Event Server
The document is delivered to the XProtect Event Server as raw XML on the Analytics Receive port — 9090 by default — or by HTTP POST with the XML as content.
Fails when: Analytics Events are not enabled in the Management Client, or the sender address is not in the allowed list.
-
Alarm, review, acknowledge
The Event Server matches the message against the alarm definition, raises the alarm, and the operator reviews it against the mapped camera and acknowledges it.
Fails when: Rules are configured to act automatically on a match, removing the human review the deployment was supposed to keep.
Architecture
Where recognition sits relative to XProtect
Recognition runs on Ayonix infrastructure inside the customer network. XProtect provides authorised access to video and receives the resulting events.
Video sources
-
IP cameras
Recorded and managed by XProtect
-
XProtect recording server
Holds the recordings
-
Authorised stream access
To the analytics host
Ayonix recognition
Customer infrastructure-
Detection and quality gating
Discards unusable captures
-
Matching engine
Gallery or watchlist
-
Event composer
Builds the AnalyticsEvent XML
XProtect
Milestone platform-
Event Server
Receives and matches the message
-
Alarm definition
Turns the event into an alarm
-
Smart Client
Operator reviews and acknowledges
Recognition does not run inside XProtect. Face images and templates are governed by the Ayonix deployment’s own retention configuration, which should be specified alongside the VMS integration.
Event structure
What an analytics event actually contains
The element names below come from Milestone's published protocol reference. The values are an illustrative example of an Ayonix face match, not a captured production payload.
<AnalyticsEvent>
<EventHeader>
<ID>00000000-0000-0000-0000-000000000000</ID>
<Timestamp>2026-09-11T08:42:17.412Z</Timestamp>
<Type>Ayonix Face Match</Type>
<Message>AyonixFaceMatch</Message>
<Source>
<Name>10.20.4.31</Name>
</Source>
</EventHeader>
<Description>Watchlist candidate, operator review required</Description>
<ObjectList>
<Object>
<Name>Face</Name>
<Confidence>0.0</Confidence>
<BoundingBox>
<Top>0.31</Top>
<Left>0.44</Left>
<Bottom>0.52</Bottom>
<Right>0.57</Right>
</BoundingBox>
</Object>
</ObjectList>
<Vendor>
<Name>Ayonix</Name>
</Vendor>
</AnalyticsEvent>Illustrative. The exact fields Ayonix populates are confirmed in the integration package for your deployment, because they depend on the camera naming convention and the alarm definitions you use.
The field that decides everything
<Message> is matched against the alarm definition created in the XProtect Management Client. If
it does not match exactly, XProtect accepts the event and raises no alarm — with no error
anywhere. More first-time integrations fail on this one string than on everything else combined.
Identifying the camera
Milestone documents three forms for
<Source>: a device IP address; an IP address with a channel number for multi-channel devices;
or a fully qualified identifier using
<FQID> with a server ID, object ID and kind. Pick one convention and use it across the estate.
A note on the confidence field
A similarity score is only interpretable alongside the threshold in force, so it is carried in the event description and the Ayonix record rather than presented as a bare percentage an operator might read as a probability of identity.
Capability status
What is implemented, and what is not claimed
Four honest states. There is deliberately no 'certified' column, because no certification has been verified with Milestone and inventing one would be exactly the kind of claim this site exists to avoid.
| Capability | Mechanism | Status |
|---|---|---|
| Receive authorised camera video | Stream access granted by the XProtect deployment | Supported: Implemented |
| Map analytics to XProtect cameras | Source element: IP, IP with channel, or FQID | Supported: Implemented |
| Deliver analytics events | AnalyticsEvent XML to the Analytics Receive port or by HTTP POST | Supported: Implemented |
| Raise alarms | Alarm definition matching the EventHeader Message | Supported: Implemented — requires the alarm definition to exist |
| Open live or recorded video from an event | Camera and timestamp carried in the event | Supported: Implemented — requires clock synchronisation |
| Operator acknowledgement | XProtect alarm state model | Supported: Implemented — the platform’s own acknowledgement |
| Rules and downstream actions | XProtect rules engine acting on the alarm | Supported: Implemented — consequential actions should require review |
| Health and connection status | Ayonix service monitoring surfaced to the operator | Supported: Implemented |
| MAD alert overlays | Alert root with rule polygon and motion path | Partial: Available by integration project |
| Milestone certification or marketplace listing | Not applicable | Not supported: Not claimed — verify any such status with Milestone directly |
Capability varies between XProtect editions and releases. The supported configuration for a specific deployment is confirmed in writing in the integration package, against the version actually installed.
XProtect receives analytics events as XML on the Analytics Receive port, default 9090, or by HTTP POST, and matches the EventHeader Message against an alarm definition created in the Management Client
- Source type
- Third-party vendor documentation
- Verified
- 2026-09-11 · Jan Mocary, Chief Technology Officer
What this does not establish
Describes the documented Milestone protocol. It is not a statement of certification or marketplace status, and the port and prerequisites should be confirmed against the XProtect version in use.
Integration work with Network Optix, Milestone and Genetec video management platforms
- Source type
- Ayonix first-party statement
- Verified
- 2026-09-11 · Jan Mocary, Chief Technology Officer
What this does not establish
Integration capability only. This is NOT a claim of certification, marketplace listing, technology-partner status or joint validation with any of the three vendors. No such status has been verified, and none is asserted anywhere on this site.
Troubleshooting
When nothing appears in Smart Client
In order of how often each turns out to be the cause. The first three account for the overwhelming majority.
Events are sent and accepted, but no alarm ever appears.
Usual cause: The EventHeader Message does not exactly match the alarm definition in the Management Client.
Fix: Compare the two strings character by character, including case and trailing whitespace. Milestone matches this exactly and reports nothing when it does not match.
Events appear to send but nothing is received at all.
Usual cause: Analytics Events are not enabled, or the sender address is not in the allowed list.
Fix: Enable the Analytics Event feature in the Management Client and add the Ayonix host address to the permitted senders. Both are required.
Connection refused or times out.
Usual cause: Wrong port, or a firewall between the analytics host and the Event Server.
Fix: Confirm the Analytics Receive port in the deployment — 9090 is the default but is frequently changed — and confirm the path is open from the sending host.
Alarms appear but are not attached to any camera.
Usual cause: The Source element does not resolve to a camera XProtect knows about.
Fix: Check the identification convention. An IP that XProtect associates with a different device, or a channel suffix on a single-channel device, will both fail to resolve.
The operator opens the video and the moment is not there.
Usual cause: Clock drift between the analytics host and the recording server.
Fix: Synchronise both to the same time source. Even a few seconds of drift makes evidence hard to find and easy to dispute.
Alarm volume is unmanageable.
Usual cause: This is a recognition configuration problem, not a VMS one.
Fix: Raise the quality floor, segment the watchlist, and set thresholds per camera. The watchlist page covers the three controls in detail.
Primary source for the protocol described on this page: Milestone MIP SDK — Analytics Event and MAD protocol. Read on 11 September 2026. Milestone documentation is the authority on Milestone behaviour; where this page and Milestone's documentation differ, theirs is correct.
XProtect deployment prerequisites
Work through these before the integration visit. Most integrations that "do not work" are a missed item from this list rather than a software fault, and each is verifiable in the Management Client in minutes.
-
Enable the Analytics Event feature
In the XProtect Management Client. Until this is on, the Event Server does not accept analytics events at all and nothing anywhere reports an error.
-
Add the sender to the allowed address list
The Ayonix server or appliance address must be permitted to send analytics events. An event from an unlisted sender is discarded silently.
-
Create the alarm definition and match the message exactly
The EventHeader Message value is matched against the alarm definition created in the Management Client. The string must match exactly, including case — this is the single most common cause of a silent integration.
-
Confirm the Analytics Receive port
Default 9090, but it is configurable and is frequently changed. Confirm the value in the deployment rather than assuming the default, and confirm the firewall allows it.
-
Decide how cameras are identified
By device IP address, by IP with a channel suffix for multi-channel devices, or by a fully qualified XProtect identifier. Choose once and apply consistently across the estate.
-
Record the XProtect version and edition
Capability and available interfaces vary between XProtect editions and releases. Record what is installed before scoping, because the answer changes what is possible.
-
Agree time synchronisation across the estate
The event timestamp is how a match is located in the recording. Clock drift between the analytics host and the recording server makes evidence hard to find and easy to dispute.
-
Define the rules that follow an alarm
Which rules fire, what they do, and explicitly which consequential actions require a person first. A rule that acts automatically on a face match removes the review the deployment depends on.
-
Plan health monitoring for the analytics service
How the control room learns that recognition has stopped. A silent failure means a site that believes it is covered and is not.
-
Test the full path before go-live
Induce a known match, confirm the alarm appears, confirm the operator can open the correct recorded video, and confirm the acknowledgement is recorded.
Frequently asked questions
How does Ayonix send events to XProtect?
Through the documented MIP SDK analytics event protocol. Milestone’s own documentation describes two transports: raw XML sent to the Analytics Receive port, which defaults to 9090, or an HTTP POST with the XML as the content. The document is an AnalyticsEvent whose EventHeader carries an ID, a timestamp, a message and a source, with an optional ObjectList containing bounding boxes.
Why does my analytics event not produce an alarm?
Almost always one of three things. The Analytics Event feature is not enabled in the Management Client; the sending address is not in the allowed list; or — most commonly — the Message value in the EventHeader does not exactly match the alarm definition created in the Management Client. Milestone matches that string to decide whether an alarm is raised, so a difference in case or whitespace produces an accepted event and no alarm.
How are Ayonix analytics mapped to XProtect cameras?
Through the Source element of the event. Milestone documents three forms: a device IP address, an IP address with a channel number for multi-channel devices, and a fully qualified identifier using FQID with a server ID, an object ID and a kind. Which to use depends on the estate; the important thing is choosing once and applying it consistently, because a mixed convention is hard to debug later.
Is the Ayonix integration certified by Milestone?
No such status is claimed anywhere on this site. Ayonix uses Milestone’s documented and publicly available integration mechanism, which is a description of how the software works rather than a statement about a commercial or certification relationship. Where certification or marketplace status matters to a procurement, it should be verified with Milestone directly rather than inferred from an integration existing.
Which XProtect versions are supported?
This site does not publish a version matrix, because publishing one that has not been tested against each release would be exactly the kind of unsupported compatibility claim we refuse to make elsewhere. Milestone’s own documentation is the authority on which interfaces exist in which release. For a specific deployment, record the installed XProtect edition and version and the supported configuration will be confirmed in writing as part of the integration package.
What is the difference between an Analytics Event and a MAD event?
Both are documented Milestone mechanisms with different shapes. An AnalyticsEvent carries an event header and an object list with bounding boxes. A MAD — Milestone Alert Data — event uses an Alert root and carries source, rule polygon, object and motion path information, which suits overlay visualisation. Which is appropriate depends on what the operator should see; Milestone’s protocol reference describes both.
Can the operator open recorded video directly from a match?
Yes, provided the event is mapped to the correct XProtect camera and clocks are synchronised. The event carries the camera and the timestamp, which is exactly what XProtect needs to locate the recording. Clock drift between the analytics host and the recording server is the usual reason an operator opens the video and finds the moment is not where the timestamp said.
Where does recognition actually run?
On Ayonix infrastructure inside the customer’s network — a server or an edge appliance — not inside XProtect. XProtect provides authorised access to camera video and receives the resulting events. This means face images and templates are governed by the Ayonix deployment’s retention configuration, which should be specified alongside the VMS integration rather than after it.
Related
Where to go next
Genetec Security Center
Custom events and event-to-action, with an honest compatibility matrix.
Network Optix
Metadata SDK plugin, so matches are searchable on the timeline.
Watchlist monitoring
What has to be in an alert before an operator can act on it.
On-premise deployment
Where the recognition server sits relative to the VMS.
Integration overview
Every integration mechanism with its status stated honestly.
Camera planning guide
A VMS integration cannot improve a camera that never sees a face.
Next step
Request the XProtect integration package
The package covers the deployment prerequisites, the event mapping for your camera naming convention, the alarm definition to create, and the installation and test sequence. Tell us the XProtect version and edition you are running and the camera count in scope.