[Developers]

Duty of Care Video

A duty of care operator needs to assess the situation around a traveler who has reported a threat but cannot describe it clearly. A voice call gives limited information. A video call changes everything: the operator can

Category: Api DomainsLast Updated: Feb 5, 2026
api-domainsreal-time

Overview#

A duty of care operator needs to assess the situation around a traveler who has reported a threat but cannot describe it clearly. A voice call gives limited information. A video call changes everything: the operator can see the traveler's environment, observe their physical state, and make a much more accurate assessment of the immediate risk level. When multiple parties need to coordinate, the traveler, the local security provider, and the home office, a conference call brings everyone into the same visual context.

The Duty of Care Video module provides that multi-modal communication capability, with recording and transcription turning every call into a documented incident record.

Key Features#

  • One-to-One Calls: Direct video calls between operators and travellers for personal welfare checks and incident assessment.
  • Conference Calls: Multi-party video conferences for coordinated incident response with multiple participants.
  • Broadcasting: One-to-many video broadcast for mass briefings and emergency communications.
  • Call Recording: Record video calls for documentation, training, and audit purposes.
  • Real-Time Transcription: Live transcription of video calls for accessibility and record-keeping.
  • Participant Management: Track and manage call participants with join/leave capabilities.
  • Programmable API Access: Full API support for all video operations.

Use Cases#

Duty of care operators conduct face-to-face welfare checks with travellers during security incidents, using visual assessment to evaluate risk factors that a voice call alone would not reveal.

Multi-agency response coordinators run conference calls between operators, supervisors, and field personnel during complex incidents, with all participants sharing the same visual context for coordinated decision-making.

Security programme managers broadcast emergency communications to groups of affected travellers during mass casualty or major disruption events, reaching multiple individuals simultaneously with a consistent message.

Training and quality teams review recorded video sessions for post-incident learning, with transcription providing searchable text records of conversations that would otherwise require full playback to review.

Integration#

  • Connects with duty of care incident management for incident-linked video sessions.
  • Integrates with duty of care telephony for voice-only fallback.
  • Feeds into duty of care audit logging for complete call records.

Open Standards#

  • WebRTC (W3C/IETF): The core peer-to-peer audio and video communication stack, including the browser APIs and protocol suite, underpins every call type in this module.
  • SDP (RFC 4566, Session Description Protocol): Offer and answer messages exchanged during call setup carry SDP payloads that describe media capabilities, codecs, and transport parameters between peers.
  • ICE (RFC 8445, Interactive Connectivity Establishment): ICE candidates are gathered and exchanged via the signalling channel to discover the optimal network path and traverse NAT between participants.
  • STUN (RFC 8489, Session Traversal Utilities for NAT): STUN servers are configured for each call session to allow peers behind NAT to discover their public address before attempting a direct connection.
  • TURN (RFC 8656, Traversal Using Relays around NAT): TURN relay servers are supported for participants on restrictive networks where a direct peer-to-peer path cannot be established via STUN alone.
  • WebSocket (RFC 6455): The real-time signalling channel for forwarding SDP offers, SDP answers, and ICE candidates between peers is implemented over a persistent WebSocket connection.
  • JWT (RFC 7519, JSON Web Token): WebSocket connections and REST endpoints are authenticated using signed JWTs carried as a session cookie, with claims verified before any signalling messages are processed.
  • ISO 639-1: Language codes returned with transcription output follow the two-letter ISO 639-1 standard, enabling downstream processing and accessibility records to identify the spoken language correctly.

Last Reviewed: 2026-02-05 Last Updated: 2026-04-14

Ready to Build?

Get started with our APIs or contact our integration team for support.