[Feature Request] National Standard RTP Compatibility with Sending Streams from the Same IP and Port

[HalcyonHuang]

Describe the purpose of this feature, and provide relevant information to describe this feature

In a certain local area network, a project that receives and forwards national standards encountered a strange situation: Two different clients, using the same IP and port, send two video streams to the media gateway, causing the gateway to fail to process the data correctly. It can only be distinguished by ssrc, for example:

Device a, IP: 192.168.0.100:5050 ssrc: 1000 Device a, IP: 192.168.0.101:5051 ssrc: 1001 Device a and b send PS data to zlmediakit at the same time, possibly due to the forwarding of intermediate nodes, resulting in zlmediakit receiving PS data from 192.168.0.100:5050, which can only be distinguished by ssrc.

It is difficult to coordinate modifications with third-party clients, so we hope to achieve compatibility from zlmediakit.

Is this feature used to improve project defects? If so, please describe the existing defects

When zlmediakit receives PS data on the same port, the existing logic uses the makeSockId() function to distinguish between different sessions, and then filters out different ssrcs in void RtpSession::onRtpPacket(const char *data, size_t len).

Describe how you expect to achieve this feature and the final effect

If it is possible to ignore the sending IP and port and only use ssrc to determine different streams, it would be better. Please ask, if you want to be compatible with this situation, what is the modification idea.

描述该功能的用处，可以提供相关资料描述该功能

某个局域网内，国标接收然后转发的项目中遇到一个很奇怪的情况: 两个不同的客户端，都用同样的ip和端口发送两路视频到媒体网关，导致网关无法正确处理数据。只能通过ssrc来区分不同流，比如：

设备a，ip：192.168.0.100:5050 ssrc：1000 设备a，ip：192.168.0.101:5051 ssrc：1001 设备a 和b 同时向 zlmediakit 发送ps数据，可能是因为中间节点的转发，导致zlmediakit 接收到的ps数据都是从192.168.0.100:5050来，只能通过ssrc来区分不同的媒体流。

第三方客户端不好协调修改，希望能从zlmediakit来做兼容。

该功能是否用于改进项目缺陷，如果是，请描述现有缺陷

zlmediakit使用同一端口接收ps数据时，已有的逻辑是通过makeSockId()函数来区分不同session， 然后在 void RtpSession::onRtpPacket(const char *data, size_t len)里面过滤掉不同的ssrc。

描述你期望实现该功能的方式和最终效果

如果能做到忽略发送端ip和端口，只通过ssrc来判断不同流就更好。请问如果要兼容这种情况，修改思路是怎样。

TRANS_BY_GITHUB_AI_ASSISTANT

[PioLing]

You can use TCP instead

你可以改用tcp 传啊

TRANS_BY_GITHUB_AI_ASSISTANT

[PioLing]

Alternatively, you can connect to the ZLM web hook stream callback interface, which supports modifying the stream name

或者你对接zlm web hook 推流回调接口，它支持改流名

TRANS_BY_GITHUB_AI_ASSISTANT

[HalcyonHuang]

@PioLing Which specific hook is used for the streaming callback interface. Is it logical to ignore the sender's IP and port when using TCP?

@PioLing 具体使用哪个 hook 推流回调接口 。 用tcp传逻辑上是会忽略发送端的ip和端口吗

TRANS_BY_GITHUB_AI_ASSISTANT

[PioLing]

在 on_publish 里 你json 赋值 这个 “stream_replace” 的key 的value (例如 obj["stream_replace"] = 通道id)，然后你就能流id 与 业务同步一致关联了

@PioLing Which specific hook is used for the streaming callback interface. Is it logical to ignore the sender's IP and port when using TCP?

@PioLing 具体使用哪个 hook 推流回调接口 。 用tcp传逻辑上是会忽略发送端的ip和端口吗

TRANS_BY_GITHUB_AI_ASSISTANT

[xia-chu]

If the source end uses the same IP:port to send streams to ZLM, then ZLM will put this connection in an RtpSession object for processing. The problem you mentioned is actually how to make the RtpSession object support multiple RTP (SSRC) streams.

如果源端使用同一个ip:port往zlm发流，那么zlm会把这个链接放在一个RtpSession对象中处理。 你说的问题其实是 怎么让RtpSession对象支持多个rtp(ssrc)流。

TRANS_BY_GITHUB_AI_ASSISTANT

[xia-chu]

Actually, I suggest you just use multi-port mode. Single-port (10000) mode does not currently support this function.

其实我建议你还是用多端口模式算了 单端口(10000)模式目前不支持这种功能

TRANS_BY_GITHUB_AI_ASSISTANT

[xia-chu]

Currently, an RtpSession can only bind to one RtpProcess object, and an RtpProcess object can only bind to one GB28181Process object. However, a GB28181Process object can bind to multiple RtpReceiver objects. So theoretically, it is possible to support multiple streams, on the condition that these multiple streams have different payload types. Therefore, if you use the same address to send two RTP streams to zlm, zlm will indeed merge them into one stream.

目前RtpSession中只会绑定一个RtpProcess对象，一个RtpProcess对象只能绑定一个GB28181Process对象， 一个GB28181Process对象可以绑定多个RtpReceiver对象。 所以理论上，是可以支持多路流的，单前提是这多路流payload类型不一样。 所以如果你用同一个地址往zlm发两路rtp流，zlm确实会把他们合并为一路流。

TRANS_BY_GITHUB_AI_ASSISTANT

[xia-chu]

[xia-chu]

However, this merging feature is not what you requested, so if you insist on doing this, it's suggested that you customize the development. Moreover, typically, a single stream is divided into two tracks, audio and video, with two SSRCs, but they need to be merged into a single stream, which is also a reasonable and common requirement. What ZLM is doing now is reasonable.

不过这个合流的特性跟你要求是两回事 所以如果你非要这么做，建议你定制开发下。 而且通常来讲，一路流分音视频两个track，两个ssrc，但是它们需要合并为一路流，这也是比较合理和常见的需求。 zlm目前这样做是合理的

TRANS_BY_GITHUB_AI_ASSISTANT