专利名称：媒体网关命令串行方法
技术领域：
本发明涉及通信领域，特别涉及下一代网络中的媒体网关。
背景技术：
电信技术的发展，必将导致下一代网络(Next Generation Network，简称″NGN″)的大规模应用。而基于保护原有电信网络投资的出发点，NGN必须支持对现有的电信业务网的平滑过渡，故NGN在相当长的时间内必须保持对原有电信网络的兼容，那么不同的网络之间必须要有能够提供不同业务、不同接口、不同功能转换的网关设备，而且，随着技术发展，问题认识的不断深入，又提出了网关功能分离的思想，即将网关功能分解为高层呼叫控制和底层资源管理/媒体处理两部分。熟悉本领域的技术人员应该知道，按上述思想分解后的主要部件是媒体网关控制器(Media Gateway Controller，简称″MGC″)和媒体网关(Media Gateway，简称″MG″)，它们是NGN中的两个关键构件。MGC负责呼叫控制功能，它掌握着各资源的可用性。MG负责业务承载功能，即媒体网关中媒体流的交换和处理需要的硬件操作。两个部件各司其职又互相配合，藉此实现呼叫控制平面和业务承载平面的分离，从而充分共享网络资源，简化设备升级和业务扩展，大大降低开发和维护成本，不会出现功能过于集中成为网络的瓶颈，MGC和MG间也由原来的内部协议变成外部开放的协议，方便了不同厂商的产品之间的互通。如图1所示在图1中，协议网络1是所有协议传送的网络，媒体网关控制器10和媒体网关11通过媒体网关控制协议110发生联系，媒体网关控制器10和媒体网关12通过媒体网关控制协议120发生联系，媒体网关控制协议110和媒体网关控制协议120可以是不同的协议。媒体网关控制协议是MG和MGC之间通信的主要协议，目前应用较为广泛的有媒体网关控制协议H.248(MediaGateway Control/H.248，简称″H.248/MeGaCo″)和媒体网关控制协议MGCP(Media Gateway Control Protoco，简称″MGCP″)两种协议。其中，MGCP协议由因特网工程任务组(Internet Engineering Task Force，简称″IETF″)于1999年10月制订并于2003年1月修订，H.248/MeGaCo协议由IETF和国际电信联盟(International Telecommunication Union，简称″ITU″)于2000年11月共同制订并于2003年6月修订。
图1中，媒体网关11、媒体网关12在媒体网关控制器10控制下通过实时传输协议140连接。网际互联协议130承载媒体网关控制协议110、媒体网关控制协议120以及实时传输协议140在协议网络1中传送。
图1中，用户终端13通过媒体网关11接入协议网络1，用户终端14通过媒体网关12接入协议网络1。用户终端13与用户终端14间的交互将通过协议网络1中的各种设备和设备间的协议来实现。
图1中，媒体网关11、媒体网关12上的各种资源被抽象表示为H.248协议中的终端(Termination)或者MGCP协议中的端点(Endpoint)。终端又分为物理终端和临时终端，前者代表一些具有半永久存在性的物理实体，例如时分复用(Time Division Multiplex，简称″TDM″)通道等，后者代表一些临时申请用后释放的公共资源，例如实时传输协议(Real-time TransportProtocol，简称″RTP″)流等。
终端或端点之间的组合被抽象表示为H.248协议中的上下文(Context)或者MGCP协议中的连接(Connection)。上下文可以包含多个终端，因而以拓扑(Topology)来描述终端间的相互关系。连接只包含两个端点，因而直接就反映了其相互关系。
基于这两种协议的抽象模型，呼叫的接续实际上就是对终端和上下文或者端点和连接的操作。
媒体网关控制器10与媒体网关11、媒体网关12之间通过协议命令(Command)进行交互，命令所携带的参数被划分为信号(Signal)、事件(Event)等类别，其中信号被媒体网关控制器10用来指示媒体网关11或者媒体网关12进行资源的操作，例如向用户放拨号音、回铃音、忙音等，事件被媒体网关控制器10用来指示媒体网关11或者媒体网关12进行状态的监测，例如监测用户摘机、挂机、拨号、拍叉等。
命令代表着呼叫接续和资源操作的各种控制细节，因此命令的执行需要严格的保证顺序。但是IP承载网络的不可靠导致命令即使在发送时是顺序的，在接收时还是有可能乱序甚至丢失，因此必须采取一定的机制来保证命令有序的被传输和执行。
H.248协议规定命令可以组合成事务(Transaction)来传送和执行，命令的相关性以事务为限定范围，也即同一事务内的命令按其先后顺序执行，而不同事务内的命令可以并行执行。与H.248协议单事务多命令的形式不同，MGCP协议是单事务单命令的形式，因此也就自然地符合该要求。
对于不同事务内命令的执行顺序有以下几点规则●对于H.248协议，针对不同终端的命令可以并行发送。对于MGCP协议，针对不同端点或者同一端点上不同连接的命令也可以并行发送。
●对于H.248协议，MGC和MG之间有8条基本命令，分别是(1)添加(Add)(2)修改(Modify)(3)删减(Subtract)(4)移动(Move)(5)审计值(AuditValue)(6)审计能力(AuditCapabilities)
(7)通报(Notify)(8)业务改变(ServiceChange)一个终端上应该最多只有一个未完成的添加(Add)、修改(Modify)或移动(Move)命令，除非这些命令在同一事务中，但删减(Subtract)命令可在任何时候发送。
对于MGCP协议，MGC和MG之间有9条基本命令，分别是(1)请求通报(RQNT)；(2)通报(NTFY)；(3)创建连接(CRCX)；(4)修改连接(MDCX)；(5)删除连接(DLCX)；(6)审计端点(AUEP)；(7)审计连接(AUCX)；(8)重启进行(RSIP)；(9)端点配置(EPCF)。
一个端点上应该最多只有一个未完成的请求通报(RQNT)或端点配置(EPCF)命令，一个连接上也应该最多只有一个未完成的创建连接(CRCX)或修改连接(MDCX)命令，但删除连接(DLCX)命令可在任何时候发送。
●对于不保证消息顺序传递的传输(例如UDP)，一个终端上应该最多只有一个未完成的H.248协议的Notify命令，一个端点上也应该最多只有一个未完成的MGCP协议的NTFY命令。需要说明的是，这两个命令在H.248和MGCP中功能类似。
●H.248协议的AuditValue和AuditCapabilities命令，MGCP协议的AUEP和AUCX命令，不受任何顺序限制。
●H.248协议的ServiceChange，MGCP协议的RSIP命令，总是MG在重启过程中发送的首个命令，其它任何命令或回应必须在此命令之后被发送。
基于上述规则，命令的接收方是以事务作为独立执行单位的，同一事务内若存在多个命令则按其先后顺序执行，而不同事务内的命令则既可以按接收顺序串行执行，也可以忽略顺序并行执行。因此命令之间若存在相关性，则命令的发送方必须有效保障其在接收方的执行顺序。
对于媒体网关控制器10而言，需要保障一个终端上最多只有一个未完成的H.248协议的Add、Modify或Move命令，或者一个端点上只有一个未完成的MGCP协议的RQNT或EPCF命令，一个连接上只有一个未完成的MGCP协议的CRCX或MDCX命令。对于可以控制呼叫进程的MGC而言，只要在前一命令被响应后再发送后一命令即可。
对于媒体网关11和媒体网关12而言，需要保障一个终端或端点上最多只有一个未完成的H.248协议的Notify命令或者MGCP协议的NTFY命令。由于媒体网关11和媒体网关12上报媒体网关控制器10的信息大多是用户的操作，例如摘机、挂机、拨号、拍叉等，而用户操作往往是随机的，因此媒体网关11和媒体网关12需要建立比媒体网关控制器10复杂得多的机制来保障自己的上报命令在媒体网关控制器10被串行执行。
现有技术一是，使用可靠连接的传输协议，例如TCP，来保证命令串行，即发送方的应用层只需将准备发送的命令消息交付给传输层，利用传输协议的可靠性机制来保证每一条消息顺序抵达接收方。这样在前一命令尚未得到响应之前，后续命令将缓存在传输层的发送队列内，通过消息串行发送的机制也就自然地达到了命令串行执行的目的。
现有技术二是使用H.248协议的事件缓存(EventBuffer)或者MGCP协议的事件隔离(EventQuarantine)机制来保证命令串行，即当某个终端或端点上出现事件上报尚未得到响应时，后续检测到的事件基于一定的筛选条件先暂时缓存或隔离到一个为该终端或端点建立的FIFO队列中，需要说明的是该队列存在MG中。等接收到前一事件上报的响应后再基于一定的条件从该队列中选取事件上报，而不符合选择条件的事件将被丢弃。
H.248协议使用Events描述符设置事件的上报条件；使用EventBuffer描述符设置事件的缓存条件；使用EventBufferControl属性设置事件缓存这个FIFO队列是关闭(Off)，还是基于Events描述符所设条件从中单次选取和上报事件(LockStep)。
MGCP协议使用RequestedEvents列表设置事件的上报条件；使用DetectEvents和RequestedEvents列表设置事件的缓存条件；使用QuarantineHandling参数设置事件隔离这个FIFO队列是被处理(Process)还是被丢弃(Discard)，基于RequestedEvents列表所设条件从中选取和上报事件是只允许单次(Step)还是多次(Loop)。
发明内容
有鉴于此，本发明的主要目的在于提供一种媒体网关命令串行方法，使得媒体网关可以简单而高效地实现命令串行。
为实现上述目的，本发明提供了一种媒体网关命令串行方法，包含以下步骤A所述媒体网关为所管理的每一个终端各创建一个用于缓存的队列；B当所述终端检测到一个事件时，所述媒体网关判断是否该终端当前激活的事件描述符已经被锁定，或虽未被锁定但前一个命令还没有完成，如果是则进入步骤C；C将检测到的所述事件缓存到该终端的队列中。
其中，所述步骤B还进一步包含以下子步骤
B1当所述终端检测到一个事件时，所述媒体网关判断该终端当前激活的事件描述符是否已经被锁定，如果是则进入步骤C，否则进入步骤B2；B2判断该终端当前激活的事件描述符中是否包含检测到的所述事件，如果是则进入步骤B3，否则丢弃该事件；B3判断前一个命令是否还没有完成，如果是则进入步骤C，否则上报检测到的所述事件。
所述步骤C还进一步包含以下子步骤C1判断所述终端是否为物理终端，如果是则进入步骤C2，否则进入步骤C3；C2根据所述检测到的事件和最近上报事件，对该检测到的事件以及该终端的队列中所有尚未上报事件基于实时有效性进行有选择地丢弃或缓存；C3将所述检测到的事件缓存到该终端的队列中。
所述步骤C2还进一步包含以下子步骤C21判断所述检测到的事件是否为摘机、挂机、拍叉、拨号中的一种，如果是则根据该检测到的事件和最近上报事件，对该检测到的事件以及该终端的队列中所有尚未上报事件基于实时有效性进行有选择地丢弃或缓存，否则将该检测到的事件缓存到该终端的队列中。
当所述最近上报事件为摘机时，所述步骤C21还进一步包含以下子步骤C211判断所述检测到的事件是否为摘机，如果是则清空所述终端的队列中现有事件，并丢弃所述检测到的事件；C212判断所述检测到的事件是否为挂机或拍叉，如果是则清空所述终端的队列中现有事件，并将所述检测到的事件缓存到该队列的末尾；C213判断所述检测到的事件是否为拨号，如果是则从所述终端的队列末尾向前回溯最近摘机或者拍叉事件，如果先找到的是最近摘机事件，则清空该队列中比该最近摘机事件更早的事件以及该最近摘机事件本身，再将所述检测到的事件缓存到该队列的末尾，如果找到的是最近拍叉事件，则清空该队列中比该最近拍叉事件更早的事件，再将所述检测到的事件缓存到该队列的末尾，如果没有找到最近摘机或者拍叉事件，则将所述检测到的事件缓存到该队列的末尾。
当所述最近上报事件为挂机时，所述步骤C21还进一步包含以下子步骤C214判断所述检测到的事件是否为摘机，如果是则清空所述终端的队列中现有事件，再将所述检测到的事件缓存到该队列的末尾；C215判断所述检测到的事件是否为挂机，如果是则清空所述终端的队列中现有事件，并丢弃所述检测到的事件；C216判断所述检测到的事件是否为拍叉或拨号，如果是则从所述终端的队列末尾向前回溯最近摘机事件，如果能够找到最近摘机事件，则清空该队列中比该最近摘机事件更早和更晚的事件，再将所述检测到的事件缓存到该队列的末尾；如果没有能够找到最近摘机事件，则清空该队列中现有事件，并丢弃所述检测到的事件，启动终端异常处理。
当所述最近上报事件为拍叉或拨号时，所述步骤C21还进一步包含以下子步骤C217判断所述检测到的事件是否为摘机，如果是则从所述终端的队列末尾向前回溯最近挂机事件，
如果能够找到最近挂机事件，则清空该队列中比该最近挂机事件更早的现有事件，再将所述检测到的事件缓存到该队列的末尾，如果没有能够找到最近挂机事件，则清空该队列中现有事件，并丢弃所述检测到的事件，启动终端异常处理；C218判断所述检测到的事件是否为挂机或拍叉，如果是则清空所述终端的队列中现有事件，再将所述检测到的事件缓存到该队列的末尾；C219判断所述检测到的事件是否为拨号，如果是则将所述检测到的事件缓存到所述终端的队列末尾。
当所述终端获得新的事件描述符时，包含以下步骤D判断所述终端的队列是否为空，如果不是则取该队列中首个事件并进入步骤E；E判断新的所述事件描述符是否包含该事件，如果是进入步骤F，否则从该队列中移除该事件并进入步骤D；F判断前一个命令是否还没有完成，如果不是则上报该事件并从该队列中移除该事件。
当所述终端获得前一个命令的响应时，包含以下步骤H判断所述终端当前激活的事件描述符是否已经被锁定，如果不是则进入步骤I；I判断所述终端的队列是否为空，如果不是则取该队列中首个事件并进入步骤J；J判断所述终端当前激活的事件描述符是否包含该事件，如果是则上报该事件并从该队列中移除该事件，否则从该队列中移除该事件并进入步骤I。
所述命令是通报命令。
通过比较可以发现，本发明的技术方案与现有技术的区别在于，媒体网关预先为所管理的每一个终端各创建一个用于缓存的队列(现有技术是在收到媒体网关控制器的相关命令以后才进行队列的建立)，当终端检测到一个事件时，如果该终端当前激活的事件描述符已经被锁定，或虽未被锁定但前一个命令还没有完成，则判断该终端是否为物理终端，如果是则对该终端所有尚未上报事件基于实时有效性进行有选择地丢弃或缓存(现有技术没有对尚未上报事件基于实时有效性进行有选择地丢弃或缓存的机制)，否则直接缓存检测到的事件。
这种技术方案上的区别，带来了较为明显的有益效果，即由于对每一个终端预先创建了用于缓存的队列，并且根据先进先出原则在收到上一个命令的回应后才上报队列头上的事件，因此可以保证命令的串行。由于队列是预先创建的，所以可以使得命令串行由媒体网关独立实现，不依赖于媒体网关控制器，实现方案更为简单。通过对所操作的物理终端进行事件的有选择丢弃，可以大大减少无效事件的上报，提高命令串行的效率。另外这种技术方案可以适用于任何传输协议。尤其是不可靠传输协议，同时也避免了使用可靠传输协议带来的交互效率的下降。
图1是NGN中MG和MGC组网示意图；图2是MG缓存实时有效事件实现命令串行示意图；图3是事件检测处理流程示意图；图4是对尚未上报的所有事件基于当前有效性进行有选择地丢弃或缓存的规则流程图；图5是摘机事件处理子规则流程图；图6是挂机事件处理子规则流程图；
图7是拍叉或者拨号事件处理子规则流程图；图8是事件描述符处理流程图；图9是通报响应处理流程图。
具体实施例方式
为使本发明的目的、技术方案和优点更加清楚，下面将结合附图对本发明作进一步地详细描述。
下面描述根据本发明的原理，详细说明为媒体网关实现Notify命令的串行提供的简单而高效的解决方案。并重点阐述本发明核心内容媒体网关主动创建先入先出队列，缓存实时有效事件，保证命令的串行传输和执行。
如图2所示，媒体网关20就是图1中的媒体网关11，媒体网关控制器21就是图1中的媒体网关控制器10。图2以这两个设备间信令流示意图形式来说明MG缓存实时有效事件实现命令串行。媒体网关MG主动为每个终端各启用一个初始化为空的先入先出(First In First Out，简称″FIFO″)队列作为事件缓存。需要说明的是，这个队列是存在于媒体网关20上的，图2中为了逻辑上更好的说明，把事件缓存22和媒体网关20分开表示，实际中二者将在一个物理设备中。以下对图2中的各个步骤进行详细描述。
步骤201，媒体网关控制器21向媒体网关20发送请求命令，该请求命令中携带了包含事件1的事件描述符，也即要求检测该事件。
步骤202，媒体网关20向媒体网关控制器21发送响应命令，确认已收到步骤201中的请求命令，该请求命令中携带的事件描述符成为当前激活的事件描述符，其包含的事件1将被检测和上报。
步骤203，媒体网关20检测到事件1的发生。由于当前激活的事件描述符未被锁定，则可以直接根据事件描述符内容决定是否上报。
步骤204，媒体网关20核实事件1是当前激活的事件描述符中包含的事件，因此决定上报检测到事件1并锁定事件描述符。
步骤205，媒体网关20向媒体网关控制器21发送请求命令，通报事件1已被检测到。
步骤206，媒体网关20检测到事件2的发生，由于当前激活的事件描述符已被锁定，因此需要考虑将其缓存。基于实时有效性判断的结果事件2当前有效，因此被追加到事件缓存中。
步骤207，媒体网关控制器21向媒体网关20发送响应命令，确认步骤已收到205中的请求命令。
步骤208，媒体网关20检测到事件3的发生，由于当前激活的事件描述符已被锁定，因此需要考虑将其缓存。基于实时有效性判断的结果事件3当前有效，因此被追加到事件缓存中。
步骤209，媒体网关控制器21向媒体网关20发送请求命令，该请求命令中携带了包含事件3的事件描述符，也即要求检测该事件。
步骤210，媒体网关20向媒体网关控制器21发送响应命令，确认已收到步骤209中的请求命令，该请求命令中携带的事件描述符成为当前激活的事件描述符，其包含的事件3将被检测和上报。
步骤211，媒体网关20根据新激活的事件描述符从事件缓存头部开始扫描已缓存的事件。发现先缓存的事件2不是当前激活的事件描述符中包含的事件，因此决定清除事件2。再发现后缓存的事件3是当前激活的事件描述符中包含的事件，因此决定上报事件2并锁定事件描述符。
步骤212，媒体网关20向媒体网关控制器21发送请求命令，通报事件3已被检测到。
步骤213，媒体网关20检测到事件4的发生，由于当前激活的事件描述符已被锁定，因此需要考虑将其缓存。基于实时有效性判断的结果事件4当前有效，因此被追加到事件缓存中。
步骤214，媒体网关控制器21向媒体网关20发送响应命令，确认步骤已收到212中的请求命令。
步骤215，媒体网关20检测到事件5的发生，由于当前激活的事件描述符已被锁定，因此需要考虑将其缓存。基于实时有效性判断的结果事件5当前有效，因此被追加到事件缓存中。
步骤216，媒体网关20检测到事件8的发生，由于当前激活的事件描述符已被锁定，因此需要考虑将其缓存。基于实时有效性判断的结果此前已缓存的事件4、5等当前已无效，因此被清除出事件缓存，而事件8当前有效，因此被追加到事件缓存。
步骤217，媒体网关控制器21向媒体网关20发送请求命令，该请求命令中携带了包含事件8的事件描述符，也即要求检测该事件。
步骤218，媒体网关20向媒体网关控制器21发送响应命令，确认已收到步骤217中的请求命令，该请求命令中携带的事件描述符成为当前激活的事件描述符，其包含的事件8将被检测和上报。
步骤219，媒体网关20根据新激活的事件描述符从事件缓存头部开始扫描已缓存的事件。发现缓存的事件8是当前激活的事件描述符中包含的事件，因此决定上报事件8并锁定事件描述符。
步骤220，媒体网关20向媒体网关控制器21发送请求命令，通报事件8已被检测到。
步骤221，媒体网关控制器21向媒体网关20发送响应命令，确认步骤已收到220中的请求命令。
需要说明的是，媒体网关20除了可以接收到新的事件描述符而取代原事件描述符并解除锁定重新允许事件上报外，还可以通过激活内嵌的事件描述符方式取代原事件描述符并解除锁定重新允许事件上报，内嵌的事件描述符是为了减少消息的交互量，由媒体网关控制器21在发送新的事件描述符时，将两个新事件描述符一起合并成在一个命令中发出来，第二个事件描述符嵌入在第一个事件描述符中，在第一个事件描述符锁定后第二个自动激活，但是激活后，并不是后续检测到事件满足了事件描述符的定义就马上被发送，一定要等到前一个事件的通报请求有了相对应的响应后才能够发送下一个事件。
以上总体描述了媒体网关缓存实时有效事件实现命令串行，以及和媒体网关控制器之间的信令流情况，下面结合流程图具体描述媒体网关上事件检测、事件描述符，通报响应的流程处理情况。
图3所示是根据本方案的一个情况，即当MG上的某个终端检测到任何事件时的处理流程。
如图所示，首先，在步骤3000中，MG检测到新的事件将触发以下流程。
在步骤3100，检测事件描述符锁定情况。如果事件描述符已被锁定，即当前激活的事件描述符中已有事件被上报过，则进入步骤3200。否则进入步骤3110。
在步骤3110，由于在步骤3100中判定事件描述符未锁定，因此在本步骤中检测事件描述符中是否含有该事件的情况。如果该事件没有在当前激活的事件描述符中出现，就进入步骤3111。否则进入步骤3120。
在步骤3111，由于在步骤3110中判定事件描述符中不含有该事件，因此在本步骤中丢弃该事件，然后结束。
在步骤3120，由于在步骤3110中判定事件描述符中含有该事件，因此在本步骤中检测该终端上通报(Notify)请求的完成情况。如果该终端当前没有未完成的通报请求，则立即进入步骤3130。否则，进入步骤3200。
随后在步骤3130，由于在步骤3120中判定该终端当前没有未完成的通报请求，因此在本步骤中通过通报请求上报MGC，然后结束。
然后在步骤3200，由于在步骤3100中，检测出当前激活的事件描述符中已有事件被上报过，即事件描述符已被锁定，进入本步骤。或者由于在步骤3120中，检测出终端当前有未完成的通报信令，也进入本步骤。因此在本步骤中检测终端情况，如果是物理终端，则进入步骤3210，否则进入步骤3300。
在步骤3210，由于在步骤3200中判定该终端是物理终端，因此在本步骤中根据最近已上报的事件和最近刚检测的事件，对尚未上报的所有事件基于其当前有效性进行有选择地丢弃或缓存。然后结束。
在步骤3300，由于在步骤3200中判定该终端是临时终端例如RTP流，而临时终端上发生的事件较少因此不需要作优化，直接将该事件添加到事件缓存的末尾，也即FIFO队列的末尾，然后结束。
在本例中，由于在物理终端例如TDM通道上可能被检测到的事件中，摘机、挂机、拍叉、拨号最为频繁并且对呼叫接续影响较大，为了对缓存的事件做一下清理，减少不必要的事件发送以提高效率，因此如上述还需根据最近已上报的事件和最近刚检测的事件，对尚未上报的所有事件基于其当前有效性进行有选择地丢弃或缓存，其处理遵循以下的规则，即图3中的步骤3210需要更详细的分步骤处理。下面结合图4、图5、图6、图7进行详细描述。
如图4所示在说明规则的时候，先说明总体规则流程，即出现新的检测事件后马上进行最近上报事件的判断处理，判断了上报事件类型后再根据具体的事件类型说明其处理步骤，即各个子规则。
首先，步骤4000，检测到新的事件触发本流程。
接下来在步骤4100，判断最近检测事件是否为摘机、挂机、拍叉、拨号之类的频繁事件。如果最近检测事件并非频繁事件，则进入步骤4110，否则进入步骤4200。
在步骤4110，由于在步骤4100中判定最近检测事件不是频繁事件，因此在本步骤中直接将该事件添加到事件缓存的末尾，即FIFO队列的末尾。
在步骤4200，由于在步骤4100中判定最近检测事件是频繁事件，因此在本步骤判断最近已上报的事件是否为摘机，如果是摘机事件，则进入步骤4210。否则进入步骤4300。
在步骤4210，由于在步骤4200中判定最近已上报的事件是摘机事件，因此在本步骤中基于这一条件处理最近刚检测的事件，后面结合图5来说明。
在步骤4300，由于在步骤4200中判定最近已上报的事件不是摘机事件，因此在本步骤判断最近已上报的事件是否为挂机，如果是挂机事件，则进入步骤4310，否则进入步骤4400。
在步骤4310，由于在步骤4300中判定最近已上报的事件是挂机事件，因此在本步骤中基于这一条件处理最近刚检测的事件，后面结合图6来说明。
在步骤4400，由于在步骤4300中判定最近已上报的事件不是挂机事件，因此在本步骤判断最近已上报的事件是否为拍叉或者拨号，如果是拍叉或者拨号事件，则进入步骤4410，否则结束。
在步骤4410，由于在步骤4400中判定最近已上报的事件是拍叉或者拨号，因此在本步骤中基于这一条件处理最近刚检测的事件，后面结合图7来说明。
下面结合图5来说明最近已上报事件为摘机情况下刚检测到的事件的处理流程。
如图5所示首先进行步骤5000，最近已上报的事件为摘机。
接着进入步骤5100，判断最近检测的事件是否为摘机事件，如果最近检测的事件为摘机事件，则进入步骤5110，否则进入步骤5200。
在步骤5110，由于在步骤5100中判定最近检测的事件为摘机事件，因此在本步骤中清空事件缓存中现有事件，同时丢弃该摘机事件，然后结束本流程。
在步骤5200，由于在步骤5100中判定最近检测的事件非摘机事件，因此在本步骤判断最近检测的事件是否为挂机或者拍叉事件，若是则进入步骤5210，否则进入步骤5300。
在步骤5210，由于在步骤5200中判定最近检测的事件为挂机或者拍叉事件，因此在本步骤中清空事件缓存中现有事件，再将该挂机或者拍叉事件添加到事件缓存的末尾，然后结束本流程。
在步骤5300，由于在步骤5200中判定最近检测的事件非挂机或者拍叉事件，因此在本步骤判断最近检测的事件是否为拨号事件，如果不是拨号事件，那么就结束本流程。如果是拨号事件，需要从事件缓存末尾向前回溯最近摘机或者拍叉事件，进入步骤5310进一步处理。
在步骤5310，从事件缓存末尾开始回溯，如果还有事件未被检查过，那么进入步骤5320，如果所有事件已被检查过，那么进入步骤5350。
在步骤5320，从事件缓存末尾向前取首个还未被检查的事件，进入步骤5330。
在步骤5330，判断步骤5320中所取事件是否为摘机事件，是则进入步骤5331，否则进入步骤5340。
在步骤5331，由于在步骤5330中判定先找到最近摘机事件，因此在本步骤中清空事件缓存中比该摘机事件更早的现有事件以及该摘机事件本身，再将该拨号事件添加到事件缓存的末尾，然后结束本流程。
在步骤5340，判断步骤5320中所取事件是否为拍叉事件，是则进入步骤5341处理，否则返回步骤5310。
在步骤5341，由于在步骤5340中判定先找到最近拍叉事件，因此在本步骤中清空事件缓存中比该拍叉事件更早的现有事件，再将该拨号事件添加到事件缓存的末尾，然后结束本流程。
在步骤5350，由于经过上述步骤都没有在事件缓存中找到最近摘机或者拍叉事件，因此直接将该拨号事件添加到事件缓存的末尾，然后结束本流程。
下面结合图6来说明最近已上报事件为挂机情况下刚检测到的事件的处理流程。
如图6所示首先进行步骤6000，最近已上报的事件为挂机。
接着进入步骤6100，判断最近检测事件是否为摘机事件，如果最近检测事件为摘机事件，则进入步骤6110。否则进入步骤6200。
在步骤6110，由于在步骤6100中判断最近刚检测的事件为摘机事件，因此在本步骤中清空事件缓存中现有事件，再将该摘机事件添加到事件缓存末尾，然后结束本流程。
在步骤6200，由于在步骤6100中判断最近刚检测的事件不为摘机事件，因此判断最近刚检测的事件是否为挂机事件，若是则进入步骤6210，否则进入步骤6300。
在步骤6210，由于在步骤6200中判断最近刚检测的事件为挂机事件，因此在本步骤中清空事件缓存中现有事件，同时丢弃该挂机事件，然后结束本流程。
在步骤6300，由于在步骤6200判断最近刚检测的事件不为挂机事件，因此判断最近刚检测的事件是否为拍叉或者拨号事件，如果不是拍叉或者拨号事件，那么就结束本流程。否则，需要从事件缓存末尾向前回溯最近摘机事件，进入步骤6310进一步处理。
在步骤6310，从事件缓存末尾开始回溯，如果还有事件未被检查过，那么进入步骤6320，如果所有事件已被检查过，那么进入步骤6340。
在步骤6320，从事件缓存末尾向前取首个还未被检查的事件，进入步骤6330。
在步骤6330，判断步骤6320所取事件是否为摘机事件，是则进入步骤6331，否则返回步骤6310。
在步骤6331，由于在步骤6330中判定找到最近摘机事件，因此在本步骤中清空事件缓存中比该摘机事件更早和更晚的现有事件，再将该拍叉事件添加到事件缓存的末尾，然后结束本流程。
在步骤6340，由于经过上述步骤都没有在事件缓存中找到最近摘机事件，因此本步骤清空事件缓存中的现有事件，同时丢弃该拍叉或者拨号事件，启动终端异常处理，然后结束本流程。需要说明的是，例如将该终端退出服务并上报状态丢失就属于一种终端异常处理方式。
下面结合图7来说明最近已上报事件是拍叉或者拨号情况下刚检测到的事件的处理流程。
如图7所示首先进行步骤7000，最近已上报的事件为拍叉或拨号。
接着进入步骤7100，判断最近检测事件是否为摘机，如果是，那么需要从事件缓存末尾向前回溯最近挂机事件，进入步骤7110进一步处理，否则进入步骤7200。
在步骤7110，从事件缓存末尾开始回溯，如果还有事件未被检查过，那么进入步骤7120，如果所有事件已被检查过，那么进入步骤7140。
在步骤7120，从事件缓存末尾向前取首个还未被检查的事件，进入步骤7130。
在步骤7130，判断步骤7120所取事件是否为最近挂机事件。是则进入步骤7131，否则返回步骤7110。
在步骤7131，由于在步骤7130判定找到最近挂机事件，因此在本步骤清空事件缓存中比该挂机事件更早的现有事件，再将该最近检测到的摘机事件添加到事件缓存的末尾，然后结束本流程。
在步骤7140，由于经过上述步骤都没有在事件缓存中找到最近挂机事件，因此本步骤清空事件缓存中的现有事件，同时丢弃该最近检测到的摘机事件，启动终端异常处理，然后结束本流程。需要说明的是，例如将该终端退出服务并上报状态丢失就属于一种终端异常处理方式。
在步骤7200，由于在步骤7100中判定最近检测事件不是摘机，因此本步骤判断最近检测事件是否为挂机或者拍叉。如果最近检测事件是挂机或者拍叉事件，则进入步骤7210，否则进入步骤7300。
在步骤7210，由于在步骤7200中判定最近检测事件是挂机或者拍叉事件，因此在本步骤清空事件缓存中现有事件，再将该最近检测到的挂机或者拍叉事件添加到事件缓存的末尾。
在步骤7300，由于在步骤7200中判定最近检测事件不是挂机或者拍叉事件，因此在本步骤判断最近检测事件是否为拨号，如果是拨号事件就进入步骤7310，否则就结束本流程。
在步骤7310，由于在步骤7300中判定最近检测事件是拨号事件，因此自本步骤将该拨号事件添加到事件缓存的末尾，然后结束本流程。
需要说明的是，上述规则中若MG上某个物理终端，如TDM通道上报状态丢失，则将启动终端的异常处理机制，具体的处理过程为MG通过向MGC发送上报状态丢失的信令，触发MGC下发审计命令以同步该终端在MG和MGC上的状态，MG反馈该终端的实际摘机或挂机状态，并清空事件缓存和启动事件描述符的上报锁定。
图8所示是根据本方案的另一个情况，即当MG上的某个终端获得新事件描述符，这个新事件描述符可能是MGC发来的新事件描述符，或者原内嵌的事件描述符被激活时，MG将扫描该终端的事件缓存的处理流程。
如图所示，首先，在步骤8000，MG获得新的事件描述符将触发以下流程。
在步骤8100，判断事件缓存的情况，如果事件缓存为空，那么MG将基于新事件描述符等待新的事件被检测，结束本流程。如果不为空，则进入步骤8200，继续处理。
在步骤8200，MG从事件缓存队列的起始提取首个事件，即按FIFO顺序排在事件缓存最前面的事件，进行步骤8300的判断。
在步骤8300，把该事件与新事件描述符相比较，看新事件描述符是否含有该事件。如果该事件未出现在新事件描述符中，那么进行步骤8310，否则进入步骤8400。
在步骤8310，由于在步骤8300中判断该事件未出现在新事件描述符中，因此在本步骤中，MG移除该事件并重新开始扫描事件缓存。
在步骤8400，由于在步骤8300中判断该事件出现在新事件描述符中，判断是否存在未完成的通报(Notify)请求，也即请求尚未得到响应。如果该终端当前存在未完成的Notify请求，那么MG将继续等待Notify请求的响应，结束本流程。如果不存在未完成的Notify请求，那么继续后面步骤8500的处理。
在步骤8500，MG通过Notify请求上报该事件，进入步骤8600。
在步骤8600，MG将该事件从事件缓存中移除，结束本流程。
需要说明的是，上报Notify请求的时间戳是该事件实际被检测到的时间。然后该终端上当前激活的事件描述符被锁定，MG等待新事件描述符，期间任何在该终端上被检测到事件将被放入该事件缓存。
图9所示是根据本方案的最后一个情况，即当MG上的某个终端获得通报(Notify)响应的处理流程。
如图所示，首先，在步骤9000，MG得到通报(Notify)响应触发以下流程。
在步骤9100，进行事件描述符是否锁定的判断。如果事件描述符已被锁定，即该终端上当前激活的事件描述符中已有事件被上报过，那么MG将等待新事件描述符，期间任何在该终端上被检测到事件将被放入该该终端的事件缓存，结束本流程。需要说明的是，此时必须等待新事件描述符，而得到新事件描述符之前不能发送下一个Notify请求，因为一个事件描述符只允许上报一次然后就被锁定。如果该终端上事件描述符没有被锁定，那么进入步骤9200。
在步骤9200，MG将扫描该终端的事件缓存。如果扫描事件缓存为空，那么MG将基于当前事件描述符，继续等待终端检测到新的事件，结束本流程。如果扫描该终端事件缓存不为空，则进入步骤9300。
在步骤9300，MG从事件缓存队列的起始提取首个事件，即按FIFO顺序排在事件缓存最前面的事件，进行步骤9400的判断。
在步骤9400，把该事件与新事件描述符相比较，看新事件描述符是否含有该事件。如果该事件未出现在新事件描述符中，那么进入步骤9410，否则进入步骤9500。
在步骤9410，由于在步骤9400中判断该事件未出现在新事件描述符中，因此在本步骤中，MG移除该事件并重新开始扫描事件缓存。
在步骤9500，由于在步骤9400中判断该事件出现在新事件描述符中，因此MG就通过Notify请求上报该事件，进入步骤9600。
在步骤9600，MG将该事件从事件缓存中移除，结束本流程。
需要说明的是，上报Notify请求的时间戳是该事件实际被检测到的时间。然后该终端上当前激活的事件描述符被锁定，MG等待新事件描述符，期间任何在该终端上被检测到事件将被放入该事件缓存。
除了上述提到的技术方案外，还可以其它的替代技术方案。
在MG终端分配事件缓存FIFO列表上，可以采用不同的方式第一种方式，可以是为每个终端都预先分配好一个定长的FIFO列表，这样实现相对简单但占用资源可能较多，也即是上述提到的技术方案采用的FIFO列表分配方式；第二种方式，可以是预留一个公共缓存区，各终端有需求时才从其中申请一个存储单元并串接成为一个自己的FIFO列表，显然，这样实现相对复杂，需要各个终端在MG的协调下共享资源，但资源利用率会较高。
在MG上，根据最近已上报的事件和最近刚检测的事件，对尚未上报的所有事件基于其当前有效性进行有选择地丢弃或缓存也可以灵活采用不同的规则第一种，可以是如上述提到的技术方案将摘机、挂机、拍叉、拨号事件作为组合判断条件。这样判断流程比较清晰并且复杂程度也比较适中。
第二种，也可以简化为只有摘机和挂机事件，这样判断流程大为减少但控制力度也相对较粗。
第三种，还可以扩充更多的事件作为组合判断条件，这样控制力度相对更高但判断流程更加复杂。
虽然通过参照本发明的某些优选实施例，已经对本发明进行了图示和描述，但涉足本领域的人士应该明白，可以在形式上和细节上对其作各种各样的改变，而不偏离所附权利要求书所限定的本发明的精神和范围。
权利要求
1.一种媒体网关命令串行方法，其特征在于，包含以下步骤A所述媒体网关为所管理的每一个终端各创建一个用于缓存的队列；B当所述终端检测到一个事件时，所述媒体网关判断是否该终端当前激活的事件描述符已经被锁定，或虽未被锁定但前一个命令还没有完成，如果是则进入步骤C；C将检测到的所述事件缓存到该终端的队列中。
2.根据权利要求1所述的媒体网关命令串行方法，其特征在于，所述步骤B还进一步包含以下子步骤B1当所述终端检测到一个事件时，所述媒体网关判断该终端当前激活的事件描述符是否已经被锁定，如果是则进入步骤C，否则进入步骤B2；B2判断该终端当前激活的事件描述符中是否包含检测到的所述事件，如果是则进入步骤B3，否则丢弃该事件；B3判断前一个命令是否还没有完成，如果是则进入步骤C，否则上报检测到的所述事件。
3.根据权利要求1所述的媒体网关命令串行方法，其特征在于，所述步骤C还进一步包含以下子步骤C1判断所述终端是否为物理终端，如果是则进入步骤C2，否则进入步骤C3；C2根据所述检测到的事件和最近上报事件，对该检测到的事件以及该终端的队列中所有尚未上报事件基于实时有效性进行有选择地丢弃或缓存；C3将所述检测到的事件缓存到该终端的队列中。
4.根据权利要求3所述的媒体网关命令串行方法，其特征在于，所述步骤C2还进一步包含以下子步骤C21判断所述检测到的事件是否为摘机、挂机、拍叉、拨号中的一种，如果是则根据该检测到的事件和最近上报事件，对该检测到的事件以及该终端的队列中所有尚未上报事件基于实时有效性进行有选择地丢弃或缓存，否则将该检测到的事件缓存到该终端的队列中。
5.根据权利要求4所述的媒体网关命令串行方法，其特征在于，当所述最近上报事件为摘机时，所述步骤C21还进一步包含以下子步骤C211判断所述检测到的事件是否为摘机，如果是则清空所述终端的队列中现有事件，并丢弃所述检测到的事件；C212判断所述检测到的事件是否为挂机或拍叉，如果是则清空所述终端的队列中现有事件，并将所述检测到的事件缓存到该队列的末尾；C213判断所述检测到的事件是否为拨号，如果是则从所述终端的队列末尾向前回溯最近摘机或者拍叉事件，如果先找到的是最近摘机事件，则清空该队列中比该最近摘机事件更早的事件以及该最近摘机事件本身，再将所述检测到的事件缓存到该队列的末尾，如果找到的是最近拍叉事件，则清空该队列中比该最近拍叉事件更早的事件，再将所述检测到的事件缓存到该队列的末尾，如果没有找到最近摘机或者拍叉事件，则将所述检测到的事件缓存到该队列的末尾。
6.根据权利要求4所述的媒体网关命令串行方法，其特征在于，当所述最近上报事件为挂机时，所述步骤C21还进一步包含以下子步骤C214判断所述检测到的事件是否为摘机，如果是则清空所述终端的队列中现有事件，再将所述检测到的事件缓存到该队列的末尾；C215判断所述检测到的事件是否为挂机，如果是则清空所述终端的队列中现有事件，并丢弃所述检测到的事件；C216判断所述检测到的事件是否为拍叉或拨号，如果是则从所述终端的队列末尾向前回溯最近摘机事件，如果能够找到最近摘机事件，则清空该队列中比该最近摘机事件更早和更晚的事件，再将所述检测到的事件缓存到该队列的末尾；如果没有能够找到最近摘机事件，则清空该队列中现有事件，并丢弃所述检测到的事件，启动终端异常处理。
7.根据权利要求4所述的媒体网关命令串行方法，其特征在于，当所述最近上报事件为拍叉或拨号时，所述步骤C21还进一步包含以下子步骤C217判断所述检测到的事件是否为摘机，如果是则从所述终端的队列末尾向前回溯最近挂机事件，如果能够找到最近挂机事件，则清空该队列中比该最近挂机事件更早的现有事件，再将所述检测到的事件缓存到该队列的末尾，如果没有能够找到最近挂机事件，则清空该队列中现有事件，并丢弃所述检测到的事件，启动终端异常处理；C218判断所述检测到的事件是否为挂机或拍叉，如果是则清空所述终端的队列中现有事件，再将所述检测到的事件缓存到该队列的末尾；C219判断所述检测到的事件是否为拨号，如果是则将所述检测到的事件缓存到所述终端的队列末尾。
8.根据权利要求1所述的媒体网关命令串行方法，其特征在于，当所述终端获得新的事件描述符时，包含以下步骤D判断所述终端的队列是否为空，如果不是则取该队列中首个事件并进入步骤E；E判断新的所述事件描述符是否包含该事件，如果是进入步骤F，否则从该队列中移除该事件并进入步骤D；F判断前一个命令是否还没有完成，如果不是则上报该事件并从该队列中移除该事件。
9.根据权利要求1所述的媒体网关命令串行方法，其特征在于，当所述终端获得前一个命令的响应时，包含以下步骤H判断所述终端当前激活的事件描述符是否已经被锁定，如果不是则进入步骤I；I判断所述终端的队列是否为空，如果不是则取该队列中首个事件并进入步骤J；J判断所述终端当前激活的事件描述符是否包含该事件，如果是则上报该事件并从该队列中移除该事件，否则从该队列中移除该事件并进入步骤I。
10.根据权利要求1至9中任一项所述的媒体网关命令串行方法，其特征在于，所述命令是通报命令。
全文摘要
本发明涉及通信领域，公开了一种媒体网关命令串行方法，使得媒体网关可以简单而高效地实现命令串行。这种媒体网关命令串行方法媒体网关预先为所管理的每一个终端各创建一个用于缓存的队列，当终端检测到一个事件时，如果该终端当前激活的事件描述符已经被锁定，或虽未被锁定但前一个命令还没有完成，则判断该终端是否为物理终端，如果是则对该终端所有尚未上报事件基于实时有效性进行有选择地丢弃或缓存，否则直接缓存检测到的事件。
文档编号H04L29/02GK1713634SQ200410062998
公开日2005年12月28日 申请日期2004年6月27日 优先权日2004年6月27日
发明者林扬波 申请人:华为技术有限公司