精通
英语
和
开源
，
擅长
开发
与
培训
，
胸怀四海
第一信赖
精通
英语
和
开源
，
擅长
开发
与
培训
，
胸怀四海
第一信赖
流媒体服务器可以接受来自QuickTime播送器的RTSP ANNOUNCE请求。服务器支持ANNOUNCE请求，同时也可以充当RTSP客户端，因此可以自行发起一个新的中继会话。本部分将描述发起自动播送的两种方式，ANNOUNCE请求如何与SDP协同工作，以及qtaccess和qtusers文件如何控制自动播送。
这个部分的主要内容如下：
QTSS支持两种自动播送的场景：
用户可以通过发送标准的DESCRIBE/SETUP/PLAY请求来向远程的源中请求一个流，然后将它中继到一个或者多个目的地。当组织机构只希望让外部流的一个拷贝消费其内部连接的带宽时，这个功能可能有用。中继位于企业网络的内部，负责将流推送给反射器（可能是它自己）。图2-7提供了一个先拉后推（pull-then-push）场景的实例。
以图 2-7作为参考，先拉后推场景的步骤如下：
流媒体服务器可以被配置为将ANNOUNCE请求创建的输入流自动发送到一个或者多个目的地。这可能可以用于配制自动播送网络。图 1-8提供了一个先侦听后推送的场景的实例。
以图 1-8作为参考，先侦听后推送场景的步骤如下：
在缺省情况下，认证对于自动播送是必要的。来自播送器的ANNOUNCE请求需要通过服务器中活跃的认证机制来过滤。为了支持播送认证，需要在qtaccess文件中加入一个新的WRITE指令。这个新的指令使得SDP文件可以被写入到电影文件夹中。
ANNOUNCE请求中包含播送流的会话描述协议（Session Description Protocol，简称SDP）信息。为了提供名字空间的功能，ANNOUNCE请求中的URI值可能包含路径的界定符。
在通过ANNOUNCE请求发起流的播送时，SDP信息被存储在内存中的一个播送列表中。如果要终止流的播送，需要播送器向服务器发送一个TEARDOWN请求，使服务器关闭播送会话，并丢弃SDP信息。类似地，RTSP连接被断开，以及播送器在90秒长的窗口内没有向服务器发送RTCP发送方报告，都会使服务器关闭播送会话及丢弃SDP信息。
为了使多个SDP引用同一个播送流，支持已发布的UDP和TCP播送流，ANNOUNCE报头中的端口设定为０。下面是一个实例：
m=audio 0 RTP/AVP |
|
为了共享不同的播送流（在这种情况下一个流来自一个播送器，另一个流来自另一个播送器），需要一个a=x-urlmap标识。a=x-urlmap标识应该出现在引用源SDP的SDP中，下面是一个实例：
a=x-urlmap: someotherbroadcastURL/TrackID=1 |
|
qtaccess文件中定义了两个新的用户标识，以控制自动播送。表2-25列举了这些新的标识。
标识 |
目的 |
|---|---|
valid-user |
对于这个标识指定的用户，如果客户端提供了与qtusers文件中的条目相匹配的用户名和密码，则可以访问其请求的电影。这个标识表示为require valid-user。 |
any-user |
这个标识指定的用户对其请求的电影具有访问权，不要求在qtusers文件中定义该用户，也不要求客户端提供被检查的名字和密码。这个标识的表示为require any-user。 |
缺省情况下，qtaccess文件允许读取文件中所有的指令符。qtaccess文件中必须包含一个允许写的Limit指令符，才能支持已发布的播送流。
Limit指令的目的是为了限制RTSP读取方或者写入方的访问控制。下面的实例对require指示符的访问控制进行限制，使得只有在qtusers文件中定义的用户才可以将一个播送流通过RTSP PLAY的方式发给服务器。而对于其它正常的客户端PLAY请求则不做限制：
<Limit WRITE> require valid-user </Limit> |
|
请注意：Limit命令符的结束端（</Limit>）必须自成一行。
下面的例子允许qtusers文件中属于movie_watchers组的所有用户，以及名为john的用户看电影；而只有隶属movie_broadcasters组的播送器才能将流播送到qtusers文件所在的目录或其受保护的目录分支下。
<Limit READ> require group movie_watchers require user john </Limit> <Limit WRITE> require group movie_broadcasters </Limit> |
|
请注意：qtaccess文件中的字符串是大小写敏感的。
下面这个例子和前一个例子的结果相同。在没有指定Limit域时，QTSS的缺省行为是将访问权限限制为只读，所以下面的配置可以正常工作。
require group movie_watchers <Limit WRITE> require group movie_broadcasters </Limit> require user john |
|
下面的例子允许qtusers文件中属于movie_watchers_and_broadcasters组的所有用户观看电影和进行流的播送:
<Limit READ WRITE> require group movie_watchers_and_broadcasters </Limit> |
|
下面部分将说明启动一个发布过的（announced）流播送（ broadcast）的过程中客户和服务器之间典型交互情况。下面的例子说明的是建立UDP组播（multicast）的交互情况。发布过的流播送也可以通过单播（unicast）RTP/AVP/UDP流和RTP/AVP/TCP交织流来建立请求。如果需要更多信息，请参见RFC 2326。
客户端发送给服务器端：
ANNOUNCE rtsp://server.example.com/meeting RTSP/1.0 |
|
服务器端发送给客户端：
RTSP/1.0 200 OK |
|
客户端发送给服务器端：
SETUP rtsp://server.example.com/meeting/trackID=1 RTSP/1.0 |
|
服务器端发送给客户端：
RTSP/1.0 200 OK |
|
客户端发送给服务器端：
SETUP rtsp://server.example.com/meeting/trackID=2 RTSP/1.0 |
|
服务器端发送给客户端：
RTSP/1.0 200 OK |
|
客户端发送给服务器端：
RECORD rtsp://server.example.com/meeting RTSP/1.0 |
|
服务器端发送给客户端：
RTSP/1.0 200 OK |
|
这部分提供了三个踪迹信息（trace）。第一个踪迹来自QuickTime Broadcaster，产生于通过TCP协议发送MPEG 4流的过程；第二个也是来自QuickTime Broadcaster，但是使用的是UDP；第三个踪迹是来自RFC 2326（RTSP），说明的是基于UDP传输的ANNOUNCE和RECORD两个RTSP方法。
值得注意的直播器请求如下：
流客户请求的镜像请求：
示例一：QuickTime Broadcaste使用TCP的踪迹