Why Merge ONVIF Server and RTSP Server?

The Testing Imperative: ODTT Real Streaming Validation

The primary driver for merging these servers lies in the strict validation rules enforced by the ONVIF Device Test Tool (ODTT), particularly within the Real Streaming test suite. Consider the following test cases:

MEDIA2 RTSS-1-1-2-v21.06 — H.264 streaming over RTSP/HTTP/TCP
MEDIA2 RTSS-1-1-9-v21.06 — H.265 streaming over RTSP/HTTP/TCP

These tests verify a device’s ability to deliver streams using the RtspOverHttp protocol. The test tool first invokes the ONVIF GetStreamUri command, specifying RtspOverHttp as the desired protocol. It then attempts to play the stream using the returned URI. However, before playback, the tool performs a critical validation step:

Validation Rules (from ONVIF Test Specification):
• If the port number in the returned streamUri does not match the port of the ONVIF web service → FAIL (skip further steps).
• If the scheme (http or https) in the streamUri does not match the scheme of the ONVIF web service → FAIL (skip further steps).

This validation ensures that the streaming endpoint is fully consistent with the device’s management interface—a requirement that is only satisfied when the ONVIF server and the RTSP over HTTP server share the same address and port.

Example: A Passing Interaction

The following example illustrates a successful exchange that meets the ODTT requirements. Note that the ONVIF service is running on 192.168.3.168:80 using HTTP, and the returned stream URI uses the same host, port, and scheme.

GetStreamUri Request (to ONVIF Media2 Service):

POST /onvif/media2_service HTTP/1.1
Host: 192.168.3.168
Content-Type: application/soap+xml; charset=utf-8
Authorization: Digest username="admin",realm="happytimesoft",qop="auth",algorithm=MD5,uri="/onvif/media2_service",nonce="78054AAA780B17BC",nc=00000004,cnonce="806544330825C176051673EB787AB978",response="886190da828cc24de57838d2098125b6"
Content-Length: 380

<?xml version="1.0" encoding="utf-8"?>
<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope">
  <s:Body>
    <GetStreamUri xmlns="http://www.onvif.org/ver20/media/wsdl">
      <Protocol>RtspOverHttp</Protocol>
      <ProfileToken>ProfileToken_1</ProfileToken>
    </GetStreamUri>
  </s:Body>
</s:Envelope>

GetStreamUri Response (from merged server):

HTTP/1.1 200 OK
Server: Happytime onvif server V11.4
Content-Type: application/soap+xml; charset=utf-8

<?xml version="1.0" encoding="UTF-8"?>
<s:Envelope ...>
  <s:Body>
    <tr2:GetStreamUriResponse>
      <tr2:Uri>http://192.168.3.168:80/test.mp4&amp;t=unicast&amp;p=http&amp;ve=H265&amp;w=640&amp;h=480&amp;ae=PCMU&amp;sr=8000</tr2:Uri>
    </tr2:GetStreamUriResponse>
  </s:Body>
</s:Envelope>

In this response, the stream URI uses the same host, port (80), and scheme (http) as the ONVIF service, allowing the test to pass.

The Problem with Separated Servers

If the ONVIF server and the RTSP server are deployed as separate processes—often on different ports—the ODTT test will fail. For instance:

ONVIF server runs on port 80 (or 443 for HTTPS).
A separate RTSP over HTTP server runs on port 8000 to avoid port conflicts.

When GetStreamUri returns http://192.168.3.168:8000/stream, the port mismatch (8000 vs. 80) triggers an immediate failure. Similarly, if the RTSP server only supports native RTSP (on port 554) and not RTSP over HTTP, the scheme will be rtsp instead of http, causing a scheme mismatch failure. Therefore, to satisfy the ODTT specification, the RTSP over HTTP endpoint must be accessible via the exact same port and scheme as the ONVIF web service.

Beyond Testing: Practical Benefits of a Merged Architecture

While ODTT compliance is a critical driver, merging the servers offers several operational advantages that benefit real-world deployments:

1. Simplified Firewall and Network Configuration

With a single port (e.g., 80 or 443) exposed for both management and streaming, network administrators need to open only one port. This reduces complexity, lowers the attack surface, and simplifies NAT traversal and port forwarding rules.

2. Unified SSL/TLS Management

When using HTTPS for ONVIF and RTSP over HTTP/TLS, a merged server can use a single SSL certificate for all services. This avoids the overhead of managing multiple certificates across different ports and ensures consistent security policies.

3. Seamless User Experience

Clients (VMS, mobile apps) receive a single URL from GetStreamUri that works immediately without requiring additional port knowledge or configuration. This aligns with the ONVIF design goal of providing a unified interface.

4. Efficient NAT and Containerized Deployments

In environments with NAT (e.g., home routers) or containers (Docker, Kubernetes), exposing a single port is far simpler than coordinating multiple port mappings. It also reduces the risk of misconfiguration.

Implementation Strategies: Merging Without Monolithic Code

Merging the ONVIF server and RTSP server does not mean tightly coupling all functionality. A clean architecture can be achieved within a single server process by using request routing based on the URL path:

ONVIF SOAP requests — typically arrive at fixed paths like /onvif/device_service, /onvif/media_service, or /onvif/media2_service. These are routed to the ONVIF handler.
RTSP over HTTP requests — follow the HTTP tunneling method defined in RFC 2326, often using the root path / or a dedicated path like /rtsp. These are routed to the RTSP-over-HTTP handler.

Both handlers share the same TCP port, listening on the same IP address. This approach maintains modularity and separation of concerns while satisfying the ODTT port/scheme requirements.

Best Practices for Merged Deployment

Use a Single Port: Configure both ONVIF and RTSP over HTTP services to listen on the same port (typically 80 for HTTP, 443 for HTTPS).
Implement Path-Based Routing: Route /onvif/* to the ONVIF SOAP handler and other paths to the RTSP handler (or a root path handler).
Test with ODTT: Run the complete ONVIF test suite, especially the RtspOverHttp tests, to ensure compliance.
Consider TLS: If using HTTPS, ensure that the RTSP over HTTP/TLS implementation correctly upgrades the connection and shares the same certificate.
Document the Architecture: Clearly describe the merged setup in your integration guide to assist third-party developers.

Conclusion

Merging the ONVIF server and the RTSP server is not merely a matter of convenience—it is a requirement for passing critical ODTT compatibility tests and a sound architectural decision for real-world deployments. By unifying these services on a single port, developers ensure that GetStreamUri returns a consistent, test-passing URI, while also simplifying network configuration, security management, and overall system complexity. As ONVIF continues to evolve with profiles like Profile M (for metadata) and Profile T (for advanced streaming), maintaining a unified service endpoint will remain a key factor in achieving robust, standards-compliant devices.

Happytimesoft