早起媒体指的是媒体。（例如： 音频，视频）是在一个指定的会话被被叫接受之前进行交换的。在一个对话里面，早期媒体发生从初始化的invite发出以后到UAS产生回应。可以是单向或者双向的，可以由主叫或者被叫或者双方产生。典型的早期媒体是由被叫产生的回铃音和announcement（例如： 排队状态）早期的媒体是由被叫产生，由声音命令或者多音多频（DTMF）音来驱动语音交互应答系统（IVR）。 基本的SIP定义只支持简单的早期媒体。这些简单的机制有很多问题在forking和安全上，并且不满足大多数应用的需求。本文档在RFC3261之上，描述早期媒体的两个模型： 网关模式（GW）和应用服务器模式（application server model）。 虽然两种模型在本文档中描述更由于RCF3261，网管模式仍然有很多问题。尤其是网关模式跟forking之间不太work well。然而，网关模式需要，因为一下SIP个体（尤其是一些GW gateway）不能支持应用服务器模式
应用服务器模式标明了一些在GW上的问题。这种模式要用到ealy-session disposition type（在RFC 3959中标明了）。
本文剩下部分: section2 描述了offer/answer 模式缺少早期媒体. section3介绍了网管模式. 在这种模式下，早期媒体是由主叫的invite建立的. Section 3.1, 3.2, 3.4描述了早期媒体的局限性和适合应用的场景。
section4介绍了英语服务器模式，像之前阐述过的，它解决了一些网关模式中的问题。section5讨论了“Alert-Info”和两种早期媒体模型之间的交互。
2. SIP的会话建立
在介绍两种早期媒体模型之前，我们先简要的总结一下SIP中是如何建立会话的。让我们把早期媒体和SIP固有的features分开.(例如在200（ok）之前播放媒体来避免媒体剪裁)
SIP是通过offer/answer 模式来协商会话参数的。 一个用户agent 提供者，准备绘画的描述，叫offer.另一个用户agent，回复者，回复另一个会话描述叫做answer. 这样的双两个之间的向握手来协商用于媒体交换的媒体参数.
The offer/answer model decouples the offer/answer exchange from the
messages used to transport the session descriptions.例如, offer可以在invite请求中发出, answer可以在invite的200(ok)中回复.又或者offer可以在ivite里面没有SDP的200(ok)中携带.，随着answer在ACK中. 当可靠地临时回应(reliable provisional response)和update请求使用时，会有更过的方式来交换offer和answer.
当用户（或者设备产生媒体）相信媒体会话已经建立，但是实际上建立的流程还没有完成时，就会发
生媒体裁剪。用户开始说话（例如产生媒体）开始的一些音节或者是一些词语会丢失。
第一种媒体裁剪。
当offer/answer交换发生在200（ok）回复和ACK中时， 媒体剪裁不可不免。被叫
用户开始在200（ok）发出以后开始说话。但是UAS（被叫）没有发出任何媒体直到UAC（主叫）通过ACK发出的回复到UAS（被叫）。
另一方面，在大多数的offer/answer情况下（invite带offer，200ok携带answer），媒体裁剪不会发生。一旦UAC（主叫）发出offer，他们随时准备播放出收到的媒体报文，因为他们不能指望通过收到200ok来开始播放被叫的媒体， SIP信令和媒体代表性的横穿不同的路径。因此媒体消息可能在200ok回复之间到达。
第二种媒体裁剪。
从上面分析，另一种媒体剪裁（跟早期媒体没有关系）发生主叫到被叫方向。当被叫债基开始说话，UAS（被叫）发出200ok回应其中带着answer。与此并行的是第一个媒体报文。假如第一个媒体报文在媒体answer之前到达UAC（主叫）。然后被叫开始说话，UAC不能发出任何媒体直到从UAS那里收到200（ok）回应。
3. 网关模式
SIP用offer/answer模式来协商会话参数(在section2中描述的一样). 当offer/answer的交换在invite的最后响音之间发生.那么随之建立的就是早期媒体会话. 当invite的最后相应发出以后，早期媒体会话结束.假如200ok是最哦那个相应，早期媒体会转变成正常媒体会话.假如最后的响应是非200类的，那么早起媒体会简单的结束.
不出人意料的，在早期媒体会话以内的媒体交换参考(refer to)早期媒体. 网关模式的早期媒体是通过offer/answer在可靠地临时回应消息PACK和 UPDATE构成的.
网关模式在forking上会有很严重的局限，会在sesion3.1中描述。 因此，它只用于当UA不能区分早期和正常媒体的时候，这部分在setion3.4中描述。在其他情况下（大部分的UAs）强烈推荐使用应用服务器模式。
3.1 forking
在缺少forking的情况下，假设初始化的invite包含了offer，网关模式不会产生媒体剪裁。下面正常的SIP流程中，UAC当它在invite中发出初始的offer的时候它可以随时播放任何收到的媒体消息。UAS发现在可靠地临时响应中发出回应，然后当有媒体发出时，它就会立即发出。即使第一个媒体报文在1XX的回应之前到达UAC，UAC也会播放出他们。
注意，在一些情况下，UAC需要先收到回复，才有可能播放出任何媒体。UAs在这种情况下（例如QoS， 媒体鉴权，或者需要媒体加密时）用precondition来避免媒体剪裁。
另一方面，假如invite forks。网关模式可能会产生媒体剪裁。这样情况会在当UAC对于自己发出的offer收到很多不同临时相应的不同的answer时发生。UAC不得不面临带宽限制和早期媒体会话的选择。
飞羽辅助
假如UAC从不同的UAS收到早期媒体，它将会显示给用户。 假如早期媒体有语音，那么在同一时间播放不用的语音流给用户，将会混淆。另一方面，
不用的媒体形式（例如：视频）可以在用一时间展现给用户。 例如UAC可以创建马赛克用不同的input。
然而，即使不同的媒体类型可以在同一时间展现给用户，假如UAC的带宽有限制，它将不能同时收到从不同用户来的不同的早期媒体。因此，很多时候，UAC需要选择一个单一的早期媒体会话， 然后mute（静音）它们发出update 请求。
皮衣加工
进化标记很难决定那种早期媒体会话携带的信息更好的表现被叫的观点。事实上，在很多情况下，UA甚至不能将媒体报文和它们特殊的SIP早期对话相联系。因此，UACs一般随机一个早期对话，然后静音其他的。
假如一个早期会话媒体转成一般媒体会话，而正好是一个被mute的早期媒体。（例如UAS发送2XX回复）那么媒体剪裁很可能发生。UAC一般发送UPDATE带着新的offer（随之收到invite的200ok）来解静音（unmute）的媒体。UAS不能发送任何媒体直到他收到从UAC发出的offer。因此，假如被叫在收到UAC发出的offer之前开始说话，那么他的话语竟被丢失。
让UAS发送UPDATE来unmute媒体会话（代替UAC）不能避免反向的媒体裁剪。并且还会引来可能的竞争情况。
八音盒制作
3.2 产生回铃音
在PSTN系统中，电话交换机一般会给主叫播放回铃音给，酮装置被叫正在被振铃。何时，何地如何产生回铃音已经被标准化了。（例如，被叫的本地交换机产生标准的回铃音，当被叫正在振铃时。）在一个均匀，同样的环境like PSTN下通过这种标准化的方式提供这样的反馈给用户是很合理的。因为所有的终端都有相同的用户界面。
这样的均匀相同在SIP用户代理上是不能到的，SIP用户代理拥有不同的容量，不同的界面和可能会建立回话根本不设计语音形式。因此，SIP UA提供给用户关于会话建立过程的信息是一个本地策略。例如，一个带GUI图形界面的UA可以选择在屏幕上显示消息，当被叫正在振铃时。然而另一个UA可能选择显示一个电话振铃的图片。很多SIP UAs选择效仿PSTN的用户界面。他们提供回铃音放被叫正
在振铃时。这样的UAC被假定在本地给这个用户产生回铃音，当没有早期媒体从UAS收到时。假如UAS产生了早期媒体（例如一个宣告announcement或者一个特殊的回铃音），那么UAS就应当播放它们而不是本地的回铃音。
问题是，有时候UAC很难知道它是不是会受到早期媒体或者它将要自己产生回铃音。 UAS可以不在可靠地临时响应中发送早期媒体（非常简单的UAS这样做）或者它可以在可靠地临时响应中发送一个answer但是不带有发送早期媒体倾向（这就是资源预留precondition的情况了）。因此通过只看SIP信令， UAC不能确定对于一个指定的会话会不会有早期媒体。
UAC需要检查在收到消息时是否也收到了媒体报文。
.\Sound\default\Ringing.wav
真正的实现甚至需要看媒体报文里面的消息，因为它们可能只带了无声或者舒适噪音。
带着这些问题，UAC应该研制它们关于产生本地回铃音本地的策略。例如 一个POTS（普通老式电话系统）like SIP UA可以实现下面的策略。
1. 除非收到180rining回复，否则不要产生本地铃音。
2. 假如180ringging收到了，但是任何进了的媒体报文，那么产生本地铃音。
3. 假如180ringing收到了，并且有进来的媒体报文，播放它们，不产生本地铃音。
注意180ringing回复意味着被叫正在振铃，无论早期媒体会话的状态如何，UAS都应该发出这样一个回复（180ringing）告诉主叫被叫已经被alerted。
乍一看，这样的策略可能对于分解的UA（例如媒体网关控制和媒体网关，就是信令媒体分开）来说很难， 但是这样的策略跟section2中描述的一样，必须在任何的UA上实现。这样就是任何UA应该播放进来的媒体包（停止产生本地振铃音假如已经在播放了）为了避免媒体裁剪，即使200ok回复还没有收到。因此，实现这种早期媒体策略的工具已经在任何使用SIP的UA上实现了。
注意，然而它不值得去规范一个本地策略来让每个SIP UA遵循。一个特殊的子集that 差不多均匀的SIP UAs（就是不同类型的sip UA）都会约定有相同的本地策略。例如，这样的SIP UA子集“所有的PSTN/SIP网关” 或者每个SGPP IMS终端。然而，定义特殊的的common 策略给不同的SIP 设备组来使用，不包括在我们的文档中。
3.3 缺少早期媒体标识
SIP，不像其他的信令协议，不会提供早期媒体标识。那么就是说在SIP中没有信息能显示早期媒体在还是不在。而只有的标识可以潜在的使用来避免UAC产生本地铃音，当UAS尝试去提供in-bind 铃音或
者是一些类型的通告announcement。 然而，最关进的问题是，这样的标识可能很少用到，由于SIP的工作方式。
一个很重要的原因限制了潜在早期媒体标识的好处，因为SIP信令和媒体的分离（疏耦合）。SIP信令跟媒体在不同的路径传输。媒体路径被特殊的优化来减少端到端的延迟。（例如，最少的数量的中间商），然后SIP信令要通过很多的proxy来提供给会话不用的服务。 所以，很有可能早期媒体报文在比携带早期媒体标识的SIP消息早到达UAC。
然而，有时SIP回复在任何媒体包之前到达UAC。有一种情况就是UAS尝试发送早期媒体但是不能立即发送。例如，UAs在交换媒体之前，需要用交互式链接建立（ICE）可能需要很多次UDP协议的交换遍历通过NAT（STUN）消息。再这样的情况下，一个早期媒体标识可以让UAC在这
期间不产生本地铃音。然而，当早期媒体没有到达UAC，用户不会知道对方正在振铃，即使180ringing被收到了。因此，一个播放本地铃音是个很好的解决方法，知道早期媒体报文从UAS发到UAC。这样的解决办法不需要早期媒体标识。
注意，UAC发生本地铃音迁移到早期媒体，当遇上forKing也是一样。一个UAS发出一个180ringing回复，然后另一个UAS喀什发早期媒体。
3.4 网关模式的适用性
Setion3 描述了一个网关模式的局限性，它将产生媒体剪裁在forking情景下，并且要求媒体监测在恰当的时候播放本地铃音。 这些问题都在应用服务器模式下addressed，将在section4中描述。那是一个推荐的方式来产生早期媒体，它是不会在会话中跟一般媒体连续的。
因此，网管模式适合当UA不能将早期媒体和一般媒体分开的设备。一个PSTN网关是符合这种情况的例子。PSTN网关收到从PSTN circuit上来的媒体， 炭黑发去IP网络。 网关不会知道媒体的内容，他不会知道什么时候早期媒体转换成一般媒体。 从PSTN的角度，circuit是一个连续的媒体来源。
4 应用服务器模式
应用服务器模式通过使用UAS的行为作为一个应用服务器来很UAC建立早期媒体会话。UAC要标识支持early-session disposition type，通过early-session option tag。这样UAS知道他们可以将早期媒体（early-session disposition type）的offer/answer交换和一般媒体（session disposition type）的分开。
发送早期媒体通过与一般媒体发送不同的offer/answer可以避免forking情况下的媒体裁剪。 当初始化的invite被认可了，UAC可以拒绝或者mute新的早期媒体的offer，不用mute一般会话的那个session。UAC可以给后来的会话一个优先级。通过这样的方式，应用服务器模式可以在适当的时候从早期模式转到一般会话。
单列调心滚子轴承给早期会话使用分开的offer/answer也可以帮助UAC决定是不是应该产生本地铃音。假如早期回家建立了，并且早起会话抱恨一个语音流， UAC可以假设将有进来的早期媒体，它就可以避免产生本地铃音。
另一种模式将用“early media”标签在UAC和UAS的原始绘画中引入新的媒体流，就是使用UPDATE来代替建立新的早期媒体。我们可以选择协调应用服务器（很UAS不在一个实体）使用的机制，这种方式，UAS使用相同的方式跟UAC在网络里面交互。
An alternative model would include the addition of a new stream,
背板制作with an "early media" label, to the original session between the
UAC and the UAS using an UPDATE instead of establishing a new
early session. We have chosen to establish a new early session to
be coherent with the mechanism used by application servers that
are NOT co-located with the UAS. This way, the UAS uses the same
mechanism as
豫公网安备41160202000603
站长QQ:729038198
关于我们
投诉建议