NGINX RTMP: Introducing asynchronous HTTP callbacks

This week I have finally implemented an extremely important feature - HTTP callbacks. The callbacks let move business logic away from RTMP server (for example to PHP).

The AMF handler implementation has been changed again since the last update to make callbacks really asynchronous. Now AMF call handlers are not stored in one place but chained by NGINX modules. Each module saves the last handler in a static variable and substitutes it with its own. The previous handler is called in the end of this module's handler. That gives great power to tear handler chain at any node. If for example a handler makes an HTTP request (using async send/recv handlers) it simply saves the handler context and returns from handler. When HTTP reply comes back it parses the result and invokes the next handler with the context saved.

Currently there are two modules implementing such callbacks: netcall module & notify module. The former provides basic (NGINX HTTP upstream-like) implementation of network AMF handler. It needs two handlers - one for creating request data and another for parsing the reply. Remember there's nothing about HTTP in this module. Any request-response network protocol is compatible with this module. The notify module is built on top of netcall module. It provides the following ready-to-use HTTP callbacks:

• on_publish


• on_play


• on_record_done

The request is made with HTTP POST method and content-type of application/x-www-form-urlencoded. All session data as well as handler arguments are passed to HTTP server with this calls. The first and the second callbacks use HTTP result code to make decision about further AMF handler processing. On success (2xx) the next AMF handler is called. On error (anything but 2xx) the AMF handler returns error and RTMP connection is closed. Remember the third call (on_record_done) does not expect any result. It only notifies you about flv file ready passing its full path along with other call arguments.