I am looking to use Wowza Streaming Engine running in a cloud instance to receive SRT streams from various locations and be able to pull those streams using an SRT receiver/player on the ground in my office.
The receiver in the office is behind a firewall which I have no control over and permits outbound traffic ONLY. The security in the cloud I have control over so am able to permit inbound connections. Therefore I need the receiver to act as the SRT Caller to request & pull the stream from Wowza.
As I understand it Wowza currently only supports SRT Stream Target where Wowza acts as the Caller. Is this correct and is there any plans to implement Stream Targets in listener mode.
It would also be advantageous for Wowza to be able to generate SRT stream āon the flyā when a pull request is received in a similar manner to how RTMP streams can be Pulled without requiring the manual step of a Stream Target being created.
That is correct. The SRT stream target is a caller where Wowza Streaming Engine is pushing a single SRT stream to a single destination. But, I can add this as a feature request and thank you for the post.
How likely is it that this feature will get included into Wowza and potential timeline.
This is a feature my company is urgently in need of and if this is not likely to be implemented then we need to venture elsewhere for a solution.
Hello Rose and the team,
is there any progress on this feature request? Itās been a long time since Wowza started using SRT as the key feature in marketing but this feature is now more and more wanted and weāre already using our workaround to receive streams from broadcasters requiring SRT pull vs. push to Wowza in listener mode.
Can you please try getting curent timeline?
@Alex_C I see that you are one of the forum moderators,
could you please relate to the topic? I see that Roseās user was disabled in December 2022.
This is very important to allow people to actually connect in various networking scenarios. Not having it forces us to switch to other products for simple notion of SRT delivery in listener/caller/rendezvouz mode - whichever is needed at the moment. And it happens more and more frequently, because SRT is already very widespread.
Especially that implementing this in Wowza Streaming Engine seems like a very simple modification, because it is not Wowza code to handle it but libsrt:
It requires ust adding a mode option to the stream target properties (listener/caller/rendezvouz - e.g. even as a string, or coded as an integer: 1,2,3), which would be passed on to the libsrt library, and that library would do the actual work of handling it properly. The target host address just needs to be 0.0.0.0 or some own IP (just like in a .stream file for SRT). Well anyway it is the responsibility of the libsrt library to handle everything, so Wowza should not care anyway.
And the same way we could add a property to a .stream file for SRT mode - again a simple option (listener/caller/rendezvouz - e.g. even as a string, or coded as an integer: 1,2,3), and the libsrt library will do whatās needed
Well this seems as the simplest implementation one could wish for. Perhaps you have some complicated Wowza code which does some roller-coaster all over the place in order to place a simple call to libsrtā¦ but I honestly doubt it would be so terrible. And I guess that SRT version requirement (1.4 or earlier - as stated in āIngest and publish an SRT stream with Wowza Streaming Engineā docs article) is simply because you havenāt ported your libsrt usage to 1.5, which is perfectly normal; and 1.4 is good for me!
I also submitted a support request for the above, letās see how it goes.
We have received your Support Ticket with the request to update SRT implementation.
Thank you for taking the time and composing a thoughtful request for a better SRT implementation.
We do have a Support engineer who will take ownership of the support ticket and discuss it further with our Product Owner.
Please provide specific workflow requirements not met with the current Wowza Streaming Engine SRT implementation as this will help prioritize the feature.
Well the most important is that when we want to distribute the processed stream further (i.e. stream targets). We often send to mulitple recipients (targets) of our partners, production teams etc - some of them for their own processing - they want to ingest the stream into their live production workflow, e.g. into vMix or other production tool. So naturally most of times these production system are not open on any public IP, but hidden behind a NAT in some local network, so they can only initiate connection. In SRT this translates to Caller mode, which means that our Wowza Engine Server has to be in Listener mode instead of Caller. This is the most common scenario, is really needed, so Iām not surprised that this forum topic was started.
Also rarely the scenario needs to set Rendezvous mode on both sides in the stream target - for convenience, i.e. less messing around with configuration changes. So as someone does implementation work in Wowza Streaming Engine, it should be also given simply as another property value for libsrt option, as it is part of the SRT standard. But this is rare, so not so important.
On the stream ingestion side (.stream files) it is also rare to specify a different SRT mode than the default Listener. But sometimes our partners have SRT a streaming server that they do not send the stream to us, but provide a Listener SRT Server with specific StreamID. This is made in order to multiple partners (including us) receive from them the IP, port and StreamID, so that they (we) can connect via SRT Caller mode and providing this StreamID, in order to just pull the stream.
So, again as with the Rendezvous mode above, if you are doing some implementation work in Wowza Streaming Engine regarding simple SRT options (connection mode Caller/Listener/Rendezvous and StreamID), and if it acutally is as simple and trivial as it seems, then it would be nice to implement the same in the .stream file, because .stream files can have their own properties/options, including SRT properties (like srtLatency, srtKeyLength, srtPassPhrase, etcā¦)
