WO2008022554A1

WO2008022554A1 - Procédé de dispositif d'émission/réception de services d'urgence

Info

Publication number: WO2008022554A1
Application number: PCT/CN2007/002464
Authority: WO
Inventors: Peng Zhao
Original assignee: Huawei Technologies Co., Ltd.
Priority date: 2006-08-16
Filing date: 2007-08-15
Publication date: 2008-02-28
Also published as: EP2053873A4; EP2053873A1; EP2375629B1; EP2375629A1; ES2532664T3; US20090147929A1

Description

' 紧急业务的收发方法及装置技术领域

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

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

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

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

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

步骤 102, P-CSCF将收到了 REGISTER消息前传到用户本域的 I-CSCF

( Interrogating Call Session Control Function 询问呼叫会话控制功能实体 ), 消息中包含有 P-CSCF所在域的标识。

步骤 103 , I-CSCF给 HSS ( Home Subscribe Server 归属用户服务器）发送 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发送 SA 消息给 HSS，刷新 HSS的记录。

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

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

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

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

步骤 201A-卜步骤 201A-2, 位于 PSTN的 PSAP通过媒体网关控制功能实体 MGCF向用户的归属域发起呼叫， MGCF需要将 PSAP发出的信令转换成 SIP信令。

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

步骤 202，用户归属网络的入口点（IBCF ( Interconnection Border Control Function 互通边界控制功能实体）或者 I-CSCF ( Interrogating Call Session Control Function 查询 -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的呼叫业务。这样，一旦恶意的用户通过发起紧急注册流程，突破了漫游和计费的限制，其他的用户就可以通过该用户的紧急用户标识来呼叫该用户，该用户就非法享受了签约外的^ 务。

发明人在发明过程中发现，基于现有技术存在用户恶意使用紧急用户标识进行紧急注册来享受越权服务的情况。发明内容

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

本发明实施例的认证实体，位于紧急业务中回叫的发起侧网络，用于在确认收到的请求消息的发起方身份后，向被叫接续网络前转该请求消息，并使被叫接续网络获知该请求消息的发起方身份。

本发明实施例的识别实体，位于紧急业务中回叫的被叫接续网络，用于识别呼叫发起侧网络发来的回叫请求消息的发起方身份 , 以及根据发起方身份是否为有效的 PSA 进行后续处理。

本发明实施例的紧急业务中发起回叫的方法，包括下列步骤：回叫发起侧在确认收到的请求消息的发起方身份后，向被叫接续网络前转该请求消息；以及使被叫接续网络获知该请求消息的发起方身份。

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

本发明实施例的一种紧急业务中呼叫接续的方法，包括下列步骤：处理主叫接续的网络收到用户发起的呼叫；处理主叫接续的网络判定该呼叫为与紧急注册相关联的呼叫；按照业务還辑策略处理该呼叫。

本发明实施例提供的紧急业务的收发方法及装置，通过识别紧急呼叫发起方的身份来防止用户享受越权服务。

本发明实施例还提供了一种紧急业务中呼叫接续的方法，其中处理呼叫接续的设备不像现有技术那样直接处理收到的呼叫请求，而是先判断该呼叫是否为与紧急注册相关联的呼叫；当处理主叫接续的网絡判定该呼叫为与紧急注册相关联的呼叫时，按照业务逻辑策略处理该呼叫。从而有效的防止了用户享受越权服务。附图说明

图 1为现有 IMS i或的紧急呼叫的流程框架图；图 2为现有的紧急注册流程图；

图 3为现有回叫流程图；

图 4为本发明实施例的紧急业务中发起回叫的方法步骤流程图；图 5为本发明实施例的识别实体实施例二的结构示意图；

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

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

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

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

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

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

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

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

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

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

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

为了防止用户恶意使用紧急用户标识进行紧急注册来享受越权服务。进一步为了在紧急业务中回叫的发起侧网络及方法中增加确认发起方身份的机制 , 进而解决被叫侧无法获知发起方真实身份的问题，本发明实施例的认证实体以及紧急业务中发起回叫的方法的主要思想是：在收到呼叫紧急用户标识的请求时，发起侧网络需要对消息发起方的身份进行确认，如果发起方为

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联系方式发来，即收到的请求消息的发起方身份未被标识为 PS AP时，由认证实体在确认该请求消息发起方的身份后，进行相应处理；若确认发起方为 PSAP, 则为该请求消息增加 PSAP指示或使用特定的 IP联系方式向被叫接续网络发送；若确认发起方不为 PSAP,则直接拒绝该请求消息，或者，将该请求消息直接或通过非特定的 IP联系方式向被叫接续网络发送。■从而使被叫接续网络获知该请求消息的发起方身份。

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

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

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

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

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

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

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

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

S 1 -3、向被叫接续网络前转该请求消息同时告知该请求消息的发起方身份。对应步骤 S 1- 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(也可通过数字签名等方式确定该回叫请求消息的有效性）。若第一识别实体判断确认所述回叫请求消息发起方 PS AP身份的有效性，则确认该回叫请求的发起方 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>" 等；也可以是头域的参数，例如 "INVITE sip:hw@homel .net;fromPSAP SIP/2.0 "專。 PSAP将携带了指示的请求发送给能够对其进行身份确认的，同时又属于被叫用户归属域的直接或间接的信任: t或中的某个实体，这里使用的是 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, G E隧道标识；或其它 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@homel .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 ( Location Retrieval Function位置取回功能实体）或者 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, 收到用户发起的呼叫与紧急注册相关，则按照业务 i£辑策略（业务逻辑策略三），直接拒绝该请求。 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协议发送给 LRP, LRF识别出该呼叫被叫方不是紧急业务， LRF将返回失败响应。

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

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

步骤 801 - 802, UE使用 "user@sos.compaiw.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 , XJE使用 ^tcuser(¾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判断出该请求是紧急注册相关联的，即用户是使用紧急用户身份发起的呼叫，则拒绝该请求。

综上所述，本发明实施例提供的紧急业务的收发方法及装置，通过识别紧急业务相关的呼叫发起方的身份来防止用户享受越权服务。

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

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

应用上述实体，本发明实施例还提供了对应的发起及接收紧急业务中回叫的方法。

本发明实施例还提供了一种紧急业务中呼叫接续的方法，其中处理呼叫接续的设备不像现有技术那样直接处理收到的呼叫请求，而是先判断该呼叫是否为与紧急注册相关联的呼叫；当处理主叫接续的网络判定该呼叫为与紧急注册相关联的呼叫时，按照业务逻辑策略处理该呼叫。从而有效的防止了用户享受越权服务。

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

Claims

权利要求

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

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

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

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

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

6、一种识别实体，位于紧急业务中回叫的被叫接续网络，其特征在于，所述识别实体，用于识别回叫请求消息的发起方身份，以及根据发起方身份是否为有效的 PSAP进行后续处理。

7、如权利要求 6所述的实体，其特征在于，所述识别实体中至少包括：第一识别实体，用于识别回叫请求消息的发起方身份，并在确认发起方身份不为有效的 PSAP时，直接拒绝该回叫请求消息。

8、如权利要求 6所述的实体，其特征在于，所述识别实体中包括：第一识别实体和第二识别实体，并且第一识别实体先于第二识别实体处理被叫请求消息；

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

所迷第二识别实体，用于在收到回叫请求消息后，识别回叫请求消息的发起方身份，并相应处理该回叫请求消息。

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

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

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

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

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

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

11、如权利要求 8 所述的实体，其特征在于，所述第二识别实体收到的回叫请求消息包括：所述第一识別实体修正后的回叫请求消息，以及发起侧网络发来的发起方身份未被标识为 PSAP的回叫请求消息。

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

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

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

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

15、如权利要求 14所述的实体，其特征在于，所述用户状态获取装置与存储有用户当前状态信息的网元之间具有扩展的接口，以传输用户当前状态信息。

16、如权利要求 15所述的实体，其特征在于，若所述用户状态获取装置位于 S-CSCF中，则在用户注册时， HSS将用户的状态信息通知 S-CSCF, 以使用户状态获取装置获得用户的状态信息；或者，若所述用户状态获取装置位于 AS中，则通过 Sh接口从 HSS获取用户的状态信息。

17、一种紧急业务中发起回叫的方法，其特征在于，包括下列步驟：回叫发起侧网络在确认收到的请求消息的发起方身份后，向被叫接续网络前转该请求消息；以及

使被叫接续网络获知该请求消息的发起方身份。

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

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

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

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

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

23、一种紧急业务中接收回叫的方法，其特征在于，包括下列步骤：被叫接续网络收到回叫请求消息后，识别该回叫请求消息的发起方身份；以及

被叫接续网络根据发起方身份是否为有效的 PSAP进行后续处理。

24、如权利要求 23所述的方法，其特征在于，被叫接续网络确认所述回叫请求消息的发起方身份不是有效的 PSAP时，直接拒绝该回叫请求消息；或者

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

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

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

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

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

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

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

29、一种紧急业务中呼叫接续的方法，其特征在于，包括下列步骤：处理主叫接续的网络收到用户发起的呼叫；

处理主叫接续的网络判定该呼叫为与紧急注册相关联的呼叫；

按照业务逻辑策略处理该呼叫。

30、如权利要求 29所述的方法，其特征在于，所述业务逻辑策略包括下列之一：

判定为非紧急呼叫后拒绝该呼叫；

将该呼叫传递给后续处理实体，后续处理实体判定为非紧急呼叫后拒绝该呼叫；

直接拒绝该呼叫；

按照用户当前状态决定是否拒绝该呼叫。

31、如权利要求 29所述的方法，其特征在于，处理主叫接续的网络中的代理呼叫会话控制功能实体 P-CSCF 收到用户发起的与紧急注册相关的呼叫后，按照业务逻辑策略进一步确定该呼叫不是紧急呼叫请求时，拒绝该呼叫。

32、如权利要求 29所述的方法，其特征在于，处理主叫接续的网络中的 P-CSCF收到用户发起的呼叫为紧急注册相关的呼叫后，按照业务逻辑策略将该呼叫发送给 E-CSCF,在进行后续处理的实体判定该呼叫不是紧急呼叫请求时 , 所述进行后续处理的实体拒绝该呼叫。

33、如权利要求 32所述的方法，其特征在于，所述后续实体为 E-CSCF, LRF或者 PSA？。

34、如权利要求 31、 32或 33所迷方法，其特征在于， P-CSCF通过下述规则判定呼叫请求与紧急注册相关：

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

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

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

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

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

36、如权利要求 29所述的方法，其特征在于，处理主叫接续的网络设备为 S-CSCF、 AS, IBCF, I-CSCF, HSS中的任一网元，其收到用户发起的呼叫与紧急注册相关后，按照业务逻辑策略，直接拒绝该呼叫。

37、如权利要求 36所述的方法，其特征在于，当处理主叫接续的网络设备为 S-CSCF或 I-CSCF时，其通过下述规则判定呼叫请求与紧急注册相关：直接根据呼叫请求中所使用的用户标识的字符特征或者检查出该用户标识的隐式注册集中的用户身份标识的字符特征，判定该呼叫请求与紧急注册相关；或者，

注册时，居注册所使用的用户标识的字符特征、头域，或参数，判定所有和该注册相关的呼叫请求与紧急注册相关；或者，

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

38、如权利要求 29所述的方法，其特征在于，所述呼叫被判定为与紧急注册相关联的呼叫，则 HSS根据业务逻辑策略传递指示给 S- CSCF, 根据该指示， S-CSCF会拒绝该呼叫；所述指示传递策略包括在任何时候都传递指示，或者只是当用户处于越权的时候才传递。

39、如权利要求 29所述的方法，其特征在于，所述呼叫被判定为与紧急注册相关联的呼叫，则 HSS根据业务逻辑策略传递指示给 AS，根据该指示， AS会拒绝该呼叫；所述指示传递策略包括在任何时候传递，或者只是用户处于越权时才传递。

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