专利名称：实现媒体流旁路的方法
技术领域：
本发明涉及一种多媒体通信技术，尤其是涉及一种基于网际协议的多媒体通信中实现媒体流旁路功能的方法。
背景技术：
软交换和分组交换技术由于具有广阔的应用前景和可以满足人们多样化、个性化的业务需求，已成为业界最关注的热点之一。
代理(PROXY)是以上述技术为核心的网络(尤以下一代网络(NGN)为代表)中的重要技术之一。一般的PROXY由信令代理及媒体代理组成，信令代理及媒体代理的工作原理如图1所示。
信令代理(SP，Signalling Proxy)PROXY对终端来说，可看作是软交换系统，即终端的注册和呼叫消息都会先发给PROXY，PROXY经过信令处理后再转发给核心软交换系统。另一方面，PROXY对核心软交换系统又可看作是终端，软交换系统首先将呼叫被叫的请求先发给PROXY，PROXY经过信令处理后再转发给真正的被叫用户终端。一般PROXY需要支持SIP、H.323、MGCP、H.248等协议中的一种或多种。由于PROXY参与了整个呼叫流程，因此PROXY可以获取相应的用户注册、呼叫等详细信息。
媒体代理(MP，Media Proxy)PROXY进行媒体流的代理。所有PROXY所代理的用户与外界互通的媒体流都经过PROXY进行处理和转发。当PROXY下的用户作为主叫用户终端时，所看到的被叫地址来自于PROXY；当PROXY下的用户作为被叫用户终端时，主叫用户终端看到的被叫地址为PROXY的地址。
图1描述了信令流及媒体流的代理过程示意图。终端的信令流通过代理最终到服务器进行处理，同时媒体流也通过代理进行中转。在图1所示环境中，信令报文数目一般较少，通常一个呼叫大约在10个信令报文左右，而媒体流一秒钟就会有30～50个报文。媒体流通过PROXY进行中转具有一些优点，比如PROXY可以为媒体流标注QoS等级标识或者提供合法侦听等功能。同时媒体流通过PROXY进行中转也存在一些的问题1)对PROXY设备性能要求较高由于每秒钟PROXY需要处理30-50个媒体流的报文，在用户数较多的情况下，PROXY就必须具备较高的性能才有能力进行媒体流的转发。
2)媒体流占用较大网络带宽资源媒体流都通过PROXY进行中转，对通信网网络带宽的占用较严重，尤其是在有视频应用的情况下，网络将不得不将更高的带宽资源用于媒体流的传输。
因此，目前的基于网际协议的多媒体通信中存在实现媒体流旁路的需求，也就是需要媒体流直接在终端之间进行传输，而不通过PROXY进行代理，如图2所示。
发明内容
本发明所要解决的技术问题是提供一种媒体流旁路的方法，这种方法使预置在同一用户组中的用户的媒体流直接在终端间实现互通，可以满足多媒体通信中对实现媒体流旁路的需求。
为解决上述问题，本发明提供了一种实现媒体流旁路的方法，其方法具体为从报文中获取主叫用户终端和被叫用户终端的位置信息；根据所获得的位置信息判断主叫用户终端和被叫用户终端是否属于同一预置的用户组，若主叫用户终端和被叫用户终端属于同一个用户组，则维持代理端用户的媒体流地址保持不变，否则将代理端用户的媒体流地址替换为代理的地址；最后继续进行呼叫处理。
本方法中所述的位置信息为用户身份标识信息或IP地址，并且在获取主叫用户终端和被叫用户终端的位置信息的过程中，首先应先取用户的身份标识作为用户的位置信息，当无法获取所述身份标识时，获取用户的IP地址作为用户的位置信息。当位置信息为用户的IP地址时，为了能够进一步再获取到用户的身份标识信息，可以对主叫用户终端和被叫用户终端是否属于同一个代理进行判断，如果是，则根据获取的用户IP地址反向查找主叫用户终端的呼叫信息，并从该呼叫信息中获取该主叫用户终端的身份标识信息。
在判断主叫用户终端和被叫用户终端是否属于同一预置的用户组的过程中，可以先选择代理端的用户，根据该用户的位置信息确定该用户所属的用户组，再判断另一用户是否属于该代理端用户所属的用户组。
为了实现本发明的方法，需要建立用户组表，该用户组表中应包括需要进行媒体流旁路的用户身份标识域，以及该用户身份标识域对应的IP地址域。该用户组表中分别定义用于实现媒体流旁路的用户组，并且所述的用户组由在IP层具有直接互通能力的用户组成。
相对于现有技术，本发明带来的有益效果是由于本发明提供的方法中，对于满足媒体流旁路条件的用户，不再改变其在信令报文中携带的媒体流地址信息，从而实现了同一用户组中的用户的媒体流在终端之间的直接互通，使得原来需要通过代理进行处理的属于同一用户组的媒体流可以不再经过IP网的传输和代理的处理，因而减少了媒体流对网络带宽资源的占用，减轻了网络的负荷，同时降低了对代理设备转发性能的依赖，使得代理的报文转发性能不再成为业务量提高时限制多媒体通信的主要因素之一。
图1是代理在下一代网络NGN中的组网结构示意图；
图2是下一代网络NGN中实现媒体流旁路的示意图；图3是一不能实现媒体流旁路的网络结构例图；图4是代理端用户作为主叫时实现媒体流旁路的流程图；图5是代理端用户作为被叫时实现媒体流旁路的流程图。
具体实施例方式
本发明提供了一种实现媒体流旁路的方法，这种方法适合在代理(PROXY)设备上实现，但是并不局限于专用的代理设备，也可以在具有PROXY功能的其他设备上实现此方法。
在VoIP系统中，终端之间通过信令协议协商媒体流的地址。在有PROXY参与的情况下，PROXY将终端的媒体流地址更改为PROXY的地址，因此实现媒体流旁路的关键之一是不修改终端在信令报文中携带的媒体流地址信息，直接将原始的媒体流地址信息传给通信对端。但不是所有的组网结构都能够实现媒体流的旁路，图3所示为无法实现媒体流旁路的一种情况，终端1与终端2分别在不同的网络地址转换(NAT)设备下，而且NAT不支持应用层网关(ALG，Application Layer Gateway)，如果直接将两个终端的地址告知对方，这两个终端将无法进行通话。除图3所示情况外，还存在其他无法实现媒体流旁路的情况，如用户终端不同属于一个防火墙等。因此，媒体流的旁路功能只能在确认终端间可以直接互通的时候才可以具体实现。
由于IP地址的分配比较复杂，IP地址存在着重叠等情况，因而PROXY设备无法仅根据IP地址判断终端之间是否可以直接互通，因此需要另外的信息参与判断。本发明采用用户身份标识(ID)信息与用户IP地址配合使用的方式判断是否可以进行媒体流旁路的具体实现。
媒体流旁路的实现因为代理所在的呼叫方不同可分为主叫流程中媒体流旁路的实现和被叫流程中媒体流旁路的实现。
首先，为了实现本发明所提供的实现媒体流旁路的方法，需要预先定义用户组，即将需要采用媒体流旁路并且可以进行媒体流旁路的用户的定义为一个媒体流旁路的用户组，且该用户组由在IP层具有直接互通能力的用户组成。影响用户具有直接互通能力的因素包括用户终端不同属于一个防火墙；用户终端分别属于不同的NAT，并且NAT又不支持应用层网关ALG等情况只有在同一用户组中进行了定义的不同用户才可以相互之间实现媒体流的旁路。
通常，用户组是根据用户的需求由运营商进行定义的，不同的用户的集合可以组成不同的媒体流旁路的用户组，不同局域网内部的用户可以分别组成不同的媒体流旁路的用户组。例如，公司A的所有用户组成媒体流旁路用户组A，公司B的所有用户组成媒体流旁路用户组B，公司A的用户间可以实现相互间的媒体流旁路，公司B的所有用户可以实现相互间媒体流的旁路，但由于公司A的用户与公司B的用户分属不同的用户组，因而公司A的用户与公司B的用户之间不能实现媒体流的旁路。
根据实现媒体流旁路的方法的需要，提供一种较佳的定义用户组的方式在PROXY系统中建立一个用户组表，在这个用户组表中每个单元应该包含以下的结构用户终端ID域，其定义了需要进行媒体流旁路的用户ID的范围；用户终端IP地址域，其定义IP地址范围。
例如用户ID组定义了某公司一个范围的电话号码(如****0001～****0999)，以及一个域名(如*@company.com)的用户属于一个用户组，则这些用户间的媒体流可以实现旁路，因而可以保证这些用户在网络中实现直接互通。
IP地址域则定义了对应于上述用户ID的IP地址的集合范围，也就是终端的IP地址范围，这个信息在代理端用户在被叫侧而且取不到主叫ID信息时使用，用于获取主叫用户终端的IP地址。
由上所述，用户组表的实现方式之一可以为
主叫流程是指，代理端的用户发起的呼叫。
背景技术：
中已经介绍所有PROXY所代理的用户与外界互通的媒体流都经过PROXY进行处理和转发；当PROXY下的用户作为主叫用户终端时，所看到的被叫地址来自于PROXY；当PROXY下的用户作为被叫用户终端时，主叫用户终端看到的被叫地址为PROXY的地址，如图1所示的网络结构。在主叫流程中实际发起呼叫的是代理下的用户，但也可以简单看作是代理发起的呼叫。
图4描述了在代理端用户作为主叫用户时实现媒体流旁路方法的一较佳实施例。步骤11为PROXY接收到主叫用户终端的呼叫请求；继续进行步骤12，取出呼叫请求中的被叫用户终端身份标识(ID)信息，同时取出主叫用户终端的ID信息。为了能够实现呼叫的建立，在发给代理的呼叫请求中都会携带被叫用户终端的ID信息，而主叫用户终端的ID信息可能在呼叫请求的报文中直接携带，也可能不携带，在不携带的情况下需要从PROXY记录的对应注册用户的信息中取出主叫用户终端ID信息。步骤13为根据获取的主叫用户终端的ID信息和被叫用户终端的ID信息，在系统中预先定义的用户组表中进行查询，以判断主叫用户终端和被叫用户终端是否属于同一个媒体流旁路的用户组。由于所获得的均是用户终端的ID信息，因而在具体判断是否属于同一个用户组时，可以先由任一端用户确定所属的用户组，若此时该端用户不属于任何一个用户组，则可说明主叫用户与被叫用户不属于同一用户组，否则继续判断另一端用户是否也在该用户组中。如果主叫用户和被叫用户属于系统定义的同一个媒体流旁路的用户组，则进行步骤14，主叫用户终端的媒体流地址不做变换，即不再用代理地址替换主叫用户终端的媒体流地址，并且继续进行呼叫处理16；如果主叫用户终端和被叫用户终端不属于同一个媒体流旁路的用户组，则进行步骤15，将主叫用户终端后续的媒体流地址替换为PROXY的地址，并且进行呼叫处理16。
在主叫流程中，也可以获得主叫用户终端的IP地址，此时可以应用上述判断方法对主叫用户与被叫用户是否属于同一用户组进行判断，也可以先由被叫用户终端的ID标识确定所属的用户组，再判断主叫用户终端是否也属于该用户组。即在利用主叫用户终端的IP地址时，同样可以实现对能否实现媒体流旁路的判断，由于此种判断方法增大了判断的运算量，因而并不推荐。在可以获得用户终端的ID信息时，应首先以用户终端的ID信息为依据进行呼叫流程的处理。
在实际的基于VoIP协议的呼叫流程中，上述的代理端用户作为主叫的流程中可能包括多个报文的交互，也就是判断出是否属于同一个媒体流旁路的用户组之后，并不一定立即进行地址的替换或保留，而是将此信息记录下来，在后续的实际媒体流地址信息交互报文中才会使用此信息，以决定进行地址的替换或是地址的保留。
被叫流程是指代理端的用户作为被叫时的呼叫。如背景技术中所述，当PROXY下的用户作为被叫用户终端时，主叫用户终端看到的被叫地址为PROXY的地址。因而在被叫流程中是代理下的用户作为被叫用户终端，但通常情况下可以简单看作是代理作为被叫。
图5描述了在代理端用户作为被叫时实现媒体流旁路方法时的一较佳实施例。步骤201为PROXY接收到呼入请求；继续进行步骤202，取出呼叫请求中的被叫用户终端身份标识(ID)信息；进一步要获取主叫用户终端ID信息。
被叫流程与主叫流程有所不同，因为作为被叫的代理不一定能获取到主叫用户终端的ID信息，如果服务器没有将主叫用户终端信息下发，则无法获取到主叫用户终端的ID信息，这种情况在被叫端未开通主叫显示业务时即会发生；而在主叫流程中，相应的主叫用户终端ID与被叫用户终端ID信息都可以获取到。此时，应该进行步骤203，判断是否能够获取主叫用户终端的ID信息。
若能够获取主叫用户终端的ID信息，则进行步骤204，判断主叫用户终端与被叫用户终端是否属于同一用户组，若属于同一个用户组则进行步骤209，保持被叫用户终端的媒体流地址不变，即不再用代理地址替换被叫用户终端的媒体流地址，并且进行步骤211继续呼叫处理，否则将被叫用户终端的媒体流地址替换为代理地址，并且进行步骤211继续呼叫处理。此种情况中，由于获得均是用户终端的ID信息，因而具体判断时可以由任一端用户确定所属的用户组，若此时该端用户不属于任何一个用户组，则可说明主叫用户与被叫用户不属于同一用户组，否则继续判断另一端用户是否也在该用户组中。
若判断不能够获得主叫用户终端的ID信息，则应该进行步骤205，从呼入请求中获取主叫用户终端的IP地址信息，获得主叫用户终端的IP地址信息后进行步骤206，根据被叫用户终端的ID信息在媒体流旁路的用户组表中进行查找，以确定被叫用户所属的用户组，若该被叫用户终端不属于任何用户组，则进行步骤210，将被叫用户终端的媒体流地址替换为代理的地址，并且进行步骤211，继续呼叫处理；如果被叫用户终端属于某一用户组，则进行步骤207，从用户组表中获取与该用户组对应的IP地址域信息，并且进行步骤208，判断已获取的主叫用户终端的IP地址是否属于所述获取的与被叫用户终端所在用户组对应的IP地址域，若主叫用户终端的IP地址在所述的IP地址域中，说明主叫用户终端与被叫用户终端属于同一用户组，则进行步骤209，保持被叫用户终端的媒体流地址不变，并且进行步骤211的呼叫处理，若主叫用户终端的IP地址不在被叫用户终端所在用户组对应的IP地址域中，说明主叫用户终端与被叫用户终端不属于同一个用户组，此时不能实现媒体流的旁路，则应该进行步骤210，将被叫用户终端的媒体流地址替换为代理的地址，并且进行步骤211的呼叫处理。
由于在被叫流程中可能无法获得主叫用户终端的ID信息而只能获得IP地址，此时，可以判断主叫用户与被叫用户是否属于同一个代理，当主叫用户终端与被叫用户终端属于同一个PROXY时，PROXY可以记录主叫用户终端的IP地址等信息，被叫用户终端可以根据主叫用户终端的IP地址等信息反向找到主叫用户终端的呼叫信息，从而获取主叫用户终端的ID信息。此时可以依据主叫用户的ID信息对主叫用户终端和被叫用户终端是否属于同一个用户组进行判断，而不必要再依据主叫用户终端的IP地址进行判断。
对于上述被叫流程的处理有相应的替代方法同样可达到相同的目的。例如，在只获取到被叫用户终端的ID信息和主叫用户终端的IP地址后，也可以先根据主叫用户终端的IP地址在媒体流旁路的用户组表中进行查找，若该IP地址不属于用户组表中的任一用户组对应的IP地址域，则将被叫用户终端的地址替换为代理的地址，并且进行呼叫处理；若该主叫用户终端的IP地址属于用户组表中的某一用户组对应的IP地址域，则获取该用户组对应的用户ID域，根据被叫用户终端的ID信息判断该被叫用户终端是否属于主叫用户终端所属的用户组，若被叫用户终端与主叫用户终端属于同一用户组，则保持被叫用户终端的地址不变，并且进行呼叫处理，若被叫用户终端与主叫用户终端不属于同一用户组，则将被叫用户终端的地址替换为代理的地址，并且进行呼叫处理。由于此方法在具体实施过程中会增加对主叫用户终端与被叫用户终端是否属于同一用户组进行判断的运算量，因而不作推荐。
在被叫流程中，可以获得被叫用户终端的IP地址，此时可以应用上述判断方法，依据被叫用户终端的IP地址对主叫用户与被叫用户是否属于同一用户组进行判断，也可以先由主叫用户终端的ID标识或IP地址确定所属的用户组，再判断被叫用户是否也属于该用户组。即在利用被叫用户的IP地址时，同样可以实现对能否实现媒体流旁路的判断，但并不推荐此种方法。在可以获得用户终端的ID信息时，应首先以用户终端的ID信息为依据进行呼叫流程的处理。
在实际的基于VoIP协议的呼叫流程中，上述的代理端用户作为主叫的流程中可能包括多个报文的交互，也就是判断出是否属于同一个媒体流旁路的用户组之后，并不一定立即进行地址的替换或保留，而是将此信息记录下来，在后续的实际媒体流地址信息交互报文中才会使用此信息，以决定进行地址的替换或是地址的保留。
在一个呼叫流程中，主叫用户与被叫用户之间可能存在多个代理，这种情况下，依据本发明所提供的方法同样可以实现媒体流的旁路。即在报文经过每个代理时，获取报文中用户终端的位置信息，而后根据所能获得的各用户终端的位置信息判断主叫用户与被叫用户是否属于同一个用户组，并且根据判断的结果决定是否将用户终端在信令报文中携带的媒体流地址信息进行替换，最后继续进行呼叫处理。
以上对本发明所提供的实现媒体流旁路的方法进行了详细介绍，本文中应用了具体个例对本发明的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本发明的方法及其核心思想；同时，对于本领域的一般技术人员，依据本发明的思想，在具体实施方式
及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本发明的限制。
权利要求
1.一种实现媒体流旁路的方法，其特征在于1)从报文中获取主叫用户终端和被叫用户终端的位置信息；2)根据所述的位置信息判断主叫用户终端和被叫用户终端是否属于同一预置的用户组，若主叫用户终端和被叫用户终端属于同一个用户组，则维持代理端用户终端的媒体流地址保持不变，否则将代理端用户终端的媒体流地址替换为代理的地址；3)进行呼叫处理。
2.如权利要求1所述的实现媒体流旁路的方法，其特征在于所述位置信息为用户身份标识信息或IP地址信息。
3.如权利要求1所述的实现媒体流旁路的方法，其特征在于，步骤1)所述获取主叫用户终端和被叫用户终端的位置信息的过程为首先获取用户的身份标识作为用户的位置信息，当无法获取所述身份标识时，获取用户的IP地址作为用户的位置信息。
4.如权利要求3所述的实现媒体流旁路的方法，其特征在于还包括当位置信息为用户的IP地址时，判断主叫用户终端和被叫用户终端是否属于同一个代理，如果是，则根据获取的用户IP地址反向查找主叫用户终端的呼叫信息，并从该呼叫信息中获取该主叫用户终端的身份标识信息。
5.如权利要求1或3所述的实现媒体流旁路的方法，其特征在于，步骤2)所述判断主叫用户终端和被叫用户终端是否属于同一预置的用户组的过程具体为21)选择一代理端的用户，根据该用户的位置信息确定该用户所属的用户组；22)判断另一用户是否属于该代理端用户所属的用户组。
6.如权利要求1或5所述的实现媒体流旁路的方法，其特征在于所述的用户组为需要实现媒体流旁路的用户的集合，且该集合由在IP层具有直接互通能力的用户组成。
7.如权利要求1所述的实现媒体流旁路的方法，其特征在于在步骤1)之前还包括生成用户组表的步骤，所述用户组表中包括需要进行媒体流旁路的用户身份标识域，以及该用户身份标识域所对应的IP地址域。
全文摘要
本发明涉及一种实现媒体流旁路的方法。该方法首先从报文中获取主叫用户终端和被叫用户终端的位置信息；根据所述的位置信息判断主叫用户终端和被叫用户终端是否属于同一预置的用户组，若主叫用户终端和被叫用户终端属于同一个用户组，则维持代理端用户的媒体流地址保持不变，否则将代理端用户的媒体流地址替换为代理的地址；最后继续呼叫处理。由于本方法中，对于满足媒体流旁路条件的用户，不再改变其在信令报文中携带的媒体流地址信息，使得用户的媒体流在终端之间直接互通，实现了媒体流的旁路，因而减少了媒体流对网络带宽资源的占用，降低了对代理设备转发性能的依赖。
文档编号H04L12/54GK1738267SQ20041005702
公开日2006年2月22日 申请日期2004年8月20日 优先权日2004年8月20日
发明者姚鑫, 袁莉 申请人:华为技术有限公司