RTSP 信令交互流程

拉流过程

第一步客户端发送 OPTIONS。

第二步服务器返回 Reply: RTSP/1.0 401 Unauthorized ，头部携带 WWW-Authenticate 字段，里面是 realm 和 nonce，用于摘要认证。

第三步客户端根据 realm 和 nonce 计算出 response，放到头部的 Authorization 字段中。

第四步服务器返回认证结果，分为认证成功和认证失败。
认证成功服务器返回 Replay: RTSP/1.0 200 OK，头部携带 Public 字段，表示服务器支持哪些 RTSP 方法。
认证失败服务器返回 Reply: RTSP/1.0 401 Unauthorized。

第五步客户端发送 DESCRIBE 向服务器请求 SDP（会话描述信息）。

第六步服务器返回 Reply: RTSP/1.0 200 OK，并且包体会携带 SDP。需要注意的是，SDP 显示有两条轨道，一条是 H264 视频轨道，一条是 pcma 音频轨道。

第七步客户端发送 SETUP，其中请求路径 /track_id=0 表示当前是请求轨道 0，根据上下文它是视频轨道。同时头部 Transport 字段指明客户端的收流端口，可以看到 client_port=58604-58605，其中 58604 是一个偶数，用于传输 RTP 数据，58605 是一个奇数，用于传输 RTCP 数据。

第八步服务器返回 Reply: RTSP/1.0 200 OK，同时头部 Transport 字段指明服务器的发流端口，可以看到 server_port=50000-50001，其中 50000 是一个偶数，用于传输 RTP 数据，50001 是一个奇数，用于传输 RTCP 数据。

第九步客户端再次发送 SETUP，因为有两条轨道，这一次的请求路径是 /track_id=1，根据上下文它是音频轨道。同时通过头部 Transport 字段看出 58606 用于传输 RTP 数据，58607 用于传输 RTCP 数据。

第十步服务器返回 Reply: RTSP/1.0 200 OK，同时通过头部 Transport 字段可以看出 50000 用于传输 RTP 数据，50001 用于传输 RTCP 数据。

第十一步客户端发送了一些未知的 RTP 和 RTCP 数据，用于探测服务器的 RTP 和 RTCP 端口是否连通，这里的疑惑点是报文显示端口不可达。

第十二步，客户端发送 PLAY 正式进入拉流过程，头部携带了 Session 和 Range 字段。

第十三步，服务器返回 Reply: RTSP/1.0 200 OK，头部携带了 Session 和 RTP-Info 字段。

第十四步，服务器通过 RTP 正式开始传输码流数据。

第十五步，停止拉流时，客户端发送 TEARDOWN。

第十六步，服务器返回 Reply: RTSP/1.0 200 OK，完成停止拉流。