Webooks vs REST API polling... significant timing differences?!?

[Jonny_Roller]

We’re are migrating away from polling the REST APIs (/live_streams, every 4 to 8 seconds) to using webhooks for determining when a stream has started and when the audio/video has connected. We are about halfway through that process. However, I am noticing a significant delay (10 to 60 seconds) between a webhook notification and confirmation of that change via the REST APIs. Are the webhooks telling me something different than the REST APIs? Is the polling we are currently doing causing some “throttling” to occur? Our intended end state is to wait for confirmation from the webhooks before making REST API calls to pick up the details. But from what I’m seeing at this point, I will still need to have a polling mechanism in place because of this lag.

Has anyone else seen a discrepancy in the information returned from these two mechanisms?

[Rose_Power-Wowza_Com]

Hello and sorry to hear that since that’s the whole point of webhooks is to save time and resources. Can you please let us know if you are using webhooks in Streaming Cloud or Streaming Engine?

Then I can check with the team.

[Jonny_Roller]

I’m going to say “Streaming Cloud” because none of our invoices contain the word “engine” in them.

[Rose_Power-Wowza_Com]

Unfortunately, we would need to know to accurately troubleshoot and review your configuration as the webhook config is quite different in each product. Haven’t heard anything about delays in webhooks though, so please send a ticket and we’ll investigate what’s happening.

This is the only doc I have though if it is Cloud. We’d still like to see a ticket to help you identify the issue, Thanks!

https://www.wowza.com/docs/wowza-streaming-cloud-webhook-event-reference-documentation

**Possible causes to consider @Jonny_Roller

1. The Cloud transcoder is what sends the webhook notification and the transcoder in Cloud has to be assigned. This can take up to 60 seconds sometimes, although rare to take that long.

2. The REST API service though will respond that the IP address has been propagated to the DNS, so when you poll, you may get a response that looks different than the webhook notification, but may not mean the same exact thing,

3. It is possible that your server, bandwidth and network conditions aren’t capable of ingesting the webhook notifications at a rapid pace. Depends on a few variables like volume of streams/webhook notifications you have set up.

[Jonny_Roller]

I’m not having a problem with the webhooks. It’s the REST API calls regarding the streams that I can no longer trust. If I create a stream, it won’t show up in the /live_streams response until 10 to 60 seconds later. Likewise, when I stop a stream, it will appear to be still connected after calling the stats endpoint.

I’m trying to program work-arounds for these issues in my production system now. Will try to submit a ticket and/or provide more details here soon.

[Jonny_Roller]

I’m finding that by adding “?ts=” and the current time to each endpoint URL, I am now getting accurate and up-to-date information from the API calls. Although I’m not seeing it at the moment, I’m going to humbly conclude that the issue is on my end.