WO2011094983A1 - 基于身份识别的遇忙回叫业务接入方法及系统 - Google Patents

基于身份识别的遇忙回叫业务接入方法及系统 Download PDF

Info

Publication number
WO2011094983A1
WO2011094983A1 PCT/CN2010/073909 CN2010073909W WO2011094983A1 WO 2011094983 A1 WO2011094983 A1 WO 2011094983A1 CN 2010073909 W CN2010073909 W CN 2010073909W WO 2011094983 A1 WO2011094983 A1 WO 2011094983A1
Authority
WO
WIPO (PCT)
Prior art keywords
calling
identity
application server
called
call request
Prior art date
Application number
PCT/CN2010/073909
Other languages
English (en)
French (fr)
Inventor
高扬
张少联
邹明江
Original Assignee
中兴通讯股份有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 中兴通讯股份有限公司 filed Critical 中兴通讯股份有限公司
Priority to US13/258,319 priority Critical patent/US8849248B2/en
Priority to EP10845066.9A priority patent/EP2519039B1/en
Publication of WO2011094983A1 publication Critical patent/WO2011094983A1/zh

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/16—Communication-related supplementary services, e.g. call-transfer or call-hold
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1441—Countermeasures against malicious traffic
    • H04L63/1466—Active attacks involving interception, injection, modification, spoofing of data unit addresses, e.g. hijacking, packet injection or TCP sequence number attacks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M3/00—Automatic or semi-automatic exchanges
    • H04M3/42—Systems providing special services or facilities to subscribers
    • H04M3/48—Arrangements for recalling a calling subscriber when the wanted subscriber ceases to be busy
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H04W12/069—Authentication using certificates or pre-shared keys
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/12—Detection or prevention of fraud
    • H04W12/126—Anti-theft arrangements, e.g. protection against subscriber identity module [SIM] cloning
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M3/00—Automatic or semi-automatic exchanges
    • H04M3/42—Systems providing special services or facilities to subscribers
    • H04M3/42025—Calling or Called party identification service
    • H04M3/42034—Calling party identification service
    • H04M3/42059—Making use of the calling party identifier

Definitions

  • the present invention relates to a CCB (Completion of Call to Busy Subscriber) processing technology, and more particularly to a callback-based application server (AS, Application Server) based on identity-based busy callback in a busy callback service. Service access method and system. Background technique
  • FIG. 1 is a flow chart of the existing busy callback service. As shown in Figure 1, the existing busy callback service process includes the following steps:
  • Step 1 Caller A calls the called subscriber B, and the called subscriber B rejects the call request of the calling subscriber A due to the busy line.
  • Step 2 The calling side application server 0_AS sends a subscription message (SUBSCRIBE) to the called side application server T_AS, and subscribes to the called user idle state.
  • SUBSCRIBE subscription message
  • Step 3 After receiving the SUBSCRIBE sent by the 0_AS, the T_AS returns a 202 OK message, and confirms that the SUBSCRIBE is received by the 0-AS.
  • step 3 the called side application server T_AS starts the busy state supervision begin to the called user B.
  • step 4 the process proceeds to step 4.
  • Step 4 When the called user is idle, the called side application server T_AS traverses the calling side AS list subscribing to the user's idle state, and sends a notification message ( NOTIFY ) to the currently subscribed calling AS.
  • a notification message NOTIFY
  • Step 5 After receiving the NOTIFY, the calling side application server 0_AS returns a 200 OK confirmation message to the called side application server T_AS.
  • Step 6 to step 10 the calling side application server 0_AS notifies the main party by means of REFER Calling the user A to initiate a call request (INVITE), and the calling side application server 0_AS adds a call completion indication (CC call indicator) information to the call request of the calling user A; or the calling side application server 0-AS A third party call control (3PCC, 3rd Party Call Control) process is sent, a call request (INVITE) is sent to the called user B, and a call completion indication (CC call indicator) information is added to the call request by the calling side application server O_AS.
  • 3PCC, 3rd Party Call Control 3PCC, 3rd Party Call Control
  • the called side application server T-AS After receiving the call request (INVITE), the called side application server T-AS determines whether the call request (INVITE) carries the call completion indication information. If the call completion indication is carried, the called side application server T-AS requests the call. Forwarded to the called user B; if the call completion indication is not carried, the called side application server T-AS rejects the current call request using the 486 (Busy Here) failure response.
  • FIG. 2 is a flow chart of performing a malicious call on the basis of FIG. 1. As shown in FIG. 2, the manner in which a malicious caller makes a malicious call is as follows:
  • Steps 1 to 5 are identical to the processing of steps 1 to 5 shown in FIG. 1, and the implementation details thereof will not be described herein.
  • Step 6 The malicious user or other application server sends a call request (INVITE) to the called side application server T_AS, and the malicious user inserts the call completion indication information into the call request initiated by the malicious user.
  • the called side application server T-AS will process the call of the malicious user in the case of the calling user A shown in the foregoing steps 1 to 5, that is, the current malicious user's call request is used as the user of the busy callback service.
  • Step 7 The called side application server T_AS will forward the call request of the malicious user to the called user B, and perform call access.
  • Steps 8 to 12 correspond to the processing flow shown in Figure 1, no longer - to describe its implementation Details.
  • the main object of the present invention is to provide a method and system for accessing a busy callback service based on identity recognition, which can reject a call request of a malicious user carrying the completion indication information.
  • An identity-based busy callback service access method includes:
  • the called side application server After receiving the call request carrying the call completion indication, the called side application server authenticates the calling user in the call request, and if the verification passes, allows the calling user to access, otherwise rejects the calling party. User access.
  • the calling party includes a calling user or a calling user equipment; the called party includes a called user or a called user equipment.
  • the rejecting the calling access is:
  • the caller access is rejected by sending a reject message to the caller, the reject message being a 486 message.
  • the method further includes:
  • the called side application server detects that the called user is idle, sends the notification message that the called user is idle to the calling user, and records the identification information of the calling user.
  • the identifying the calling user in the call request specifically:
  • the called side application server extracts the identity identification information of the calling user in the call request forwarded by the application server on the calling user side, and the calling user recorded in the called side application server The identification information is compared. If the identity certificate passes when it is consistent, the verification fails.
  • the called side application server performs identity authentication on the calling user based on the shared key.
  • the called side application server performs identity verification on the calling user based on the shared key, specifically:
  • the called side application server determines whether the call request of the calling user's callback forwarded by the application server on the calling user side carries the shared key information, and the application to the calling user side when not carried
  • the server sends a reject message, where the reject message carries a challenge value generated based on the shared key;
  • the calling user resends a call request to the called side application server, and carries the shared key information
  • the called side application server verifies the shared key information, and if the verification succeeds, the calling user identity is legal, otherwise it is illegal.
  • the called side application server performs identity verification on the calling user based on the shared key, specifically:
  • the called side application server detects that the called user is idle, and sends a notification message to the application server on the calling user side, where the notification message carries a challenge value generated based on the shared key;
  • the called side application server sends a call request for the call back, and carries the shared key information;
  • the called side application server verifies the shared key information in the call request of the callback, and if the verification succeeds, the identity of the calling user is legal, otherwise it is illegal.
  • the method further includes:
  • the called side application server assigns an identity identifier to the calling user that is rejected for busy, and notifies the calling user or the application server measured by the calling user;
  • the calling user sends a call request to the called side application server to carry the call back, and carries the identification information;
  • the called side application server verifies the identification information in the call request of the callback, and if the verification succeeds, the identity of the calling user is legal, otherwise it is illegal.
  • An identity-based busy callback service access system includes a receiving unit, a verification unit, an access unit, and a reject unit; wherein:
  • a receiving unit configured to receive a call request carrying a call completion indication
  • a verification unit configured to perform identity verification on the calling user in the call request, and if the verification succeeds, trigger the access unit, otherwise trigger the rejection unit;
  • An access unit configured to access a call for the calling user
  • a reject unit configured to reject the calling user from accessing the call.
  • the system further comprises:
  • a monitoring unit configured to monitor a sending and recording unit when the called user is idle
  • a sending and recording unit configured to send, to the calling user, a notification message that the called user is idle, and record the calling user's Identification information
  • the verification unit extracts the identity identification information of the calling user in the call request forwarded by the application server on the calling user side, and the identification information of the calling user recorded in the called side application server For comparison, if the identity verification is passed, the face certificate will not pass.
  • the verification unit authenticates the calling user based on the shared key.
  • the card unit comprises a determining subunit, a transmitting subunit, a retransmitting subunit, and a verifying subunit; wherein:
  • a determining sub-unit configured to determine whether the call request of the calling user's callback forwarded by the application server on the calling user side carries the shared key information, and triggers the sending of the sub-letter when not carried Yuan, triggering the verification subunit when carrying;
  • a sending sub-unit configured to send a reject message to the application server on the calling user side, where the reject message carries a challenge value generated based on the shared key
  • a retransmission subunit configured to send a call request to the called side application server, and carry the shared key information
  • the verification subunit is configured to verify the shared key information, and if the verification succeeds, the identity of the calling user is legal, otherwise it is illegal.
  • the card unit comprises a monitoring subunit, a first sending subunit, a second sending subunit, and a dividing subunit; wherein:
  • a monitoring subunit configured to detect that the sending subunit is triggered when the called user is idle
  • a first sending subunit configured to send a notification message to the application server on the calling user side, where the notification message carries a challenge value generated based on the shared key
  • a second sending subunit configured to send a call request to the called side application server, and carry the shared key information
  • the verification subunit is configured to verify the shared key information in the call request of the callback, and if the verification succeeds, the identity of the calling user is legal, otherwise it is illegal.
  • the system further includes an allocating unit, a notifying unit, and a sending unit; wherein: an allocating unit, configured to allocate an identity identifier to a calling user that is rejected for being busy;
  • a notification unit configured to notify the calling user or the application server of the calling user by using the identity identifier
  • a sending unit configured to send a call request to the called side application server, and carry the identifier information
  • the verification unit verifies the identification information in the call request of the callback, and if the verification passes, the identity of the calling user is legal, otherwise it is illegal.
  • an authentication mechanism for the calling user is set in the called side application server, The identity of the user carried in the call request initiated by the calling user is performed, and the calling party authenticated by the calling party is allowed to access the call. Otherwise, the calling user is denied access to the call.
  • the invention fully guarantees the call access sequence of the calling user to the called user, embodies the fairness of the call access, and eliminates the priority call access right of the malicious user.
  • Figure 1 is a flow chart of an existing busy callback service
  • FIG. 2 is a flow chart of performing a malicious call on the basis of FIG. 1;
  • Embodiment 3 is a flow chart of Embodiment 1 of an identity-based method for accessing a busy callback service according to the present invention
  • Embodiment 4 is a flow chart of Embodiment 2 of an identity-based method for accessing a busy callback service according to the present invention
  • FIG. 5 is a flow chart of Embodiment 3 of the method for accessing the busy callback service based on the identity identification according to the present invention
  • Embodiment 6 is a flow chart of Embodiment 4 of an identity-based method for accessing a busy callback service according to the present invention
  • FIG. 7 is a schematic diagram of a first component structure of an identity-based busy callback service access system according to the present invention.
  • FIG. 8 is a schematic diagram of a second component structure of an identity-based busy callback service access system according to the present invention.
  • FIG. 9 is a schematic diagram of a third component structure of an identity-based busy callback service access system according to the present invention. detailed description
  • the basic idea of the present invention is: setting an authentication mechanism for the calling user in the called side application server, and performing face authentication on the user identity carried in the call request initiated by the calling user.
  • the caller is allowed to access the call by the identity card, otherwise the caller will be denied access to the call.
  • the credit score of the invention ensures the call access sequence of the calling user to the called user, which embodies the fairness of the call access and eliminates the priority call access right of the malicious user.
  • FIG. 3 is a flow chart of Embodiment 1 of the method for accessing the busy callback service based on the identity identification. As shown in FIG. 3, the method for accessing the busy callback service based on the identity identification method includes the following steps:
  • Step 3 Caller A calls the called subscriber B, the called subscriber B is busy, rejects the call; Step 2, when the calling subscriber A has a busy callback service (CCBS), the calling AS subscribes to the called AS. Calling user B's idle state;
  • CCBS busy callback service
  • Step 3 The called AS (T-AS) returns a 202 OK message to the subscription message, and starts monitoring the idle state of the user B (busy state supervision begin);
  • Step 4 The called AS monitors that the called user B is idle, sends a notification message to the calling AS (0_AS), and the called AS records the identity of the calling user of the current notification;
  • Step 5 the AS returns 200 OK to the notification message
  • Step 6 at this time, user C, or another AS, on behalf of user C, sends a call request to the called AS of called user B, with a call completion indication (CC call indicator);
  • CC call indicator a call completion indication
  • Step 7 The called AS matches the identity of the calling user A according to the recorded current notification with the identity of the user C, the matching is unsuccessful, and the call request is rejected, and the 486 rejection message is sent to the user C.
  • Step 8 the calling AS initiates a callback process (Recall), using the REFER mode callback process as an example, the calling AS sends a REFER to the calling user A;
  • Step 9 the calling user A returns 200 OK to REFER
  • Step 10 the calling user sends a call request to the calling AS;
  • Step 11 the calling AS forwards the call request to the called AS;
  • step 12 the called AS forwards the call request to the called user B.
  • the called AS matches the identity of the calling user in the received call request, and the result is completely matched.
  • the called AS forwards the call request to the called user B, so that the calling user A accesses the called user. B.
  • the identity of the calling user A will be stored, so that after receiving the call request for the called user B to call back, the call is cleared. Whether the identity of the calling user in the request matches the identity of the notified calling user that is stored by itself, and if the matching does not match, the call request is rejected, and the current call clearing is forwarded to the called user B only when the matching is performed. Through this mechanism, illegal call requests from malicious users are avoided.
  • the calling party includes a calling user or a calling user equipment (UE, User Equipment); the called party includes the called user or the called user equipment.
  • UE User Equipment
  • the called party includes the called user or the called user equipment.
  • FIG. 4 is a flow chart of Embodiment 2 of the method for accessing the busy callback service based on the identity identification. As shown in FIG. 4, the method for accessing the busy callback service based on the identity identification method includes the following steps:
  • Steps 1 through 5 are identical to the steps shown in Figure 3, and the details of the processing are not described here.
  • Step 6 user C, or another AS on behalf of user C, sends a call request to the called AS of the called user B, with a call completion indication (CC call indicator);
  • Step 7 the called AS receives the callback INVITE, determines whether the current call request carries the shared key, and if the authentication fails (including not carrying the shared key), the called AS uses 401 to reject the call request, and Carrying the challenge value generated based on the shared key; For the malicious user C or the AS that forwards the call request of the malicious user C, there is no shared key in the call request, the authentication information cannot be forged, and the call that can be authenticated can no longer be sent.
  • Step 8 The calling AS that carries the challenge value generated based on the shared key initiates a callback process (Recall), and uses the REFER mode callback process as an example, and the calling AS sends the caller A to the calling user A.
  • Recall a callback process
  • REFER mode callback process as an example
  • Step 9 the calling user A returns 200 OK to REFER
  • Step 10 The real calling party (calling party A) initiates a call request, and does not carry the authentication information of the shared key at this time;
  • Step 14 The calling AS forwards the call request to the called AS. Since the call request of the first callback of the calling user A does not carry the authentication information of the shared key, it cannot pass the verification.
  • Step 12 The called AS rejects the call request by using 401, and carries the challenge value generated based on the shared key;
  • Step 13 the calling AS forwards the 401 reject message to the calling user A, and the reject message carries the challenge value generated based on the shared key;
  • Step 14 The calling user A re-initiates the call request, and the call request carries the authentication information of the shared key.
  • Step 15 The calling AS forwards the call request of the calling user A to the called AS.
  • Step 16 the called AS forwards the call request to the called user B.
  • the called AS verifies the shared key in the received call request.
  • ⁇ When the certificate passes, the called AS forwards the call request to the called user B, so that the calling user A accesses the called user B.
  • step 14 the call request initiated by the calling user A may not carry the key information, but in step 15, after receiving the call request, the calling AS generates a corresponding key and inserts the call request. in.
  • FIG. 5 is a flowchart of Embodiment 3 of the method for accessing the busy callback service based on the identity identification. As shown in FIG. 5, the method for accessing the busy callback service based on the identity identification method includes the following steps:
  • Steps 1 to 3 are identical to the steps shown in FIG. 3, and the processing thereof will not be described here. Details.
  • Step 4 The called AS monitors that the called user B is idle, and sends a notification message to the calling AS (0_AS), where the notification message carries the challenge value generated based on the shared key;
  • Step 5 The calling AS sends a 200 OK confirmation message to the called AS.
  • Step 6 user C, or another AS on behalf of user C, sends a call request to the called AS of the called user B, with a call completion indication (CC call indicator);
  • Step ⁇ the called AS receives the callback INVITE, and determines whether the current call request carries the shared key. If the authentication fails to pass the verification (including not carrying the shared key), the called AS sends the 486 message directly to the user C. , rejecting the call request;
  • Step 8 The calling AS initiates a callback process (Recall), and uses the REFER mode callback process as an example.
  • the calling AS sends a REFER to the calling user A.
  • Step 9 The calling user A sends a 200 OK confirmation message to the calling AS.
  • Step 10 The calling user A initiates a call request, and the call request carries the authentication information of the shared key.
  • Step 11 The calling AS forwards the call of the calling user A to the called AS. _ request; Step 12, the called AS forwards the call request to the called user B.
  • the called AS verifies the shared key in the received call request. After the authentication is passed, the called AS forwards the call request to the called user B, so that the calling user A accesses the called user B.
  • step 10 the call request initiated by the calling user A may not carry the key information, but in step 11, after receiving the call request, the calling AS generates a corresponding key and inserts the call request. in.
  • FIG. 6 is a flowchart of Embodiment 4 of the method for accessing the busy callback service based on the identity identification. As shown in FIG. 6, the method for accessing the busy callback service based on the identity identification method includes the following steps:
  • Steps 1 to 3 are identical to the steps shown in FIG. 3, and the processing thereof will not be described here. Details.
  • Step 4 During the subscription process, the called AS monitors that the called user B is idle, and sends a notification message to the calling user A.
  • the called AS receives the call request of the calling user and determines the called user B.
  • the called AS assigns the calling user a corresponding identity, such as an authentication sequence number; and sends the NOTIFY message to the calling AS through this step.
  • the calling AS notifies the calling user A of the identity, or does not notify the calling user A of the identity.
  • the identity assigned by the called AS may also be inserted in the 202 OK message in step 3 to achieve the purpose of notifying the calling AS or the rejected calling user.
  • Step 5 The calling AS sends a 200 OK confirmation message to the called AS.
  • Step 6 the malicious call user C or other AS sends a call request INVITE to the called AS, without the corresponding identity;
  • Step 7 the called AS rejects the call request, and directly sends a 486 reject message to the user C or other AS, rejecting the call request;
  • Step 8 the calling AS initiates a callback process (Recall), using the REFER mode callback process as an example, the calling AS sends a REFER to the calling user A;
  • Step 9 The calling user A sends a 200 OK confirmation message to the calling AS.
  • Step 10 The calling user A initiates a call request, and the call request carries the identity identifier assigned by the called AS.
  • the calling AS After receiving the notification message or 202 OK message of the called user, the calling AS will call the called AS as the calling user A.
  • the assigned identity is sent to the calling user A;
  • Step 11 The calling AS forwards the call request of the calling user A to the called AS.
  • step 12 the called AS forwards the call request to the called user B.
  • the called AS verifies the identity in the received call request. After the authentication is passed, the called AS forwards the call request to the called user B, so that the calling user A accesses the called user B.
  • the call request initiated by the calling user A may not carry the identity assigned by the called AS to the calling user A, and in step 11, the calling AS receives the call.
  • the identity assigned by the called AS to the calling user A is inserted into the call request.
  • the calling AS receives the call request sent by the calling user A in step 11, and inserts the called identity assigned by the called AS to the calling user A.
  • FIG. 7 is a schematic diagram of a first component structure of an identity-based busy callback service access system according to the present invention.
  • the example of the busy callback service access system based on the identity includes a receiving unit 70. Verification unit 71, access unit 72 and reject unit 73; wherein:
  • the receiving unit 70 is configured to receive a call request, and determine that the call completion indication is carried in the call request by the verification unit 71;
  • the verification unit 71 is configured to perform identity verification on the calling user in the call request, and if the verification succeeds, trigger the access unit, otherwise trigger the reject unit;
  • An access unit 72 configured to access a call for the calling user
  • the rejecting unit 73 is configured to reject the calling user from accessing the call.
  • the above verification unit may be to authenticate the calling user based on the shared key.
  • the verification unit 71 includes a determination subunit, a transmission subunit, a retransmission subunit, and a verification subunit; wherein:
  • a determining subunit configured to determine whether the call request of the calling user callback forwarded by the application server on the calling user side carries the shared key information, triggers the sending subunit when not carried, and triggers the authenticator when carrying Unit
  • a sending sub-unit configured to send a reject message to the application server on the calling user side, where the reject message carries a challenge value generated based on the shared key
  • a retransmission subunit configured to send a call request to the called side application server, and carry the shared key information
  • the verification subunit is configured to verify the shared key information, and if the verification succeeds, the identity of the calling user is legal, otherwise it is illegal.
  • the face certificate unit 71 includes a monitoring subunit, a first transmitting subunit, a second transmitting subunit, and a verifying subunit; wherein:
  • a monitoring subunit configured to detect that the sending subunit is triggered when the called user is idle
  • a first sending subunit configured to send a notification message to the application server on the calling user side, where the notification message carries a challenge value generated based on the shared key
  • a second sending subunit configured to send a call request to the called side application server, and carry the shared key information
  • the verification subunit is configured to perform face verification on the shared key information in the call request of the callback, and if the verification succeeds, the identity of the calling user is legal, otherwise it is illegal.
  • FIG. 8 is a schematic diagram of a second component structure of an identity-based busy callback service access system according to the present invention. As shown in FIG. 8, based on the system shown in FIG. 7, the example is based on the busy callback of the identity recognition.
  • the service access system further includes an allocating unit 74, a notification unit 75, and a transmitting unit 76;
  • the allocating unit 74 is configured to allocate an identity identifier to the calling user that is rejected for busy;
  • the notification unit 75 is configured to notify the calling user or the calling user of the application server by using the identity identifier;
  • the sending unit 76 is configured to send a call request of the callback to the called side application server, and carry the identifier information;
  • the verification unit 71 verifies the identification information in the call request of the callback, and if the verification succeeds, the identity of the calling user is legal, otherwise it is illegal.
  • FIG. 9 is a schematic diagram of a third component structure of an identity-based busy callback service access system according to the present invention. As shown in FIG. 9, based on the system shown in FIG. 7, the example is based on the busy callback of the identity recognition.
  • the service access system further includes a monitoring unit 77 and a sending and recording unit 78; wherein: a monitoring unit 77 is configured to monitor the sending and recording unit when the called user is idle; and a sending and recording unit 78 is configured to Calling the user to send the called user idle pass Knowing the message, and recording the identification information of the calling user;
  • the verification unit ⁇ 1 extracts the identity identification information of the calling user in the call request forwarded by the application server on the calling user side, and the identification information of the calling user recorded in the called side application server For comparison, if the identity is passed, the face certificate will not pass.
  • the identity-based busy callback service access system shown in FIG. 7, FIG. 8 and FIG. 9 is designed to implement the foregoing identity-based busy callback service access method.
  • the functions of the processing units in the system shown in FIG. 7, FIG. 8 and FIG. 9 can be understood by referring to the description of the foregoing method.
  • the functions of each processing unit can be implemented by a program running on the processor, or by a specific The logic circuit is implemented.

Description

基于身份识别的遇忙回叫业务接入方法及系统 技术领域
本发明涉及遇忙回叫业务 （ CCBS , Completion of Call to Busy Subscriber ) 处理技术， 尤其涉及一种遇忙回叫业务中被叫侧应用服务器 ( AS, Application Server )基于身份识别的遇忙回叫业务接入方法及系统。 背景技术
图 1为现有遇忙回叫业务的流程图， 如图 1所示， 现有的遇忙回叫业 务流程包括以下步驟：
步樣 1， 主叫用户 A呼叫被叫用户 B， 被叫用户 B由于忙线而拒绝主 叫用户 A的呼叫请求。
步驟 2，主叫側应用服务器 0_AS向被叫侧应用服务器 T_AS发送订阅 消息 （SUBSCRIBE ), 订阅被叫用户空闲状态。
步驟 3， T_AS接收到 0_AS发送的 SUBSCRIBE后，返回 202OK消息， 向 0— AS确认接收到 SUBSCRIBE。
步驟 3之后， 被叫侧应用服务器 T_AS对被叫用户 B开始进行忙状态 监管 （busy state supervision begin ), 当检测到被叫用户 B当前状态变为可 用 ser B become available ) 时， 执行步骤 4。
步驟 4， 当被叫用户空闲， 被叫侧应用服务器 T_AS遍历订阅该用户空 闲状态的主叫侧 AS 列表， 向当前第一个订阅的主叫 AS 发送通知消息 ( NOTIFY )。
步骤 5, 主叫侧应用服务器 0_AS接收到 NOTIFY后， 向被叫侧应用 服务器 T_AS返回 200OK确认消息。
步驟 6至步驟 10，主叫侧应用服务器 0_AS采用 REFER的方式通知主 叫用户 A发起回呼的呼叫请求（INVITE ), 并由主叫侧应用服务器 0_AS 在主叫用户 A的呼叫请求中添加呼叫完成指示 （CC call indicator )信息； 或者主叫侧应用服务器 0— AS发送第三方呼叫控制 （3PCC, 3rd Party Call Control )流程， 向被叫用户 B发送呼叫请求 ( INVITE ), 并由主叫侧应用 服务器 O_AS在呼叫请求中添加呼叫完成指示（ CC call indicator )信息。
被叫侧应用服务器 T— AS接收到呼叫请求（INVITE )后， 判断呼叫请 求（INVITE )是否携带有呼叫完成指示信息， 如果携带有呼叫完成指示， 被叫侧应用服务器 T— AS将该呼叫请求转发到被叫用户 B;如果未携带呼叫 完成指示， 则被叫侧应用服务器 T— AS使用 486 ( Busy Here )失败响应来拒 绝当前呼叫清求。
如果被叫侧应用服务器 T_AS 允许本次呼叫， 则会继续后续的处理流 程， 完成本次呼叫。
图 2为在图 1的基础上进行恶意呼叫的流程图， 如图 2所示， 恶意呼 叫的用户进行恶意呼叫的方式具体为：
步骤 1至步骤 5与图 1所示的步骤 1至步骤 5的处理方式完全相同， 这里不再赘述其实现细节。
步骤 6，恶意用户或其他应用服务器向被叫侧应用服务器 T_AS发送呼 叫请求（ INVITE ),该恶意用户在自身发起的呼叫请求中自行插入有呼叫完 成指示信息。被叫侧应用服务器 T—AS将会前述步驟 1至步骤 5所示的主叫 用户 A的情形来处理该恶意用户的呼叫， 即将当前恶意用户的呼叫请求作 为遇忙回叫业务的用户。
步驟 7，被叫侧应用服务器 T_AS将向被叫用户 B转发恶意用户的呼叫 请求， 而进行呼叫接入。
这样， 恶意用户反而较正常用户 A优先与被叫用户 B实现用户接入。 步驟 8至步骤 12与图 1所示的处理流程相对应， 不再——赘述其实现 细节。
由图 2可知， 如果存在恶意用户在呼叫请求中自行添加呼叫完成指示 信息， 主叫侧网络并不会对其进行过滤处理， 这会让恶意用户的携带呼叫 完成指示信息的呼叫请求 （INVITE )发送到被叫侧应用服务器 T—AS而建 立呼叫。 这样， 先发起订阅的主叫用户并不能先完成呼叫， 而是被后发起 订阅的主叫用户先完成呼叫。 这样， 恶意用户相当于实现了插队。 显然， 这非常不利于呼叫公平性， 严重时还会影响正常用户的正常呼叫。 发明内容
有鉴于此， 本发明的主要目的在于提供一种基于身份识别的遇忙回叫 业务接入方法及系统， 能过拒绝携带有完成指示信息的恶意用户的呼叫请 求。
为达到上述目的， 本发明的技术方案是这样实现的：
一种基于身份识别的遇忙回叫业务接入方法， 包括：
被叫侧应用服务器接收到携带有呼叫完成指示的呼叫请求后， 对所述 呼叫请求中的主叫用户进行身份验证， 若验证通过则允许所述主叫用户接 入， 否则拒绝所述主叫用户接入。
优选地， 所述主叫包括主叫用户或主叫用户设备； 所述被叫包括被叫 用户或被叫用户设备。
优选地， 所述拒绝所述主叫接入， 为：
通过向所述主叫发送拒绝消息而拒绝所述主叫接入， 所述拒绝消息为 486消息。
优选地， 所述方法还包括：
被叫侧应用服务器监测到被叫用户空闲， 向所述主叫用户发送所述被 叫用户空闲的通知消息， 并记录所述主叫用户的标识信息；
所述对所述呼叫请求中的主叫用户进行身份识別， 具体为： 所述被叫侧应用服务器在所述主叫用户侧的应用服务器转发的呼叫请 求中提取所述主叫用户的身份标识信息， 并与所述被叫侧应用服务器中记 录的所述主叫用户的标识信息进行比对， 若一致时身份臉证通过， 否则验 证未通过。
优选地， 所述被叫侧应用服务器基于共享密钥对主叫用户进行身份脸 证。
优选地， 所述被叫侧应用服务器基于共享密钥对主叫用户进行身份验 证， 具体为：
所述被叫侧应用服务器确定所述主叫用户侧的应用服务器转发的所述 主叫用户回呼的呼叫请求中是否携带有共享密钥信息， 未携带时向所述主 叫用户侧的应用服务器发送拒绝消息， 所述拒绝消息中携带基于共享密钥 生成的挑战值；
所述主叫用户重新向所述被叫侧应用服务器发送呼叫请求， 并携带共 享密钥信息；
所述被叫侧应用服务器对所述共享密钥信息进行验证， 验证通过则所 述主叫用户身份合法， 否则不合法。
优选地， 所述被叫侧应用服务器基于共享密钥对主叫用户进行身份验 证， 具体为：
所述被叫侧应用服务器监测到被叫用户空闲， 向所述主叫用户侧的应 用服务器发送通知消息， 所述通知消息中携带基于共享密钥生成的挑战值； 所述主叫用户向所述被叫侧应用服务器发送回呼的呼叫请求， 携带有 共享密钥信息；
所述被叫侧应用服务器对所述回呼的呼叫请求中的共享密钥信息进行 验证， 验证通过则所述主叫用户身份合法， 否则不合法。
优选地， 所述方法还包括： 被叫侧应用服务器为遇忙而被拒绝的主叫用户分配身份标识， 并通知 所述主叫用户或所述主叫用户测的应用服务器；
所述主叫用户向所述被叫侧应用服务器发送回呼的呼叫请求， 携带所 述标识信息；
所述被叫侧应用服务器对所述回呼的呼叫请求中的所述标识信息进行 验证， 验证通过则所述主叫用户身份合法， 否则不合法。
一种基于身份识別的遇忙回叫业务接入系统， 包括接收单元、 验证单 元、 接入单元和拒绝单元； 其中：
接收单元， 用于接收携带有呼叫完成指示的呼叫请求；
验证单元， 用于对所述呼叫请求中的主叫用户进行身份验证， 若验证 通过则触发接入单元， 否则触发拒绝单元；
接入单元， 用于为所述主叫用户接入呼叫；
拒绝单元， 用于拒绝所述主叫用户接入呼叫。
优选地， 所述系统还包括：
监测单元， 用于监测到被叫用户空闲时触发发送及记录单元； 发送及记录单元， 用于向所述主叫用户发送所述被叫用户空闲的通知 消息， 并记录所述主叫用户的标识信息；
所述验证单元在所述主叫用户侧的应用服务器转发的呼叫请求中提取 所述主叫用户的身份标识信息， 并与所述被叫侧应用服务器中记录的所述 主叫用户的标识信息进行比对， 若一致时身份验证通过， 否则脸证未通过。
优选地， 所述验证单元基于共享密钥对主叫用户进行身份验证。
优选地， 所述 证单元包括确定子单元、 发送子单元、 重发子单元和 验证子单元； 其中：
确定子单元， 用于确定所述主叫用户侧的应用服务器转发的所述主叫 用户回呼的呼叫请求中是否携带有共享密钥信息， 未携带时触发发送子单 元， 携带时触发验证子单元；
发送子单元， 用于向所述主叫用户侧的应用服务器发送拒绝消息， 所 述拒绝消息中携带基于共享密钥生成的挑战值；
重发子单元， 用于向所述被叫侧应用服务器发送呼叫请求， 并携带共 享密钥信息；
验证子单元， 用于对所述共享密钥信息进行验证， 验证通过则所述主 叫用户身份合法， 否则不合法。
优选地， 所述 证单元包括监测子单元、 第一发送子单元、 第二发送 子单元和除证子单元； 其中：
监测子单元， 用于监测到被叫用户空闲时触发发送子单元；
第一发送子单元， 用于向所述主叫用户侧的应用服务器发送通知消息， 所述通知消息中携带基于共享密钥生成的挑战值；
笫二发送子单元， 用于向所述被叫侧应用服务器发送回呼的呼叫请求， 并携带有共享密钥信息；
验证子单元， 用于对所述回呼的呼叫请求中的共享密钥信息进行验证， 验证通过则所述主叫用户身份合法 , 否则不合法。
优选地， 所述系统还包括分配单元、 通知单元和发送单元； 其中： 分配单元， 用于为遇忙而被拒绝的主叫用户分配身份标识；
通知单元， 用于将所述身份标识通知所述主叫用户或所述主叫用户测 的应用服务器；
发送单元， 用于向所述被叫侧应用服务器发送回呼的呼叫请求， 并携 带所述标识信息；
所述验证单元对所述回呼的呼叫请求中的所述标识信息进行验证， 验 证通过则所述主叫用户身份合法， 否则不合法。
本发明中， 在被叫侧应用服务器中设置对主叫用户的身份验证机制， 对于主叫用户发起的回呼的呼叫请求中携带的用户身份进行脸证， 通过身 份验证的主叫用户才允许接入呼叫， 否则， 将拒绝主叫用户接入呼叫。 本 发明充分保证了呼叫用户对被叫用户的呼叫接入顺序， 体现了呼叫接入的 公平性， 杜绝了恶意用户的优先呼叫接入权。 附图说明
图 1为现有遇忙回叫业务的流程图；
图 2为在图 1的基础上进行恶意呼叫的流程图；
图 3 为本发明基于身份识别的遇忙回叫业务接入方法实施例一的流程 图；
图 4为本发明基于身份识别的遇忙回叫业务接入方法实施例二的流程 图；
图 5 为本发明基于身份识别的遇忙回叫业务接入方法实施例三的流程 图；
图 6为本发明基于身份识别的遇忙回叫业务接入方法实施例四的流程 图；
图 7为本发明基于身份识别的遇忙回叫业务接入系统的第一种组成结 构示意图；
图 8为本发明基于身份识別的遇忙回叫业务接入系统的第二种组成结 构示意图；
图 9为本发明基于身份识别的遇忙回叫业务接入系统的第三种组成结 构示意图。 具体实施方式
本发明的基本思想是： 在被叫侧应用服务器中设置对主叫用户的身份 验证机制， 对于主叫用户发起的回呼的呼叫请求中携带的用户身份进行脸 证， 通过身份 3佥证的主叫用户才允许接入呼叫， 否则， 将拒绝主叫用户接 入呼叫。 本发明克分保证了呼叫用户对被叫用户的呼叫接入顺序 , 体现了 呼叫接入的公平性， 杜绝了恶意用户的优先呼叫接入权。
为使本发明的目的、 技术方案和优点更加清楚明白， 以下举实施例并 参照附图， 对本发明进一步详细说明。
图 3 为本发明基于身份识别的遇忙回叫业务接入方法实施例一的流程 图， 如图 3 所示， 本示例基于身份识别的遇忙回叫业务接入方法包括以下 步驟：
步 ¾ 1， 主叫用户 A呼叫被叫用户 B， 被叫用户 B忙， 拒绝呼叫； 步驟 2， 当主叫用户 A有遇忙回叫业务（CCBS ), 主叫 AS向被叫 AS 订阅被叫用户 B的空闲状态；
步骤 3， 被叫 AS ( T— AS )对订阅消息回 202OK消息， 并开始监测用 户 B的空闲状态 ( busy state supervision begin );
步骤 4， 被叫 AS监测到被叫用户 B空闲， 向主叫 AS ( 0_AS )发送通 知消息， 被叫 AS记录本次通知的主叫用户的身份标识；
步骤 5 , 0— AS对通知消息回 200OK;
步 6, 此时用户 C, 或另一 AS代表用户 C, 向被叫用户 B的被叫 AS发送呼叫请求， 并带有呼叫完成指示 （ CC call indicator );
步骤 7，被叫 AS根据所记录的当前通知的主叫用户 A的身份标识与用 户 C的身份标识进行匹配， 匹配不成功， 并拒绝该呼叫请求， 向用户 C发 送 486拒绝消息；
步驟 8, 主叫 AS发起回呼流程（Recall ), 以使用 REFER方式的回呼 流程为例， 主叫 AS向主叫用户 A发送 REFER;
步骤 9， 主叫用户 A对 REFER回 200OK;
步驟 10， 主叫用户发送呼叫请求到主叫 AS; 步骤 11 , 主叫 AS将呼叫请求转给被叫 AS;
步驟 12，被叫 AS将呼叫请求转给被叫用户 B。被叫 AS对所接收到的 呼叫请求中的主叫用户的身份标识进行匹配， 结果完全匹配， 则被叫 AS将 呼叫请求转发给被叫用户 B , 使主叫用户 A接入到被叫用户 B。
本示例中， 被叫 AS在步骤 4向主叫 AS发送通知消息时， 将会存储主 叫用户 A的身份标识， 以在接收到对被叫用户 B回呼的呼叫请求后， 判断 该呼叫清求中的主叫用户身份是否与自身存储的已通知主叫用户的身份标 识是否匹配， 不匹配则拒绝该呼叫请求， 匹配时才将当前的呼叫清求转发 到被叫用户 B。 通过这一机制， 避免了恶意用户的非法呼叫请求。
本发明中， 主叫包括主叫用户或主叫用户设备（UE, User Equipment )； 被叫包括被叫用户或被叫用户设备。
图 4为本发明基于身份识别的遇忙回叫业务接入方法实施例二的流程 图， 如图 4所示， 本示例基于身份识别的遇忙回叫业务接入方法包括以下 步骤：
步骤 1至步骤 5均与图 3所示的步骤完全相同， 这里不再赘述其处理 细节。
步骤 6, 用户 C, 或另一 AS代表用户 C, 向被叫用户 B的被叫 AS发 送呼叫请求， 并带有呼叫完成指示（ CC call indicator );
步骤 7, 被叫 AS收到回呼 INVITE, 判断当前的呼叫请求中是否携带 有共享密钥，若未能通过验证（包括未携带共享密钥），则被叫 AS使用 401 拒绝呼叫请求， 并携带基于共享密钥生成的挑战值； 对于恶意的用户 C或 转发恶意用户 C的呼叫请求的 AS , 呼叫请求中没有共享密钥， 无法伪造认 证信息， 将无法再发出可以被鉴权通过的呼叫请求；
步骤 8 , 携带基于共享密钥生成的挑战值的主叫 AS 发起回呼流程 ( Recall ), 以使用 REFER方式的回呼流程为例， 主叫 AS向主叫用户 A发 送 REFER;
步驟 9， 主叫用户 A对 REFER回 200OK;
步驟 10, 真正的主叫侧 （主叫用户 A )发起呼叫请求， 此时未携带共 享密钥的认证信息；
步錄 11， 主叫 AS将呼叫请求转发到被叫 AS。 由于主叫用户 A首次 回呼的呼叫请求中未携带共享密钥的认证信息， 因此不能通过验证。
步骤 12， 被叫 AS使用 401拒绝呼叫请求， 并携带基于共享密钥生成 的挑战值；
步骤 13, 主叫 AS向主叫用户 A转发 401拒绝消息， 拒绝消息中携带 基于共享密钥生成的挑战值；
步骤 14, 主叫用户 A重新发起呼叫请求， 呼叫请求中携带共享密钥的 认证信息；
步骤 15, 主叫 AS向被叫 AS转发主叫用户 A的呼叫请求； 步骤 16,被叫 AS将呼叫清求转给被叫用户 B。被叫 AS对所接收到的 呼叫请求中的共享密钥进行验证， ^：证通过则被叫 AS将呼叫请求转给被叫 用户 B， 使主叫用户 A接入到被叫用户 B。
本示例中， 在步驟 14中， 主叫用户 A发起的呼叫请求中也可以不携带 密钥信息， 而在步骤 15中， 主叫 AS接收到呼叫请求后， 生成相应的密钥 并插入呼叫请求中。
本领域技术人员应当理解， 通过在相应的接入设备中设置密钥验证方 式是容易实现的。
图 5 为本发明基于身份识别的遇忙回叫业务接入方法实施例三的流程 图， 如图 5 所示， 本示例基于身份识别的遇忙回叫业务接入方法包括以下 步骤：
步驟 1至步骤 3均与图 3所示的步骤完全相同， 这里不再赘述其处理 细节。
步驟 4， 被叫 AS监测到被叫用户 B空闲， 向主叫 AS ( 0_AS )发送通 知消息， 通知消息中携带基于共享密钥生成的挑战值；
步骤 5 , 主叫 AS向被叫 AS发送 200OK确认消息；
步骤 6, 用户 C， 或另一 AS代表用户 C， 向被叫用户 B的被叫 AS发 送呼叫请求， 并带有呼叫完成指示（ CC call indicator );
步骤 Ί， 被叫 AS收到回呼 INVITE, 判断当前的呼叫请求中是否携带 有共享密钥， 若未能通过验证 (包括未携带共享密钥）， 则被叫 AS直接向 用户 C发送 486消息， 拒绝该呼叫请求；
步驟 8 , 主叫 AS发起回呼流程（Recall ), 以使用 REFER方式的回呼 流程为例， 主叫 AS向主叫用户 A发送 REFER;
步骤 9, 主叫用户 A向主叫 AS发送 200OK确认消息；
步骤 10, 主叫用户 A发起呼叫请求， 呼叫请求中携带共享密钥的认证 信息；
步骤 11 , 主叫 AS向被叫 AS转发主叫用户 A的呼叫 _清求； 步骤 12，被叫 AS将呼叫请求转给被叫用户 B。被叫 AS对所接收到的 呼叫请求中的共享密钥进行验证，验证通过则被叫 AS将呼叫请求转给被叫 用户 B, 使主叫用户 A接入到被叫用户 B。
本示例中， 在步骤 10中， 主叫用户 A发起的呼叫请求中也可以不携带 密钥信息， 而在步驟 11中， 主叫 AS接收到呼叫请求后， 生成相应的密钥 并插入呼叫请求中。
图 6为本发明基于身份识别的遇忙回叫业务接入方法实施例四的流程 图， 如图 6所示， 本示例基于身份识别的遇忙回叫业务接入方法包括以下 步骤：
步驟 1至步骤 3均与图 3所示的步骤完全相同， 这里不再赘述其处理 细节。
步驟 4， 在订阅过程中， 被叫 AS监测到被叫用户 B空闲， 将向主叫用 户 A发送通知消息； 本示例中， 被叫 AS接收到主叫用户的呼叫请求而确 定被叫用户 B忙时， 被叫 AS为该主叫用户分配相应的身份标识， 如一个 认证序列号； 通过本步骤的 NOTIFY消息发送给主叫 AS。 主叫 AS将身份 标识通知给主叫用户 A, 或不向主叫用户 A通知身份标识。
也可以在步骤 3中的 202OK消息中插入被叫 AS分配的身份标识， 而 达到通知主叫 AS或被拒绝的主叫用户的目的。
步骤 5， 主叫 AS向被叫 AS发送 200OK确认消息；
步驟 6,恶意呼叫的用户 C或其他 AS向被叫 AS发送呼叫请求 INVITE, 未带相应的身份标识；
步骤 7， 被叫 AS拒绝该呼叫请求， 直接向用户 C或其他 AS发送 486 拒绝消息， 拒绝该呼叫请求；
步骤 8， 主叫 AS发起回呼流程（Recall ), 以使用 REFER方式的回呼 流程为例， 主叫 AS向主叫用户 A发送 REFER;
步骤 9， 主叫用户 A向主叫 AS发送 200OK确认消息；
步骤 10, 主叫用户 A发起呼叫请求， 呼叫请求中携带被叫 AS分配的 身份标识； 这里， 主叫 AS接收到被叫用户的通知消息或 202OK消息后， 将被叫 AS为主叫用户 A分配的身份标识发送给主叫用户 A;
步驟 11 , 主叫 AS向被叫 AS转发主叫用户 A的呼叫请求；
步骤 12,被叫 AS将呼叫请求转给被叫用户 B。被叫 AS对所接收到的 呼叫请求中的身份标识进行验证，验证通过则被叫 AS将呼叫请求转给被叫 用户 B， 使主叫用户 A接入到被叫用户 B。
本示例中， 在步驟 10中， 主叫用户 A发起的呼叫请求中也可以不携带 被叫 AS为主叫用户 A分配的身份标识， 而在步骤 11中， 主叫 AS接收到 主叫用户 A发送的呼叫请求后， 将被叫 AS为主叫用户 A分配的身份标识 插入呼叫请求中。 当主叫 AS不向主叫用户 A通知身份标识时， 由主叫 AS 在步骤 11中接收到主叫用户 A发送的呼叫请求后， 将被叫 AS为主叫用户 A分配的身份标识插入呼叫请求中
图 Ί为本发明基于身份识别的遇忙回叫业务接入系统的第一种组成结 构示意图， 如图 7所示， 本示例基于身份识别的遇忙回叫业务接入系统包 括接收单元 70、 验证单元 71、 接入单元 72和拒绝单元 73; 其中：
接收单元 70, 用于接收呼叫请求， 确定所述呼叫请求中携带有呼叫完 成指示时触发验证单元 71 ;
验证单元 71 , 用于对所述呼叫请求中的主叫用户进行身份验证， 若验 证通过则触发接入单元， 否则触发拒绝单元；
接入单元 72， 用于为所述主叫用户接入呼叫；
拒绝单元 73 , 用于拒绝所述主叫用户接入呼叫。
上述验证单元可以是基于共享密钥对主叫用户进行身份验证。 此时， 验证单元 71包括确定子单元、 发送子单元、 重发子单元和俭证子单元； 其 中：
确定子单元， 用于确定所述主叫用户侧的应用服务器转发的所述主叫 用户回呼的呼叫请求中是否携带有共享密钥信息， 未携带时触发发送子单 元， 携带时触发验证子单元；
发送子单元， 用于向所述主叫用户侧的应用服务器发送拒绝消息， 所 述拒绝消息中携带基于共享密钥生成的挑战值；
重发子单元， 用于向所述被叫侧应用服务器发送呼叫请求， 并携带共 享密钥信息；
验证子单元， 用于对所述共享密钥信息进行验证， 验证通过则所述主 叫用户身份合法， 否则不合法。 或者， 脸证单元 71包括监测子单元、 第一发送子单元、 第二发送子单 元和验证子单元； 其中：
监测子单元， 用于监测到被叫用户空闲时触发发送子单元；
第一发送子单元， 用于向所述主叫用户侧的应用服务器发送通知消息， 所述通知消息中携带基于共享密钥生成的挑战值；
笫二发送子单元， 用于向所述被叫侧应用服务器发送回呼的呼叫请求， 并携带有共享密钥信息；
验证子单元， 用于对所述回呼的呼叫请求中的共享密钥信息进行脸证， 验证通过则所述主叫用户身份合法 , 否则不合法。
图 8为本发明基于身份识别的遇忙回叫业务接入系统的第二种组成结 构示意图， 如图 8所示， 在图 7所示系统的基础上， 本示例基于身份识别 的遇忙回叫业务接入系统还包括分配单元 74、 通知单元 75和发送单元 76; 其中：
分配单元 74, 用于为遇忙而被拒绝的主叫用户分配身份标识； 通知单元 75, 用于将所述身份标识通知所述主叫用户或所述主叫用户 测的应用服务器；
发送单元 76, 用于向所述被叫侧应用服务器发送回呼的呼叫请求， 并 携带所述标识信息；
验证单元 71对所述回呼的呼叫请求中的所述标识信息进行验证， 验证 通过则所述主叫用户身份合法， 否则不合法。
图 9为本发明基于身份识别的遇忙回叫业务接入系统的第三种组成结 构示意图， 如图 9所示， 在图 7所示系统的基础上， 本示例基于身份识别 的遇忙回叫业务接入系统还包括监测单元 77和发送及记录单元 78; 其中： 监测单元 77, 用于监测到被叫用户空闲时触发发送及记录单元； 发送及记录单元 78， 用于向所述主叫用户发送所述被叫用户空闲的通 知消息， 并记录所述主叫用户的标识信息；
验证单元 Ί 1在所述主叫用户侧的应用服务器转发的呼叫请求中提取所 述主叫用户的身份标识信息， 并与所述被叫侧应用服务器中记录的所述主 叫用户的标识信息进行比对， 若一致时身份臉证通过， 否则臉证未通过。
本领域技术人员应当理解， 图 7、 图 8及图 9所示的基于身份识别的遇 忙回叫业务接入系统是为实现前述的基于身份识别的遇忙回叫业务接入方 法而设计的， 图 7、 图 8及图 9所示的系统中各处理单元的功能可参照前述 方法的描述而理解， 各处理单元的功能可通过运行于处理器上的程序而实 现， 也可通过具体的逻辑电路而实现。
以上所述， 仅为本发明的较佳实施例而已， 并非用于限定本发明的保 护范围。

Claims

权利要求书
1、 一种基于身份识别的遇忙回叫业务接入方法， 其特征在于， 所述方 法包括：
被叫侧应用服务器接收到呼叫请求， 确定所述呼叫请求中携带有呼叫 完成指示时， 对发起所述呼叫请求的主叫进行身份验证， 身份验证通过时， 允许所述主叫接入， 并将所述呼叫请求提供给被叫； 身份验证未通过时， 拒绝所述主叫接入。
2、 根据权利要求 1所述的方法， 其特征在于， 所述主叫包括主叫用户 或主叫用户设备； 所述被叫包括被叫用户或被叫用户设备。
3、根据权利要求 1所述的方法，其特征在于， 所述拒绝所述主叫接入， 为：
通过向所述主叫发送拒绝消息而拒绝所述主叫接入， 所述拒绝消息为 486消息。
4、 根据权利要求 1所述的方法， 其特征在于， 所述方法还包括： 被叫侧应用服务器监测到被叫空闲， 向所述主叫发送所述被叫空闲的 通知消息， 并记录所述主叫的标识信息；
所述对发起所述呼叫请求的主叫进行身份验证， 具体为：
所述被叫侧应用服务器在所述呼叫请求中提取所述主叫的身份标识信 息， 并与所述被叫侧应用服务器中记录的主叫的标识信息进行比对； 一致 时身份验证通过， 不一致时身份验证未通过。
5、 根据权利要求 1所述的方法， 其特征在于， 所述被叫侧应用服务器 基于共享密钥对主叫进行身份验证。
6、 根据权利要求 5所述的方法， 其特征在于， 所述被叫侧应用服务器 基于共享密钥对主叫进行身份验证， 具体为：
所述被叫侧应用服务器确定所述主叫侧的应用服务器转发的所述主叫 回呼的呼叫请求中是否携带有共享密钥信息， 未携带时向所述主叫侧的应 用服务器发送拒绝消息， 所述拒绝消息中携带基于共享密钥生成的挑战值； 所述主叫重新向所述被叫侧应用服务器发送呼叫请求， 并携带共享密 钥信息；
所述被叫侧应用服务器对所述共享密钥信息进行验证， 验证通过时所 述主叫身份合法， 验证不通过时所述主叫身份不合法。
7、 根据权利要求 5所述的方法， 其特征在于， 所述被叫侧应用服务器 基于共享密钥对主叫进行身份脸证， 具体为：
所述被叫侧应用服务器监测到被叫空闲， 向所述主叫侧的应用服务器 发送通知消息， 所述通知消息中携带基于共享密钥生成的挑战值；
所述主叫向所述被叫侧应用服务器发送回呼的呼叫请求， 携带有共享 密钥信息；
所述被叫侧应用服务器对所述回呼的呼叫请求中的共享密钥信息进行 脸证， 验证通过时所述主叫身份合法， 验证不通过时所述主叫身份不合法。
8、 根据权利要求 1所述的方法， 其特征在于， 所述方法还包括： 被叫侧应用服务器为遇忙而被拒绝的主叫分配身份标识， 并通知所述 主叫或所述主叫测的应用服务器；
所述主叫向所述被叫侧应用服务器发送回呼的呼叫请求， 携带所述标 识信息；
所述被叫侧应用服务器对所述回呼的呼叫请求中的所述标识信息进行 验证， 验证通过则所述主叫身份合法， 验证不通过时所述主叫身份不合法。
9、 一种基于身份识别的遇忙回叫业务接入系统， 其特征在于， 包括接 收单元、 验证单元、 接入单元和拒绝单元； 其中，
接收单元， 用于接收呼叫请求， 确定所述呼叫请求中携带有呼叫完成 指示时触发验证单元； 验证单元， 用于对所述呼叫请求中的主叫进行身份验证， 身份验证通 过时触发接入单元， 身份验证不通过时触发拒绝单元；
接入单元， 用于为所述主叫接入呼叫；
拒绝单元， 用于拒绝所述主叫接入呼叫。
10、 根据权利要求 9所述的系统， 其特征在于， 所述系统还包括监测 单元和发送及记录单元； 其中，
监测单元， 用于监测到被叫空闲时触发发送及记录单元；
发送及记录单元， 用于向所述主叫发送所述被叫空闲的通知消息， 并 记录所述主叫的标识信息；
所述验证单元在所述主叫侧的应用服务器转发的呼叫请求中提取所述 主叫的身份标识信息， 并与所述被叫侧应用服务器中记录的所述通知消息 中的主叫的标识信息进行比对， 一致时身份验证通过， 不一致时身份验证 未通过。
11、 根据权利要求 9所述的系统， 其特征在于， 所述验证单元进一步 基于共享密钥对主叫进行身份验证。
12、 根据权利要求 11所述的系统， 其特征在于， 所述验证单元进一步 包括确定子单元、 发送子单元、 重发子单元和验证子单元； 其中，
确定子单元， 用于确定所述主叫侧的应用服务器转发的所述主叫回呼 的呼叫请求中是否携带有共享密钥信息， 未携带时触发发送子单元， 携带 时触发验证子单元；
发送子单元， 用于向所述主叫侧的应用服务器发送拒绝消息， 所述拒 绝消息中携带基于共享密钥生成的挑战值；
重发子单元， 用于向所述被叫侧应用服务器发送呼叫请求， 并携带共 享密钥信息；
验证子单元， 用于对所述共享密钥信息进行验证， 验证通过时所述主 叫身份合法， 脸证不通过时所述主叫身份不合法。
13、 根据权利要求 11所述的系统， 其特征在于， 所述验证单元进一步 包括监测子单元、 第一发送子单元、 第二发送子单元和儉证子单元； 其中， 监测子单元， 用于监测到被叫空闲时触发发送子单元；
笫一发送子单元， 用于向所述主叫侧的应用服务器发送通知消息， 所 述通知消息中携带基于共享密钥生成的挑战值；
笫二发送子单元， 用于向所述被叫侧应用服务器发送回呼的呼叫请求， 并携带有共享密钥信息；
验证子单元， 用于对所述回呼的呼叫请求中的共享密钥信息进行验证， 验证通过时所述主叫身份合法， 验证不通过时所迷主叫身份不合法。
14、 根据权利要求 9所述的系统， 其特征在于， 所述系统还包括分配 单元、 通知单元和发送单元； 其中，
分配单元， 用于为遇忙而被拒绝的主叫分配身份标识；
通知单元， 用于将所述身份标识通知所述主叫或所述主叫测的应用服 务器；
发送单元， 用于向所述被叫侧应用服务器发送回呼的呼叫请求， 并携 带所述标识信息；
所述验证单元对所述回呼的呼叫请求中的所述标识信息进行验证， 验 证通过时所述主叫身份合法， 验证不通过时所述主叫身份不合法。
PCT/CN2010/073909 2010-02-02 2010-06-12 基于身份识别的遇忙回叫业务接入方法及系统 WO2011094983A1 (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US13/258,319 US8849248B2 (en) 2010-02-02 2010-06-12 Method and system for accessing completion of call to busy subscriber service based on identity
EP10845066.9A EP2519039B1 (en) 2010-02-02 2010-06-12 Method and system for accessing completion of call to busy subscriber service based on identity

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201010105056.5 2010-02-02
CN201010105056.5A CN102143460B (zh) 2010-02-02 2010-02-02 基于身份识别的遇忙回叫业务接入方法及系统

Publications (1)

Publication Number Publication Date
WO2011094983A1 true WO2011094983A1 (zh) 2011-08-11

Family

ID=44354909

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2010/073909 WO2011094983A1 (zh) 2010-02-02 2010-06-12 基于身份识别的遇忙回叫业务接入方法及系统

Country Status (4)

Country Link
US (1) US8849248B2 (zh)
EP (1) EP2519039B1 (zh)
CN (1) CN102143460B (zh)
WO (1) WO2011094983A1 (zh)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9521141B2 (en) 2014-02-12 2016-12-13 Bank Of America Corporation Caller validation
CN106572053B (zh) * 2015-10-09 2020-02-21 阿里巴巴集团控股有限公司 用于社交通信应用的安全监控的方法和设备
CN108449518B (zh) * 2017-02-16 2020-04-03 平安科技（深圳）有限公司 保险契约回访方法和装置
CN108111700B (zh) * 2018-01-05 2020-07-24 迈普通信技术股份有限公司 遇忙回叫方法、装置及服务器
US11909912B2 (en) 2021-10-26 2024-02-20 Ribbon Communications Operating Company, Inc. Methods and apparatus for call traffic anomaly mitigation

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101035166A (zh) * 2007-04-25 2007-09-12 中兴通讯股份有限公司 一种实现遇忙回呼的方法
CN101047741A (zh) * 2006-03-30 2007-10-03 华为技术有限公司 一种漏话提醒的方法及系统
CN101217598A (zh) * 2007-01-04 2008-07-09 中国移动通信集团公司 遇忙回叫方法及系统

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1324581A1 (en) * 2001-12-28 2003-07-02 Telefonaktiebolaget L M Ericsson (Publ) CCBS using Session Initiation Protocol (SIP)
DE60215335T2 (de) * 2002-08-07 2007-05-10 Lucent Technologies Inc. Verfahren zum Erstellen eines anwendungseingeleiteten Rufs an eine Mobilstation in einem CAMEL-Netzwerk, und ein Telekommunikationssystem mit einem CAMEL-Netzwerk
CN100563154C (zh) * 2004-11-05 2009-11-25 华为技术有限公司 一种保证用户身份标识私密性的方法
EP1677502A1 (en) * 2004-12-28 2006-07-05 Koninklijke KPN N.V. Method for providing presence information in a telecom network
ATE445976T1 (de) * 2006-01-24 2009-10-15 British Telecomm Verfahren und system zur rekursiven authentifikation in einem mobilnetz
WO2008022554A1 (fr) 2006-08-16 2008-02-28 Huawei Technologies Co., Ltd. Procédé de dispositif d'émission/réception de services d'urgence
CN101309329B (zh) * 2007-05-14 2011-04-20 中兴通讯股份有限公司 一种呼叫完成业务的激活及发生时的实现方法
EP2037666B1 (de) * 2007-09-11 2018-08-22 Unify GmbH & Co. KG Verfahren und Kommunikationssystem zum Bereitstellen von Informationen für einen Rückruf unter geänderten Vergebührungsbedingungen
US20090110172A1 (en) * 2007-10-26 2009-04-30 Musa Raoul Unmehopa Method of queuing and returning calls to an interactive voice response system
CN101911635B (zh) * 2007-12-27 2014-05-28 阿尔卡特朗讯 用于在电信网络中向未注册或不可用的用户提供呼叫完成服务的方法

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101047741A (zh) * 2006-03-30 2007-10-03 华为技术有限公司 一种漏话提醒的方法及系统
CN101217598A (zh) * 2007-01-04 2008-07-09 中国移动通信集团公司 遇忙回叫方法及系统
CN101035166A (zh) * 2007-04-25 2007-09-12 中兴通讯股份有限公司 一种实现遇忙回呼的方法

Also Published As

Publication number Publication date
CN102143460A (zh) 2011-08-03
CN102143460B (zh) 2017-07-14
EP2519039A4 (en) 2013-07-17
EP2519039A1 (en) 2012-10-31
US8849248B2 (en) 2014-09-30
EP2519039B1 (en) 2016-10-12
US20120282897A1 (en) 2012-11-08

Similar Documents

Publication Publication Date Title
US11563734B2 (en) System and method for authenticating called parties of individuals within a controlled environment
US11856132B2 (en) Validating automatic number identification data
TW201008340A (en) Method and apparatus for handling uplink grant
US20180069963A1 (en) Voice communication processing method and system, electronic device, and storage medium
JP2006148648A5 (zh)
US8514845B2 (en) Usage of physical layer information in combination with signaling and media parameters
US20140009560A1 (en) Mitigating spam and identifying callers in video calls
US8351579B2 (en) System and method for securely authenticating and lawfully intercepting data in telecommunication networks using biometrics
WO2011094983A1 (zh) 基于身份识别的遇忙回叫业务接入方法及系统
WO2008022554A1 (fr) Procédé de dispositif d'émission/réception de services d'urgence
WO2009005253A1 (en) Apparatus and method for preventing spams in voip system
WO2019000885A1 (zh) 一种身份验证方法及装置，电子设备
US20090061888A1 (en) Transaction Method Between Two Servers Including a Prior Validating Step Using Two Mobile Telephones
WO2012068963A1 (zh) 一种克隆设备的检测方法和装置
JP2002229951A (ja) 本人認証システム
US9237587B2 (en) Method and system for implementing group message service based on converged service system
WO2011045616A1 (en) Authenticated voice or video calls
WO2012122914A2 (zh) 基于ip的可视化语音邮件实现方法和系统
CN108270747B (zh) 一种认证方法及装置
TWI678901B (zh) 預約式語音會議裝置及其方法
KR101531198B1 (ko) 푸쉬 메시지를 이용하여 인증을 수행하는 호 처리 장치 및 방법
CN114050906B (zh) Sip语音业务的鉴权系统、方法、安全管理网元和客户端
CN111770048B (zh) 一种防止sip设备被攻击的方法、主叫设备及被叫设备
KR20070093274A (ko) Ｓｕｐｌ을 이용한 응급 서비스 시스템 및 방법
JP3742613B2 (ja) セッション管理システムおよびセッション管理方法

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 10845066

Country of ref document: EP

Kind code of ref document: A1

REEP Request for entry into the european phase

Ref document number: 2010845066

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 2010845066

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 13258319

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE