Transitioning from Vonage OpenTok to Daily
This guide will walk you through common paradigms in the API for Vonage OpenTok (previously Tokbox OpenTok) and how they translate to Daily's API. The goal of the guide is to help you migrate an existing application from Vonage to Daily video and audio APIs.
As an alternative to migration, we encourage you to take Daily Prebuilt into consideration for your use case. Prebuilt is a complete, full-featured video call component that you can embed in your app or website with just a few lines of code.
If Prebuilt doesn't suit your use case, you can opt to follow the advice in this guide, which builds on top of Daily's Client SDKs.
If you are interested in migrating to Daily's infrastructure without modifying your application logic, please refer to our OpenTok shims.
We will first cover the core, high-level concepts and their mappings between OpenTok and Daily, and then look in more granular detail at specific parts of the API.
Vonage API key and secret → Daily API key
One of the most important distinctions between Vonage and Daily is in the developer credentials each API provides.
- OpenTok: Each Vonage project gets its own API key and secret. Both sets of Vonage credentials are then used on the server-side, and the Vonage API key is also exposed on the client-side.
- Daily: You get a single API key for your Daily domain. This key should never be exposed to a client. The Daily API key is not required for clients to join video calls or perform any other in-call operations.
You can read our blog post covering best practices for handling Daily's API keys securely for additional information and a usage example.
OpenTok sessions → Daily rooms
OpenTok connects users to sessions, which are conceptually equivalent to rooms in Daily.
- OpenTok: An OpenTok session ID is a randomized base64-encoded string (e.g.,
2_MX40NzU0Mjc1MX5-MTY3MFU3NjMzMTUwMn50ZkhWbHVpYlMxeVI1UXplYVBpYml1cFN-fn4) - Daily: A Daily room ID is a URL that consists of your Daily domain and room name (e.g.,
https://DOMAIN.daily.co/ROOM_NAME).
Daily rooms can be created through the developer dashboard or the REST API.
Unlike OpenTok's sessions, Daily rooms can have an optional expiry date along with other configuration properties.
If you create OpenTok sessions dynamically on the server side, you can write code similar to the following to create Daily rooms instead:
Additional resources
OpenTok session tokens → Daily meeting tokens
OpenTok's session tokens are equivalent to Daily's meeting tokens.
Meeting tokens can be obtained through Daily's REST API, or by self-signing a token using your Daily API key.
You can scope Daily's meeting tokens to be used with a specific Daily room or across your entire domain. Below is an example of how a room-specific self-signed Daily meeting token can be created on your server:
Additional resources
- Working with Daily meeting tokens
- Obtaining, handling, and validating meeting tokens in your video application
OpenTok publishers and subscribers → Daily participants
- OpenTok: Publishers and subscribers connect to an OpenTok session. Publishers can publish a
MediaStreamthat contains audio and video tracks. Subscribers represent remote users' media streams. - Daily: Daily uses a model of participants who join a Daily room. Each participant can send one or more media tracks.
The OpenTok camera and microphone track publisher is analogous to Daily's local participant, whose details can be obtained at any time through the participants() instance method.
For example, Daily participants can, in OpenTok's terms, publish or unpublish a video track by calling setLocalVideo()—here wrapped in a toggleLocalVideo() function:
To obtain either a local or remote participant's video track at any time, refer to the participant's tracks object:
When a media track is started for any participant, Daily emits a "track-started" event on the call object instance. The event payload contains information about the affected track. Likewise, when a media track is stopped, a "track-stopped" event is emitted.
By default, Daily automatically manages audio and video tracks as well as tracks for sharing screen audio and video. You can also add your own custom tracks to a participant.
- If you are using
daily-js, you can read our blog post about working with participants' media tracks. - If you are using our
daily-reactlibrary, we provide<DailyVideo />and<DailyAudio />components to handle tracks for you.
Despite all of the similarities between Daily participants and OpenTok publishers and subscribers, there are still some differences that may impact your existing application logic, especially for screen sharing:
Screen sharing logic
- OpenTok: A screen share has its own publisher that handles screen video and optionally screen audio. Existing OpenTok applications often include logic that treats a user's screen-share tracks as an object that's separate from the tracks coming off the camera and microphone.
- Daily: Users sharing their screen video or audio will simply have
screenVideoandscreenAudiotracks, which will be present on the participant object'stracksproperty.
Additional resources
OpenTok signals → Daily "app-message" events
- OpenTok: To send data to session participants with OpenTok, you would use OpenTok's signaling API to send and receive
"signal"events. - Daily: To pass data between Daily room participants, you will send and receive
"app-message"events.
"app-message" events can be sent on the client-side by using the sendAppMessage() call object instance method, or through our REST API's /rooms/:name/send-app-message endpoint.
Additional resources
- Implementing cursor sharing with Daily's
"app-message"events - Sending data to video call participants:
"app-message"or dedicated WebSocket?
OpenTok media modes → Daily network topologies
- OpenTok:
"relayed"or"routed"media modes. - Daily: Peer-to-Peer (P2P) or Selective Forwarding Unit (SFU) network topologies.
With OpenTok, you can select the "relayed" or "routed" media mode when you create a session. Daily opts for more standard WebRTC vernacular, so these modes translate to Daily's Peer-to-Peer (P2P) and Selective Forwarding Unit (SFU) network topologies respectively.
There's one key difference between OpenTok's media modes and Daily's network topologies: Daily's topology can change seamlessly while a call is in progress.
Daily's default network topology behavior
By default, Daily's rooms start out in P2P mode. Once more than two participants join the room, the room automatically switches to SFU mode.
You can customize this behavior by specifying the sfu_switchover property when creating a Daily room. The value you set on this property determines the maximum participant count to retain P2P network topology. Once more participants join, the room will switch to SFU topology.
If you would like the room to be in SFU mode as soon as the first participant joins, you can set the sfu_switchover property to 0.5.
Toggling between relayed (P2P) and routed (SFU) topologies
- OpenTok: You choose which mode you want when creating an OpenTok session. Swapping between modes while people are connected to a session is not supported at the time of writing this guide.
- Daily: You have the option of setting the default mode you want on room creation, but can then also switch modes on the fly by using our
setNetworkTopology()call object instance method.
To determine which topology is currently active in a Daily room, call the getNetworkTopology() method.
Additional resources
OpenTok and Daily event mappings
The following table illustrates some commonly used OpenTok events and similar Daily events that can take their place. Our reference documentation contains a full list of events emitted by Daily.
| OpenTok event | Similar Daily events |
|---|---|
"sessionReconnected" | "network-connection", "joined-meeting" |
"sessionReconnecting" | "network-connection", "joining-meeting" |
"sessionConnected" | "joined-meeting" |
"sessionDisconnected" | "network-connection", "left-meeting" |
"streamCreated" | "track-started" |
"streamDestroyed" | "track-stopped" |
"connectionCreated" | "participant-joined" |
"connectionDestroyed" | "participant-left" |
"exception" | "error", "nonfatal-error" |
Virtual backgrounds
- OpenTok: If you utilize custom virtual backgrounds with Vonage OpenTok, you're likely currently writing your own background replacement logic.
- Daily: Background-replacement logic can be expressed in a call to our
updateInputSettings()instance method:
Additional resources
- Add backround blur to a Daily call
- Adding video backgrounds to a Daily call in a browser app
- Adding video backgrounds to a Daily call in an Electron app
Live streaming with RTMP
OpenTok's RTMP live-streaming logic can be replaced with a call to Daily's startLiveStreaming() method with your RTMP URL. Our guide on live streaming with RTMP contains in-depth information about live streaming with Daily.
We also encourage you to look into our support for interactive live streaming, which supports up to 100,000 participants in an interactive real-time call.
Cloud recordings
If you're already writing to your S3 bucket with Vonage, you can have Daily write to the same one by following our S3 storage setup guide. We also provide a repository with sample code for this setup. Any existing logic to process these recordings should be modified to account for Daily's file-naming format for recordings.
Additional resources
Conclusion
We hope this guide serves as a fruitful starting point for developers interested in migrating from Vonage OpenTok to Daily's WebRTC video APIs. Please contact us if you have any questions or would like any support in your migration.