CN102647487B - 一种节约ip地址的方法及接入代理设备 - Google Patents

Abstract

本发明提供一种节约IP地址的方法及接入代理设备，该方法应用于IP监控网络中为多个终端设备提供接入代理服务，终端设备配置与接入代理设备相同IP地址且被配置为不发送免费ARP报文且不响应ARP请求报文，该方法包括：解析上行监控信令或数据报文，报文源MAC地址与终端设备标识（或端口号）的对应关系保存到代理列表并将报文的源MAC地址修改为自身的MAC地址后从上行口发送出去；解析从上行口收到的下行监控据报文，并根据信令报文中携带的设备标识或根据数据报文的目的端口号从代理列表中获取对应的MAC地址，并将该信令报文或数据报文的目的MAC地址修改为前述获取到的MAC地址后发送出去。本发明实现了多个终端设备共用一个IP地址，有效地节约了IP地址。

Description

一种节约IP地址的方法及接入代理设备

技术领域

本发明涉及网络技术，尤其涉及一种节约IP地址的方法接入代理设备。

背景技术

IP网络的发展使得视频监控能够在更广阔的范围内被用户使用，在公安部门部署的平安工程等大型监控网络中IP监控方案被大规模的采用。IP网络天然的优势不需赘言，在很多IP监控系统都需要将多媒体数据（主要是视频以及音频数据）承载在现有的IP公网。但是由于IPv4地址稀缺，很多用户拥有的IPv4地址有限，或者即便拥有较多的IPv4但在前期进行整网地址规划时，冗余的IPv4地址有限。在这种情况下，如果客户需要在现有网络中增加大量的监控设备（比如编码终端，EC）时，会存在IPv4地址不足的现象。如何在现网IPv4不足的情况下，继续满足用户增加大量的监控设备的迫切需求，是各个IP视频监控方案提供厂商都在积极解决的重要技术问题。

目前业界主流的解决IPv4短缺的问题有两种：一种是使用NAT（网络地址转换）技术，另一种是使用IPv6地址。

NAT技术能够在一定程度上缓解IPv4地址短缺的问题，并且具有良好的安全性。然而NAT技术的使用也会引发很多业务互动的问题，尤其从NAT外部访问NAT内部的需求，这对各种网络应用的开发带来很大的难度。目前各个主流厂商都提出过很多“穿越”NAT的技术方案。

IPv4地址短缺是早期在IP协议设计上的考虑缺乏前瞻性造成的，IPv6协议正是在这种背景下诞生的。由于采用了128位的地址长度，IPv6协议中地址缺乏问题将不复存在。目前国家以及行业主管部门都在积极推进IPv6的商用，已经取得了良好的进展，目前网络中大量的交换机以及路由器均同时支持IPv4以及IPv6协议。然而IPv6协议发展的瓶颈在于包括普通计算机在内的各种终端设备，尤其是各种终端设备难以短时间内全部切换到IPv6上来，因此IPv6的好处难以立刻发挥出来。IPv4与IPv6将在较长的时间内共存与网络中。

由于IPv4与IPv6共存，尤其是当网络中需要通信的终端设备既有IPv4终端也有IPv6终端的时候，IPv4与IPv6互通就成了一个技术难题。比如我们在家里使用IPv4地址的计算机访问使用IPv6地址的Web服务器时就需要网络服务提供者在网络设备上为我们访问服务器做协议转换以及映射等操作，甚至需要使用隧道技术。然而网络设备做转换或者映射的时候一样需要使用到IPv4的地址，因此从网络设备角度来解决IPv4地址短缺问题效果并不明显，而且改造网络设备的成本不菲。

目前主流的两种解决IPv4地址短缺的技术目前也有应用到IP监控系统中，然而由于这两种技术自身存在的问题，其效果仍然难以满足用户对成本以及便利性的要求。

发明内容

有鉴于此，本发明提供一种接入代理设备，应用于IP监控网络中为该网络中多个终端设备提供接入代理服务，所述每一终端设备配置的IP地址与所述接入代理设备的IP地址相同，每一终端设备以及接入代理设备的MAC地址均不相同，且终端设备与接入代理设备位于同一个二层网络中，所述终端设备被配置为不响应ARP请求报文及禁止发送免费ARP报文，该接入代理设备包括连接至网络的上行口、多个连接到终端设备的下行口、上行代理单元以及下行代理单元，其中：

上行代理单元，用于解析从下行口收到的来自终端设备的上行监控信令报文，获取该信令报文的源MAC地址，从该信令报文中获取终端设备标识，并将该MAC地址与终端设备标识的对应关系保存到代理列表中；该上行代理单元进一步用于将信令报文的源MAC地址修改为自身的MAC地址后从上行口发送出去；

下行代理单元，用于解析从上行口接收到的下行监控信令报文，并根据信令报文中携带的设备标识从代理列表中获取对应的MAC地址，并将该信令报文的目的MAC地址修改为前述获取到的MAC地址后发送出去。

本发明还提供一种节约IP地址的方法，该方法应用于接入代理设备上，为IP监控网络中的多个终端设备提供接入代理服务，所述每一终端设备配置的IP地址与所述接入代理设备的IP地址相同，每一终端设备以及接入代理设备的MAC地址均不相同，且终端设备与接入代理设备位于同一个二层网络中，所述终端设备被配置为不响应ARP请求报文及禁止发送免费ARP报文，该方法包括：

A、解析从下行口收到的来自终端设备的上行监控信令报文，获取该信令报文的源MAC地址，从信令报文中获取终端设备标识，并将该MAC地址与终端设备标识的对应关系保存到代理列表中；

B、将信令报文的源MAC地址修改为自身的MAC地址后从上行口发送出去；

C、解析从上行口接收到的下行监控信令报文，并根据信令报文中携带的设备标识从代理列表中获取对应的MAC地址;

D、将该信令报文的目的MAC地址修改为前述获取到的MAC地址后发送出去。

本发明充分利用了监控网络中监控终端设备在信令以及数据上的业务特点提出MAC地址修改来达到多个终端设备共用一个IP地址的技术，本发明并没有向传统NAT技术那样通过公网IP地址与私网IP地址转换来节约IP地址，所以本发明技术对用户以及运营商的IP网络无任何影响，不需要在交换机以及路由器等IP网络设备上做任何改变。同时由于修改MAC地址仅仅限于被服务终端设备，而根据监控网络的业务特点，由于被代理的终端设备（比如EC）之间通常并没有通信需求，使用相同的IP地址也不会引发业务混乱的问题。

附图说明

图1是一种典型的IP监控网络组网图;

图2是本发明一种实施方式中接入代理设备的硬件架构图；

图3是本发明一种实施方式中接入代理设备的逻辑结构；

图4是本发明一种实施方式中上行监控报文处理流程图；

图5是本发明一种实施方式中信令报文结构示例图；

图6是本发明一种实施方式中数据报文结构示例图；

图7是本发明一种实施方式中上行监控报文处理流程图。

具体实施方式

请参考图1，一个典型的IP监控网络包括：解码终端设备、编码终端设备（比如EC或IPC等）、视频管理服务器VM、媒体交换服务器MS、数据管理服务器DM以及交换机和路由器等网络设备，其中视频解码设备可以包括DC解码终端或者安装有通用解码软件（又称通用播放器，XPlayer）的XP终端。除了网络设备外，其他设备均是监控业务的实际参与者，即监控业务节点。当然监控网络中还包括未图示的摄像头以及语音采集器等多媒体采集终端（主要用来采集图像与语音形成模拟多媒体流），编码终端设备会将采集到的模拟多媒体流编码为数字多媒体流发送到网络中去。监控业务通常包括信令业务以及数据业务两部分，信令业务通常是监控业务节点之间通过收发信令报文传递指令与请求等，而数据业务则是在信令的指引下通过收发数据报文来实现多媒体流的网络传输或网络存储。

以下以编码终端设备为例，本发明从MAC层着手结合监控业务自身的客观规律来解决IP层地址短缺的问题。请参考图1，该IP监控网络中包括多个终端设备以及为所述多个终端设备提供网络接入服务的接入代理设备。下面结合附图，以计算机程序实现为基础来介绍本发明接入代理设备的实现以及处理流程。本发明并不排除硬件或者软硬结合的实现方式。图2展示出了一个接入代理设备的基本硬件架构，其中业务硬件可能包括编码芯片和或转发芯片，当然业务硬件可能是不存在的，比如说接入代理设备本身仅仅提供接入代理服务，并不参与监控业务时则不需要编码芯片，再比如说如果使用软件实现报文转发时，转发芯片则不是必须的。

请参考图3，本发明一种实施方式中，接入代理设备包括连接至监控网络的上行口（未图示）、多个连接到终端设备的下行口（未图示）、上行代理单元、下行代理单元以及转发单元。其中转发单元可能是转发芯片这样的业务硬件，而上行口以及下行口可以是主流的以太网口，然而本发明并不关注如何实现对报文的转发，这是现有技术中已经有广泛教导的技术。请参考图4，以下描述本发明接入代理设备如何完成网络接入代理服务从而实现节约IP地址这个目标的。

步骤101，配置或者选举出接入代理设备，并对各个终端设备进行ARP配置；

在本发明中，每个终端设备与接入代理设备位于同一个二层网络中。事实上每个终端设备都可以被改造为一个接入代理设备（即接入代理设备内部在逻辑上也有一个终端设备），此时它可以与其他终端设备一起按照预定的选举规则进行选举出一个终端设备来充当接入代理设备。当然接入代理设备这一角色也可以通过手工配置来指定。被接入代理设备接入的终端设备配置有与接入代理设备相同的IP地址，但每个终端设备都配置有唯一的MAC地址。由于被接入的终端设备通常会有多个，为了避免发生IP地址冲突的问题，终端设备都被配置为不响应ARP请求报文以及禁止发送免费ARP报文，可以避免网络中各个终端或者设备感知到IP地址冲突。

步骤102，上行代理单元从下行端口接收来自各个终端设备的监控信令报文或数据报文并解析，然后确定当前报文是信令报文还是数据报文，如果是信令报文则转103处理，如果是数据报文转步骤105处理；

从下行端口（比如以太网口）上来的报文可以全部上送到上行代理单元处理，如果底层是借用以太网交换机的实现，可以下发ACL或者其他方式将报文上送到上行代理单元。上行代理单元需要根据配置好的解析规则（可参考现有技术实现）将报文进行解析，主要是确定报文是基于UDP的SIP协议信令报文还是基于UDP的SIP协议的数据报文以及基于TCP的iSCSI数据报文。通常信令报文可能携带有实况多媒体流点播信令、存储信令等，而数据报文通常是承载着终端设备向网络中发送的实况多媒体流或存储多媒体流。

步骤103，当所述报文为信令报文时，上行代理单元判断代理列表中是否已经存在该报文携带的终端设备标识，如果是则转步骤109，如果否则转步骤104；

步骤104，上行代理单元进一步将报文的源MAC地址与报文携带的终端设备标识的对应关系添加到代理列表中；

在本发明中，通过研究监控业务的特点发现各个终端设备可能会使用相同的源端口向外发送信令报文，因此反向的信令报文（比如VM服务器发送给各个终端设备的下行监控信令报文）会相应使用相同的目的端口（与终端设备源端口对应），此时下行代理单元无法做有效区分，因此对于信令报文本发明使用报文中的设备标识来做区分。如果终端设备是首次发送信令报文，则需要将其设备标识与报文的源MAC（也就是终端设备的MAC地址）记录到代理列表中。请参考图5标记出的MAC地址以及设备标识，报文中如果有其他的字段也有设备标识，同样可以使用，而代理列表中MAC地址与设备标识的对应关系可以参考表1所示。如果一个终端设备之前已经发送过信令报文了，那么通过检查代理列表就会发现有相同的设备标识，下行代理单元已经有处理反向报文的依据了，此时可以跳转到步骤109进行处理。

MAC地址	设备标识
		00:1B:21:88:94:69	EC1001-HF-112_1
00:1B:21:88:94:70	EC1001-HF-112_2
		......	......

表1

步骤105，当所述报文为数据报文时，上行代理单元判断代理列表中是否已经存在该报文的源MAC地址与报文的源端口号的对应关系，如果是则转步骤109，如果否则转步骤106；

步骤106，上行代理单元进一步判断所述源端口号是否已经存在于所述代理列表中，如果是转步骤107，否则转步骤108

步骤107，上行代理单元丢弃终端设备的报文或者进一步向发送报文的终端设备发送目的端口不可达报文；

步骤108，上行代理单元将报文的源MAC地址与报文携带的源端口号的对应关系添加到代理列表中；转步骤109；

各个终端设备通常会使用不同的源端口向外发送数据报文，因此反向的数据报文（比如监控中心网络设备与终端设备进行语音对讲过程中发送给终端设备的下行监控数据报文）会相应使用相同的目的端口（与终端设备采用的源端口对应），此时下行代理单元可以根据端口号进行区分。如果终端设备发送的数据报文是UDP或TCP会话的首报文，则需要将其源端口号与报文的源MAC地址记录到代理列表中，监控业务可能会使用到UDP传输，也可能会使用到TCP传输。在实际应用中，比较流行的做法是实况视频流是通过UDP承载，而存储视频流是通过TCP承载。请参考图6标记出的MAC地址以及端口号，而代理列表中MAC地址与端口号的对应关系可以参考表2所示。如果一个是UDP或者TCP会话的后续数据报文，那么通过检查代理列表就会发现MAC地址与端口号的对应关系已经记录在代理列表中，即下行代理单元已经有处理反向报文的依据了，此时可以跳转到步骤109进行处理。

MAC地址	设备标识	TCP端口号	UDP端口号
				00:1B:21:88:94:69	EC1001-HF-112_1	3231	46094
00:1B:21:88:94:70	EC1001-HF-112_2	3232	46095
				......	......	......	......

表2

进一步来说，端口号在本发明中用来对应不同的MAC地址，有可能出现不同的MAC地址（也就是不同的终端设备）使用相同端口号的情形，如果不加以处理可能会导致下行代理单元处理出错。为保证代理列表中一个端口号唯一对应到终端设备，本发明可以在保存对应关系之前进一步判断端口号是否已经被使用了，如果是则丢弃该报文或者向该终端设备发送目的端口不可达报文，终端设备的报文被丢弃后，终端设备在等待一段时间之后会尝试使用其他端口号作为源端口号，同样如果终端设备收到目的端口不可达报文后，也会尝试使用不同的源端口号再次发送报文，这两种方式都可以促使终端设备使用新的端口号作为其发送报文的源端口。然而，步骤107这一处理并不是必须的，因为有些厂商的设备以及解决方案能很好地规划每个终端设备在每个会话中使用的UDP或TCP端口号以确保不重复，此时就不需要进行这个步骤的判断了。需要补充说明的是，步骤105以及步骤106执行顺序也可以颠倒过来，可以先判断代理列表中是否已经保存了源端口号，如果没有就可以将MAC地址与端口号的对应关系保存到代理列表中（表明这是一个终端设备新建会话的首报文），如果有，则进一步判断代理列表是否已经保存了该端口号与该数据报文源MAC地址的对应关系，如果有，则说明该数据报文是该终端已建立会话的后续数据报文，即该终端设备之前已经通过发送首报文占用了这个端口号；如果没有，说明查询到的端口号已经被其他终端设备占用了，因此需要丢弃当前数据报文或者向终端设备发送端口不可达报文。综合来说，步骤106主要是要根据代理列表来判断该数据报文的源端口号是否已经被其他终端设备占用了，如果已经被占用则应该丢弃当前数据报文或者向终端设备发送端口不可达报文。

步骤109，上行代理单元将信令报文或数据报文的源MAC地址修改为自身的MAC地址后从上行口发送出去。

在本发明中，各个终端设备都不发送免费ARP报文，也不会响应ARP请求，因此对于网关来说并不会知道各个终端设备的MAC地址，因此无法直接与外界进行双向IP通信。因此接入代理设备会将终端设备发送过来的报文的源MAC都修改为自身的MAC地址然后发送出去，以代表各个终端设备与外部进行IP通信。步骤102-109描述了终端设备向网络中发送信令报文或者数据报文时上行代理单元的处理过程。从网关以及外部网络上来看会理解为所有报文都是来自接入代理设备的，即接入代理设备会被理解为与之通信的节点。请进一步参考图3以及图7，以下介绍从网络中发送过来的反向报文，也就是通过上行口接收到的报文到底应该归属哪个终端设备，即找出真正需要参与通信的节点。

步骤201，下行代理单元解析从上行口接收到的下行监控信令报文或数据报文；确定当前报文是信令报文还是数据报文，如果是信令报文则转202处理，如果是数据报文转步骤203处理。

步骤202，根据信令报文中携带的设备标识从代理列表中获取对应的MAC地址，转步骤204。

步骤203，根据数据报文的目的端口号从代理列表中获取对应的MAC地址，转步骤204。

步骤204，将该信令报文或数据报文的目的MAC地址修改为前述获取到的MAC地址后发送出去。

如前所述，所有的报文最终都是“以接入代理设备的名义”发送出去的，即报文的目的MAC地址与目的IP地址均是接入代理设备的。由于接入代理设备正常使能ARP功能，因此来自VM服务器以及其他节点的反向报文自然也会被网关设备发送到接入代理设备。反向报文到达时，解析报文之后，对于下行的信令报文可以通过表2中的设备标识找到对应的MAC地址（找到真正参与通信的终端设备），对于数据报文，如果是TCP承载的则根据TCP端口号找到对应，如果UDP承载，处理相同。找到对应MAC地址后把报文的目的MAC地址修改为终端设备的MAC地址后通过转发单元发送出去。这里的转发单元可能是二层转发芯片也可能是软件实现的二层转发单元，其主要依靠MAC地址学习建立MAC地址转发表来指导二层报文转发，二层转发属于常见的技术，不再赘述。终端设备收到被修改过的报文后，目的MAC地址是自身的MAC地址，如前所述，由于终端的IP地址被配置为与代理设备的IP地址相同，因此报文的目的IP地址也是终端设备自身的IP地址，因此终端设备可以在二层与三层正确处理收到的信令或数据报文。

需要补充说明的是，以上描述了对信令报文以及数据报文的处理，事实上对于终端设备而言，可能仅仅需要进行双向的信令报文交互，而数据报文可能仅仅是单向的，比如一个没有语音对讲需求的编码终端设备来说，其没有接收数据报文的需求，只有发送数据报文的需求；因此本发明中保存MA地址与端口号的对应关系并不是必须的步骤。此时由于不会存在反向的数据报文，终端仅需要从上行口发送数据报文即可。此外，就数据报文而言，有的终端设备并不需要进行视频流存储，那么TCP端口号并不是必须的，相反有的终端可能不需要发送实况，比如仅仅进行存储，那么UDP端口号也不是必须的。

进一步来说，从产品形态设计上，接入代理设备可以是根据本发明全新设计的专门用于接入代理服务的产品，也可以是在一个终端设备上根据本发明实施方式借助终端设备既有的软硬件资源改造而成。对于从终端设备改造而成的接入代理设备也可以称为主终端设备。请参考图3，此时业务处理单元在逻辑对于接入代理来说上就是一个集成在内部终端设备，与其他通过下行口连接的终端设备一样，只不过这个集成终端设备其下行口在接入代理设备内部。以上两种产品形态的实现方式能够应对不同的应用场景，如果接入代理设备需要服务的终端设备较多，比如多达几十台时，设计专职的接入代理设备，这样其接入服务的质量较高。如果接入代理设备需要服务的终端设备较少，则可以在现有的终端设备上进行改造形成兼职的接入代理设备，此时接入代理设备既可以服务其他终端设备，自身还可以作为终端设备参与到监控业务中来，这样可以有效地利用既有终端设备产品的软硬件资源。

本发明充分利用了监控网络中监控终端设备的在信令以及数据上的业务特点提出MAC地址修改来达到多个终端设备共用一个IP地址的技术，本发明并没有向传统NAT技术那样通过公网IP地址与私网IP地址转换来节约IP地址，这对IP网络无任何影响，不需要在交换机以及路由器等IP网络设备上做任何改变。同时由于修改MAC地址仅仅限于被服务终端设备，而根据监控网络的业务特点，由于被代理的终端设备（比如EC）之间通常并没有通信需求，使用相同的IP地址并不会引发业务混乱的问题。

以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本发明保护的范围之内。

Claims (10)

1.一种接入代理设备，应用于IP监控网络中为该网络中多个终端设备提供接入代理服务，所述每一终端设备配置的IP地址与所述接入代理设备的IP地址相同，每一终端设备以及接入代理设备的MAC地址均不相同，且终端设备与接入代理设备位于同一个二层网络中，所述终端设备被配置为不响应ARP请求报文及禁止发送免费ARP报文，该接入代理设备包括连接至网络的上行口、多个连接到终端设备的下行口、上行代理单元以及下行代理单元，其特征在于：

上行代理单元，用于解析从下行口收到的来自终端设备的上行监控信令报文，获取该信令报文的源MAC地址，从该信令报文中获取终端设备标识，并将该MAC地址与终端设备标识的对应关系保存到代理列表中；该上行代理单元进一步用于将信令报文的源MAC地址修改为自身的MAC地址后从上行口发送出去；

下行代理单元，用于解析从上行口接收到的下行监控信令报文，并根据信令报文中携带的设备标识从代理列表中获取对应的MAC地址，并将该信令报文的目的MAC地址修改为前述获取到的MAC地址后发送出去；

所述上行代理单元进一步用于解析从下行口收到的来自终端设备的上行监控数据报文，获取该数据报文的源MAC地址，从该数据报文中获取报文源端口号，并将该MAC地址与所述端口号的对应关系保存到代理列表中；该上行代理单元进一步用于将数据报文的源MAC地址修改为自身的MAC地址后从上行口发送出去；

所述下行代理单元进一步用于，解析从上行口接收到的下行监控数据报文，并根据数据报文中携带的目的端口号从代理列表中获取对应的MAC地址，并将该数据报文的目的MAC地址修改为前述获取到的MAC地址后发送出去。

2.如权利要求1所述的设备，其特征在于，所述上行代理单元进一步用于在从下行口收到监控数据报文时先检查该报文的源MAC地址与源端口的对应关系是否已经存在于所述代理列表中，如果是则将报文的源MAC地址修改为自身的MAC地址后从上行口发送出去，否则将该MAC地址与源端口号的对应关系保存到代理列表中；或者在从下行口收到监控信令报文时先检查该报文的源MAC地址与设备标识的对应关系是否已经存在于所述代理列表中，如果是则将报文的源MAC地址修改为自身的MAC地址后从上行口发送出去，否则将该MAC地址与设备标识的对应关系保存到代理列表中。

3.如权利要求1所述的设备，其特征在于，所述上行代理单元进一步判断从下行口接收到的报文是数据报文还是信令报文，如果是数据报文则在将所述MAC地址与源端口号的对应关系保存到代理列表之前，根据代理列表判断该数据报文的源端口号是否已经被其他终端设备占用了，如果是则不保存并丢弃终端设备的报文或者发送目的端口不可达报文，否则继续。

4.如权利要求1所述的设备，其特征在于，所述终端设备为编码终端设备，所述接入代理设备还包括集成于该设备内的编码终端设备，所述编码终端设备用于将来自多媒体采集终端的模拟多媒体流编码为数字多媒体流。

5.如权利要求1所述的设备，其特征在于，所述信令报文为SIP报文，所述源端口号包括UDP端口号和/或TCP端口号。

6.一种节约IP地址的方法，该方法应用于接入代理设备上，为IP监控网络中的多个终端设备提供接入代理服务，所述每一终端设备配置的IP地址与所述接入代理设备的IP地址相同，每一终端设备以及接入代理设备的MAC地址均不相同，且终端设备与接入代理设备位于同一个二层网络中，所述终端设备被配置为不响应ARP请求报文及禁止发送免费ARP报文，该方法包括：

A、解析从下行口收到的来自终端设备的上行监控信令报文，获取该信令报文的源MAC地址，从信令报文中获取终端设备标识，并将该MAC地址与终端设备标识的对应关系保存到代理列表中；

B、将信令报文的源MAC地址修改为自身的MAC地址后从上行口发送出去；

C、解析从上行口接收到的下行监控信令报文，并根据信令报文中携带的设备标识从代理列表中获取对应的MAC地址；

D、将该信令报文的目的MAC地址修改为前述获取到的MAC地址后发送出去；

所述步骤A进一步包括：解析从下行口收到的来自终端设备的上行监控数据报文，获取该数据报文的源MAC地址，从该数据报文中获取报文源端口号，并将该MAC地址与所述端口号的对应关系保存到代理列表中；

所述步骤B进一步包括：将数据报文的源MAC地址修改为自身的MAC地址后从上行口发送出去；

所述步骤C进一步包括，解析从上行口接收到的下行监控数据报文，并根据数据报文中携带的目的端口号从代理列表中获取对应的MAC地址，

所述步骤D进一步包括，将该数据报文的目的MAC地址修改为前述获取到的MAC地址后发送出去。

7.如权利要求6所述的方法，其特征在于，所述步骤A进一步包括在从下行口收到监控数据报文时先检查该报文的源MAC地址与源端口的对应关系是否已经存在于所述代理列表中，如果是则将报文的源MAC地址修改为自身的MAC地址后从上行口发送出去，否则将该MAC地址与源端口号的对应关系保存到代理列表中；或者在从下行口收到监控信令报文时先检查该报文的源MAC地址与设备标识的对应关系是否已经存在于所述代理列表中，如果是则将报文的源MAC地址修改为自身的MAC地址后从上行口发送出去，否则将该MAC地址与设备标识的对应关系保存到代理列表中。

8.如权利要求6所述的方法，其特征在于，所述步骤A进一步包括：判断从下行口接收到的报文是数据报文还是信令报文，如果是数据报文则在将所述MAC地址与源端口号的对应关系保存到代理列表之前，根据代理列表判断该数据报文的源端口号是否已经被其他终端设备占用了，如果是则不保存并丢弃终端设备的报文或者发送目的端口不可达报文，否则继续。

9.如权利要求6所述的方法，其特征在于，所述终端设备为编码终端设备，所述接入代理设备还包括集成于该设备内的编码终端设备，所述编码终端设备用于将来自多媒体采集终端的模拟多媒体流编码为数字多媒体流。

10.如权利要求6所述的方法，其特征在于，所述信令报文为SIP报文，所述源端口号包括UDP端口号和/或TCP端口号。