Background
I have two wowza apps:rtp and rtp-cr. Both of them use the MediaCaster API and rely on a IMediaStreamNameAliasProvider3 to resolve a stream alias. Both apps have unique custom java modules; each of which overrides onAppStart to call setStreamNameAliasProvider. There are some differences between them:
-
rtp-cris for recording 24/7 streams and has historically used stream files to save static RTSP URIs -
rtpstarts streams on demand, and terminates them after a few minutes. Streams are started exclusively via the mediaCaster API
We’re on Wowza version 4.8.28. We can’t upgrade due to outstanding issues in future wowza versions that break certain devices.
Problem
We now have some devices with dynamic RTSP URIs, so rtp-cr cannot rely on static stream files for these devices. Instead, we’ll have a daemon start the stream with the MediaCaster API, and rely on stream aliasing to resolve the device URI.
In practice, the rtp app calls resolvePlayAlias and resolveStreamAlias as expected. But the thertp-cr app only calls resolvePlayAlias. So when I used the Media Caster API to start a stream for rtp-cr, I end up with an Incoming Stream stuck in the Waiting For Stream state. This is the problem I’m trying to solve.
Analysis
Here are the relevant logs when starting a stream on each app:
# rtp-cr
2024-10-30 17:33:41 UTC INFO -> 200 ApplicationInstance.startMediaCasterStream[rtp-cr/_definst_]: Stream started: mp4:device1 - - - 5.848
2024-10-30 17:33:41 UTC INFO -> 200 RTPMediaCaster.Reconnector[1964503668:rtp-cr/_definst_:device1]: start: 1 - - - 5.853
2024-10-30 17:33:41 UTC INFO -> 200 RTPSessionDescriptionDataProviderBasic.getStreamInfo[rtp-cr/_definst_]: /usr/local/WowzaStreamingEngine/content/device1 - - - 5.954
2024-10-30 17:33:41 UTC WARN -> 200 RTPSessionDescriptionDataProviderBasic.getStreamInfo: SDP file missing: /usr/local/WowzaStreamingEngine/content/device1 - - - 5.954
# rtp
2024-10-30 17:26:48 UTC INFO -> 200 ApplicationInstance.startMediaCasterStream[rtp/_definst_]: Stream started: mp4:device1 - - - 1956.056
2024-10-30 17:26:48 UTC INFO -> 200 StreamNameAliasProvider.resolveStreamAlias: device1 -> rtsp://<url> - - - 1956.156
The logs suggest that rtp-cr is trying and failing to look up the stream URI from a nonexistent stream file.
This isn’t surprising, since that was the intended workflow up until now. But if it’s causing trouble, then how can I avoid that lookup for specific streams?
Unsatisfactory Workaround
One workaround I’ve tried is to resolve the RTSP URI before invoking the mediaCaster API, but this results in an Incoming Stream with a name that matches the URI. This is not ideal; we’d like the stream name to be the device id, for debugging purposes. If there was a Media Caster method allowing us to set the stream name and URI independently, this could work.
The decompiled wms jars show an undocumented startMediaCasterStream operation that accepts an additional String argument. I had hoped this was a stream name, but trial and error show it seems to be a port.
boolean startMediaCasterStream(String var1, String var2, String var3);
Conclusion
I’m hoping someone can help me understand what factors and configuration settings may lead to resolveStreamAlias not being called for this one app. Unfortunately, there’s a lot of code, which can’t be easily shared.