早期媒体

早期媒体的概念比较泛，只要处于早期对话内的媒体交互都属于早期媒体。

根据方向性，早期媒体可以分为前向早期媒体、后向早期媒体，当然也可能出现双向早期媒体。当前我们主要关注后向早期媒体。

根据目前RFC标准规范定义，早期媒体有Gateway模式、App模式，目前《中国电信IMS网络SIP协议总体技术要求》必须支持Gateway模式，对于App模式没有做特别说明。当前我们主要关注Gateway模式。

前向早期媒体

前向早期媒体是指由主叫定制向被叫方播放的媒体，比如在早期对话阶段，根据一些特殊业务需求，需要主叫向被叫发送按键音。或者一种新业务，多媒体彩像功能（多媒体彩像是由主叫定制，被叫享用的业务，在主叫呼叫被叫时，多媒体彩像平台向被叫用户播放主叫用户定制的多媒体信息）等都属于前向早期媒体。

后向早期媒体

后向早期媒体是指由被叫定制向主叫方播放的媒体，这个我们最熟悉的就是是彩铃业务，当主叫呼叫被叫时，会听到被叫设置的不同彩铃音乐。

Gateway模式

网关模式主要为了兼容现网中大部分不支持APP模式的传统设备，整个早期媒体的控制全部集中在网络中做为网关的网元设备，使得终端不会感知到远端到底有多少个媒体源。

在上图中Server充当网关的角色，在对话初期，被叫侧UE_B提供了媒体源，同时Server为了完成特定业务，也提供了媒体源。

1)、UE_A与Server建立好媒体协商

UE_A在初期发送Invite请求后，虽然被叫UE_B提供了自己的媒体信息，但此时Server正好也需要在早期对话完成特定媒体发送业务，所有Server将UE_B的媒体信息屏蔽了，

使用自己的媒体信息与UE_A完成初期交互。

2)、UE_B摘机后，Sever辅助完成UE_A与UE_B的媒体协商。

UE_B摘机后，在200OK中将不会再带媒体信息，因为之前已经完成了一对交互处理。这时候Server为了挽回之前丢失的UE_B信息，只能通过Reinvite不带SDP，再重新向UE_B索取一次媒体信息，得到UE_B的信息后，Server通过Update与UE_A完成协商，之后将协商的结果通过Reinvite流程中的ACK告知UE_B，完成最终的双方媒体协商。

在《RFC5009》中，针对Gateway模式早期媒体，定义了P-Early-Media头域，《中国电信IMS网络SIP协议总体技术要求》标准仅以“sendonly”值为通用场景，其它“inactive”、“gated”值不做考虑。这里大家一下要理解一下，早期媒体里面的sendonly等头域值和SDP中sendonly不同，不代表收发模式的意思，它们表示的是传输方向，sendonly表示从被叫侧到主叫侧方向的媒体，即后向早期媒体，同时，早期媒体头域与SDP同时出现时，也不会有冲突，早期媒体协带sendonly，仅仅告诉终端请把你的RTP接收线程准备好，我要向你发送，而SDP中的sendonly是告诉终端的Dsp，当你什么时候准备发送数据时，记得按我告诉你的收发模式来处理。

这个流程和上一个流程在Server与UE_B之间的处理有些不同，目前标准仅定义早期媒体的概念，在具体实施上并没有刻意描述如保处理，这里因为中国电信目前仅关心后向早期媒体，所以实例中我们仅描述UE_A与Server的信令交互体现。

1）UE_A发起初始Invite请求

INVITEsip:ue_b@ ims.com SIP/2.0

P-Early-Media：supported

信令中协带P-Early-Media：supported头域，指明UE_A支持网关模型的早期媒体

2）Server完成与UE_A的早期媒体处理

Server在收到Invite请求后，知道UE_A支持此功能，转发不含SDP的Invite请求（此处实现可以简化与UE_B的交互流程），之后给UE_A回应183SDP，在183信令中添加P-Early-Media：sendonly，来告诉UE_A现在Server想在早期对话中给其发送媒体信息。

SIP/2.0183 Session Progress

P-Early-Media：sendonly

3）UE_A处理早期媒体（当前我们仅考虑无资源预留的情况下）

• 如果收到的第一个180响应无SDP，则本端自己提供回铃音，直到以下场景出现后将停止本地回铃音：

• 收到最终应答

• 收到带有P-Early-Media+ SDP的18X消息，或者带有P-Early-Media+ SDP的UPDATE消息，或者失败的消息

• 收到的第一个18X消息带有P-Early-Media+ SDP，是由网络侧提供回铃音

4）被叫UE_B摘机后，Server处理

当被叫UE_B摘机后，在200OK里协带自己的SDP信息，Server通过使用Update与UE_A进行信令交互，来完成UE_A与UE_B的媒体协商。

UPDATEsip:ue_a@ ims.com SIP/2.0

P-Early-Media：sendonly

5）收到UPDATE后，UE_A处理

UE_A在收到含有P-Early-Media+ SDP的UPDATE后，了解到早期媒体已经完成，网络侧更新了媒体源，则对新的媒体源进行重新协商。

App模式

在网关模式小节，我们看到第一个流程图中，如果UE_B和Server都提供早期媒体源，则会导致UE_B的媒体信息被丢弃，因为传统SIP的媒体交互是成对出现的，并且在同一时间仅能处理一对媒体协商，同时信令交互上比较繁琐。

App模式为了解决这种问题，提出在终端与服务器侧，可以同时在一个信令消息中处理多个媒体协商的机制，这种实现很大程度上减少了信令交互，也完成了完美的无缝媒体切换。但该机制需要终端与服务端都必须支持才可以，中国电信考虑到目前现网中传统SIP终端还占据很大的使用比例，所以目前对该模式并没有强制要求终端需要实现。

1）UE_A发送Invite请求，告知Server他支持APP模式早期媒体

INVITEsip:ue_b@ ims.com SIP/2.0

Supported:early-session,100rel

Content-Type:application/sdp

Content-Disposition:session

v=0

o=UE_A2890844730 2890844731 IN IP4 ims.com

s=

c=INIP4 192.0.2.1

t=00

m=audio20000 RTP/AVP 0

• Supported头域值含有early-session，表明终端支持APP模式早期媒体

• Content-Disposition:session 指明当前的BODY是一个普通会话媒体

2）Server收到被叫媒体信息后，自身也需要提供媒体，则在183响应中协带多个媒体信息，其中第一个Content-Disposition:session是UE_B协商后的媒体信息，指明是普通会话媒体，第二个Content-Disposition:early-session是Server向UE_A发出的会话媒体请求，同时指明是早期会话媒体。

Content-Type:multipart/mixed; boundary="boundary1"

Content-Length:401

--boundary1

Content-Type:application/sdp

Content-Disposition:session

v=0

o=Bob2890844725 2890844725 IN IP4 host.example.org

s=

c=INIP4 192.0.2.2

t=00

m=audio30000 RTP/AVP 0

--boundary1

Content-Type:application/sdp

Content-Disposition:early-session

v=0

o=Bob2890844714 2890844714 IN IP4 host.example.org

s=

c=INIP4 192.0.2.2

t=00

m=audio30002 RTP/AVP 0

--boundary1--

3）UE_A收到含有两个媒体信息的183响应后，已经得到UE_B的媒体协商应答，同时也了解到Server发来一个早期媒体请求。此时，UE_A将与UE_B的普通媒体信息先存储到本地，并对Server发来的早期媒体请求进行协商处理，之后在PRACK信令中仅将与Server协商后的媒体信息发送给Server端。

Content-Type:application/sdp

Content-Disposition:early-session

v=0

o=alice2890844717 2890844717 IN IP4 host.example.com

s=

c=INIP4 192.0.2.1

t=00

m=audio20002 RTP/AVP 0

4）Server收到UE_A早期媒体会话响应后，完成早期媒体的处理，之后给UE_A提供早期媒体源。

5）UE_B摘机应答后给UE_A发送200响应，UE_A收到200响应后，了解到当前对话已经变为正式对话，此时UE_A自动将媒体处理切换为之前保存的普通媒体会话。

参考资料

《中国电信IMS网络SIP协议总体技术要求》

《基于IMS的早期媒体类业务》

《VoipIMS早期媒体建立中多实体媒体协商解决方案》

《SIP中的早期媒体earlymedia与回铃音》

《RFC5009》

《RFC3959》

《RFC3960》