RTSP-Simple-Server项目中WHIP/WHEP协议DELETE请求处理问题分析

背景介绍

RTSP-Simple-Server是一个开源的媒体服务器项目，支持多种流媒体协议。近期版本中增加了对WHIP/WHEP协议的支持，这是基于WebRTC的推拉流协议标准。在实际使用过程中，发现该实现存在DELETE请求处理不当的问题，影响了客户端正常终止会话的能力。

问题现象

在WHIP/WHEP协议实现中，当客户端尝试通过HTTP DELETE方法终止会话时，服务器返回404错误。具体表现为：

1. 客户端首先通过POST方法建立WHIP/WHEP会话
2. 服务器响应201 Created，并在Location头中返回资源路径
3. 客户端随后向该路径发送DELETE请求终止会话
4. 服务器错误地返回404 Not Found

技术分析

协议规范要求

根据WHIP/WHEP协议规范，会话终止必须通过向初始POST响应中Location头返回的资源URL发送HTTP DELETE请求实现。服务器收到DELETE请求后，应当释放相关资源并终止ICE和DTLS会话。

实现问题根源

经过分析，发现问题主要出在两个方面：

1. Location头格式问题：服务器返回的Location头使用相对路径而非绝对URL，导致部分客户端（如OBS Studio）无法正确构造DELETE请求的目标URL。

2. DELETE请求路由问题：服务器未正确配置DELETE方法的路由处理，导致即使请求到达正确路径也无法被处理。

兼容性考量

虽然RFC3986规定相对路径应基于请求URL进行解析，但实际中发现多个主流客户端（包括OBS Studio等）都直接使用Location头内容作为DELETE请求目标，而不进行路径拼接处理。这种实现方式虽然不完全符合规范，但已成为事实标准。

解决方案

项目维护者最终采用了以下改进方案：

1. 修改Location头生成逻辑，使用以斜杠开头的完整路径而非相对路径
2. 正确实现DELETE方法的路由处理
3. 保持对反向代理场景的兼容性考虑

相关技术扩展

WHIP/WHEP协议特点

WHIP(WebRTC-HTTP ingestion protocol)和WHEP(WebRTC-HTTP egress protocol)是基于HTTP的WebRTC协议，简化了传统WebRTC的信令流程。它们分别用于推流和拉流场景，具有以下特点：

• 使用简单的HTTP请求完成信令交换
• 支持Trickle ICE渐进式候选收集
• 资源定位通过Location头实现
• 会话终止通过DELETE方法完成

防火墙配置建议

在部署WebRTC服务时，需要注意以下防火墙配置：

1. 开放UDP端口范围（用于TURN/STUN服务）
2. 考虑使用固定端口配置减少开放范围
3. 可通过webrtcAdditionalHosts指定服务器公网IP
4. 使用webrtcIPsFromInterfaces控制本地IP公布

总结

RTSP-Simple-Server对WHIP/WHEP协议的支持整体表现良好，此次发现的DELETE请求处理问题主要源于路径格式和路由配置的细节处理。通过改用完整路径格式并完善路由逻辑，问题得到了有效解决。这提醒我们在实现协议时，不仅要遵循规范文本，还需要考虑实际客户端的实现方式，确保最大兼容性。