Bug: Config http_api and rtc_server.tcp listen on same port. about srs HOT 2 OPEN

APIs and WebRTC are capable of functioning together, and the type of protocol can be determined based on the content of the body. If they do not work well together, it is actually due to issues with the software implementation rather than the protocols being unable to recognize each other.

Since the Listener is a mechanism that is continuously patched, it is not considered reasonable. A better approach would be to completely redesign the mechanism of the Listener.

It is important to note that the SRT's listener requires special handling. For reference, see the issue at #3251 (comment). This issue necessitates improvements to the current structure.

TRANS_BY_GPT4

from srs.

Let APIs and WebRTC works on same endpoints would be easy, just refer the reuse_rtc_over_server_ code will add this feature, and really make sense, if reuse_api_over_server_ & reuse_rtc_over_server_ can be both true, then why not another reuse_rtc_over_api_? This is a small patch, can introduce a tiny but controllable complexity.

I like the SrsTcpListener's design, it's really light weight, lower-level abstraction and flexible, maybe I didn't know more better one.

One more thing to consider, the listen config, I notice the inconsistence here.

    virtual std::string get_http_api_listen();
    virtual std::string get_https_api_listen();
    // Get the http stream listen port.
    virtual std::string get_http_stream_listen();
    virtual std::string get_https_stream_listen();
    virtual std::string get_exporter_listen();

For the RTMP, http_api, http_server, the listen config means endpoint = [ip4/6 | any address] + port;

But for the rest of the listens, which means just port number (or just ipv4 loop back address + port number).

    virtual std::vector<std::string> get_listens();
    // Get the listen port of stream caster.
    virtual int get_stream_caster_listen(SrsConfDirective* conf);
    // Get the sip.listen port configuration.
    virtual int get_stream_caster_sip_listen(SrsConfDirective* conf);
    virtual int get_rtc_server_listen();
    virtual int get_rtc_server_tcp_listen();
    // Get the srt service listen port
    virtual unsigned short get_srt_listen_port();

Here is how gb28181 config its listener, I think it lost its flexibility.

Because srs_any_address_for_listener() will return the ipv4 loopback in priority. I would rather suggest use a string to represent the listen config, at least it have the capacity of ipv6 address and explicit ip addresses (for the machine with multi physical and virtual network interfaces).

from srs.