@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.