Forbidding Concurrent Stream Playing

In this article we'll quickly see how can you configure Wrench to prevent your users watching your stream concurrently in Wowza Streaming Engine®. First off, you have to be familiar with setting up user authentication using Wrench.

The latest version of Wrench comes out with powerful features that allows you to forbid concurrent playing of your video streams. The configuration parameter you have to use is wrench.duplicate.check. If set to true (by default its false)


Whenever a new client attempts to connect to your application, its username is resolved by token resolver query (wrench.token.resolver.sql) and Wrench checks whether there is any active client with the same name.

The limitation of the current implementation is that it does not support clusers. It is on the roadmap to perform duplicate player checks using SQL query, which would allow you to perform this check cluster-wide.

The limit is a per username limit, where the username is determined by the wrench.token.resolver.sql query based on the token passed by the client. So it is not affected by shared IP address or NAT or anything.

Advanced Concurrent Player Features

Wrench comes with two other nice features related to concurrency. One is that you can set a concurrency limit, say allow 3 people with the same username watching your stream. This can be set by the wrench.duplicate.limit (default is 1) option. The wrench.duplicate.drop.other toggle (true / false) allows you to kick off an existing player if someone connects and the limit for that username is exceeded. In that case a previous player with that username is disconnected. In case of RTMP players this results in an immediate black screen, but if you are using HTTP-based streaming, it might take up to a minute for the video to get interrupted, as the player might have already downloaded a long chunk of the stream.

For full reference of this setting and all the others, please read the Wrench configuration reference An overview of the authentication mechanism can be found here.

Update: versions from 2015.03.23. support concurrency checking in edge-origin setup as well in a cluster of Wowza Streaming Engine® instances

Duplicate Checking in multi-server scenario

Starting with version 2015.03.26. Wrench is able to check concurrency using the wrench.duplicate.check.sql SQL query. The idea is that all servers administer connection and disconnection events in a single database table, and duplicate checks are performed against this table. The SQL based checking is turned on by specifying the wrench.duplicate.check.sql query itself.

Below is a proposed configuration: the wrench.connect.accept.sql is responsible for the inserts, the wrench.disconnect.log.time.sql does the cleanup.

    <Value>insert into wtb_duplicates (clientid,username) values (:clientid, :username)</Value>
    <Value>delete from wtb_duplicates where clientid=:clientid and username=:username</Value>
    <Value>select count(id) from wtb_duplicates where username=:username</Value>


"How do I use Wrench or Measure in an edge-origin server setup? Connection information is not passed from edge servers to the origin, so you need to install the modules on each edge server. Of course they can all connect to the same database." So if we use a CDN, this basically can't work? Could you please reach out?

Hi, if you use a CDN and completely leave out Wowza from the game, then unfortunately my modules have no chance to get activated. However there is at least one CDN where Wrench still works with a trick.

Hi .. i tested this function and it worked perfectly as expected for RTMP but there is a problem with HLS, the client disconnect take long time on the server so when the client refresh he get denied because the server consider him as a second counnection. Cheers

Hi Simo, your point about the timeout delay on Wowza side is valid. I can suggest some workarounds. One is that you hook some Javascript code on the stop event of the HLS player and the "navigating away" browser event. In these cases you can send a message to the backend and delete the session from the database. (This assumes you are using database driven concurrency checking). An other approach is making the client wait for say 60 sec before actually allowing the player to play, e.g. a countdown. A third approach would be allowing +1 extra session for a certain grace period with Wrench, but this would also mean that someone can repeatedly watch a small chunk of the stream leveraging these grace periods.

Can you check this please