锐英源精品开源心得，禁止转载，违法必究。

以RTSP和RTP实现托管媒体聚合之新改进特点

首版本代码迅速发展，它遵循KISS架构，功能非常强大。在确定大多数用户将使用2个音轨和音频会话后，最大的变化是在改动中完成的。

在下一个版本里，通过提高性能和添加新功能来完成和优化库，从而改进了功能。

TransportContext类......这不是平常的System.Net.TransportContext。

它实际上是独一无二的，我是第一个这么耐心做精细活的人。

它的功能强是有两个原因，大多数其他库不能提供此类功能，因为他们理解的概念与我的不同。

我认为它更好和更灵活，但其他人可能不会，我将在下面解释这个概念。

我最初有一个叫做Interleave的类，我用于跟踪状态，但是在发送者也可以是接收者的情况下（反之亦然）（认为组播或会议系统）我认为这对于类型来说更好的工作要做，并在用户/开发人员被重复使用时变得更加熟悉。

该名称可能是“SubSession”，但是TransportContext旨在成为一个SubSession，并且更多的是例如，如果您想要与Rtp同时实现Tcp和Udp，那么这个库就是唯一一个允许你这么做的选择，如果有的话另一个请做评论，我会修改我的声明。（商业或其他）

它保持套接字、传输内存、请求计数器和状态信息，使Rtp工作变得轻而易举。

这是类图 TransportContext

注意第三人称的属性名称Sender、Receiver和SinceLastReport，这种抽象设计立场。这些属性使得TransportContext变得更有用。

它是一个活跃的庞然大物，并在必要时（如果需要或强制）通过使用RtpClient从发送者切换到接收者。

阻塞套接字....

通常，高性能代码在非阻塞套接字上运行。这允许您以比有瓶颈的硬件和网络设备上基础网络速率更大的速率发送和接收。

Windows环回适配器大多适用于处理正常的流量负载，但是当您有意以高速率发送时，特别是高于网络接口评级的速率，有时会对底层系统产生负面影响。

环回适配器的问题是，没有“网络电缆”，也没有网络接口处理器，这个处理器期望一个虚拟的内核，一个驻留在永远受欢迎的新技术内核（或者类似）中。

这将导致分层服务提供商中的一些问题，它负责验证此流量，当流量离开和到达交互对象时（如套接字）

在Unix上这不是一个问题，而且我还没有测试过Windows 8，但是根据这个 MSDN页面可能会有一些变化; 然而，我想要得到的是，如果您在本地系统上遇到Udp测试的奇怪问题，同时还要从本地系统进行测试... 在评论或声明库的问题之前，请确认您没有遇到某种软件硬件问题或预读优化。

Tcp交错支持终于完成，这意味着QuickTime和其他媒体播放器也可以开箱即用。

还有一些事情要做，但是基础工作（如分组和报告类已经在那里），如：

Rtcp XR框架 - RFC2032，RFC3611，RFC5450 RFC5760

Rtcp反馈框架 - RFC4585

Rtsp / Http隧道支持。