一句话结论
SMPP 短信业务只有【信令流】，不存在【媒体流】。
你之前 L1 规格：信令（5% 丢包、50ms 时延、5ms 抖动）、媒体（1% 丢包、50ms 时延、5ms 抖动） ✅ SMPP 只需要施加信令那套网络损伤参数，媒体损伤规则不用配。
详细解释
1. SMPP 是什么
SMPP（Short Message Peer-to-Peer），短消息点对点协议，基于 TCP 长连接 （默认端口 2775）。 所有交互 PDU：Bind、Submit_SM（下发短信）、Deliver_SM（上行短信）、Delivery Receipt（投递回执），都属于业务控制信令 。 短信内容本身封装在 SMPP 信令 PDU 的 payload 里，没有单独独立媒体通道。
区分一下音视频 vs SMPP：
- 音视频：信令（SIP/WS）负责会话控制；媒体 RTP单独一路 UDP 流承载语音视频码流，两条独立流。
- SMPP 短信：控制指令 + 短信内容全部在同一条 TCP 连接内传输，不存在独立媒体流。媒体一般指持续承载音视频这类实时媒体码流的独立数据流，短信不属于媒体。
2. 网络损伤测试要点（重点写进测试报告）
- 流量匹配：匹配 TCP 2775 端口，归类为信令流；
- 损伤参数：丢包 5%，单向时延 50ms，抖动 5ms；
- SMPP 底层是 TCP：TCP 自带重传。底层 5% 网络丢包，TCP 会自动重传报文。 风险：重传 + 50ms 时延叠加，会拉长 SMPP 请求响应 RTT；如果 SMPP 客户端超时设置过小，会出现：Bind 失败、Submit_SM 提交超时、回执丢失、长连接断开。
3. SMPP 场景 L1 容错【预期结果】
✅ 通过标准
- SMPP Bind 绑定成功率≥99%，长连接不会频繁断连；
- 短信提交成功率≥99%；
- 短信投递回执正常返回，业务状态一致；
- 持续并发压测，无连接雪崩，服务资源平稳。
❌ 判定不通过
- Bind 频繁失败，SMPP 长连接随机断开；
- 大量 Submit_SM 请求超时，短信下发积压；
- 投递回执大量丢失，业务侧无法识别短信真实送达状态。
补充
- 如果你后续同时跑 SMPP + 音视频混合业务：SMPP (2775) 打 mark 走信令损伤；RTP 媒体端口单独走媒体损伤。