Profile S to Profile T: The Engineering Migration Guide for Camera Manufacturers

This guide is written for the people who will do the work: firmware and embedded engineers, product managers and R&D leads at companies that make IP cameras, encoders or recorders and currently declare ONVIF Profile S and nothing else. It assumes you already know why the deadline exists — if not, start with the deprecation itself and what it means for estate owners — and concentrates on what has to be built, how large that job is likely to be for a given stack, and how to sequence it so a declaration is in place before 31 March 2027.

Two framing points before the detail. First, Profile T was published in 2018, so this is not a new target; it is a well-understood one with a mature test tool behind it. Second, the effort is dominated by one item, the Media 2 service, and the size of that item depends almost entirely on what your existing ONVIF stack looks like. Everything else in the profile is incremental by comparison.

1. What Profile T actually asks of a device

Profile T is a device-side and client-side profile. On the device side it defines a set of mandatory features and a set of conditional ones, where "conditional" means mandatory if the hardware supports the capability. The table below is a working summary for planning purposes; the authoritative list is the current ONVIF Profile T specification and the feature list embedded in the Device Test Tool, and both should be checked before scope is signed off.

The practical reading of that table: seven of the eleven rows are re-verification of things a Profile S device already does. The remaining four — Media 2, authentication and TLS, events with tampering, and OSD/masking through Media 2 — are where new code is written.

2. Media 1 to Media 2: what actually changes

Media 2 is not a renamed Media 1. It reorganises how a device describes what it can stream. The changes that matter to an implementation are these.

Configuration becomes token-based and composable. A Media 2 profile is a container of configuration references — video source, video encoder, audio source, audio encoder, metadata, PTZ, analytics — each addressed by token and attached or detached with generic AddConfiguration and RemoveConfiguration operations. Media 1's family of type-specific calls (AddVideoEncoderConfiguration, AddAudioEncoderConfiguration and so on) collapses into this one mechanism. If your Media 1 implementation hard-wires profiles to fixed encoder slots, this is the first place the architecture pushes back.

Encoder configuration is expressed differently. Media 2 describes the codec as a string (H264, H265, JPEG) with an associated profile and a GovLength, rather than Media 1's codec-specific sub-structures. Rate control, resolution and quality move with it. Devices that encode H.265 must expose it here.

Stream and snapshot URIs are simpler, and stricter. GetStreamUri takes a protocol argument and a profile token and returns a URI; the old stream setup structure goes away. Clients expect the returned RTSP URI to work with digest authentication.

OSD and masks live in Media 2. Overlay and mask configuration is retrieved and set per video source through Media 2 operations, which is why the profile lists them alongside the media service rather than as a separate feature.

Metadata is a first-class configuration. Analytics and event metadata are streamed through a metadata configuration attached to the profile. Profile T clients pull event metadata this way in addition to the pull-point event service.

The table below maps the operations a Profile S stack most commonly implements to their Media 2 counterparts. It is representative rather than exhaustive.

One architectural consequence is worth stating plainly: Media 1 and Media 2 must coexist on the device for the transition period, because installed VMS platforms will continue to use Media 1 with existing cameras. Implementations that bolt Media 2 onto a Media 1 engine by translating one to the other tend to fail the test tool on configuration consistency; the cleaner pattern is a single configuration model underneath with two service front-ends.

3. Authentication and transport

The security change is the reason the profile is being retired, so it is the change that will be scrutinised most closely by buyers and by the test tool.

• HTTP digest authentication on the SOAP interface. WS-UsernameToken may remain for backwards compatibility with older clients, but the device must not require it and must accept digest.
• TLS 1.2 for HTTPS on the device web service. In practice this means certificate handling on the device: a default self-signed certificate at first boot, the ability to load a customer-supplied certificate, and sensible behaviour when the clock is wrong and validity windows fail. The test tool exercises the TLS server; the field exercises the certificate management.
• RTSP authentication with digest, consistent with the credentials used on the SOAP side.

Teams that have implemented this before will recognise the hidden cost: it is rarely the digest algorithm, and almost always the certificate lifecycle, the clock and the user-management edge cases.

4. Events, tampering and metadata

Profile S devices already generate events. Profile T is more specific about which ones and how they are delivered.

• Pull-point subscription through the event service, with the standard CreatePullPointSubscription / PullMessages cycle and correct handling of subscription renewal and termination.
• Motion alarm on the tns1:VideoSource/MotionAlarm topic, with a property state that clients can query.
• Tampering — scene change, image too dark, image too bright, or the vendor's equivalent — published under the video-source tampering topics. This is the event most often absent from entry-level firmware, and adding a robust detector is real work if the SoC does not provide one.
• Metadata streaming, so a client can attach a metadata configuration to a profile and receive event and analytics metadata in the RTP stream.

5. Sizing the work: three tiers

Every migration we have looked at falls into one of three tiers, and the tier is set by the state of the existing ONVIF stack rather than by the camera hardware.

The single most useful thing a manufacturer can do this quarter is establish which tier each product line is in. That is a short, bounded piece of work — read the stack, run the Device Test Tool against the Profile T feature list, catalogue the failures — and it converts an unknown into a plan.

6. Testing and declaring conformance

Conformance is demonstrated, not asserted. The process has three parts, and the order matters.

1. ONVIF Device Test Tool. Run the Profile T test cases against the device on real firmware. Expect the first run to fail; the value is the failure list, which becomes the engineering backlog. Re-run after every significant firmware change, because a passing build is what gets declared.
2. Interoperability against real clients. The test tool proves the device speaks the specification. It does not prove that a particular VMS will discover it, pull the right stream, authenticate with digest, and render the events. Test against the platforms your customers actually run, including at least one that is itself Profile T conformant, before declaring.
3. Declaration of Conformance. The manufacturer submits the test-tool results and the declaration through its own ONVIF membership portal, per product and per firmware version. Only the manufacturer can do this; a contractor cannot submit on your behalf. Plan for re-declaration when firmware changes materially.

That third point has a planning implication that is easy to miss: if your ONVIF membership has lapsed, or is at a level that does not permit declarations, renewing it sits on the critical path and can take weeks on its own.

7. A working checklist

• Inventory every product line that declares Profile S only, with firmware version and SoC.
• Identify the origin of each ONVIF stack: in-house, contracted, or silicon-vendor SDK.
• Run the Device Test Tool against the Profile T feature list on current firmware and keep the failure report.
• Assign each line to Tier A, B or C.
• Confirm ONVIF membership status and declaration rights.
• Design the Media 2 service over the existing configuration model, keeping Media 1 alive alongside it.
• Implement digest authentication and the TLS 1.2 server with certificate management.
• Implement or verify tampering detection and the required event topics.
• Bring OSD, masks and metadata configuration into Media 2.
• Re-run the test tool until the Profile T cases pass on a release candidate.
• Run interoperability tests against the VMS platforms your customers use.
• Submit the declaration, and diarise re-declaration for the next firmware release.

8. Back-planning from 31 March 2027

Working backwards from the deadline with realistic buffers gives the following shape for a Tier B line. Tier A compresses it; Tier C stretches the implementation block and should start immediately.

The thing that breaks this plan is not the coding. It is discovering in January that the stack is Tier C rather than Tier B. The inventory and test-tool baseline in October exist to remove that risk while there is still time to act on it.

Where DevSpark fits

DevSpark is an ONVIF member and a UK engineering consultancy working on embedded video, protocol interoperability and edge AI. We help manufacturers with the engineering described above: a fixed-scope assessment of one product line against Profile T, a written gap analysis with the test-tool failures explained, a Media 2 implementation plan sized to your stack, and interoperability testing against real VMS platforms rather than the test tool alone. The findings are yours, the code is yours, and the declaration is submitted by you through your own membership. If you are carrying a Profile S only line and have not yet established which tier it is in, that assessment is the right first step, and we will tell you honestly if it is a small job.

See also: ONVIF Profile S deprecation 2027: what it means for your estate → for the buyer-side view, and ONVIF conformance engineering services →.

Sources and scope: ONVIF Profile T Specification and Profile T feature list; ONVIF Media Service Specification version 2 (Media 2); ONVIF Core Specification (event service, security); ONVIF Profile S Deprecation Q&A and the 9 October 2025 announcement; ONVIF conformance process documentation and Device Test Tool. Feature classifications summarised for planning; confirm mandatory and conditional status against the current specification and test tool before committing scope. Effort bands reflect engagements and reviews to date and are indicative, not quotations. Current at the date of publication.