多媒体会议系统具有传统网络应用所没有的特殊要求。首先，它要求多媒体数据的传输是实时的。其次，它要求多媒体数据流的传输基于IP组播（multicast）。再次，多媒体数据的海量特性，需要研究多媒体数据的编码和存贮技术。计算机分组网络是建立在尽力而为（Best Effort）服务模型之上的，无法提供传输延时的上限和带宽的最低保证，完全是动态随机变化的。为了解决分组网络上多媒体会议系统应用的要求，IETF（Internet工程任务组）先后制定了许多协议，如网络层的IP组播及依赖于它的RSVP协议、传输层的RTP协议和会话层的SAP和SIP协议等。下面就对IP分组网上的IETF相关协议标准进行介绍。
　　
　　会话控制协议
　　1.会话描述协议SDP
　　
　　SDP用于描述多媒体会议，以便实现会议宣布、会议邀请和其他形式多媒体会议的启动，设计SDP就是为了传达关于多媒体会议中媒体流的信息以使得某个会议描述的接收方能够参加该会议。但是，SDP不用于媒体编码方式的协商。
　　
　　虽然SDP十分通用，可以描述其它网络环境中的会议，但它主要用于Internet。在Internet环境下，多媒体会议被定义为一组存在一段时间的媒体流，这些媒体流可以是多对多的媒体流，会议活动的时间不需要连续。Internet上基于组播的会议与许多其它会议形式的不同之处在于，用户只需知道该会议的组播地址和用于该会议数据流的UDP端口，就能够接收该会议的通信流量并加入该会议（除非该会议的通信流量是加密的）。SDP必须传达的信息包括：会议名称和目的；该会议活动的时间；组成该会议的媒体种类；接收这些媒体的控制信息。
　　
　　SDP纯粹是一种会话描述的格式（它不包括传输协议），它可以使用不同的传输协议，如包括会话宣布协议SAP、会话启动协议SIP、实时流协议RTSP、使用MIME扩展的电子邮件SMTP和超文本传输协议HTTP。
　　
　　根据SDP的要求，我们可将会话描述分为以下两种：会话级描述和媒体级描述。会话级描述适用于整个会话和所有媒体流的细节信息，媒体级描述适用于单个媒体流的细节信息。媒体描述使得宣布的接收方能够使用所有正确的标记和设置，从会话目录直接启动正确的媒体工具来加入该会议。
　　
　　一个宣布是由一个会话级描述部分及其后面的零个或多个媒体级描述部分组成。当某种媒体被选择时，应该同时选择相应的缺省媒体格式以及缺省地址、传输协议和端口，并且将它们传送给相应的媒体应用工具。新创建的会议应该具有一个名字、一段简短的描述、范围、联系信息、启动时间和停止时间。
　　
　　2.会话宣布协议SAP
　　
　　SAP是用于处理组播和单播会话描述分组的协议，它定义了会话目录传输所使用的封装分组的格式。宣布会议会话的SAP模块周期性地将宣布分组组播到一个众所周知的组播地址和端口上，并且和它所宣布的会话具有同样的scope（范围），以******该宣布的接收方也能够成为所宣布的会话的接收方。在众所周知的SAP地址中使用的scope值和分配给该会话的组播地址中所使用的值完全一样。
　　
　　宣布会议会话使用SAP协议，周期性地向一个众所周知组播地址和端口上组播描述特定会议的会议宣布分组，SAP所使用的TTL（IPv4）或scope（IPv6）应该和它正在宣布的会话的TTL（IPv4）或scope（IPv6）一样，以便******收到该宣布的接收方也能够收到所宣布的会话的通信流量。为了接收SAP，接收方可以简单地在一个众所周知的组播地址和端口上进行监听。
　　
　　会议使用会话描述协议SDP来进行描述。如果某个接收方收到一个会议宣布分组，则可简单地解码该SDP消息，然后显示该用户的会议信息，以便接收方了解目前的会议状况。接收方选择想要加入的会议，并向该会议的传输地址（组播地址加上端口对）发出请求加入的申请。同样的会议描述消息的重复时间间隔由正在被宣布的会议的数量决定，以******其不会占用太多的带宽。
　　
　　如果接收方已经监听了设定的时间并且没有能够收到会议宣布，那么接收方可以断定该会议已经取消并且不再存在。该期限的设定依据为接收方对发送者应该发送的频度的估计量，并且（任意地）将它设置为这个估计的发送周期的10倍左右的时间。
　　
　　3.会话启动协议SIP
　　
　　会话启动协议SIP是用于创建、修改和终止多媒体会话或者呼叫的应用层控制（信令）协议。这些会话包括Internet多媒体会议、远程教育、Internet电话呼叫以及类似的应用。会话中的成员可以借助组播或借助大量单播关系、或者二者的组合来进行通信。
　　
　　用来创建会话的SIP邀请数据携带会话描述，这些会话描述使得与会者能够商定一套一致的媒体类型。SIP通过代理重定向用户的当前位置来支持用户的移动性(mobility)。用户可以登记他们的当前位置。SIP不受任何特定会议控制协议的束缚，它被设计成独立于低层传输协议并且可以对它进行其它性能的扩展。
　　
　　会议发现
　　在开始的时候，与会者应该能够相互找到对方，即建立通信联系。有两种基本的会议发现机制：
　　
　　1、由会话目录提供的会话宣布机制
　　
　　许多轻型会话的汇聚机制都使用基于会话目录的组播机制。会话目录将会话描述“广播给”所有可能的与会者。这些会话描述提供了该会话的生存期、组播地址、端口、媒体格式和会话次数，以便收到该会话描述的接收者都能够加入该会话。SDP描述多媒体会话的内容和格式，而SAP将它们分发给所有可能的会话接收者。
　　
　　2、使用诸如SIP或者H.323之类的会话启动协议所提供的会话邀请机制
　　
　　作为Internet多媒体会议系统，在会议期间，还需要交换一些会议控制信息以便实现会议控制策略，使得有关人员（例如，会议主席）可以决定哪些人可以参加会议、谁可以在什么时间发言等等。此外，还需要采取一些安全保密措施来增强会议控制。
　　
　　实时传输协议
　　　
　　1.实时流协议RTSP
　　
　　实时流协议RTSP是应用级协议，用于控制具有实时特性的数据投递，它提供一个可扩展的框架，以使诸如音频和视频之类的实时媒体的点播投递成为可能。该协议为了控制多种数据投递的会话，提供了用于选择投递信道（例如UDP、组播UDP和TCP信道）的方法，以及选择基于RTP的投递机制的方法。
　　
　　2 实时传输协议RTP
　　
　　IETF定义的实时传输协议RTP提供用于具有实时特性的数据的投递服务，是用来解决IP网上实时通信问题的一种技术方案。开发RTP就是为了提供用于音频和视频这类连续媒体数据的轻型应用层协议并且在会议工具之间提供协同工作的能力。RTP可以支持各种实时通信的应用，比如同步的恢复、信号丢失的监测、安全保密和内容的识别等。RTP还具备一种时间戳与控制机制，可以实现带有定时特性的不同信息流之间的同步，它采用基于速率的流量控制机制，发送方采用与接收方约定的速率发送，可以保证发送方既不会“淹没”接收方，也不会使接收方产生“饥饿”。
　　
　　但是，RTP本身并不提供任何******及时的投递机制或者其它的QoS（服务质量）保证，没有指定恢复丢失数据报的任何机制，而是依赖较低层服务去完成这些工作。它既不保证投递或者防止失序投递，也不假定低层网络是可靠的并且按顺序投递分组。RTP无法解决资源预留和QoS控制问题，因此它还要依靠资源预留协议RSVP来提供这方面的功能。RTP中所包括的顺序编号使得接收端能够复原发送端的分组顺序，但是顺序编号也可以用来确定一个分组在数据流中的恰当的位置（例如在视频解码中），而不需要按顺序解码分组。
　　
　　实时运输控制协议RTCP用于分发发送者和接收者统计信息以及与会者的详细信息，RTCP的功能包括QoS监控和拥塞控制；标识媒体间的同步；以及会话规模估计和缩放等等。
　　
　　结语
　　IETF是Internet规划与发展的主要标准化组织，每年都有许多标准RFC出台。但这些标准与ITU和ISO的的工业标准不同，更加强调研究的性质并且多数具有时效性（如六个月的有效期）。即便是这样，IETF的标准化成果对Internet的发展有很关键的作用。有的标准被ITU接纳，如RTP标准用在H.323中。有的标准被生产厂家直接采用，如Cisco的IP/TV中采用了SDP协议。可以说，IETF标准是潜在的工业标准。因此了解这些相关标准和应用，无论对生产厂商还是一般工程技术人员，都是一种必要的技术储备。