Video Chat / Streaming-as-a-Service Website

In this recipe the blueprint of a simple streaming-as-a-service system is outlined based on Wowza Streaming Engine® and Wrench module. This can be used for multipublisher and multiplayer video streaming solutions, e.g.:

This article assumes that you are familiar with the basics of Wrench installation and elementary setup. If not, then please check out this introductory article first and study the basics of how Wrench works.

The common in all the above scenarios is the following set of requirements:

The login part obviously means that users must enter your website and prove their identities before doing anything. The authorization part can mean that:

Some possible use-cases are:

Mechanics

In this case (as opposed to the most usual one trusted publisher - many authenticated players scenario), we are not going to utilize wrench.encoder.token, as that would open up the door for any publisher without restrictions. Instead, we are going to use dynamically generated tokens for both publishers and players. We are going to use the wrench.connect.authorization.sql to permit or deny players from starting a particular stream and wrench.publish.authorization.sql to permit or deny users from publishing a particular stream.

Happy-path scenario for a publisher starting a live stream

  1. The user logs into your website, his username and password is checked and a valid session is started
  2. The user navigates to the “Start Publish” page. If he has the proper role/balance/etc. a row is inserted into the database wtb_token table containing: the username, a dynamically generated token’s hash, IP, timestamp and the encoder=true flag.
  3. A HTML page is returned to the user, with the instruction that he can start to push the stream from his encoder software (Flash Media Live Encoder, or Wowza GoCoder, or any other software to the following URL: rtmp://wowzaserver:port/application/xystream?t=generatedtoken. The main point is that the user needs to receive a custom URL in which the token is present.
  4. When the user’s encoder software connects to Wowza, the Wrench module detects the attempt and based on the received token, is able or not able to associate the publisher with a user. This association is based on the executed wrench.token.resolver.sql, which is an arbitrary SELECT statement executed on the wtb_token table. Wrench allows some further tweaks here, like IP match-checking, token expiration checking, etc. See the reference for more details.
  5. If the token was resolved, Wrench will perform the configured wrench.publish.authorization.sql, which is an arbitrary query, that allows checking if the identified user is (1) allowed to publish (or only to play) at all, (2) allowed to publish the stream with that name, etc.
  6. If all the above went fine, Wowza will start receiving the video stream and allow players to connect to that stream.
  7. Optionally, Wrench can call back your system by POSTing a JSON message to the configured wrench.publish.http.url, allowing you to detect that the stream really started, so you can start listing that stream for players. When the stream is stopped, you’ll be notified again.

Happy-path scenario for a player connecting to a live stream

  1. The user logs into your website, his username and password is checked and a valid session is started
  2. The user navigates to the “Play Stream” page. If he has the proper role/balance/etc. a row is inserted into the database wtb_token table containing: the username, a dynamically generated token’s hash, IP, timestamp and the encoder=false flag.
  3. An HTML page is returned to the user, with the the list of various videos that are available to the user. The trick is that each video box or playback URL contains the token that was just generated for that user. An example URL is like rtmp://wowzaserver:port/application/xystream?t=generatedtoken. The details of how to set up different players (like JW Player or similar) is not covered here, see the FAQ for more details.
  4. The user chooses a video and click on the play button. His video player connects to Wowza, sending the token in the request
  5. Wrench intercepts the connection attempt and executes wrench.token.resolver.sql to find out who is connecting. Wrench comes with a large set of optional checks that you can turn on, e.g. IP, token expiration, duplicate play attempt, User-Agent, Http-Referer, etc. Wrench will now be aware of the user who is connecting, and the query should tell him that now it is a player coming, not a publisher.
  6. The next step is that the configured wrench.connect.authorization.sql is executed, which allows fine-grained control over which user is allowed to play which stream. This is the point where you can check if a particular user has bought a ticket for a stream or not.

Optional pay-per-minute or pay-per-view function

Wrench has a monitor job that is executed periodically (wrench.monitor.period). This job iterates over all players and publishers and can perform the configured wrench.ppm.update.sql and wrench.ppv.update.sql. These can be used to dynamically count the minutes each player has spend publishing or playing a stream for billing purposes. See this pay-per-minute article for details. The PPM module also enables you to dynamically check the client balances during streaming with wrench.ppm.disconnect.sql, dropping anyone who consumes all credit.

This above article is a vague outline for giving you a hint to implement your own live event streaming or video chat application based on Wowza Streaming Engine and Wrench. Not all details are covered, but if you have any questions after reading the other articles and the detailed reference, feel free to comment or contact us.