DSS流媒体IPv6方案：流媒体代理和JMF客户端

Streaming Proxy Implementation 流媒体代理的实现

The Improved Streaming Proxy was based on Apple's old C proxy code — basically a polled, shared socket, RTSP and RTP proxy program written for Unix systems with IPv4 sockets. 改善流媒体代理是基于苹果的旧的C代理代码——基本上就是一个轮询和共享的套接字、RTSP和RTP代理程序，为Unix系统编写，和IPv4的套接字配套。

This structure of the program was unchanged, leaving the logic intact. Only code related to TCP and UDP sockets was altered to support IPv6. Initially the code was rewritten in classic BSD socket programming fashion with correct type casting of IPv4 addresses (instead of using integers to hold IP addresses). The code was then rewritten using the class library called SocketCC for ease of programming and potential IPv4/IPv6 transparency.

这种结构的计划不变,保留原有的逻辑。只有相关的TCP和UDP套接字代码改变支持IPv6。最初的代码用BSD经典套接字编程，把IPv4地址进行正确类型转换（代替了使用整数保持IP地址）。然后，该代码使用类库的是Socketcc，为便于编程和潜在的IPv4 / IPv6透明度改写。

The RTSP specification allows extensions and options that are not supported by the implemented proxy. RTSP规范允许的扩展和选项是代理不支持的。

Streaming Proxy Experimental Work 流媒体代理实验工作

The Improved Streaming Proxy has been compiled on Linux, MacOSX (10.1 and Jaguar 10.2) and should also compile on Solaris as the SocketCC library it is based on has been ported to all systems.

改善的流媒体代理已在Linux、MacOSX(10.1和Jaguar 10.2)上编译过,也应该在Solaris上编译，因为SocketCC库能移植到所有系统。

Running as a user process on a Pentium II Linux box it is easily able to cope with 4 clients (The code has been compiled with a limit of fifty clients) viewing videos with bandwidths ranging from 28kbs to 700kbs simultaneously. The clients were initially tested using the proxy as an IPv4-IPv4 proxy, but also as an IPv4-IPv6 application layer gateway.

作为一个用户进程运行在奔腾II Linux机器很容易能够应付4个客户端(已编译的代码的限制50个客户)，观看视频带宽同时从28 kbs - 700 kbs。客户最初测试使用代理作为IPv4-IPv4代理,也作为一个IPv4-IPv6应用层网关。

The improved proxy shows no packet loss when a client calls a DSS server that has a feature called ‘reliable UDP’ turned on — the original Apple code causes a 40% packet loss at the client due to incorrect handling of the RTP/RTCP packets soon after the start of streaming.

客户端调用的DSS服务器功能“reliable UDP”打开，所以改进的代理没有包丢失——原苹果代码导致在客户端40％的分组丢失，由于流开始后不久将RTP / RTCP分组的不正确的处理。

The MPEG4IP Linux streaming MPEG4 player had no support for RTSP proxies, so it was modified to support the use of a proxy. It was then used to trial the full IPv6 RTSP/RTP streaming video solution via the improved proxy. Aside from adding IPv6 proxy support, no other changes were required to be made to the MPEG4IP programs — verifying compatibility between my IPv6 RTSP messages and another implementation. The MPEG4IP player is capable of playing industry standard ISMA streaming MPEG4 (which can be served by a DSS server amongst other systems).

MPEG4IP Linux流MPEG4播放器不支持RTSP代理服务器，所以它被修改,以支持使用一个代理。它将通过改进的代理被用来试验IPv6 RTSP和RTP流媒体视频解决方案。除添加IPv6代理的支持，要求没有其他对MPEG4IP程序改变进行 - 验证我的IPv6的RTSP消息和另一种实现之间的兼容性。MPEG4IP播放器能够播放行业标准互联网统计流MPEG4(可通过DSS服务器之间的其他系统提供服务)。

Fragmentation of the IPv6 packets containing the Video RTP packets was observed due to the increased header size of the IPv6 UDP packets. IPv6数据包碎片包含RTP数据包，这是因为增加IPv6 UDP数据包的头部大小而观察到的。

Various student and vacation worker projects have been underway to provide client applications that support IPv6. Java 1.4 supports IPv6, but the JMF (java media framework) has not been written sufficiently transparently to IP type to allow it to be directly used to play IPv6 based streaming video. A current B.Tech. student group project is seeking to implement a JMF IPv6 player. Apple currently has no IPv6 support in its QuickTime players, and a vacation work project currently under way is demonstrating a proof of concept method to use the QuickTime API on Microsoft's XP platform to play streaming video over IPv6.

各种学生和假期的工作者已经提供支持IPv6的应用程序。Java 1.4支持IPv6,但是JMF(Java媒体框架)没有写入足够透明的IP类型可以直接用于播放IPv6的视频。当前的B.Tech学生团体项目正在寻求实现一个JMF IPv6的播放器。苹果目前不支持IPv6的QuickTime播放器,并且目前正在进行一个假期工作项目，演示在微软XP平台使用QuickTime的API来播放基于IPV6的视频流，用此对IPv6概念方法进行证明。

DSS 4.1.2+ Server and QuickTime 6 issues DSS 4.1.2 +服务器和QuickTime 6问题

The streaming proxy was updated to support some features used by DSS4.10 servers (including having track sources coming from different IP numbers) while QuickTime 5 was current. Since then we have progressed to QuickTime 6.1+ and extra features like Instant On have been added. The DSS server already had support for these features, but the proxy does not. The extra RTSP messages required by Instant On (identified by an x-dynamic-rate=1 in the RTSP Setup message) caused the streaming proxy to ignore the connection as it is preprogrammed for certain RTSP state transitions and sequences. The problem was resolved within the proxy, by setting the x-dynamic-rate to 0, and rewriting the User-Agent field string. The changes make the client requests appear to come from a non-QuickTime client that does not support Instant On.

流媒体代理更新支持DSS4.10服务器所使用的一些功能(包括轨道来自不同来源IP数字)，然而当前的是QuickTime 5版本。从那时起我们已经发展到QuickTime 6.1 +和额外的功能,如瞬时接通。DSS服务器已经具备了这些功能的支持，但代理不会。瞬时接通需要在额外的RTSP消息（在RTSP建立消息的x-dynamic-rate=1定义）引起的，因为它是事先设定为一定的RTSP状态转换和顺序流代理忽略连接。问题是在代理内解决，通过X-动态速率设置为0，以及重写User-Agent字段的字符串。这些变化使客户端的请求似乎来自不支持瞬时接通QuickTime的客户端。

QuickTime (RTSP/RTP) IPv6 CLIENT programs QuickTime(RTSP和RTP)IPv6客户程序

MPEG4IP for Linux — MPEG-4 player compatible with QuickTime streams MPEG4IP为Linux-MPEG-4播放器兼容QuickTime流.

The MPEG4IP project on sourceforge.net provides a QuickTime compatible MPEG-4 player. It is a project that was founded by some CISCO workers, bringing together a large collection of available code libraries for Linux systems. Originally they distributed the Darwin Streaming server version 2 with their collection of code. The 6Net.org consortium’s applications project workers had added IPv6 functionality to the MPEG4IP player, and this has been used to test and demonstrate IPv6 based MPEG-4 video streaming via the proxy. The code to support a proxy was added by myself into the RTSP communications library of the MPEG4IP player.

MPEG4IP项目在sourceforge.net上提供了QuickTime兼容的mpeg-4播放器。这是一个项目,由思科开发人员成立,组建一个大集合增加Linux系统可用的代码库。最初他们支持了达尔文流媒体服务器版本2的代码集合。6net.org财团的应用程序项目成员增加了IPv6功能MPEG4IP播放器，这通过代理被用来测试和演示基于IPv6的mpeg-4视频流。支持的代理代码由我自己加入到MPEG4IP播放器的RTSP通信库。

IPv6 and the Windows QuickTime SDK IPv6和Windows的QuickTime 软件开发工具包

An ATcrc Vacation Scholarship worker was given the task to identify and build an IPv6 QuickTime player application for windows. Unfortunately the QuickTime SDK does not reveal the RTSP protocol, so IPv6 is unable to be added using the SDK. A partial client was written with the RTSP protocol and user interface being coded explicitly to support IPv6. The RTP stream was then received from IPv6 and passed on to an instance of the QuickTime player. The player opened an SDP file (containing configuration information for the streams) generated by the application. This combined application proved to be rather inefficient, but led to the development of the much more capable client described next.

一个ATcrc假期奖学金开发者被给予任务来识别并建立一个IPv6 QuickTime播放器应用程序。不幸的是,QuickTime SDK不支持RTSP协议,所以使用SDK IPv6是无法添加。部分客户是用RTSP协议和被显式编码支持IPv6的用户界面。从IPv6接收的RTP流，然后传递到QuickTime播放器的一个实例。播放器打开一个SDP文件(包含配置信息来源)生成的应用程序。这个组合应用程序被证明是相当低效的,但是能支持更多的随后开发。

Local Bridge IPv6-IPv4 client for Windows XP QuickTime Player 本地桥IPv6-IPv4客户端为Windows XP 的QuickTime播放器

This application was created under ATcrc Vacation Scholarship and provides a bridge between QuickTime and the IPv6 streaming world, using a local proxy (within the windows workstation) that performs RTSP proxying and RTP bridging functions. A final year bachelor of engineering student has been further developing the code as his thesis project. The application requires no modification to the Apple distributed QuickTime player, and does not use the QuickTime SDK. Instead it creates IPv4 and IPv6 sockets for both RTSP and RTP and passes the incoming RTP and RTSP messages to the QuickTime player. The RTSP messages are rewritten to provide a unique User-Agent string, and support IPv6 when communicating with a server or streaming proxy. Incoming RTSP messages are converted where appropriated so that the standard IPv4 only QuickTime player can use them. The QuickTime player only needs to have its streaming proxy preference configured to use the localhost IP address and Port of this bridge application for it to all work. At present the windows local bridge/proxy consumes too much CPU time due to the polling method implemented, and is undergoing a rewrite.

在ATcrc假期奖学金下创建此应用程序，它提供了一座桥梁，连接QuickTime和IPv6流,使用本地代理(在windows工作站),执行RTSP代理和RTP桥接功能。一个本科最后一年工科学生的进一步开发会加入到他的论文项目的代码。应用程序不需要修改苹果QuickTime播放器,分布和不使用QuickTime SDK。相反,它创造了IPv4和IPv6 RTSP和RTP的套接字并将传入RTSP和RTP消息传递到QuickTime播放器。重写的RTSP消息提供一个独特的用户代理字符串,当连接服务器或代理时就支持IPv6了。传入的RTSP消息会在合适时转换,以便标准IPv4QuickTime播放器能使用它们。QuickTime播放器只需要有它的流媒体代理配置，这些配置对应用于桥梁程序需要的本地主机的IP地址和端口,让桥梁程序展开所有工作。目前windows本地桥/代理程序消耗过多的CPU时间，因为是轮询方法实现,正在改写。

Java JMF client Java JMF客户端

The Java Media Framework (JMF) has RTSP/RTP support and can communicate with a QuickTime streaming server. JMF has limited codec support, so specially made QuickTime movies were used for the testing. JMF has an MPEG-4 codec provided by IBM, but during the research period, IBM withdrew that codec due to licensing issues (which have now been resolved).

Java媒体框架（JMF）具有RTSP / RTP的支持，并可以用QuickTime流服务器进行通信。JMF编解码器支持有限,所以特制的QuickTime电影被用于测试。JMF具有由IBM提供一个MPEG-4编解码器，但在研究期间，IBM撤出编解码器(现在已经由于授权问题解决)。

JMF was investigated using both an ATcrc Vacation Scholarship worker and B.Tech (Computer Studies) Industrial Design project group of students. Initial work showed that Java v1.4 and JMF could support and receive IPv6 RTP streams, but further work was needed to get the RTSP protocol supporting IPv6. This work is ongoing by the student group.

ATcrc假期奖学金开发者和B.Tech（计算机学）工业设计项目组学生都对JMF进行了调查。最初的工作表明,Javav1.4,JMF可以支持和接收IPv6 RTP流,但需要进一步的工作得到了RTSP协议支持IPv6。这项工作由学生团体正在进行。

Conclusions and Future Work 结论和未来的工作

The AUDF grant application that I had submitted turned out to be too ambitious but provided a good framework for investigating IPv6 based streaming media. The AUC website’s visibility on the web meant that there was a relatively constant stream of enquiries for IPv6 enabled QuickTime streaming server code from overseas. Some collaboration has occurred with a number of these overseas researchers.

AUDF授予应用程序,我已经提交了,过于雄心勃勃,但提供一个好的框架,研究基于IPv6的流媒体。AUC网站的可见性在网络上就意味着有一个相对稳定的询盘为IPv6来自海外的启用QuickTime流媒体服务器代码。发生了一些合作与这些海外人员的数量。

The Improved Streaming Proxy provides a relatively straightforward way of testing IPv6 QuickTime streaming. It correctly handles basic RTSP/RTP streaming media, but does not handle all of the extended RTSP messages used by the latest QuickTime players. The proxy is sufficient to demonstrate streaming MPEG-4 (ISMA[10] standard) in addition to other codecs suitable for playing via Apple's QuickTime player.

改善流媒体代理提供了一个相对简单的方法测试IPv6QuickTime播放。它正确地处理基本的RTSP和RTP流媒体,但不处理所有的扩展RTSP消息所使用的最新的QuickTime播放器。代理是足以证明MPEG-4流（ISMA[10]标准），除了适合于通过Apple的QuickTime播放器中播放的其他编解码器。

The code is not particularly robust as it was assembled as a proof of concept, rather than an end product. 因为它被组装为一个概念证明，而不是最终产品的代码，所以不是特别稳健。

The experimental work has shown IPv6 fragmentation of the RTP payload and this leads to further work and investigation into the potential effects of fragmentation and repacketisation. Re-hinting the video file to use smaller maximum packet size reduces the risk of fragmentation.

实验工作已经表明RTP有效载荷的IPv6的碎片，这导致进一步的工作，并调查碎片和repacketisation的潜在影响。重新线索化视频文件来使用最大包长度会减少碎片风险。

The AUDF Developer Grant and Apple’s Developer Connection programme and Open Source initiative have been extremely helpful in providing a framework for exploring IPv6 issues related to streaming media.

该AUDF开发者格兰特和苹果的开发者连接程序和开放源码的举措已经为研究流媒体的IPv6问题打下了框架，这是极其有益的。