Forward: Fetch the URL to forward from a backend, dynamic forwarding, on-demand forwarding, forwarding Hook.

[ArvinRokni]

Wiki

• EN: https://ossrs.io/lts/en-us/docs/v5/doc/forward#dynamic-forward
• CN: https://ossrs.net/lts/zh-cn/docs/v5/doc/forward#dynamic-forward

Usage

Start backend server:

python research/api-server/server.py 8085

Start master SRS enables forwarding with backend:

./objs/srs -c conf/forward.backend.conf

Start slave SRS server, to which forward by master:

./objs/srs -c conf/forward.slave.conf

Publish to master by FFmpeg:

./objs/ffmpeg/bin/ffmpeg  -re -i ./doc/source.flv -c copy -f flv rtmp://127.0.0.1:1935/live/livestream

Play the stream:

• Master SRS: rtmp://127.0.0.1:1935/live/livestream
• Slave SRS: rtmp://127.0.0.1:19350/test/teststream

Note that you could change the backend urls by:

srs/trunk/research/api-server/server.py

Line 884 in e222f0d

forwards = ["rtmp://127.0.0.1:19350/test/teststream"]

TRANS_BY_GPT3

[winlinvip]

It's a good idea to change the forward url in config to dynamic url, which is fetched from backend api.

[winlinvip]

Check it in next release.

[HowQuitVim]

Check it in next release.

this feature is very useful and import for me ,please release it as soon as possible,thanks

[winlinvip]

Also need to carry the right vhost, #1213

[winlinvip]

Or parse the url from the publish url query string, #53

[winlinvip]

But sometimes, we should remove the vhost, #2130 or #1202

[winlinvip]

Use scenario by https://github.com/clime

Hello,

I would like to setup RTMP forwarding based on stream key. That is, I would like to specify rules like:

• rtmp://address.com/live/key1 -> forward to machine1
• rtmp://address.com/live/key2 -> forward to machine2

Is it possible? Thank you

[winlinvip]

Thank you @chundonglinlin for providing the Forward scenario used in actual business. Please refer to #2799 (comment)

After some consideration, I realized that all these scenarios can actually be achieved by improving the fourth scenario. By configuring dedicated backend services, we can achieve these forwarding operations, for example:

    forward {
        enabled on;
        destination 127.0.0.1:1936 127.0.0.1:1937;
        backend http://127.0.0.1:8085/api/v1/forward;
    }

If the forward.backend parameter is configured, then first access this backend service (with streaming parameters and other information) to obtain the forwarding address (otherwise use the destination address as the default forwarding address). In this way, the destination becomes the default forwarding address, and the backend provides an opportunity to modify the forwarding address.

Verify the mentioned scenario:

• Scenario one: Default scenario, no backend configuration, continue using the current Forward method, and existing users are not affected.
• Scenario two: Matching certain streams, the backend returns specific forwarding parameters based on the stream name.
• Scenario three: The client specifies forwarding parameters, and if the backend detects that the client has specified them, it uses the client's parameters. This can also avoid the server parsing and configuring these parameters.
• Scenario four: 302 Redirect for on_publish. Decouple these two APIs, and on_publish will only perform validation, while the forwarding will be handled by the backend service configured through Forward.
• Scenario five: Issued by the API, which is basically described in this solution.

Additionally, points to consider:

• Protocol description, specifically the definition of this API, including parameters, request, response, and error codes.
• Which parameters are required and what they mean need to be clarified.
• Definition of behavior when errors occur, whether to refuse connection retry or try another backend (whether multiple backends need to be supported).

Please update this issue as an important reference material.

TRANS_BY_GPT3

[chundonglinlin]

Thank you, Boss Yang, for providing the specific plan. I will reorganize the logic and proceed with the implementation. One additional point to note is that the users need to have the ability to build the backend service after incorporating the above mentioned scenarios.

TRANS_BY_GPT3

[winlinvip]

Yeah, that's right. Except for scene one, which has default forwarding, all the other scenes require independent backend server support. I think this is the future direction because it allows for complex business logic to be placed on external servers, which can be implemented using Go or Node.js. This way, stability and flexibility are also improved.

This backend server can share the same set of APIs with the HTTP callback, so please ensure that the APIs are not conflicting when designing them.

TRANS_BY_GPT3

[chundonglinlin]

Currently, after implementing one version, it was found that scenario five cannot be covered. Scenario five is the logic actively transmitted by the backend service, while scenarios one to four belong to the operation of unidirectional query and creation of relay. Is it necessary to support something similar to SrsGoApiForwarder?

Explanation of the backend API interface /api/v1/forward:

Request:
     POST /api/v1/forward
     {
         "action": "on_forward",
         "server_id": "vid-k21d7y2",
         "client_id": "9o7g1330",
         "ip": "127.0.0.1",
         "vhost": "__defaultVhost__",
         "app": "live",
         "tcUrl": "rtmp://127.0.0.1:1935/live",
         "stream": "livestream",
         "param": "?auth_token=xxx&forward=rtmp://ossrs.net/live/livestream"
     }
Response:
     {
         "code": 0,
         "data": {
             "forwards":[{
                 "url": "rtmp://ossrs.net:1935/live/livestream?auth_token=xxx"
              },{
                 "url": "rtmp://aliyuncdn.com:1935/live/livestream?auth_token=xxx"
              }]
         }
     }

TRANS_BY_GPT3

[chundonglinlin]

Scene five may be a type of requirement that is strongly related to the business, relatively more complex, and how to cover and test these scenes is a big issue, so let's first support forwarding backend in simple scenes.

TRANS_BY_GPT3

[winlinvip]

@MohammadZarifiyan If want some discussion, here's the discord.

[ximenpo]

Another solution is to expand the return value of "on_publish" and directly return "whether to enable DVR", "forward list", etc. This way, the required status will be initialized when the source is initialized and there is no need to worry about the status issues during the streaming process.

TRANS_BY_GPT3

[winlinvip]

@ximenpo, returning from on_publish is a viable solution, but from a design perspective, it is extremely poor because on_publish is primarily for handling streaming events. Relaying, on the other hand, is Forward's own internal strategy, and forcibly combining two unrelated logics and modules is not ideal.

As for the management of the source's state, it belongs to the specific implementation and is unrelated to any specific callback. The interface and implementation have no connection and should not have any connection. They should be considered independently. The interface only needs to consider whether it meets the expectations and assumptions in terms of usage, while the implementation can be continuously adjusted.

What is an assumption that meets usage requirements? Users who use "on_publish" are typically responsible for authentication and event handling, and they may not necessarily be aware of the concept of "Forward". On the other hand, "Forward" is often used for stream forwarding, which is related to system integration, and they may not be concerned about events.

TRANS_BY_GPT3