CN100542328C - 紧急业务的收发方法及装置 - Google Patents

Abstract

本发明公开了紧急业务的收发方法及装置，用以解决用户恶意使用紧急用户标识进行紧急注册来享受越权服务的问题。本发明紧急业务中发起回叫的方法，包括：回叫发起侧在确认收到的请求消息的发起方身份后，向被叫接续网络前转该请求消息；以及使被叫接续网络获知该请求消息的发起方身份。本发明一种紧急业务中接收回叫的方法，包括：被叫接续网络识别呼叫发起侧网络发来的回叫请求消息的发起方身份，根据发起方身份是否为有效的PSAP进行后续处理。

Description

紧急业务的收发方法及装置

技术领域

本发明涉及通信领域，特别是涉及紧急业务的收发方法及装置。

背景技术

在紧急的状态下，用户会呼叫PSAP已获取帮助，而PSAP也有可能在用户挂机后对用户进行呼叫，以便了解更多的信息。这种在紧急状态下，PSAP主动呼叫用户的行为称为回叫。目前IMS域的紧急呼叫的流程框架图，参见图1所示。

图1中只列出了几个主要的网元，包括：用户终端，代理呼叫会话控制功能实体P-CSCF，紧急呼叫会话控制功能实体E-CSCF，公共安全应答点PSAP，本文所描述的PSAP包含公共安全应答点和紧急呼叫中心(警察局，消防大队等)这两种情况。以及服务呼叫会话控制功能实体S-CSCF。图1中的实线部分描述了用户作为发起方进行的呼叫流程，虚线部分描述了PSAP作为发起方进行的呼叫流程，也就是回叫的流程。在呼叫流程中P-CSCF会检查请求中用户所使用的用户标识，并插入网络确认的用户标识。

为了实现回叫，用户需要发起一个紧急注册的过程，在紧急注册的过程中，使用的是一个特殊的紧急用户标识。通过注册的流程，告知S-CSCF将紧急用户标识和用户所在的联系地址绑定一起，这样才能保证PSAP发出的回叫该紧急用户标识的请求能够经过S-CSCF发到用户的联系地址。为了保证PSTN的PSAP能够回叫到该用户，在该紧急用户标识的隐式集中需要包含相关的telURI用户身份。本文所提到的紧急用户标识可以包含这些相关的tel用户身份，也可以不包含这些tel用户身份。所谓的隐式注册集就是只要该集中一个用户身份被注册了，就表示该集中所有的用户身份都被注册了。所述注册流程参见图2所示，包括下列步骤：

步骤101，用户发起REGISTER消息，消息中携带紧急用户标识。

步骤102，P-CSCF将收到了REGISTER消息前传到用户本域的I-CSCF，消息中包含有P-CSCF所在域的标识。

步骤103，I-CSCF给HSS发送UAR消息，消息中携带有P-CSCF所在域的标识。

步骤104，HSS根据UAR消息中的P-CSCF所在域的标识进行漫游限制检查。如果用户来自不允许的漫游域，将给I-CSCF回失败响应。如果该请求消息是合法的，将使用UAA消息给I-CSCF返回合适的S-CSCF或者一些让I-CSCF选择S-CSCF的信息。在紧急注册的过程中，HSS可以省略漫游限制检查。

步骤105，I-CSCF参考UAA中的信息，将REGISTER前传给相关的S-CSCF。

步骤106，S-CSCF发送SAR消息给HSS，刷新HSS的记录。

步骤107，HSS响应SAA消息，消息中携带用户的配置服务信息。

步骤108，S-CSCF将配置服务信息保存在本地，用于在以后的会话过程中对用户触发相关的配置服务。并给用户回成功响应。响应消息中包含该注册用户身份的隐式注册集。

步骤109～步骤110，该响应经过I-CSCF、P-CSCF传递给UE。

在用户完成注册后，PSAP就可以使用用户的标识对用户发起回叫。具体回叫流程参见图3所示，包括下列步骤：

步骤201A-1～步骤201A-2，位于PSTN的PSAP通过MGCF向用户的归属域发起呼叫，MGCF需要将PSAP发出的信令转换成SIP信令。

步骤201B，位于IP域的PSAP直接使用SIP信令向用户的归属域发起呼叫。

步骤202，用户归属网络的入口点(IBCF或者I-CSCF)在收到INVITE消息后，会对该消息进行检查，如果发现该消息来之非信任域，将删除消息中的部分字段，例如：消息的发起方身份(P-Asserted-Identity字段)。然后将消息传给I-CSCF。

步骤203，I-CSCF将发送LIR命令，从HSS获取S-CSCF的地址。

步骤204，HSS给I-CSCF返回LIA信令，包含有相关的S-CSCF名称。

步骤205，I-CSCF将INVITE消息前传给S-CSCF。

步骤206～步骤207，S-CSCF根据用户的签约信息到AS上触发相关的业务。

步骤208～步骤209，S-CSCF再通过P-CSCF将消息传递给用户。

使用紧急注册可以使用户享受很多额外的权限，比如说用户处于非签约漫游地的时候，通过紧急注册可以享受PSAP的呼叫业务。或者用户处于欠费的情况下，通过紧急注册，就可以享受PSAP的呼叫业务。这样一个恶意的用户通过发起紧急注册流程，突破了漫游和计费的限制，然后其他的用户就可以通过该用户的紧急用户标识来呼叫该用户，使得该用户享受了签约外的服务。

IMS中的实体可以使用route头域来决定后续的路由，UE在发起紧急呼叫的时候有可能在route头域中含有S-CSCF的信息，这样处理紧急呼叫的网元将请求发送给PSAP的时候，PSAP有可能会按照多余的route头域，将该请求路由到S-CSCF，从而导致呼叫失败。

发明内容

本发明提供紧急业务的收发方法及装置，用以解决用户恶意使用紧急用户标识进行紧急注册来享受越权服务的问题。

本发明还提供了一种紧急业务中呼叫接续的方法，用以解决用户恶意使用紧急用户标识进行紧急注册来享受越权服务的问题。

本发明还提供了另一种紧急业务中呼叫接续的方法，用以解决请求消息中携带了过多的route头域字段，而造成呼叫失败的问题。

本发明认证实体，位于紧急业务中回叫的发起侧网络，用于在确认收到的请求消息的发起方身份后，向被叫接续网络前转该请求消息，并使被叫接续网络获知该请求消息的发起方身份，所述发起方身份为公共安全应答点PSAP。

本发明的识别实体，位于紧急业务中回叫的被叫接续网络，包括：第一识别实体，用于识别回叫请求消息的发起方身份，并在确认发起方身份不为有效的PSAP时，直接拒绝该回叫请求消息；或者用于识别回叫请求消息的发起方身份是否为PSAP，并在判断该回叫请求消息发起方身份的有效性后进行修正。

本发明的紧急业务中发起回叫的方法，包括下列步骤：回叫发起侧在确认收到的请求消息的发起方身份后，向被叫接续网络前转该请求消息；以及使被叫接续网络获知该请求消息的发起方身份，所述发起方身份为公共安全应答点PSAP。

本发明的紧急业务中接收回叫的方法，包括下列步骤：被叫接续网络识别呼叫发起侧网络发来的回叫请求消息的发起方身份，根据发起方身份是否为有效的PSAP进行后续处理。

本发明的一种紧急业务中呼叫接续的方法，包括下列步骤：

收到用户发起的注册，识别该注册是一个紧急注册；处理主叫接续的网络收到用户发起的呼叫；当所述处理主叫接续的网络获知所述用户发起的呼叫与紧急注册相关联时，按照预设的策略相应处理该呼叫。

本发明的另一种紧急业务中呼叫接续的方法，包括下列步骤：处理主叫接续的网元收到请求消息后，对该请求消息中route头域进行有效性处理；以及

处理主叫接续的网元以处理后的请求消息接续呼叫。

本发明有益效果如下：

本发明通过识别紧急呼叫发起方的身份来防止用户享受越权服务。

进一步，本发明在紧急业务中回叫的发起侧网络中提供了认证实体，不再像现有技术那样直接前转请求消息，而是由该认证实体在确认收到的请求消息的发起方身份后，再向被叫接续网络前转该请求消息，并使被叫接续网络获知该请求消息的发起方身份。所述认证实体可位于被叫接续网络的信任域中，以使被叫接续网络信任本网络对发起方身份的认证。

进一步，本发明在紧急业务中回叫的被叫接续网络中提供了识别实体，其识别呼叫发起侧网络发来的回叫请求消息的发起方身份，以及根据发起方身份是否为有效的PSAP进行后续处理。进而有效的防止了用户享受越权服务。应用上述实体，本发明还提供了对应的发起及接收紧急业务中回叫的方法。

本发明还提供了一种实现紧急呼叫业务的方法，其中处理呼叫接续的设备不像现有技术那样直接处理收到的呼叫请求，而是查询该呼叫的关联信息；当处理主叫接续的网络获知所述用户发起与紧急注册相关联的呼叫时，按照预设的策略相应处理该呼叫。从而有效的防止了用户享受越权服务。本发明还提供了另一种紧急业务中呼叫接续的方法，其中处理主叫接续的网元收到请求消息后，对该请求消息中route头域进行有效性处理；之后处理主叫接续的网元以处理后的请求消息接续呼叫。通过本发明方法，若请求消息中携带了过多的route头域字段，也会被处理主叫接续的网元处理掉，从而保证呼叫接续的成功率。

附图说明

图1为IMS域的紧急呼叫的流程框架图；

图2为现有的紧急注册流程图；

图3为现有回叫流程图；

图4为本发明的紧急业务中发起回叫的方法步骤流程图；

图5为本发明的识别实体实施例二的结构示意图；

图6为本发明的识别实体实施例三的结构示意图；

图7为本发明的紧急业务中接收回叫的方法步骤流程图；

图8为结合本发明发送、接收紧急业务中回叫的方法实例1的信令流程图；

图9为结合本发明发送、接收紧急业务中回叫的方法实例2的信令流程图；

图10为结合本发明发送、接收紧急业务中回叫的方法实例3的信令流程图；

图11为结合本发明发送、接收紧急业务中回叫的方法实例4的信令流程图；

图12为本发明紧急业务中呼叫接续的方法步骤流程图；

图13为本发明紧急业务中呼叫接续的方法实例1的信令流程图；

图14为本发明紧急业务中呼叫接续的方法实例2的信令流程图；

图15为本发明紧急业务中呼叫接续的方法实例3的信令流程图；

图16为本发明紧急业务中呼叫接续的方法实例4的信令流程图；

图17为本发明紧急业务中呼叫接续的方法实例5的信令流程图；

图18为本发明紧急业务中呼叫接续的方法实例6的信令流程图；

图19为本发明另一种紧急业务中呼叫接续的方法步骤流程图；

图20为本发明另一种紧急业务中呼叫接续的方法实例1的信令流程图；

图21为本发明另一种紧急业务中呼叫接续的方法实例2的信令流程图。

具体实施方式

为了防止用户恶意使用紧急用户标识进行紧急注册来享受越权服务。进一步为了在紧急业务中回叫的发起侧网络及方法中增加确认发起方身份的机制，进而解决被叫侧无法获知发起方真实身份的问题，本发明的认证实体以及紧急业务中发起回叫的方法的主要思想是：在收到呼叫紧急用户标识的请求时，发起侧网络需要对消息发起方的身份进行确认，如果发起方为PSAP，那么就按回叫流程处理这个请求；如果发起方身份不能确认为PSAP，那么可以直接拒绝该请求，或者根据本地策略(例如当用户处于非签约漫游地，欠费或其它正常情况下不允许享受服务的时候才拒绝请求)来拒绝该请求。进一步考虑到漫游的情况，PSAP的位置非常分散，可以在漫游地选择一个被叫用户归属地的直接或间接的信任域对PSAP的身份进行确认，同时通过该信任域将呼叫请求发送到被叫用户归属地，因此该信任域要保证所发出的回叫是合法的，从而被叫的归属域可以确认发起方的身份。

本发明的认证实体其可位于S-CSCF、P-CSCF、MGCF、IBCF、E-CSCF或I-CSCF中；或者与S-CSCF、P-CSCF、MGCF、IBCF、E-CSCF或I-CSCF存在接口，且相互独立。用于在确认收到的请求消息的发起方身份后，向被叫接续网络前转该请求消息，并使被叫接续网络获知该请求消息的发起方身份。

根据所述认证实体收到的请求消息的发起方身份是否已被标识为PSAP，存在以下两种处理方式。

情况一：所述认证实体收到的请求消息中携带有PSAP指示，或者收到的请求消息通过特定的IP联系方式发来，即收到的请求消息的发起方身份被标识为PSAP时，由认证实体在确认该请求消息发起方的身份后对该标识进行修正，若确认发起方为PSAP，则认定该标识，再直接或通过特定的IP联系方式向被叫接续网络发送；否则直接拒绝所述请求消息，或者，删除该请求消息中携带的指示或通过非特定的IP联系方式向被叫接续网络发送。从而使被叫接续网络获知该请求消息的发起方身份。

情况二：所述认证实体收到的请求消息中未携带PSAP指示，或者收到的请求消息通过非特定的IP联系方式发来，即收到的请求消息的发起方身份未被标识为PSAP时，由认证实体在确认该请求消息发起方的身份后，进行相应处理；若确认发起方为PSAP，则为该请求消息增加PSAP指示或使用特定的IP联系方式向被叫接续网络发送；若确认发起方不为PSAP，则直接拒绝该请求消息，或者，将该请求消息直接或通过非特定的IP联系方式向被叫接续网络发送。从而使被叫接续网络获知该请求消息的发起方身份。

所述认证实体若位于被叫接续网络的信任域中，则可使被叫接续网络信任并接受该认证实体对发起方身份的认证，以达到更好的防止用户享受越权服务的效果。

应用上述认证实体，本发明还提供了一种紧急业务中发起回叫的方法，参见图4所示，包括下列主要步骤：

S1-1、回叫发起侧收到请求消息。

回叫发起侧收到的请求消息存在以下两种情况。

情况一：收到的请求消息中携带有PSAP指示，或者特定的头域值，或者收到的请求消息通过特定的IP联系方式发来，即收到的请求消息的发起方身份被标识为PSAP。

情况二：收到的请求消息中未携带PSAP指示，或者收到的请求消息通过非特定的IP联系方式发来，即收到的请求消息的发起方身份未被标识为PSAP。

S1-2、回叫发起侧确认收到的请求消息的发起方身份。

回叫发起侧可为被叫接续网络的直接或者间接信任域，以使被叫接续网络信任并接受回叫发起侧对发起方身份的认证。所述信任域的某个网元从消息的发起方身份P-Asserted-Identity字段中可以获知发起方的真实身份。

S1-3、向被叫接续网络前转该请求消息同时告知该请求消息的发起方身份。

对应步骤S1-1中的两种情况，本步骤中回叫发起侧前转并同时告知该请求消息的发起方身份的过程也存在两种情况。

对应步骤S1-1中的情况一：回叫发起侧确认请求消息发起方的身份后对该标识进行修正，若确认发起方为PSAP，则认定该标识，再直接或通过特定的IP联系方式向被叫接续网络发送；否则直接拒绝所述请求消息，或者，删除该请求消息中携带的指示、头域值或通过非特定的IP联系方式向被叫接续网络发送。

对应步骤S1-1中的情况二：回叫发起侧确认该请求消息发起方的身份后，进行相应处理；若确认发起方为PSAP，则为该请求消息增加PSAP指示或使用特定的IP联系方式向被叫接续网络发送；若确认发起方不为PSAP，则直接拒绝该请求消息，或者，将该请求消息直接或通过非特定的IP联系方式向被叫接续网络发送。从而使被叫接续网络获知该请求消息的发起方身份。

至此本发明的认证实体以及紧急业务中发起回叫的方法的描述完毕。

为了防止用户恶意使用紧急用户标识进行紧急注册来享受越权服务。进一步为了在紧急业务中回叫的被叫接续网络及方法中增加识别收到的回叫请求消息的发起方PSAP身份的机制，进而相应处理回叫请求消息，本发明的识别实体以及紧急业务中接收回叫的方法的主要思想是：被叫接续网络收到回叫请求后，首先识别该回叫请求消息的发起方身份是否被识别为PSAP，若是，则需要对该回叫请求消息发起方身份的有效性进行修正，再相应处理该回叫请求消息；否则，可直接进行后续处理。

本发明的识别实体，用于识别呼叫发起侧网络发来的回叫请求消息的发起方身份，以及根据发起方身份是否为有效的PSAP进行后续处理。

被叫接续网络实施例一、所述识别实体中至少包括：第一识别实体，用于识别呼叫发起侧网络发来的回叫请求消息的发起方身份，并在确认发起方身份不为有效的PSAP时，直接拒绝该回叫请求消息。

被叫接续网络实施例二、参见图5所示，所述识别实体中包括：相互连接的第一识别实体和第二识别实体，并且第一识别实体先于第二识别实体处理被叫请求消息。所述第一识别实体与第二识别实体合设，或者分别设置。若所述第二识别实体位于HSS、I-CSCF、S-CSCF、P-CSCF或AS中，或者与所述HSS、I-CSCF、S-CSCF、P-CSCF或AS存在接口且相互独立，则所述第一识别实体与第二识别实体分别设置。若所述第二识别实体位于IBCF、I-CSCF中，或者与所述IBCF、I-CSCF存在接口且相互独立，则所述第一识别实体与第二识别实体合设。

所述第一识别实体，用于识别呼叫发起侧网络发来的回叫请求消息的发起方身份是否为PSAP，并在判断该回叫请求消息发起方身份的有效性后进行修正(所述修正操作包括但不限于：删除标识，通过非特定的IP联系方式转发，标识该回叫请求消息的发起方身份无效)。

其中，第一识别实体收到从信任域发来的回叫请求消息后，根据该回叫请求消息中携带的指示，或者特定的头域值，或者根据所述回叫请求消息通过特定的IP联系方式发来识别该回叫请求消息发起方是否为有效的PSAP(也可通过数字签名等方式确定该回叫请求消息的有效性)。若第一识别实体判断确认所述回叫请求消息发起方PSAP身份的有效性，则确认该回叫请求的发起方PSAP身份；否则，否定该回叫请求消息发起方身份的有效性。第一识别实体否定回叫请求消息发起方身份的有效性后，进行的处理的方式包括下列之一：若所述回叫请求消息中携带有指示或者头域值标识该回叫请求消息的发起方身份为PSAP的指示，则删除该指示或者头域值；若所述回叫请求消息中携带有指示或者头域值标识该回叫请求消息的发起方身份为PSAP的指示，则通过非特定的IP联系方式转发该回叫请求消息；若所述回叫请求消息通过特定的IP联系方式发来，则标识该回叫请求消息的发起方身份不为有效的PSAP；若所述回叫请求消息通过特定的IP联系方式发来，则通过非特定的IP联系方式转发该回叫请求消息。

所述第二识别实体，用于在收到回叫请求消息(包括所述第一识别实体修正后的回叫请求消息，以及发起侧网络发来的发起方身份未被标识为PSAP的回叫请求消息)后，识别回叫请求消息的发起方身份，并相应处理该回叫请求消息。若第二识别实体识别出收到的回叫请求消息的发起方身份为PSAP，则直接继续提供呼叫服务。若第二识别实体识别出收到的回叫请求消息的发起方身份不为PSAP，则直接拒绝该请求消息或者根据用户状态处理所述回叫请求消息。

被叫接续网络实施例三、所述识别实体中包括：相互连接的第一识别实体和第二识别实体，并且第一识别实体先于第二识别实体处理被叫请求消息。所述第一识别实体和第二识别实体的位置及功能与被叫接续网络实施例二相同。若第二识别实体根据用户状态处理所述回叫请求消息，并且第二识别实体中未存储用户当前状态信息(例如：第二识别实体未置于HSS中)，则参见图6所示，所述网络还包括用户状态获取装置，其用于与存储有用户当前状态信息的网元交互，以获取用户当前状态，并将获取的信息发送给第二识别实体。若所述用户状态获取装置位于S-CSCF中，则扩展S-CSCF与HSS之间的接口，在用户注册时，HSS将用户的状态信息通知S-CSCF，以使用户状态获取装置获得用户的状态信息。若所述用户状态获取装置位于AS中，则扩展AS与HSS之间的Sh接口，通过Sh接口从HSS获取用户的状态信息。

应用上述识别实体，本发明还提供了一种紧急业务中接收回叫的方法，参见图7所示，包括下列主要步骤：

S2-1、被叫接续网络识别呼叫发起侧网络发来的回叫请求消息的发起方身份。

被叫接续网络识别出呼叫发起侧网络发来的回叫请求消息中携带有指示，特定头域值，或者识别出所述回叫请求消息通过特定的IP联系方式发来，则识别该回叫请求消息的发起方身份为PSAP；否则认为该回叫请求消息的发起方身份不为PSAP。

S2-2、根据发起方身份是否为有效的PSAP进行后续处理。

若发起方身份被标识为PSAP，则被叫接续网络判断发起方身份被识别为PSAP的回叫请求消息是否来自本网络的信任域，或者其特定指示、头域值是否为可信网元添加，以确定该回叫请求消息的有效性。

进一步，若确认所述回叫请求消息发起方PSAP身份的有效性，则确认该回叫请求的发起方身份；否则，被叫接续网络确认所述回叫请求消息的发起方身份不为有效的PSAP，直接拒绝该回叫请求消息；或者对该回叫请求消息进行修正。被叫接续网络确认所述回叫请求消息的发起方身份不为有效的PSAP时，对该回叫请求消息进行修正的方式，包括下列之一：若所述回叫请求消息中携带有指示或者头域值标识该回叫请求消息的发起方身份为PSAP的指示，则删除该指示或者头域值；若所述回叫请求消息中携带有指示或者头域值标识该回叫请求消息的发起方身份为PSAP的指示，则通过非特定的IP联系方式转发该回叫请求消息；若所述回叫请求消息通过特定的IP联系方式发来，则标识该回叫请求消息的发起方身份不为有效的PSAP；若所述回叫请求消息通过特定的IP联系方式发来，则通过非特定的IP联系方式转发该回叫请求消息。对所述回叫请求消息进行修正之后，再次识别修正后的回叫请求消息，在识别出修正后的回叫请求消息的发起方身份为PSAP时，直接指示提供呼叫服务。在识别出修正后的回叫请求消息的发起方身份不为PSAP时，则可直接拒绝回叫请求；或者获取并根据用户当前状态处理所述回叫请求消息。

若发起方身份未被标识为PSAP，则在识别出收到的回叫请求消息的发起方身份为PSAP时，直接指示提供呼叫服务。在识别出收到的回叫请求消息的发起方身份不为PSAP时，则可直接拒绝回叫请求；或者获取并根据用户当前状态处理所述回叫请求消息。

至此本发明的识别实体以及紧急业务中接收回叫的方法的描述完毕。

以下结合上述发送、接收紧急业务中回叫的方法及网络，通过四个实例具体描述。

实例1-回叫流程：位于IP域的PSAP使用漫游地的S-CSCF作为代理，使用在SIP消息中增加指示的方法标明主叫PSAP身份，在AS进行策略检查。参见图8所示，包括下列步骤：

步骤300，需要为紧急用户标识配置一条服务规则，该规则必须保证在紧急用户标识作为被叫时，需要到指定的AS上进行策略检查。而该AS能获取到策略相关信息，例如用户是否处于非签约的漫游地，用户是否欠费。这些消息可以通过Sh接口从HSS等相关网元获得。如果策略为仅允许PSAP呼叫紧急用户标识，那么AS就不用去获取用户信息。

步骤301，位于IP域的PSAP呼叫被叫用户，发送时可以在SIP消息中增加指示，通过该指示表明这是一个合法的PSAP回叫。具体的指示可以是一个头域，例如“P-Caller-Category:PSAP”、“Priority:emergency”、“P-Asserted-Identity:″PSAP″<tel:+911>”，“P-Asserted-Identity:″PSAP″<urn:service:sos>”等；也可以是头域的参数，例如“INVITEsip:hw@home1.net；fromPSAP SIP/2.0”等。PSAP将携带了指示的请求发送给能够对其进行身份确认的，同时又属于被叫用户归属域的直接或间接的信任域中的某个实体，这里使用的是PSAP所在地的和被叫用户归属域有信任关系的某个S-CSCF。

步骤302，S-CSCF对PSAP的身份进行确认，如果确定为PSAP，那么就将该请求前传到被叫用户的归属域；如果不能确认为PSAP，那么，S-CSCF将删除INVITE消息中可能存在的假冒的指示，再将该请求前传到被叫用户的归属域，或直接拒绝这个请求。

步骤303，归属域的入口点IBCG收到了INVITE请求，如果发现该请求来自不信任域同时携带了可以表明是回叫的指示，那么IBCF将删除请求中的指示后，将请求传递给I-CSCF，IBCF也可直接拒绝该请求。如果是从信任域来的，就可直接前传该请求到I-CSCF。

步骤304，I-CSCF向HSS发送LIR消息去获取用户当前所在的S-CSCF。

步骤305，HSS返回LIA携带S-CSCF名称。

步骤306，I-CSCF将请求发送给S-CSCF。

步骤307，S-CSCF根据用户的签约信息，到相关的AS去触发服务。

步骤308，AS收到了INVITE消息将检查消息中是否包含了指示表明这是一个合法的PSAP回叫。如果有，则前传该请求，如果没有则根据策略(直接拒绝，或者是用户正处于正常情况下不允许享受服务的状态时才拒绝)决定是否拒绝该请求。

步骤309～步骤310，S-CSCF通过P-CSCF将请求发送给UE。

实例2-回叫流程：位于IP域的PSAP使用漫游地的MGCF作为代理呼叫用户，使用特定的IP联系方式表明这是一个回叫，IP联系方式是指IP地址，端口，IPSEC的SPI，GRE隧道标识；或其它IP层上的通信协议标识会话的标志，也可以是以上的组合，在I-CSCF或HSS进行策略检查。参见图9所示，包括下列步骤：

步骤401，位于IP域的PSAP呼叫被叫用户。PSAP将请求发送给能够对其进行身份确认的，同时又属于被叫用户归属域的直接或间接的信任域中的某个实体，这里使用的是PSAP所在地的和被叫用户归属域有信任关系的某个MGCF。

步骤402，MGCF对PSAP的身份进行确认，如果确定为PSAP，那么就将该请求前传到被叫用户的归属域的特定的入口点IP联系方式，例如一个特定的端口；如果不能确认为PSAP，那么，MGCF将该请求前传到被叫用户的归属域的普通入口点IP联系方式，或直接拒绝该请求。

步骤403，归属域的入口点I-CSCF收到了INVITE请求后，如果该INVITE消息是从特定的入口点IP联系方式接收的，将判断该请求是否来自信任域，如果消息来自信任域，I-CSCF将向HSS发出查询S-CSCF的请求LIR消息，LIR中携带指示标明该LIR消息是由一个合法的回叫所触发的。否则I-CSCF可以拒绝该INVITE消息，或者向HSS发送查询的LIR消息中不标明该LIR消息是由一个合法PSAP回叫所触发的。

步骤404，收到LIR消息后，HSS将检查LIR消息是否有指示标明这是一个合法的回叫所触发的，如果LIR有指示标明这是一个合法的PSAP回叫所触发的，HSS将给I-CSCF回成功LIA消息；如果没有，根据本地的策略给I-CSCF回响应。步骤403，404的流程也可以改成由HSS通过LIA给I-CSCF下指示，让I-CSCF检查会话消息的发起方是否是一个合法PSAP，I-CSCF如果能够确认发起方是一个合法的PSAP，将正常处理后续流程；否则I-CSCF将拒绝该请求。

步骤405～407，I-CSCF将请求前传给S-CSCF，S-CSCF根据用户配置触发相关的业务。

步骤408～步骤409，S-CSCF通过P-CSCF将请求发送给UE。

实例3-回叫流程：位于PSTN域的PSAP使用漫游地的MGCF接入IMS域，使用在SIP消息中携带指示来标明是合法的PSAP回叫，在S-CSCF进行策略检查。参见图10所示，包括下列步骤：

步骤500(可选)，S-CSCF获取用户的状态信息，例如用户是否处于非签约漫游地，用户是否欠费等。该信息可以在用户注册的时候通过HSS通知S-CSCF。

步骤501，位于PSTN域的PSAP通过漫游地的MGCF接入IMS。

步骤502，假设本MGCF处于被叫用户归属域的信任域，MGCF对PSAP的身份进行确认，如果确定为PSAP，则在SIP消息中增加指示表明这是一个合法PSAP的回叫。具体的指示可以是一个头域，例如“P-Caller-Category:PSAP”、“Priority:emergency”、“P-Asserted-Identity:″PSAP″<tel:+911>”，“P-Asserted-Identity:″PSAP″<urn:service:sos>”等；也可以是头域的参数，例如“INVITE sip:hw@home1.net；fromPSAP SIP/2.0”等，然后将该请求发送到被叫的归属域。如果MGCF不属于被叫用户的归属域的信任域，MGCF将该请求发送给能够对PSAP进行身份确认，同时又属于被叫用户归属域的直接或间接的信任域中的某个实体，由该实体将携带了表明为回叫的指示的请求消息发送到被叫的归属域。

步骤503，归属域的入口点I-CSCF收到了INVITE请求后，向HSS发送LIR请求查询S-CSCF。

步骤504，HSS通过LIA返回S-CSCF名称。

步骤505，I-CSCF将请求前传给S-CSCF，如果该INVITE是来自非信任域，I-CSCF将删除其中的表明该请求为回叫的指示。该指示的删除也可以在I-CSCF收到INVITE请求时。

步骤506，S-CSCF收到INVITE消息后，如果该请求为合法PSAP的回叫，S-CSCF将根据用户配置去AS触发签约服务。如果不能确认为合法PSAP的回叫，S-CSCF将根据策略处理该请求。如果策略为仅允许PSAP回叫紧急标识，S-CSCF将拒绝该请求；如果策略为用户处于正常情况下不能享受服务的状态时才拒绝该请求，那么S-CSCF将根据获取到的用户的状态信息决定是否拒绝该请求。

步骤507，AS给S-CSCF返回INVITE请求。

步骤508～509，S-CSCF将请求消息通过P-CSCF发送给UE。

实例4，回叫流程：P-CSCF根据回叫请求消息中的p-asserted-idenity头域值来识别PSAP的有效性，并拒绝不可信的PSAP，参见图11所示，包括下列步骤：

步骤600，在P-CSCF设置一些特定的sip或/和tel值为合法的PSAP用户身份，同时设定PSTN域的PSAP发出的呼叫都从拜访地的MGCF接入IMS网络。

步骤601～602，PSAP发起回叫请求，该请求通过I-CSCF前传到S-CSCF。

步骤603，S-CSCF将请求前传到P-CSCF，P-CSCF根据P-Asserted-Identity所标识的用户身份“+86-755-28880119”，和预设的值进行比较，如果包含在预设的值之中，那么就确认该呼叫是一个合法回叫，否则就拒绝该请求。

步骤604，P-CSCF将可信的呼叫请求发送给UE。

为了防止用户恶意使用紧急用户标识进行紧急注册来享受越权服务。进一步为了在现有实现紧急呼叫业务的方法中增加识别和屏蔽用户以紧急用户标识发起呼叫请求的策略，本发明还提供了一种紧急业务中呼叫接续的方法，参见图12所示，包括下列主要步骤：

S3-1、处理呼叫接续的网络收到呼叫请求。

处理主叫接续的设备包括：P-CSCF、IBCF、I-CSCF、S-CSCF、AS，以及HSS。

S3-2、处理主叫接续的网络获知所述用户发起与紧急注册相关联的呼叫(可能包括其隐式注册集中的用户标识，也可以不包括其隐式注册集中的用户标识)，则转入步骤S3-3。

S3-3、按照预设的策略相应处理该呼叫。

所属预设的策略包括：

●直接拒绝该呼叫；

●用户是否处于非签约漫游地，用户是否欠费等，例如：当用户处于非签约漫游地且欠费才拒绝该呼叫。

对应步骤S3-1中的具体处理呼叫接续的设备：

所述处理呼叫接续的设备为P-CSCF，收到用户发起的与紧急注册相关的呼叫(可以包含其隐式注册集中的用户标识，也可以不包含隐式注册集中的用户标识)，且该呼叫不是紧急呼叫请求，则直接拒绝该请求。或者，P-CSCF收到用户发起的呼叫为紧急注册相关(可以包含其隐式注册集中的用户标识，也可以不包含隐式注册集中的用户标识)的请求，将该请求发送给E-CSCF：处理主叫接续的P-CSCF在发往E-CSCF的请求消息中的route头域中只携带该E-CSCF的相关信息；或者，E-CSCF收到请求消息后，清空请求消息中的route头域；或者，E-CSCF在转发请求消息时，在该请求消息中的route头域只携带下一跳的相关信息。在后续处理中，如果处理实体(该实体可以是E-CSCF，LRF或者PSAP)获知该请求不是紧急呼叫请求，则拒绝该请求。

上述P-CSCF作为处理呼叫接续设备的两种情况中，P-CSCF识别呼叫请求与紧急注册相关(可以包含其隐式注册集中的用户标识，也可以不包含隐式注册集中的用户标识)的方法为：根据呼叫请求中所使用的用户身份或者该用户身份的隐式注册集中的用户身份标识的字符特征，例如用户身份中含有特殊的“SOS”字段，则认为该呼叫请求与紧急注册相关(可以包含其隐式注册集中的用户标识，也可以不包含隐式注册集中的用户标识)；或者，注册时，P-CSCF根据注册成功的用户身份的字符特征，例如注册请求消息所使用的用户身份中含有特殊的“SOS”字段，认为所有和该注册相关的呼叫请求与紧急注册相关(可以包含其隐式注册集中的用户标识，也可以不包含隐式注册集中的用户标识)；又或者在注册时，P-CSCF通过注册响应消息中的某个特征指示，例如在响应消息中不携带service-route头域，或者响应消息中的携带的注册成功的隐式注册集中有包含一定字符特征的用户身份标识，则P-CSCF认为所有和该注册相关的呼叫请求与紧急注册相关(可以包含其隐式注册集中的用户标识，也可以不包含隐式注册集中的用户标识)；又或者在注册时，P-CSCF根据注册请求中的指示，直接识别该注册为紧急注册，P-CSCF识别所有与该注册相关的请求都与紧急注册相关(可以包含其隐式注册集中的用户标识，也可以不包含隐式注册集中的用户标识)。

所述处理呼叫接续的设备为HSS、IBCF或I-CSCF，则HSS、IBCF或I-CSCF，收到用户发起的呼叫与紧急注册相关，则直接拒绝该请求。S-CSCF识别呼叫请求与紧急注册相关(可以包含其隐式注册集中的用户标识，也可以不包含隐式注册集中的用户标识)的方法为：直接根据呼叫请求中所使用的用户身份的字符特征或者检查出该用户标识的隐式注册集中的用户身份标识的字符特征，例如所使用的用户身份中含有特殊的“SOS”字段，则认为该呼叫请求与紧急注册相关(可以包含其隐式注册集中的用户标识，也可以不包含隐式注册集中的用户标识)；或者，注册时，S-CSCF根据注册所使用的用户身份的字符特征、头域，或参数等，例如所使用的用户身份中含有特殊的“SOS”字段，认为所有和该注册相关的呼叫请求与紧急注册相关(可以包含其隐式注册集中的用户标识，也可以不包含隐式注册集中的用户标识)；又或者在注册时，通过HSS下发的指示，获知所有和该注册相关的呼叫请求与紧急注册相关(可以包含其隐式注册集中的用户标识，也可以不包含隐式注册集中的用户标识)。

所述处理呼叫接续的设备为S-CSCF，则S-CSCF根据用户所使用的紧急用户标识直接拒绝该呼叫；或者，根据指示拒绝该呼叫。S-CSCF获取指示的途径为：如果用户使用紧急注册，HSS根据策略传递指示给S-CSCF；根据该指示，S-CSCF会拒绝该用户发起的呼叫；所述指示传递策略包括在任何时候都传递指示，或者只是当用户处于越权的时候才传递(用户处于非签约漫游地，用户欠费时)。

所述处理呼叫接续的设备为AS，则AS直接拒绝该呼叫；所述主叫呼叫接续的网络中针对紧急注册相关联的呼叫创建iFC，HSS根据策略下发该iFC给S-CSCF，其策略为任何时候下发，或者是用户越权时才下发；根据该iFC，S-CSCF会将使用紧急用户标识的主叫请求前传到指定的AS，该AS直接拒绝该请求。

或者，所述处理呼叫接续的设备为AS，如果用户使用紧急注册，HSS根据策略传递指示给AS，根据该指示，AS会拒绝该用户发起的呼叫；所述指示传递策略包括在任何时候下发，或者只是用户处于越权时才下发。

本发明还提供了一种紧急业务中呼叫接续的方法实施例，包括：

处理主叫接续的网络收到用户发起的呼叫时，查询该呼叫的关联信息；当处理主叫接续的网络从所述关联信息中获知所述用户发起与紧急注册相关联的呼叫时，按照预设的策略相应处理该呼叫。

以下通过6个实例具体描述上述紧急业务中呼叫接续的方法。

实例1-主叫流程：用户使用紧急用户标识发起主叫流程。参见图13所示，包括下列步骤：

步骤600(可选)，用户使用“user@sos.company.com”的紧急用户标识发送注册请求，S-CSCF获取针对紧急用户标识进行主叫拒绝的指示，该指示可以在用户注册的时候通过HSS通知S-CSCF，也可以通过注册所使用的用户标识的特征来获取。或者AS获取针对紧急用户标识进行主叫拒绝的指示，该指示可以通过Sh接口从HSS获得。

步骤601～602，P-CSCF将用户发起的所有非紧急的INVITE消息发送给S-CSCF，S-CSCF根据指示，或者直接根据紧急用户标识中的“SOS”字段，可以拒绝该请求，或者根据iFC将该请求前传到指定的AS。

步骤603，AS收到主叫请求后，可以根据指示或者直接拒绝该请求。

实例2-主叫流程：用户使用紧急用户标识发起主叫流程，P-CSCF进行拒绝。参见图14所示，包括下列步骤：

步骤701～702，UE使用“user@sos.company.com”的紧急用户标识发送注册请求，P-CSCF根据用户标识中的sos字段识别出是一个紧急用户标识的紧急注册，将请求消息前传给S-CSCF。

步骤703～704，S-CSCF返回注册成功的响应消息，响应消息中包含有“user@sos.company.com”所在的隐式注册集，P-CSCF将响应消息前传给UE。

步骤705，UE发起一个非紧急的呼叫。

步骤706，P-CSCF判断出该UE发起的为非紧急呼叫，同时该呼叫是和紧急注册相关联的，则拒绝该请求。

实例3-主叫流程：用户使用紧急用户标识发起主叫流程，E-CSCF进行拒绝。参见图15所示，包括下列步骤：

步骤801～802，UE使用“user@sos.company.com”的紧急用户标识发送注册请求，P-CSCF将请求消息前传给S-CSCF。

步骤803～804，S-CSCF返回注册成功的响应消息，响应消息中没有包含service-route头域，P-CSCF检查响应消息中不包含service-route头域，则P-CSCF获知该注册只能发起紧急呼叫。P-CSCF将响应消息前传给UE。

步骤805，UE发起一个非紧急的呼叫。

步骤806，因为该呼叫是和上面的注册是关联的，因此PCSCF将该UE发起的所有呼叫请求直接前传给E-CSCF。在转发消息前，PCSCF设置请求中route头域中仅包含ECSCF的信息。

步骤807，E-CSCF根据被叫方字段，识别出该呼叫不是紧急呼叫，则拒绝该请求。

实例4-主叫流程：用户使用紧急用户标识发起主叫流程，E-CSCF根据LRF的响应进行拒绝。参见图16所示，包括下列步骤：

步骤801～802，UE发送携带了“priority:emergency”特征头域的请求进行注册，P-CSCF将请求消息前传给S-CSCF。

步骤803～804，S-CSCF返回注册成功的响应消息，P-CSCF根据请求消息中的特征指示“priority:emergency”识别该注册是一个紧急注册。P-CSCF将响应消息前传给UE。

步骤805，UE发起一个非紧急的呼叫。

步骤806，因为该呼叫是和上面的注册是关联的，因此PCSCF将该UE发起的所有呼叫请求直接前传给E-CSCF。

步骤807～808，E-CSCF将被叫方字段和位置信息通过Lost协议发送给LRF，LRF识别出该呼叫被叫方不是紧急业务，LRF将返回失败响应。

步骤809，E-CSCF根据LRF的响应，拒绝该呼叫请求。

实例5-主叫流程：用户使用紧急用户标识发起主叫流程，PSAP进行拒绝。参见图17所示，包括下列步骤：

步骤801～802，UE使用“user@sos.company.com”的紧急用户标识发送注册请求，P-CSCF将请求消息前传给S-CSCF 。

步骤803～804，S-CSCF返回注册成功的响应消息，响应消息中返回的隐式注册集中包含user@sos.company.com，P-CSCF检查到该用户身份中的“SOS”字段，则P-CSCF获知该注册只能发起紧急呼叫。P-CSCF将响应消息前传给UE。

步骤805，UE发起一个非紧急的呼叫。

步骤806，因为该呼叫是和上面的注册是关联的，因此PCSCF将该UE发起的所有呼叫请求直接前传给E-CSCF。

步骤807，E-CSCF收到请求后，清空其route头域中的值，在前传前，加入下一跳的信息。E-CSCF根据本地配置将呼叫前传给PSAP。

步骤808，PSAP根据被叫方字段发现该请求不是一个紧急业务请求，将拒绝该请求。

实例6-主叫流程：用户使用紧急用户标识发起主叫流程，S-CSCF进行拒绝。参见图18所示，包括下列步骤：

步骤901～902，UE使用“user@sos.company.com”的紧急用户标识发送注册请求，P-CSCF将请求消息前传给S-CSCF。

步骤903～904，S-CSCF检查到注册的用户身份标识中的“SOS”字段，则认为这是一个紧急注册。S-CSCF返回注册成功的响应消息，P-CSCF将响应消息前传给UE。

步骤905～906，UE发起一个呼叫。

步骤906，P-CSCF识别出该呼叫如果不是紧急呼叫，则P-CSCF按照正常呼叫的处理，将请求消息传给S-CSCF。

步骤906a～907a，P-CSCF识别出该呼叫是紧急呼叫，那么设置请求消息中的route头域只包含E-CSCF的地址，将消息前传给E-CSCF；或者P-CSCF识别出是紧急呼叫后，将该请求直接前传给E-CSCF，E-CSCF在收到请求后，清空请求消息中的route头域再进行后续处理。

步骤907，S-CSCF判断出该请求是紧急注册相关联的，即用户是使用紧急用户身份发起的呼叫，则拒绝该请求。

有时UE在发起紧急呼叫的时候，可能会在route头域中携带S-CSCF的信息，为了防止携带了过多的route头域字段，而造成呼叫的失败，可以在P-CSCF或者E-CSCF在处理呼叫时，保证route头域的合理性。本发明又提供了一种紧急业务中呼叫接续的方法，参见图19所示，包括下列主要步骤：

S4-1、处理主叫接续的网元收到请求消息。

S4-2、处理主叫接续的网元对该请求消息中route头域进行有效性处理。

对应处理主叫接续的网元及有效性处理方式的不同，存在三种情况：处理主叫接续的P-CSCF在发往E-CSCF的请求消息中的route头域只携带该E-CSCF的相关信息；或者，E-CSCF收到请求消息后，清空请求消息中的route头域；或者，E-CSCF在转发请求消息时，在该请求消息中的route头域只携带下一跳的相关信息。

S4-3、处理主叫接续的网元以处理后的请求消息接续呼叫。

以下通过两个方法实例具体描述：

实例1-主叫流程：用户发起紧急呼叫，P-CSCF保证route头域的合理性。参见图20所示，包括下列步骤：

步骤1001，UE发起一个紧急呼叫，请求消息中携带的route头域为：“route:<sip:pcscf.home.com；lr>，<sip:scscf.home.com；lr>”。

步骤1002，P-CSCF在收到请求后，需要移除route头域中的<sip:pcscf.home.com；lr>，P-CSCF在识别是紧急呼叫后需要删除多余的<sip:scscf.home.com；lr>，在前转请求前，P-CSCF需要再请求消息中增加E-CSCF的信息，这样发出的消息的route头域为“route:<sip:ecscf.home.com>”。

步骤1003～1006，紧急呼叫的后续正常处理。

实例2-主叫流程：用户发起紧急呼叫，E-CSCF保证route头域的合理性。参见图21所示，包括下列步骤：

步骤1101，UE发起一个紧急呼叫，请求消息中携带的route头域为：“route:<sip:pcscf.home.com；lr>，<sip:scscf.home.com；lr>”。

步骤1102，P-CSCF在收到请求后，需要移除route头域中的<sip:pcscf.home.com；lr>，P-CSCF在识别是紧急呼叫后在route头域的最顶端加上<sip:ecscf.home.com；lr>后，将请求前转到E-CSCF。这样发出的消息的route头域为“route:<sip:ecscf.home.com>，<sip:scscf.home.com；lr>”。

步骤1103，E-CSCF收到请求后，删除route头域中的<sip:ecscf.home.com>和sip:scscf.home.com；lr>，在前传消息时，加上下一跳的地址信息。这样发出的消息route头域为“route:<sip:psap@home.com>”。

步骤1104～1106，紧急呼叫的后续正常处理。

显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样，倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。

Claims (36)

1、一种认证实体，位于紧急业务中回叫的发起侧网络，其特征在于，所述认证实体，用于在确认收到的请求消息的发起方身份后，向被叫接续网络前转该请求消息，并使被叫接续网络获知该请求消息的发起方身份，所述发起方身份为公共安全应答点PSAP。

2、如权利要求1所述的实体，其特征在于，通过SIP消息携带指示，或者通过特定的IP联系方式标识请求消息的发起方身份为公共安全应答点PSAP。

3、如权利要求2所述的实体，其特征在于，所述认证实体收到的请求消息的发起方身份被标识为PSAP时，由认证实体在确认该请求消息发起方的身份后对该标识进行修正，若确认发起方为PSAP，则认定该标识，再向被叫接续网络发送；否则直接拒绝所述请求消息，或者，删除该请求消息中携带的指示或通过非特定的IP联系方式向被叫接续网络发送。

4、如权利要求2所述的实体，其特征在于，所述认证实体收到的请求消息的发起方身份未被标识为PSAP时，由认证实体在确认该请求消息发起方的身份后，进行相应处理；若确认发起方为PSAP，则为该请求消息增加指示或使用特定的IP联系方式向被叫接续网络发送；若确认发起方不为PSAP，则直接拒绝该请求消息，或者，将该请求消息直接或通过非特定的IP联系方式向被叫接续网络发送。

5、如权利要求1至4任一项所述的实体，其特征在于，所述认证实体位于被叫接续网络的信任域中。

6、一种识别实体，位于紧急业务中回叫的被叫接续网络，其特征在于，所述识别实体包括：

第一识别实体，用于识别回叫请求消息的发起方身份，并在确认发起方身份不为有效的PSAP时，直接拒绝该回叫请求消息；或者

用于识别回叫请求消息的发起方身份是否为PSAP，并在判断该回叫请求消息发起方身份的有效性后进行修正。

7、如权利要求6所述的实体，其特征在于，当所述第一识别实体用于识别回叫请求消息的发起方身份是否为PSAP，并在判断该回叫请求消息发起方身份的有效性后进行修正时，所述识别实体中进一步包括：第二识别实体，并且第一识别实体先于第二识别实体处理被叫请求消息；

所述第二识别实体，用于在收到所述第一识别实体修正后的回叫请求消息，以及发起侧网络发来的发起方身份未被标识为PSAP的回叫请求消息，识别回叫请求消息的发起方身份，并相应处理该回叫请求消息。

8、如权利要求6或7所述的实体，其特征在于，第一识别实体收到从信任域发来的回叫请求消息后，根据该回叫请求消息中携带的指示，或者特定的头域值，或者根据所述回叫请求消息通过特定的IP联系方式发来识别该回叫请求消息发起方是否为有效的PSAP。

9、如权利要求7所述的实体，其特征在于，所述第一识别实体否定回叫请求消息发起方身份的有效性后，进行的处理的方式包括下列之一：

若所述回叫请求消息中携带有指示或者头域值标识该回叫请求消息的发起方身份为PSAP的指示，则删除该指示或者头域值；

若所述回叫请求消息中携带有指示或者头域值标识该回叫请求消息的发起方身份为PSAP的指示，则通过非特定的IP联系方式转发该回叫请求消息；

若所述回叫请求消息通过特定的IP联系方式发来，则标识该回叫请求消息的发起方身份不为有效的PSAP；

若所述回叫请求消息通过特定的IP联系方式发来，则通过非特定的IP联系方式转发该回叫请求消息。

10、如权利要求7所述的实体，其特征在于，所述第二识别实体在识别出收到的回叫请求消息的发起方身份为PSAP时，直接继续提供呼叫服务。

11、如权利要求7所述的实体，其特征在于，所述第二识别实体在识别出收到的回叫请求消息的发起方身份不为PSAP时，直接拒绝该请求消息或者根据用户状态处理所述回叫请求消息。

12、如权利要求11所述的实体，其特征在于，若根据用户状态处理所述回叫请求消息，并且第二识别实体中未存储用户当前状态信息，则所述网络还包括：

用户状态获取装置，用于与存储有用户当前状态信息的网元交互，以获取用户当前状态，并将获取的信息发送给第二识别实体。

13、一种紧急业务中发起回叫的方法，其特征在于，包括下列步骤：

回叫发起侧在确认收到的请求消息的发起方身份后，向被叫接续网络前转该请求消息；以及

使被叫接续网络获知该请求消息的发起方身份，所述发起方身份为公共安全应答点PSAP。

14、如权利要求13所述的方法，其特征在于，通过SIP消息携带指示，头域值或者通过特定的IP联系方式标识请求消息的发起方身份为公共安全应答点PSAP。

15、如权利要求14所述的方法，其特征在于，回叫发起侧网络收到的请求消息的发起方身份被标识为PSAP时，在确认该请求消息发起方的身份后对该标识进行修正，若确认发起方为PSAP，则认定该标识，再向被叫接续网络发送；否则直接拒绝所述请求消息，或者，删除该请求消息中携带的指示、头域值或通过非特定的IP联系方式向被叫接续网络发送。

16、如权利要求14所述的方法，其特征在于，回叫发起侧网络收到的请求消息的发起方身份未被标识为PSAP时，在确认该请求消息发起方的身份后，进行相应处理；若确认发起方为PSAP，则为该请求消息增加指示或使用特定的IP联系方式向被叫接续网络发送；若确认发起方不为PSAP，则直接拒绝该请求消息，或者，将该请求消息直接或通过非特定的IP联系方式向被叫接续网络发送。

17、如权利要求14所述的方法，其特征在于，回叫发起侧在SIP消息的头域或头域的参数中携带所述指示。

18、如权利要求13至17任一项所述的方法，其特征在于，回叫发起侧是被叫接续网络的直接或者间接信任域。

19、一种紧急业务中接收回叫的方法，其特征在于，包括下列步骤：

被叫接续网络识别回叫请求消息的发起方身份，根据发起方身份是否为有效的PSAP进行后续处理，其中所述的后续处理具体包括：

被叫接续网络确认所述回叫请求消息的发起方身份不为有效的PSAP时，直接拒绝该回叫请求消息；或者

对该回叫请求消息进行修正，之后再相应处理修正后的回叫请求消息。

20、如权利要求19所述的方法，其特征在于，被叫接续网络收到从信任域发来的回叫请求消息后，根据该回叫请求消息中携带的指示，或者特定的头域值，或者根据所述回叫请求消息通过特定的IP联系方式发来识别该回叫请求消息发起方是否为有效的PSAP。

21、如权利要求19或20所述的方法，其特征在于，被叫接续网络确认所述回叫请求消息的发起方身份不为有效的PSAP时，对该回叫请求消息进行修正的方式，包括下列之一：

若所述回叫请求消息中携带有指示、头域值标识该回叫请求消息的发起方身份为PSAP的指示，则删除该指示、头域值；

若所述回叫请求消息中携带有指示、头域值标识该回叫请求消息的发起方身份为PSAP的指示，则通过非特定的IP联系方式转发该回叫请求消息；

若所述回叫请求消息通过特定的IP联系方式发来，则标识该回叫请求消息的发起方身份不为有效的PSAP；

若所述回叫请求消息通过特定的IP联系方式发来，则通过非特定的IP联系方式转发该回叫请求消息。

22、如权利要求19所述的方法，其特征在于，处理修正后的回叫请求消息为在识别出收到的回叫请求消息的发起方身份为PSAP时，直接指示提供呼叫服务。

23、如权利要求19所述的方法，其特征在于，处理修正后的回叫请求消息为在识别出收到的回叫请求消息的发起方身份不为PSAP时，则可直接拒绝回叫请求；或者获取并根据用户当前状态处理所述回叫请求消息。

24、一种紧急业务中呼叫接续的方法，其特征在于，包括下列步骤：

收到用户发起的注册，识别该注册是一个紧急注册；

处理主叫接续的网络收到用户发起的呼叫；

当所述处理主叫接续的网络获知所述用户发起的呼叫与紧急注册相关联时，按照预设的策略相应处理该呼叫。

25、如权利要求24所述的方法，其特征在于，所述处理主叫接续的网络获知所述用户发起的呼叫与紧急注册相关联具体为：所述处理主叫接续的网络查询该呼叫的关联信息获知所述用户的呼叫发起与紧急注册相关联。

26、如权利要求24或25所述的方法，其特征在于，处理主叫接续的网络中的P-CSCF收到用户发起的与紧急注册相关的呼叫且该呼叫不是紧急呼叫请求，则直接拒绝该请求。

27、如权利要求24、25所述的方法，其特征在于，处理主叫接续的网络中的P-CSCF，收到用户发起的呼叫为紧急注册相关的请求，将该请求发送给E-CSCF，在进行后续处理的实体判定该请求不是紧急呼叫请求，则拒绝该请求。

28、如权利要求27所述的方法，其特征在于，处理主叫接续的P-CSCF在发往E-CSCF的请求消息中的route头域中只携带该E-CSCF的相关信息；或者，E-CSCF收到请求消息后，清空请求消息中的route头域；或者，E-CSCF在转发请求消息时，在该请求消息中的route头域只携带下一跳的相关信息。

29、如权利要求27所述的方法，其特征在于，所述后续实体为E-CSCF，LRF或者PSAP。

30、如权利要求26、27、28或29所述方法，其特征在于，P-CSCF通过下述规则识别呼叫请求与紧急注册相关：

根据呼叫请求中所使用的用户标识的字符特征或者检查该用户标识的隐式注册集中的用户身份标识的字符特征，判定该呼叫请求与紧急注册相关；或者，

注册时，P-CSCF根据注册成功的用户标识的字符特征或者注册成功响应中携带的隐式注册集中的用户身份标识的字符特征，判定所有和该注册相关联的呼叫请求与紧急注册相关；或者，

在注册时，P-CSCF通过注册响应消息中的特征指示，识别所有和该注册相关的呼叫请求与紧急注册相关；

在注册时，P-CSCF通过注册响应消息中的特征指示，同时检查和该注册相关联的呼叫请求所使用的用户标识中含有字符特征，以识别该呼叫请求与紧急注册相关；

在注册时，P-CSCF根据注册请求中的指示，直接识别该注册为紧急注册，P-CSCF识别所有与该注册相关的请求都与紧急注册相关。

31、如权利要求30所述的方法，其特征在于，所述紧急用户标识为该紧急用户标识本身，或者为该紧急用户标识所在的隐式注册集。

32、如权利要求24、25所述的方法，其特征在于，处理主叫接续的S-CSCF、AS，IBCF，I-CSCF，HSS中的任一网元，收到用户发起的呼叫与紧急注册相关，则直接拒绝该请求。

33、如权利要求32所述的方法，其特征在于，S-CSCF，I-CSCF通过下述规则识别呼叫请求与紧急注册相关：

S-CSCF，I-CSCF直接根据呼叫请求中所使用的用户标识的字符特征或者检查出该用户标识的隐式注册集中的用户身份标识的字符特征，识别该呼叫请求与紧急注册相关；或者，

注册时，S-CSCF，I-CSCF根据注册所使用的用户标识的字符特征、头域，或参数，识别所有和该注册相关的呼叫请求与紧急注册相关；或者，

在注册时，通过HSS下发的指示，获知所有和该注册相关的呼叫请求与紧急注册相关。

34、如权利要求24、25所述的方法，其特征在于，所述主叫呼叫接续的网络中，如果用户使用紧急注册，HSS根据策略传递指示给S-CSCF，根据该指示，S-CSCF会拒绝该用户发起的呼叫；所述指示传递策略包括在任何时候都传递指示，或者只是当用户处于越权的时候才传递。

35、如权利要求24、25所述的方法，其特征在于，所述主叫呼叫接续的网络中，如果用户使用紧急注册，HSS根据策略传递指示给AS，根据该指示，AS会拒绝该用户发起的呼叫；所述指示传递策略包括在任何时候传递，或者只是用户处于越权时才传递。

36、如权利要求24、25所述的方法，其特征在于，所述主叫呼叫接续的网络中针对紧急注册相关联的呼叫创建iFC，HSS根据策略下发该iFC给S-CSCF，其策略为任何时候下发，或者是用户越权时才下发；根据该iFC，S-CSCF会将使用紧急注册相关的主叫请求前传到指定的AS，该AS直接拒绝该请求。

Images