“OPTIONS” 可能可行,但标准指定正确的方式是通过使用 “GET_PARAMETER”。RFC2326 明确地概述了这一点。
http://www.ietf.org/rfc/rfc2326.txt
10.8 GET_PARAMETER
GET_PARAMETER请求检索URI中指定的演示文稿或流的参数值。响应内容由实现自己确定。没有实体主体的GET_PARAMETER可以用于测试客户端或服务器存活性(“ping”)。
虽然服务器可能不支持GET_PARAMETER
,但无法确切确定该服务器将如何对不需要sessionID甚至的OPTIONS
请求做出反应。因此不能保证它将保持您现有的会话处于活动状态。
从同一RFC关于OPTIONS
请求的阅读中可以明显看出这一点。
10.1 OPTIONS
该行为相当于[H9.2]中描述的行为。可以在任何时候发出OPTIONS请求,例如,如果客户端即将尝试非标准请求。它不会影响服务器状态。
例:
C->S: OPTIONS * RTSP/1.0
CSeq: 1
Require: implicit-play
Proxy-Require: gzipped-messages
S->C: RTSP/1.0 200 OK
CSeq: 1
Public: DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE
请注意,这些都是虚构的特性(我们希望不会有人故意忽略真正有用的功能,只是为了在本节中展示一个强有力的例子)。
如果不支持 GET_PARAMETER,则应使用要保持活动状态的会话的 SessionId 发出 PLAY 请求。
即使 OPTIONS 不支持,这也应该有效,因为 PLAY 会尊重会话 ID,如果您已经在播放,就没有负面影响。
对于 C# RtspClient,请参阅我的项目 @
https://net7mma.codeplex.com/
以及 CodeProject 上的文章 @
http://www.codeproject.com/Articles/507218/Managed-Media-Aggregation-using-Rtsp-and-Rtp。