调用Telegram API加入视频通话返回GROUPCALL_SSRC_DUPLICATE_MUCH报错咨询

1. GROUPCALL_SSRC_DUPLICATE_MUCH 错误含义 #

这个错误是Telegram服务端返回的入会拒绝错误，核心原因是发起加入群组通话请求时携带的音视频同步源（SSRC）标识，和当前通话内已存在的大量参会者SSRC重复，服务端判定为无效的重复流请求，直接拦截入会。
当前示例代码里audioSourceId传固定值0、payload传空JSON{}是触发这个错误的直接原因：0是SSRC的保留无效值，大量调试场景下的客户端都会传这个默认值，极易触发重复校验；空payload没有携带任何流协商信息，服务端无法为请求端分配独立的流路由，也会触发重复判定。

2. audioSourceId、payload参数说明与获取方式 #

audioSourceId #

• 作用：该参数是本端上行音频流的RTP同步源唯一标识，是群组通话中区分不同参会者音频流的核心字段，在整个通话生命周期内不能和其他参会者的SSRC重复，为32位无符号整数。
• 获取方式：不需要调用TDLib接口获取，在本地初始化音视频采集模块、RTP/WebRTC传输栈时，自行在1~2^32-1范围内随机生成即可，必须避开保留值0。如果需要同时上行视频流、屏幕共享流，对应的流SSRC也要按同样规则单独生成不重复的值。

payload #

• 作用：该参数是JSON序列化的入会流协商参数，内部需要包含本端所有上行音视频流的SSRC、编解码能力、传输配置、加密协商信息，服务端依赖该字段识别所有上行流，配置流转发路由。传空JSON相当于没有上报任何有效流信息，必然导致入会失败。
• 获取方式：不需要从TDLib接口获取，在本地集成的RTP/WebRTC传输栈完成本端能力收集、初始协商后，按照Telegram群组通话要求的GroupCallPayload结构序列化生成即可。基础结构至少要包含生成的audioSourceId对应的音频源配置，开启视频/互动功能时还要补充视频源列表、数据通道配置等字段。

修正调用示例 #

import java.util.concurrent.ThreadLocalRandom;

// 生成非0的随机音频SSRC
int audioSourceId = ThreadLocalRandom.current().nextInt(1, Integer.MAX_VALUE);
// 替换为本地RTP栈实际生成的符合格式要求的payload
String joinPayload = """
{
  "audioSources": [{"ssrc": %d, "volume": 10000}],
  "videoSources": []
}
""".formatted(audioSourceId);

simpleTelegramClient.send(new TdApi.JoinGroupCall(
                groupCallID,
                null,
                audioSourceId,
                joinPayload,
                true,
                false,
                null
        ),
        response -> {
            // 处理入会响应逻辑
        }
);

注意：如果修正参数后仍偶发该错误，重新随机生成新的audioSourceId重试即可，小概率是随机值刚好和通话内现有参会者SSRC撞值。

内容的提问来源于stack exchange，提问作者pswrdf