Opentok Video API Callback Service Update Jan 2024 Opentok Video API Callback Service Update Jan 2024

Opentok Video API Callback Service Update Jan 2024

Vonage API Support

 

Vonage added support for Secure callbacks and has been converging the architecture that handles callbacks to use the common Vonage Callback service. In order to complete development, we will move all callbacks, which were originally handled by separate services. This change also allows any callback to be secured with a signature secret, without needing to enable the ‘secure callbacks’ flag in the dashboard. 

The change is expected to go into effect mid-Jan 2024. (approx week Jan 15)

What changes in the new callback services:

Callback IP address

The IP Address range used by the Vonage callback service will be of a different set than previous Video API callbacks. Please allow the following range to enable seamless communication with Vonage secure callbacks: 216.147.0.0/18. (note: This address is now part of IP whitelist)

Callback retry and backoff policy changes

What will happen if the callback events of my application goes down?

  • Previous behaviour: Vonage will retry 4 times for each event that we fail to deliver to the application server. For Session Monitoring Only - If the platform detects 50 delivery failures within a 30 minutes time frame, the event forwarding was disabled for Session monitoring callbacks. A notification email was sent to the customer to notify that callbacks were disabled. To re-enable event forwarding, the Session monitoring callback URL needed to be configured again via the Vonage Video API Account Portal.
  • New behaviour: Once new callbacks are enabled on the account, a new callback service is used. The new service will use a retry and backoff policy to try and deliver any individual callback (e.g. archiveStopped, archiveAvailable, etc) of any type (Session Monitoring, Archiving, SIP, or Experience Composer) for up to 24 hours. After 24 hours, the individual callback retry logic will stop and the individual callback event will no longer be sent. The retry logic strategy, is based on exponential backoff (the wait doubles before each retry) The initial backoff retry is 5 seconds and then time between retries doubles each time increase to every 15 min until 24hours is reached. Additionally, the callback retry would be only enable for connection error (5xx) or connection timeout.

      1. initial_back_off: 5 seconds
      2. max_back_off: 15 minutes
      3. max_retry_time: 24 hours

Important: The new service will no longer disable event forwarding in the case of excessive delivery failures, since the retry and backoff mechanism will be used. Therefore, there will no longer be any expected email indication to notify that callbacks were disabled and need to be re-enabled, because the new service will not suspend/disable callbacks in any way.