There is nothing built-in for this. To limit users in real-time will take some work, but I will show you one approach. First though, the easier approach is to look back at logs. If some accounts are over, have a plan to bill for that. To add user info to logs follow this guide:
https://www.wowza.com/docs/how-to-track-streaming-by-users
Then you could aggregate x-duration values per user from rows with x-event “destroy” and x-category “stream”. There can be exceptions however, and it is actually best to get x-duration from rows with max(time). Parsing logs into db table(s) would probably be necessary for you. There is a way to log directly to a database, but I won’t even show it to you because it is too fragile for business use.
You might be able to start use Sawmill for this
The way to limit for a real-time Pay Per Minute (PPM) type system for Flash RTMP clients is using IMediaStreamActionNotify3:
https://www.wowza.com/docs/how-to-use-imediastreamactionnotify3-interface-to-listen-for-rtmp-stream-events-includes-codec-info
This system is probably going to want to interface with other systems. Direct JDBC calls to a db are better than HTTP calls to, for example, a web service, but both are going to impact the system.
For HTTP clients, with large chunk size in device cache, real-time PPM is harder to implement as precisely as for Flash RTMP clients. The way to involve HTTP and RTSP clients in a real-time PPM system is get data from the session objects and IOPerformanceCounter in these events:
public void onRTPSessionDestroy(RTPSession rtpSession) {
IOPerformanceCounter perf = rtpSession.getIOPerformanceCounter();
}
public void onHTTPSessionDestroy(IHTTPStreamerSession httpSession) {
IOPerformanceCounter perf = httpSession.getIOPerformanceCounter();
}
To monitor HTTPSession and kill it if it goes over, would be much more involved and be initiated in onHTTPSessionCreate and onRTPSessionCreate.
Again, be aware that interacting with backend systems is going to have an impact. Avoid HTTP calls. Use JDBC, but as minimally as possible. Looking back at logs has no impact.
Richard