H.248-Transcoding与Interception

Transcoding

PLMN中的Transcoding

在PLMN（Public Land Mobile Network）中，跨网络的语音通信时，有可能在一次呼叫的用户面存在四次编码解码操作：

主叫UE(encoding 成AMR)->主叫侧BTS(decoding成 G.711)->被叫侧BTS(encoding 成AMR)->被叫UE(decoding)

3GPP希望减少编解码转换，即在用户面只进行一次编码解码操作。

3GPP定义了OoBTC（Out of Band Transcoder Control）带外语音编解码控制的协议，利用TrFO（Transcoder Free Operation）机制进行语音编解码初始化、协商、速率控制等操作。同时，定义了TFO协议，主要为了实现与2G的互通（当然3G也支持TFO模式）：

TrFO带外协商、呼叫建立过程中协商

TFO带内协商，呼叫建立后协商

TFO（Tandem Free Operation）呼叫：在语音呼叫的通讯路径上相邻的TC都支持TFO协议时，如果两者的编解码类型相兼容，则两个TC之间可以传输压缩的语音编解码而不再是PCM编码。

TRFO呼叫与TFO呼叫的联系和区别：

TRFO呼叫是在呼叫建立过程中使用带外信令进行端到端的编解码协商，找到呼叫的通讯路径上各方都能支持的编解码类型，使得呼叫通讯路径的用户面上传递压缩编解码，而可不使用TC。

TFO呼叫是在呼叫进入稳态以后，相邻的TC之间使用TFO带内协议进行带内协商。如果两个TC的编解码类型可以兼容，则TC之间可以传递压缩的编解码。

TRFO和TFO呼叫在通讯路径上都传输压缩编解码，减少了码型转换的次数，提高语音质量。但是TRFO呼叫进行的是带外控制，不需要TC的参与。可以节省TC设备，降低运营成本。而TFO呼叫进行的是带内控制，必须有TC的参与。

IMS中的Transcoding

IMS中，也存在PLMN中类似的需求。一般，VOIP用户面是直接在主被叫终端间建立的，中间没有其它网元。但由于终端多样性。不同的终端或者网元（指MGW，用于IMS终端与PSTN、PLMN互通时）采用的编解码不同，会让呼叫失败。比如固定接入网的IMS终端支持G.711，CDMA 接入的IMS终端支持EVRC，3GPP接入的IMS终端支持AMR。

此时类似于PLMN中的TC，3GPP认为应该有一个网元来做transcoding。

3GPP的TS23.228 的5.14.4以及Annex P中采用了MRFC/MRFP来完成。其方式分为预先transcoding以及失败后transcoding。

在中国电信集团公司技术标准-视频互通网关技术要求中提出：Video Interworking Gateway (VIG)应该支持以下语音编码格式及转换：

-- G.711u

-- G.711a

-- G.723

-- G.729

-- EVRC

-- EVRC-B

-- AMR

中国电信视频互通网关（VIG）是实现各种IP终端（例如：VT手机、PC客户端、机顶盒终端）视频互通的功能实体，包含信令互通功能（SIF）和媒体互通功能（MIF）两个模块。SIF控制互通双方在SIP信令中完成媒体协商，当主被叫媒体类型不一致时，SIF将控制MIF分配媒体资源和完成媒体转换；MIF在会话建立后实施媒体流的转换。

进行视频通话的两个终端（如VT手机、IMS PC客户端、机顶盒终端等）都属于IMS终端，该场景下，VIG在被叫侧部署，控制双方终端的媒体协商和媒体转换。

如果视频通话双方的媒体能力不匹配、无法直接互通，SIF将分别与主、被叫进行媒体协商，并控制MIF分配媒体资源，实施媒体流的转换。如果视频（音频）能力匹配，但音频（视频）能力不匹配，为保证音/视频同步，音频流（视频流）经MIF转换的同时，视频流（音频流）也要通过MIF的透传。

如果视频通话双方可以成功协商媒体能力，SIF只需要透传主、被叫的媒体能力信息，媒体流可直接在互通双方间传送，以节省MIF的资源。

SIF应支持使用以下两种方式来控制MIF参与媒体协商：

1）视频互通网关控制方式（推荐方式）

该方式是指SIF向被叫转发主叫SDP信息时，添加预置的被叫适用的媒体能力，并对被叫返回的SDP应答进行判断。如果主、被叫双方的媒体能力能够匹配，则直接将被叫的SDP应答转给主叫，会话建立后主、被叫之间直接传送媒体流；如果不能匹配，则由SIF根据主、被叫媒体能力分别与主、被叫进行媒体协商，并在会话建立后由MIF实施主、被叫媒体流的转换和转发。

2）被叫控制方式

该方式是指SIF在向被叫转发主叫SDP信息时，不判断主、被叫双方的媒体能力是否匹配。如果被叫终端发现能够匹配主叫媒体能力，则返回SDP应答，会话建立后主、被叫之间直接传送媒体流；如果不能匹配，则返回488或606消息，并在488或606消息的SDP中携带被叫支持的媒体能力（若终端不支持通过488消息带SDP，则由视频互通网关添加预置的被叫适用的媒体能力），SIF根据主、被叫媒体能力分别与主、被叫进行媒体协商，并在会话建立后由MIF实施主、被叫媒体流的转换和转发。

1）H.263编码能力的描述：

m=video 5132 RTP/AVP 34

b=AS:64

a=rtpmap:34 H263/90000

a=fmtp:34 profile=1; level=10

a=fmtp:34 QCIF=2 CIF=2 MaxBR=640

2）H.264编码能力的描述：

m=video 49170 RTP/AVP 98

b=AS:384

a=rtpmap:98 H264/90000

a=fmtp:98 profile-level-id=42A01E; packetization-mode=0;

sprop-parameter-sets=Z0IACpZTBYmI,aMljiA==

3）MPEG-4编码能力的描述：

m=video 49170/2 RTP/AVP 98

b=AS:384

a=rtpmap:98 MP4V-ES/90000

a=fmtp:98 profile-level-id=1;

config=000001B001000001B5090000010000000120008440FA282C2090A21F

4）G.711 A编码能力的描述（G.711 u、G.729、G.723类似）：

m=audio 13492 RTP/AVP 8

a=rtpmap:8 PCMA/8000

a=ptime:20

5）AMR编码能力的描述：

m=audio 10024 RTP/AVP 97

b=AS:13

a=rtpmap:97 AMR/8000

a=fmtp:97 octet-align=1; crc=0; robust-sorting=0; interleaving=0

a=maxptime:20

6）EVRC编码能力的描述：

m=audio 10024 RTP/AVP 99

b=AS:13

a=rtpmap:99 EVRC/8000

a=fmtp:99 maxinterleave=0 silencesupp=1 dtxmax=32 dtxmin=12 hangover=1

a=maxptime:60

对于只支持音频的互通网关，对于呼叫中同时含音频、视频（即两个m行时)，MRFC会过滤出音频给MRFP。视频仍发给被叫或主叫侧，所以最后两个终端通话时，音频RTP通过MRFP。视频RTP是终端直联的。

（1）对于预先transcoding，核心网元通过各种途径获知被叫端支持的编解码格式类型，而主叫端给出的编解码格式被叫都不支持。

（2）核心网元向MRFC申请一份媒体，媒体的对端IP以及端口为UE-A给出的SDP，媒体的编解码格式为UE-A支持的格式（code-A）。

（3）核心网元同时向MRFC申请另一份媒体，此媒体支持的编解码格式为被叫支持的编解码格式（code-B）。

（4）MRFP上会把这两个媒体进行关联，并进行transcoding。

（5）核心网元发送给被叫用户的媒体地址为MFRP给出的媒体，编解码格式为code-A+ code-B。被叫用户回应答消息，选择了code-B。

（6）核心网元将被叫用户的IP地址及端口号通过MRFC通知给MRFP。

（7）核心网元修改被叫用户的应答，将媒体替换成MRFP的媒体，编解码格式为code-A，通知主叫用户A。

失败呼叫后的transcoding的流程如图

（1）此流程和上面不同的是，呼叫先到被叫用户。被叫用户不支持主叫端给出的编解码格式，回异常响应。

（2）核心网元根据被叫端给出的异常响应，如果携带了被叫端支持的媒体，则上面流程中code-B为此媒体。如果没有，则发送给被叫用户的INVITE消息中携带MRFP所支持的全部媒体编解码格式。此后流程同预先transcoding的流程。

Transcoding功能的H.248流程

在3GPP TS 23.333(Multimedia Resource Function Controller (MRFC) - Multimedia Resource Function Processor (MRFP) Mp interface) 中只说明了对于Audio Transcoding 、Video Transcoding 的需求。未介绍具体H.248流程。

对于transcoding功能进行媒体控制的基本思路是：

以预先Transcoding流程为例。

核心网\MRFC 向MRFP发送两个Add命令，在一个上下文Context中申请两个RTP，即两个终端点（T1，T2），然后分别在SIP消息中把T2给被叫用户、T1给主叫用户。所以现在主叫终端看到的远端是T1，被叫侧看到的远端则是T2。而MRFP内部因为T1、T2这两个终端点在一个上下文中，则媒体流是双向互通的，但因为编解码不同，MRFP会自动转换编解码（这也是对MRFP的一个要求）。

比如在收到初始invite时，MRFC发现主叫侧媒体是G.711（编解码格式为RTP/AVP 0），且知道被叫侧只支持EVRC（编解码格式为RTP/AVP 99 a=rtpmap:99 EVRC/8000）。则MRFC控制MRFP产生的T1、T2。

目的是：T1给主叫（让T1的Remote 媒体为主叫媒体）。T1采用RTP/AVP 0。T2给被叫，T2采用的编解码格式为RTP/AVP 99 a=rtpmap:99 EVRC/8000。

MRFP会对两个add，返回两个reply，分别携带T1、T2媒体（IP地址，端口号、编解码格式）。

核心网\MRFC 在发给被叫的初始invite中，携带了T2媒体（作为SDP offer放在invite中）。之后，被叫在200 ok中返回自己的SDP answer。这个SDP会被MRFC在H.248 Modidy消息中作为T2媒体的Remote媒体发给MRFP。这时，被叫与MRFP之间的用户面已经建立起来。

然后核心网\MRFC 在发给主叫的200 ok响应中，携带T1媒体（作为SDP answer）。这时，主叫与MRFP之间的用户面已经建立起来。

呼叫释放时，用sub时，和add相对应，有几个add，就必须有几个sub。

注1：通过将两个终结点放在一个context，一个stream中，表示这两个终结点/端点是串在一起的，这就是transcoding功能，这种操作在会议中也有，只是会议中不需要编解码转换功能。但248流程类似。

注2：如果 transcoding功能在主叫侧核心网\MRFC 来做，那么预先transcoding流程中，transcoding功能完成后。被叫侧核心网\MRFC 收到的初始请求中已经携带的是T2媒体。被叫侧会对主叫放回铃音、彩铃音，这个媒体是与T2终结点互通的。

注3：transcoding功能要求核心网可以知道主叫、被叫的媒体是不一致才会启动。如果核心网没有被叫媒体的信息，则可以对所以呼叫都默认采用transcoding流程。而呼叫建立后，如果主被叫之间的编解码格式一致，则MRFP能建立T1与T2之间的直达通路，不再利用TC资源。这种做法在H.248接口上只多了一些交互消息，信令面开销增加不大。媒体面由MRFP自适应选择是否做Transcoding。

注4：由于IMS中分主叫、被叫侧网络，即transcoding功能可以在主叫MRFC、或被叫MRFC完成。两个MRFC必须在呼叫中协调一致，只允许发生一次Transcoding。即不能发生：主叫与被叫侧都发生Transcoding的情况，这不影响呼叫体验，但浪费了媒体面资源。办法是通过运营管理手段或主叫侧在信令中携带特殊标识（表示自己是否做过Transcoding)。

如果MRFP支持音频与视频，而主叫终端发出的SDP中含同时含音频、视频（即两个m行时)，MRFC要把每个m行要分别放在H.248的两个Stream Descriptor 中发给MRFP，因为一个流中只能含一个媒体流(m行）。两个流间的同步由终结点内部的机制保证。

此时，如果MRFP只支持音频（MRFP不支持视频，或主被叫可以支持就视频编解码协商成功），MRFC在H.248接口上只传递音频m行媒体（过滤出音频），在发给被叫的初始invite中携带原视频m行与T2媒体。在200 ok中得到视频m行的answer后，与T1媒体m行一起放在 200 ok中发给主叫侧。

所以最后两个终端通话时，音频RTP通过MGW。视频RTP是终端直联的。

===============================================

监听

3GPP监听标准见：

3GPP TS 33.106 Lawful Interception requirements

3GPP TS 33.107 Lawful interception architecture and functions

3GPP TS 33.108: "3G Security; Handover interface for Lawful Interception".定义了各监听接口的具体参数

此外，3GPP引用了ETSI的诸多监听标准。

3GPP TS 33.107定义了3GPP各网络的监听方式。3GPP 的监听包括电路交换（Circuit switched）的监听、包交换（Packet Switched）的监听、CSCF的监听、WLAN的监听以及IMS会议（IMS Conferencing）的监听。

IMS网络的MRFP只需要完成会议的X3接口监听，不需要完成基本呼叫、其它补充业务的监听。原因是：不管IMS的接入网是通过CS域，还是PS域、Wlan域接入，UE收发的媒体在这三个接入域中是完全可见的。所以3GPP只要求在这三个接入网中完成X3接口的监听（监听网关LIG可能需要在X3接口，区分出语音媒体、各种数据媒体后发给LIC）。

而在会议中，媒体流汇聚到IMS网的MRFP中。

注：在合法监听中，接口分为X1、X2以及X3接口。

其中X1接口消息主要完成设置、取消、查询监控对象等功能。

X2接口主要完成呼叫相关事件(例如呼叫开始、用户应答、呼叫释放、发生前转业务、发生限制业务、注册注销、DTMF收号、CC通道标识、激活撤销业务事件报告等)的上报。CC通道指X3信令接口的会话标识

X3接口主要完成通信内容的提交。X3接口由于涉及通信媒体，则与H.248有关。

MRFC要控制MRFP完成语音媒体的复制。

与其它H.248流程不同的是，监听中使用了H.248 Topology描述符。

3GPP TS 33.107中有

如图，用户面连接是RNC A->MGW 1->MGW 2->RNC B。信令面连接是RNC A->MSC1->MSC2->RNC B。

X1、X2接口在MSC1-DF3间建立。X3接口在MSC1-DF3、MGW1-DF3间建立（因为分信令接口与媒体接口）

上图中是收发分离方式监听的例子。上图虽然是指MSC控制MGW出来X3接口，但对于IMS同样适用。

核心网可以通过控制MRFP，类似于Transcoding一样，让主被叫媒体流通过MRFP中转。而MRFP截取到语音、视频媒体后，可以与LIG建立RTP连接（这也是在核心网的控制下），把主被叫的媒体原样复制一份发给LIG。

3GPP TS 33.107中有

这张图反映出H.248的控制流程，

在 Ctx=1,accept(T5) 表示事务已经完成（TransactionAccept响应）， topology关系是：(T1, T5, oneway) ，T1用于接收主叫UE的媒体流，这个topology让T1媒体流单向复制发送给T5终结点。

之后，“Establishment between MSC1 and DF3”之间的信令流程（有时也称为 X3通道创建信令）与H.248流程被忽略了。它的细节应该是MSC1在信令里通知DF3 Signaling 模块（信令中携带了T5 媒体的SDP，这个信令流不是X2接口，应该称为X3接口的信令部分），而DF3 signaling模块则控制DF3 Bearer（应该是另一个MGW）产生T7与T8终结点，T7媒体 SDP在信令响应中返回给MSC1（再在H.248 modify中发给MGW，让T5与T7加到一个上下文中）。T8媒体则发给LEMF。同样，T7与T8之间也是单向topology。

之后，Ctx=1，Topology（{T*，T$，isolate},{T1,T$,bothway}) 似乎是错的。{T*，T$，isolate}意思是所以名称以T开头的终结点不能把媒体流发给返回结果T2，应该是{T5，T$，isolate}。{T1,T$,bothway}则表示T1与T2之间是双向媒体流，这个topology完全没有必要，当add一个终结点（指T2）到当前上下文时，默认与当前所有终结点是互通的。

。。。

MGW上产生的各终结点(T1,T2,T5,T6)均在同一个上下文、同一个Stream(终结点的Media描述符中的StreamID表示，它表示了哪些终结点之间有连接关系)中。

如这些终结点不在同一个stream中，则媒体流不能连接在一起。

如不采用Topology描述符(属于上下文的属性)，它们之间的媒体流都是互通的（拓扑描述符的缺省值是：关联双向bothway）。 Topology 描述Context内各终结点间的流的方向，用于Context而不是 Termination。

终结点的模式（send/receive/）则描述了该终结点对外的媒体流向（即与上下文外部实体之间的媒体流方向，或说是 MGW入口和出口处的媒体流流向，而不是在上下文内）。则T1\T2应在Add时指定为sendrecv（如果是放回铃音、呼叫保持、呼叫等待等业务中，这两个媒体流也可指定为sendonly），X3媒体流T5\T6则指定为sendonly

另一种更简单的H.248控制流程可以是：MSC在收到终端发来的呼叫信令时，首先控制MGW在上下文C1中产生两个终结点RTP，称为T1，T2，分别作为上行通道以及下行通道。上行通道T1与主叫UE互通。下行通道T2与被叫UE互通。

由于监听媒体采用收发分离方式，MSC向MGW中通过Add操作，指示MGW在上下文C1中再Add两个RTP，分别为T5，T6，并且通过Topology{T1,T5,Oneway}，Topology{T2,T6,Oneway}}指定T1’只接收来自T1的媒体流，T2'只接收来自T2的媒体流。

然后，MSC将T5以及T6所对应的SDP 通过信令发给LEMF。

如果MSC是IMS中的MRFC，那么这个信令就是SIP信令中的invite。由于是收发分离方式。MRFC会与LEMF之间建立两个单独的SIP会话，分别传递T5 SDP与T6 SDP。LEMF在两个SIP会话中分别返回两个200 ok，分别携带T7，T9，此时MRFC发两个modify给MRFP。指示T7作为T5的远端、T9作为T6的远端。此时，MRFP与LEMF之间的两个RTP流就建立起来。

然后，MSC（要先控制BTS分配RAB资源）或IMS\MRFC 再传递信令给被叫侧网络。

注：如被叫侧网络中也指示对这个呼叫进行监听的话，同样的过程也会在被叫侧网络再发生一遍。

收发合并方式的流程重点是topology设置不同。

比如MSC在产生T1、T2之后，由于知道LEMF要求收发合并方式，则MSC通过add，指示指示MGW在上下文C1中再Add一个RTP。此RTP为T56，并且通过Topology{T1,T56,Oneway}，Topology{T2,T56,Oneway}}指定T56接收来自T1的媒体流，T56接收来自T2的媒体流。此后MSC与LEMF之间的X3信令接口只会产生一个会话，因为MGW与LEMF之间的X3接口媒体流只有一个RTP通道了。

IMS网络中其它的监听方案还包括：

1， MRFC控制主被叫终端分别与LEMF\LIG 通信，即媒体流通过LIG中转。让LIG本身转发媒体流给LIC监听中心。（即通信媒体没有通过MRFP。而对MRFC来说，流程也简化了）

2，核心网不提供X3接口（只提供X1、X2接口）。由核心网入口网元A-SBC提供X3接口。

这里面还可细分为：

2.1，A-SBC直接接受监听指令后知道对哪个用户进行监听、

2.2，A-SBC不接受监听指令，而是在呼叫建立时，根据核心网的通知（一条SIP对话内消息）知道是否要监听本呼叫。

很有可能网络中存在多个监听中心，它们如果均要求监听同一个用户的呼叫，那么MSC在呼叫中会控制MGW复制多份媒体给不同的监听中心LEMF。也存在有的LEMF要求收发合并、而有的LEMF要求收发分离，使得流程更加复杂。但基本思路仍是上述流程的组合。

收发分离与收发合并

X3接口提供通信内容监听，输出方式分收发合并以及收发分离两种方式。

收发合并方式，是指在被监听网元(上图中的MSC\MGW)提供的监听X3接口中已完成了主叫和被叫方的语音混合工作。

收发分离方式，是X3接口分别占用两路或更多路通道输出主叫方和被叫方或其它方的语音信息。(会议中可能有多方通道)

收发分离方式有利于分析收发方的背景或识别数据通信。

不管是收发合并还是收发分离，主被叫媒体均通过MGW中转（类似Transcoding)，则MGW要提供TC资源。

收发合并方式时，MGW需要使用混音资源。

收发分离方式还分为A方式以及B方式。区别是：A方式针对会议等多方业务，则在某一路X3媒体流中会传送会议混音后的媒体流。B方式则要求每条X3媒体流中都只携带单方的语音及背景音。两种方式对于MGW的要求不同。

收发分离方式监听时，监听MRFP上各终结点的topology关系如下图所示。

收发合并方式(A方式）监听时，监听MRFP上各终结点的topology关系如下图所示。。

ETSI、3GPP有关术语

监听中心（LEA Domain）

ADMF（Administration Function）功能：用于设置、取消、查询监控对象。

IRI mediation功能：用于传递监控对象的IRI信息。

CC mediation功能：用于传递通讯内容。

IRI：通讯相关事件Intercept Related Information

DF2（IRI mediation function），DF3（CC mediation function）

IA Interception Area

LDI Location Dependent Interception

LEA Law Enforcement Agency

LEMF Law Enforcement Monitoring Facility

通过为知笔记发布

H.248-Transcoding与Interception相关推荐

【NGN学习笔记】4 软交换中的协议2—Megaco/H.248
作者:gnuhpc 出处:http://www.cnblogs.com/gnuhpc/ 1.概述: 软交换设备之间采用SIP(Session Initiation Protocol)协议或者BICC( ...
MGCP /H.248 鉴权认证
MGCP /H.248 鉴权认证 MGCP /H.248 鉴权认证鉴权概述和基本算法 MGCP/H.248鉴权概述 MGCP协议没有涉及安全认证的标准.对于网络应用终端客户或运营商来说都不安全的盗号 ...
关于H.248的树图规则
一.H248数图数图可以是一个字符串,我们不妨称之为数图字符串,它遵循了Unix系统命令中的规则表达式的语法规定,也可以是许多数图字符串的并集,之间用"|"分隔,我们不妨称之为数 ...
10036.简评多媒体协议H.323和SIP
http://www.cmvc.com.cn/printpage.asp?id=381 简评多媒体协议H.323和SIP www.aspsky.net 2004-3-30 动网先锋摘要:业界对 ...
MRFC-概念与功能
目录 MRFC概念 SDP介绍 PSTN.PLMN中的放音智能网放音流程 MRFC标准列表 H.248标准 3GPP标准 SIP RFC W3C 呼叫中心 ...
VOICE VOER IP(VoIP)理论（NP水平学的）
VOICE VOER IP:承载在IP数据包中的语音信息分组电话网络的优点: Mor efficient use of bandwidth and equipment Lower transmiss ...
OpenGL的几何变换4之内观察全景图
上一次写了OpenGL的几何变换3之内观察全景图上次采用的是图片分割化方式,这次采用数据分割化方式. 先说下思路,数据分割化方式呢,是只读取一张图片imgData,然后通过glTexCoord2f( ...
【NGN学习笔记】5 IMS技术
作者:gnuhpc 出处:http://www.cnblogs.com/gnuhpc/ 1.移动网络的发展--引子 20世纪80年代,商业性移动通信网络得到发展第一代移动通信系统:TACS.NMT等 ...
WebRTC实时音视频技术基础：基本架构和协议栈
概述本文主要介绍WebRTC的架构和协议栈. 最基本的三角形WebRTC架构为了便于理解,我们来看一个最基本的三角形WebRTC架构(见下图): 在这个架构中,移动电话用"浏览器M&qu ...

H.248-Transcoding与Interception

H.248-Transcoding与Interception相关推荐

最新文章

热门文章