ossrs/srs

Turn to push aws lvs failed

Closed this issue · 1 comments

191474639 commented

!!! Before submitting a new bug report, make sure you have asked the AI about your issue, because we have setup the project with docs for AI, so AI know everything including questions, usage, bugs, features, workflows, etc.

Describe the bug
A clear and concise description of what the bug is.
aws address : rtmps://cf2238438596.global-contribute.live-video.net:443/app/sk_eu-central-1_j1MqXF46WVhq_XrsRBUC2Wu56rOBCeMhfyCUkc4ZU9P

Version
Desribe your SRS Server version here.
6.0
To Reproduce
Steps to reproduce the behavior:

  1. Go to '...'
  2. Click on '....'
  3. Scroll down to '....'
  4. See error

Expected behavior
A clear and concise description of what you expected to happen.

Screenshots
If applicable, add screenshots to help explain your problem.

Image Image

Additional context
Add any other context about the problem here.

winlinvip commented

Why SRS Doesn't Support RTMPS in Forward Feature

1. Architecture Design - Server-Side SSL Only

SRS's SSL/TLS support is designed for server-side connections only (accepting incoming RTMPS connections), not for client-side connections (initiating outgoing RTMPS connections).

  • What SRS supports: RTMPS server - accepting encrypted connections from clients (publishers/players)
  • What SRS doesn't support: RTMPS client - making encrypted connections to other servers

2. Forward Feature Uses Simple RTMP Client

The forward feature in SRS uses SrsSimpleRtmpClient which is a basic RTMP client implementation that:

  • Only supports plain RTMP protocol (no SSL/TLS layer)
  • Generates URLs using srs_net_url_encode_rtmp_url() which always creates rtmp:// URLs
  • Has no SSL handshake or encryption capabilities for outgoing connections
  • The srs_net_split_hostport() function doesn't parse RTMPS URLs correctly (treats entire URL as hostname)

3. Technical Complexity vs. Use Case Priority

Adding RTMPS client support would require:

  • Implementing SSL/TLS client handshake logic
  • Managing SSL certificates and validation for outgoing connections
  • Handling SSL errors and reconnection scenarios
  • Updating URL parsing to handle rtmps:// scheme
  • Significant code complexity for a relatively rare use case

Most SRS deployments use:

  • Plain RTMP for internal forwarding between SRS instances
  • RTMPS only at the edge (user-facing connections) for security

4. Why Use FFmpeg Instead

FFmpeg is the recommended solution because:

✅ FFmpeg already has mature RTMPS client support

  • Battle-tested SSL/TLS implementation
  • Handles all edge cases and error scenarios
  • Supports certificate validation and various SSL options

✅ Automated with SRS HTTP Hooks

Instead of manually running FFmpeg, use SRS HTTP Hooks to automatically manage FFmpeg processes:

  • on_publish event: When a stream is published to SRS, your HTTP callback server receives the event and automatically starts an FFmpeg process to relay the stream to the RTMPS destination (e.g., AWS IVS)

  • on_unpublish event: When the stream stops, your HTTP callback server receives the event and automatically stops the corresponding FFmpeg process

This provides a fully automated, production-ready solution where:

  • Streams are automatically relayed when published
  • FFmpeg processes are automatically cleaned up when streams stop
  • Multiple concurrent streams are handled dynamically
  • No manual intervention required

✅ Separation of concerns

  • SRS focuses on high-performance streaming and protocol conversion
  • FFmpeg handles the secure external delivery
  • HTTP callback server manages the automation logic
  • Each component does what it does best

5. AWS IVS Specific Context

AWS IVS requires RTMPS for security reasons (protecting stream keys in transit). The recommended architecture is:

The video stream is published to a Streaming Relay Server (SRS) using RTMP or RTMPS protocol, which then triggers an HTTP hook to notify a callback server. The callback server processes the stream using FFmpeg, and then the stream is sent to Amazon Web Services (AWS) Interactive Video Service (IVS) using RTMPS protocol.
            [Internal Network]    (on_publish/on_unpublish)          [Internet]

This design:

  • Keeps internal SRS forwarding simple and fast (plain RTMP)
  • Uses FFmpeg at the edge for secure external delivery
  • Provides better security isolation and error handling
  • Fully automated via HTTP hooks - no manual intervention

Summary

SRS doesn't support RTMPS in forward because:

  1. By design - SRS SSL is server-side only (accepting connections)
  2. Complexity - RTMPS client adds significant code complexity for rare use case
  3. Better solution exists - FFmpeg is purpose-built for RTMPS client functionality
  4. Architecture - Separation of concerns between streaming server and secure relay
  5. Automation - HTTP hooks provide fully automated FFmpeg relay management

The production-ready solution: Use SRS HTTP hooks (on_publish/on_unpublish) to automatically start FFmpeg processes when streams are published and stop them when streams end. This provides a robust, automated, and scalable solution for relaying streams to RTMPS destinations like AWS IVS, without adding complexity to SRS core.

TRANS_BY_GPT4