Simple redirect (publisher)

[lossius30]

Hello,

I would make a simple redirect (to other server) when a user begins broadcasting.

The problem is that a "push xxx", the stream is redirected to all those push servers, when my goal is to redirect the user to a single server.

When the user start broadcast, i try to redirected with a header Location: rtmp://x.x.x.x/app/test

nginx.conf : rtmp { server { listen 1935; ping 30s; notify_method post;

        application app {
            live on;
            notify_update_timeout 15s;
            on_publish http://x.x.x.1/publishStart;
        }
    }
}

The script located at http://x.x.x.1/publishStart make some stuff and end with an header Location: rtmp://x.x.x.2/app/test

The following error occur, nginx-error.log: 2015/07/04 14:17:38 [error] 27994#0: *35 notify: push 'test' to 'rtmp://x.x.x.x:1935/app/test', client: x.x.x.x, server: 0.0.0.0:1935 2015/07/04 14:17:38 [error] 27994#0: relay: no address

Any help would be appreciated

Thanks

[chetan-prime]

I had a similar issue with ffmpeg and on_play redirects. Thanks to @sergey-dryabzhinsky 's comment on ffmpeg I noticed that ffmpeg 2.x was working fine while 3.x was giving issues. So I just used avconv instead on the machine having ffmpeg 3.x installed and that works fine with on_play reirects. Do note that I am using nginx-rtmp 1.1.7 and "notify_relay_redirect on" to achieve this

[frickenate]

@sergey-dryabzhinsky Hi Sergey. I'm not sure if this feature covers my use case. I want to use notify_send_redirect to create a load balancer for publishers. The load balancer server has no ffmpeg, and will not accept play requests. This server's only purpose is to take publish requests, and return a 302 redirect so that the publisher will be sent to another server that will accept the publish and support playing.

Without notify_send_redirect, the "redirect" works properly - but of course the stream exists on both the original publish URL and where it was redirected to (keeping the original connection open and using double bandwidth). Once I enable notify_send_redirect, it just doesn't want to work. Whether the on_publish request for rtmp://10.10.10.2/app1 with stream name "hello" returns a 302 for rtmp://10.10.10.2/app2 or rtmp://10.10.10.2/app2/hello the publisher is not getting redirected. Right now I have app1 and app2 on the same machine for testing; later it would be a public IP equivalent for 10.10.10.3/app2 for example.

Do I understand this feature properly? I want the publisher to receive the new url and connect to that server instead. I don't want any ffmpeg or push involved, just purely forcing the publisher onto a different URL.

Separately, someone else here mentioned OBS (the most popular streaming client). Assuming this feature should do what I want, do we know if OBS supports handling 302 redirects?

[winshining]

@frickenate https://github.com/winshining/nginx-http-flv-module covers you use case. You can use it as following: server { application app1 { proxy_pass rtmp://host(ip or domain name)[:port]/app2; } }

[frickenate]

Am I wrong in thinking that notify_send_redirect in the fork of rtmp-module already supports this use case? Can you briefly explain what exactly it does if not sending the redirect to the client? No real documentation to find :)

[winshining]

@frickenate Sorry, I have no idea about directive 'notify_send_redirect'. What I've done is similar to what nginx does when it is used on Unix-like platforms (Windows doesn't support unix domain socket) and used in multi-processes mode: a process serves as a publisher, and relays streams to other processes, this is done through the locally unix domain sockets on a single machine. I extended the feature according to proxy & upstream features used in HTTP modules in nginx, simple redirect can be automatically done by it, without the help of sending redirect to the client. In addition, with it, you can play the stream both on the redirected servers and the balancer, since your play will also be relayed to the upstream servers.

[frickenate]

We're talking about different functionality then. I'm looking for a "simple" redirect from one rtmp server to another, the same way I can do an http redirect from http://example1.com/ to http://example2.com/. What you are talking about is a reverse proxy, where http://example1.com/ would proxy the request to http://example2.com/, instead of telling the client to go look at example2.com themselves. That is not acceptable as it requires twice the bandwidth (as well as cpu and memory overhead). I believe this is what rtmp notify redirect is supposed to accomplish - but I might be wrong. I'm trying to avoid the extremely complicated and prohibitively expensive requirement of a setup known as "Direct Server Return", which heavily manipulates the TCP stack.

Basically: I should be able to handle thousands of publishers connecting to a single load balancer on publish.example.com, whereby each incoming publish connection is redirected to one of a hundred backend servers (ie: publish001.example.com through publish100.example.com). Having publish.example.com be a reverse proxy to 100 backend servers doesn't work - you can't support a reverse proxy of 1,000+ clients at 1000-3000 KB bitrate each.

[sergey-dryabzhinsky]

@frickenate The main issue is publisher itself. It must understand "redirect" status error response. Like I mention

• librtmp must be patched, ffmpeg if compiled w/o it - must be patched too.
• FMLE don't understand it. Adobe suck.
• Flash reaction is unknown, flash/as3 recorder must be programmed correctly.

I suppose that simplest way is to make a pool of receivers (domains). And each of them will have several IPs defined in DNS. Which may round-robin them or stick some to sender IP. Or use some CDN, like Akamai / Cloudflare.

[winshining]

@frickenate Yeah, you gave the scenario not pratical for reverse proxy which I didn't take into consideration. Maybe 'notify_send_redirect' is a good solution, but it requires clients to support 302 redirection, whereas not every client meets the requirement. Hope someone can work it out!

[potsky]

@frickenate If you want to support any client, this is unfortunately not the solution. You need to manage a load balancer which support DSR. All ingress servers directly respond to client without pass thru the load balancer. Take a coffee and watch this https://www.youtube.com/watch?v=bxhYNfFeVF4

No L7 for RTMP, no anycast at start and not obliged to used ECMP, round robin will be ok.

[pgharios]

Hello, is the rtmp publishing redirect feature working with the patched module? I was checking the above conversation but lost track along the way. Idea is to completely redirect publisher to a given server instead of relaying from server to server Thank you

[mpisat]

Hello, is the rtmp publishing redirect feature working with the patched module? I was checking the above conversation but lost track along the way. Idea is to completely redirect publisher to a given server instead of relaying from server to server Thank you

I don't think OBS supports this redirect. I tested it and checked with WireShark, OBS keeps staying connected to the nginx instead of following redirect so Load Balancing is not working unfortunately.