RTC: Supports direct forwarding, does not change SSRC and Timestamp, making problem troubleshooting easier.

[winlinvip]

Describe the bug
When SRS forwards RTC packets, it modifies the SSRC and Timestamp, which is inconvenient for end-to-end troubleshooting.

Version
6.0.95

To Reproduce
Steps to reproduce the behavior:

1. Start packet capture with Wireshark.
2. Use WHIP for streaming.
3. Use WHEP for playback.
4. Notice that the SSRC and Timestamp for streaming and playback are different.

Expected behavior
Add a new configuration that can support not changing the SSRC and Timestamp, which is helpful for troubleshooting in certain scenarios.

Screenshots
For example, when adding a weak network in tc, it can help identify which packets are being dropped or delay:

Additional context
Previously, SRS recalculated Timestamp to support scenarios such as starting a stream, stopping a stream, and restarting a stream, so that continuous playback could be achieved. Additionally, SRS allows for playback before streaming, which requires the generation of SSRC first.

TRANS_BY_GPT4

[winlinvip]

Direct forwarding with the same SSRC can be beneficial for debugging purposes, while indirect forwarding that rewrites the SSRC is helpful when needing to conceal the source SSRC.

[winlinvip]

This modification was made to ensure the continuity of timestamps, particularly when restreaming. Inconsistent timestamps can cause issues such as stuttering on the playback client.

TRANS_BY_GPT4