WO2011131055A1 - 一种实现安全呼叫转移的方法、系统及装置 - Google Patents

一种实现安全呼叫转移的方法、系统及装置 Download PDF

Info

Publication number
WO2011131055A1
WO2011131055A1 PCT/CN2011/071203 CN2011071203W WO2011131055A1 WO 2011131055 A1 WO2011131055 A1 WO 2011131055A1 CN 2011071203 W CN2011071203 W CN 2011071203W WO 2011131055 A1 WO2011131055 A1 WO 2011131055A1
Authority
WO
WIPO (PCT)
Prior art keywords
called party
call
party
key management
management server
Prior art date
Application number
PCT/CN2011/071203
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 EP11771508.6A priority Critical patent/EP2563001B1/en
Priority to US13/258,258 priority patent/US9077806B2/en
Publication of WO2011131055A1 publication Critical patent/WO2011131055A1/zh

Links

Classifications

    • 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/54—Arrangements for diverting calls for one subscriber to another predetermined subscriber
    • 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/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/062—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key distribution, e.g. centrally by trusted party
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1096—Supplementary features, e.g. call forwarding or call holding
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M3/00—Automatic or semi-automatic exchanges
    • H04M3/22—Arrangements for supervision, monitoring or testing
    • H04M3/2281—Call monitoring, e.g. for law enforcement purposes; Call tracing; Detection or prevention of malicious calls
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/04—Key management, e.g. using generic bootstrapping architecture [GBA]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/04—Key management, e.g. using generic bootstrapping architecture [GBA]
    • H04W12/043—Key management, e.g. using generic bootstrapping architecture [GBA] using a trusted network node as an anchor
    • H04W12/0431—Key distribution or pre-distribution; Key agreement
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/1016—IP multimedia subsystem [IMS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M7/00—Arrangements for interconnection between switching centres
    • H04M7/006—Networks other than PSTN/ISDN providing telephone service, e.g. Voice over Internet Protocol (VoIP), including next generation networks with a packet-switched transport layer
    • 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

Definitions

  • the present invention relates to a network communication security technology, and more particularly to a method, system and device for implementing secure call transfer in an IP Multimedia Subsystem (IMS).
  • IMS IP Multimedia Subsystem
  • call diversion communication diversion
  • SIP Session Initiation Protocol
  • call diversion communication diversion
  • the call server of the called party transfers the call to the user equipment of the called party set by the called party in advance, thereby improving the flexible configurability of the call.
  • Call forwarding includes the following types of services: busy call forwarding (CFB), non-answering call forwarding (CFNR), unconditional call forwarding (CFU), paging unavailable transfer (CFNRc), call forwarding without registration (CFNL), and Session transfer (CD).
  • This service allows the user to transfer all of their incoming calls to another phone number set in advance or to the user's voicemail.
  • the system can also provide a licensed call when activating Unconditional Call Transfer (CFU).
  • the call transfer also includes a special multiple transfer call scenario, that is, user A calls user B, user B uses call forwarding service, the call is transferred to user C, and user C also uses call forwarding service, and the call is transferred to user D again. .
  • the call server receives an INVITE message containing the ticket from the calling party, and forwards the message to the called party, and adds a CAUSE parameter indicating the type of call forwarding to the message.
  • the CAUSE parameter indicates that the call forwarding service and its type are used.
  • the calling party is user 1
  • its identifier is userl_publicl@homel.net
  • the called party is user 2
  • its identifier is user2_publicl@homel.net
  • user 2 enables unconditional call forwarding service
  • the target of setting call forwarding is user 3.
  • Its ID is User-3@example.com, and User 2 belongs to it.
  • FIG. 1 is a schematic diagram of a KMS-based IMS media security solution architecture in the prior art, where: User A ( UE-A) and User B (UE-B) are senders and receivers of media information, respectively; Key Management Server (KMS) acts as a trusted third party to implement key management and distribution functions; P-CSCF (Proxy) - Call Session Control Function) and S-CSCF (Service-Call Session Control Function) are network elements in the IMS network; for the function description of other network elements, please refer to related documents.
  • UE-A User A
  • UE-B User B
  • KMS Key Management Server
  • P-CSCF Proxy
  • S-CSCF Service-Call Session Control Function
  • FIG. 1 A schematic diagram of a prior art KMS based call process in FIG.
  • the calling party sends a request message (REQUEST-INT) requesting the relevant key and ticket, and the KMS returns a response message (REQUEST-RESP) to the calling party.
  • the response message carries the ticket requested by the calling party, and the ticket is based on the public user identity of the called party, and the ticket includes the encrypted related key and the calling party identifier and the called party identifier, the calling party
  • the ticket is sent to the called party by transmitting a message (Transfer-INIT).
  • the ticket is sent to the KMS through a parsing message (RESOLVE-INIT), and the KMS decrypts the ticket and decrypts the ticket and The relevant key is returned to the called party, and the KMS learns the called party identity through the ticket, and compares whether the called party identifier in the ticket is the same as the identifier of the responding party that sends the TRANSFER-INIT message, and if the same, the responder is determined. It is a legal called party.
  • the responder sending the RESOLVE-INIT to the KMS is the called party in the call, and the identity of the called user can be authenticated through the KMS.
  • the bifurcation call scenario one calling party simultaneously calls Multiple called parties, but the multiple called parties all correspond to the same public user identity, so multiple answering terminals can also be authenticated by the user; in the call forwarding scenario, the called party can use the service.
  • the user can set it at any time.
  • the final responder may have different public user IDs from the original called party. In this case, the above authentication method based on the called party's public user identity will no longer be applicable, resulting in failure.
  • the identity of the responder is authenticated, causing the call to fail. So a new solution is needed to achieve secure call forwarding. Summary of the invention
  • the technical problem to be solved by the present invention is to provide a method, system and device for realizing secure call transfer, realizing the identity of the called party, thereby realizing secure call transfer in the IMS system.
  • the present invention provides a method for implementing secure call forwarding, the method comprising:
  • the calling party calls the called party, and the called party triggers the signed call forwarding service
  • the key management server obtains the called party information of the called party through the application server; the called party obtains the media key from the key management server;
  • the calling party establishes a call connection with the called party.
  • the step of the key management server obtaining the called party information of the called party through the application server includes:
  • the application server carries the binding relationship information of the called party and the called party in the call request message, and sends a call request message to the called party;
  • the key management server determines, according to the message sent by the forwarded party that the encrypted binding relationship information is carried, whether the called party is the legal called party of the called party.
  • the encrypted binding relationship information between the called party and the called party includes the encrypted binding information of the called party identifier and the called party identifier in the current call transfer, and the called party identifier and the previous call forwarding in the previous call transfer.
  • the encryption binding information of the paging party ID includes the encrypted binding information of the called party identifier and the called party identifier in the current call transfer, and the called party identifier and the previous call forwarding in the previous call transfer.
  • the step of the key management server obtaining the called party information of the called party through the application server includes:
  • the application server determines, according to the information of the called party and the called party provided by the key management server, whether the called party is a legal called party of the called party and determines the result Feedback to the key management server.
  • the above method also has the following characteristics:
  • the step of the key management server obtaining the called party information of the called party through the application server includes:
  • the application server returns, according to the called party information provided by the key management server, the called party call transfer user identifier list to the key management server;
  • the key management server determines, according to the called party call transfer user identification list, whether the called party is a legal called party of the called party.
  • the present invention also provides a system for implementing secure call transfer, the system comprising: a calling party, a called party, a called party, an application server, and a key management server; Set to: call the called party;
  • the called party is configured to: trigger a contracted call forwarding service according to the call of the calling party;
  • the key management server is configured to: obtain, by the application server, the called party that is legally called by the called party Information
  • the called party is set to: obtain a media key from the key management server.
  • the application server is configured to: carry the encrypted binding relationship information of the called party and the called party in the call request message, and send the call request message to the called party;
  • the key management server is configured to: determine, according to the message sent by the forwarded party that the encrypted binding relationship information is carried, whether the called party is legally called by the called party square.
  • the application server is configured to: send a call request message to the called party, and carry the encrypted binding information of the called party identifier and the called party identifier in the current call transfer in the message And the encryption binding information of the called party identifier and the called party identifier in the previous call forwarding.
  • the application server is configured to: determine, according to the information of the called party and the called party that the key management server provides, whether the called party is a legal called party of the called party and The judgment result is fed back to the key management server.
  • the above system also has the following characteristics:
  • the application server is configured to: return, according to the called party information provided by the key management server, the called party call transfer user identifier list to the key management server;
  • the key management server is configured to: determine, according to the called party call transfer user identifier list, whether the called party is a legal called party of the called party.
  • the present invention further provides a key management server, comprising: a message receiving module, configured to: receive a media key request message of a called party of a call; an authentication module, which is set to : authenticating the called party according to the called party's call forwarding information provided by the application server.
  • the authentication module is configured to: determine, according to the encrypted binding relationship information of the called party and the called party that is provided by the application server, whether the called party is legal of the called party The called party is forwarded; the encrypted binding relationship information is carried in the media key request message.
  • the key management server further includes a message sending module
  • the message sending module is configured to: send a request message carrying the called party information to the application server, requesting the application server to return a call forwarding user identifier list of the called party; the authentication module is configured And determining, according to the call forwarding user identifier list of the called party returned by the application server, whether the called party is a legal called party of the called party.
  • the key management server further includes a message sending module
  • the message sending module is configured to: send a request message carrying the called party and the called party information to the application server, requesting the application server to determine whether the called party is the called party The party’s legally transferred party;
  • the authentication module is configured to: determine, according to the judgment result returned by the application server, whether the called party is a legal called party of the called party.
  • the present invention also provides an application server, including: a module, configured to: determine, according to information of the called party and the called party provided by the key management server, whether the called party is a legal called party of the called party;
  • a sending module configured to: feed back the judgment result to the key management server.
  • the present invention provides a new key agreement mechanism for implementing secure call forwarding in an IMS system, and the message format in the original IMS system is substantially preserved in the present invention.
  • FIG. 1 is a schematic diagram of a KMS-based IMS media security solution architecture in the prior art
  • FIG. 2 is a schematic diagram of a KMS-based call process in the prior art
  • FIG. 3 is a schematic diagram of a method for implementing secure call forwarding in an embodiment
  • FIG. 4 is a schematic diagram of a method for implementing secure call forwarding in a single call transfer according to Embodiment 1;
  • FIG. 5 is a schematic diagram of a method for implementing secure call transfer in a single call transfer using the first query mode in Embodiment 2;
  • FIG. 6 is a schematic diagram of a method for implementing secure call transfer in multiple call forwarding using the first query mode in Embodiment 2;
  • FIG. 7 is a schematic diagram of a method for implementing secure call transfer in a single call transfer using the second query mode in the second embodiment.
  • the system for implementing secure call transfer in the present invention includes: a calling party, a called party, a called party, an application server, and a key management server (here, a trusted third party for implementing key management and distribution) General name).
  • the called party sets the called party as the call forwarding target, and triggers the call forwarding service signed by the called party, which is one of the following situations: unconditional transfer, no answer transfer, paging unreachable transfer, user busy Transfer, session transfer service, call transfer when not registered.
  • the application server is available as a call transfer server. When the application server is used as the call server to which the called party belongs, it is used to send a call request message to the called party after receiving the call of the calling party to the called party. among them: Calling party, used to call the called party;
  • a called party configured to trigger a contracted call forwarding service according to the call of the calling party
  • a key management server configured to obtain, by using an application server, the called party information that is legally called by the called party
  • the called party is configured to obtain a media key from the key management server.
  • the call forwarding process involves three-way users: the calling party, the called party, and the called party.
  • An application server configured to carry, in a call request message, encrypted binding relationship information of the called party and the called party, and send a call request message to the called party;
  • the key management server uses And determining, according to the message sent by the forwarded party that the encrypted binding relationship information is carried, whether the called party is a legal called party of the called party.
  • the forwarded party is configured to carry the identifier of the called party and the encryption binding information when the media key request is sent to the key management server after receiving the call request message; And determining, by the server, that the called party identifier in the encrypted binding message is consistent with the called party identifier carried in the media key request sent by the forwarded party, determining that the called party is Legally transferred party.
  • the call forwarding process involves multiple users, including: calling party, called party, and multiple called parties.
  • the calling party is in turn: the first called party, the second called party, ..., the second called party, and finally the called party,
  • the called party, the first called party, the second called party, ..., and the second called party correspond to a call server.
  • the application server is used as a call server of the called party in the process of one call transfer in the multiple call transfer, and is configured to send a call request message to the call server to which the called party belongs, and carry the called party identifier in the call transfer in the message.
  • the final called party after receiving the call request message, sends a media key request message to the key management server, and carries the final called call identifier and the encrypted binding information in the previous call transfer;
  • the key management server After receiving the media key request message, verifying that the final called party identifier carried in the media key request message is consistent with the identity of the finally called party in the encrypted binding information of the last call forwarding, according to The time when the encryption binding information is generated is verified in the order from the back to the top, and the identifier of the called party in each encryption binding information is verified in succession, and when the verification is successful, it is determined that the final called party is a legitimate called party.
  • the application server is configured to determine, according to the information of the called party and the called party provided by the key management server, whether the called party is The legally called party of the called party is fed back to the key management server.
  • the first query mode is used and applied to a single call transfer situation, and the call transfer process involves three-party users: the calling party, the called party, and the called party.
  • the forwarded party after receiving the call request message sent by the call server to which the called party belongs, sends a media key request message to the key management server and carries the identifier of the called party;
  • the key management server is configured to send a query message to the call server to which the called party belongs after receiving the media key request message, and carry the called party and the called call in the query message.
  • the identifier of the party is further configured to: after receiving the success confirmation message returned by the call server, determine that the called party is a legitimate called party;
  • the calling server to which the called party belongs is configured to notify the key management server of the success confirmation message when the called party is determined to be the call forwarding target set by the called party after receiving the query message.
  • the second implementation manner of the system uses the first query mode and is applied to multiple call forwarding situations.
  • the call forwarding process involves multiple users including: a calling party, a called party, and a plurality of called parties.
  • the called party is in turn: the first called party, the second called party, ..., the second called party, and finally the called party, Among them, the called party, the first one The calling party, the second called party, ..., the second-end called party respectively correspond to a call server.
  • the call server to which the called party belongs is used to receive the inquiry message and determine that the first called party is the call forwarding target set by the called party, and notify the key management server of the success confirmation message by each call server;
  • the called party's call server in a call transfer as a multiple call transfer used to send a call request message to the called party in the current call transfer, and carries the called party identity and previous previous calls in the current call transfer
  • the called party identifier during the transfer process also used to receive the inquiry message from the call server to which the called party belongs in the current call transfer, and determine that the called party in the current call transfer is called in the current call transfer
  • the inquiry message is sent to the call server of the last called party of the called party, and carries all the called party identifiers during the previous call transfer process between the called party and the called party.
  • the final called party is configured to send a media key request message to the key management server after receiving the call request message from the call server to which the second party is called, and carry the identifier of the final called party and the previous call transfer.
  • the called party identification in the process is configured to send a media key request message to the key management server after receiving the call request message from the call server to which the second party is called, and carry the identifier of the final called party and the previous call transfer.
  • the key management server is configured to send a query message to the call server to which the second callee belongs after receiving the media key request message, and carry all the called party identifiers in the previous call transfer process; After confirming the message, it is determined that the final called party is a legitimate called party.
  • the application server is configured to return the called party call transfer user identifier list according to the called party information provided by the key management server;
  • the key management server is configured to determine whether the called party is a legal called party of the called party.
  • the second implementation of the system uses the second query mode and is applied to a single call transfer situation.
  • the call transfer process involves three-party users: the calling party, the called party, and the called party.
  • the forwarded party after receiving the call request message sent by the call server to which the called party belongs, sends a media key request message to the key management server and carries the identifier of the called party; a key management server, configured to receive a media key request message from the called party, Sending a query message to the call server to which the called party belongs, and carrying the called party identifier in the query message; and further, after receiving the call forwarding target list set by the called party from the call server, determining the location When the identifier of the called party is located in the list, it is determined that the called party is a legitimate called party;
  • the call server is configured to send the call forwarding target list set by the called party to the key management server after receiving the query message from the key management server.
  • the second query mode is used and applied to multiple call forwarding situations.
  • the call forwarding process involves multiple parties including: calling party, called party, and multiple called parties.
  • the called party is in turn: the first called party, the second called party, ..., the second called party, and finally the called party,
  • the called party, the first called party, the second called party, ..., and the second called party correspond to a call server.
  • a call server to which the called party belongs in one call transfer in a multiple call transfer used to send a call request message to the called party in the current call transfer; and also used to receive the query message sent by the key management server, Sending a list of call forwarding targets set by the called party in the call forwarding process performed by itself to the key management server;
  • the final called party is configured to send a media key request message to the key management server after receiving the call request message and carry the identifier of the finally called party;
  • the key management server is configured to: after receiving the media key request message from the final paged party, send an inquiry message to the call server to which the second party is called, and carry the identifier of the second party to be called; After receiving the list from a call server, after determining that the call server corresponds to the forwarded call list, the call forwarding execution time is sent from the previous call server to the call server in the order from the back to the forward.
  • the message carries the identifier of the forwarded party corresponding to the previous call server; and is further configured to receive the call forwarding target list set by the called party returned by the call server to which the called party belongs and determine that the identifier of the first called party is located In this list, it is determined that the final called party is a legitimate called party.
  • the method for implementing secure call transfer includes: calling party Calling the called party, the called party triggers the subscribed call forwarding service; the key management server obtains the called party's legitimate called party information through the application server; the called party manages from the key The server obtains a media key; the calling party establishes a call connection with the called party.
  • the case of triggering the call forwarding service signed by the called party is one of the following situations: unconditional transfer, no answer transfer, page unreachable transfer, user busy transfer, session transfer service, call transfer when not registered. .
  • the called party is authenticated by the key management server to ensure the secure implementation of call forwarding.
  • the present invention is applicable to one call transfer and multiple call transfer.
  • the first embodiment is applicable to two types of call forwarding, one is a single call transfer, and the other is multiple call transfer.
  • the process of obtaining, by the application server, the called party's legitimate called party information by using the application server includes: the application server carrying the called party and the called party in the call request message Encrypted binding relationship information and a call request message is sent to the called party; the key management server determines, according to the message sent by the forwarded party that carries the encrypted binding relationship information, Whether the calling party is the legal called party of the called party.
  • the call request message when the call server to which the called party belongs sends a call request message to the called party, the call request message carries the encrypted binding information of the called party identifier and the called party identifier, and the called direction is forwarded.
  • the key management server carries the identifier of the called party and the encryption binding information when the media key request is sent, and the key management server verifies the called party identifier and the location in the encrypted binding message.
  • FIG. 4 is a schematic diagram of a method for implementing secure call forwarding in a single call transfer.
  • User A is the calling party
  • User B is the called party
  • User C is the call forwarding target set by User B, that is, the called party
  • the AS is the Call the call server to which the party belongs.
  • Step 401 User A sends a ticket request to the KMS to apply for a ticket required by the user B.
  • the KMS authenticates the user A and generates a corresponding ticket to be sent to the user A.
  • Step 403 The user A sends a call request message to the IMS network, and the call request message carries a ticket. Specifically, the user A places the TRANSFER_INIT message including the ticket into the SIP INVITE message and sends the ticket to the IMS network.
  • Step 404 The IMS network forwards the received INVITE message to the AS to which the called party belongs. Step 405 406, because User B uses the unconditional call transfer service, the AS notifies the user through the IMS network that the call is transferred.
  • Step 407 The AS sends a call request message to the IMS network according to the forwarding number set by the user B, and the call request message carries the encryption binding information of the user B identifier and the user C identifier.
  • the encryption binding message refers to the binding information of user B and user C encrypted by the shared key Kas of the AS and the KMS, that is, Eas (ID-B, ID-C); and the identifier of the AS (including the public) is also carried.
  • User ID if the general authentication mechanism GBA is used in this process, it also includes the GBA identifier (BTID).
  • the AS includes the foregoing information and the ticket received from the user A in the SIP INVITE message, and forwarded through the IMS network.
  • Step 408 the IMS network forwards the INVITE message to the user C.
  • Step 409 After receiving the INVITE message, the user C sends a media key request message to the KMS, and includes the user C identifier (including the public user identifier in the message. If the universal authentication mechanism GBA is used in this process, the GBA identifier is also included. BTID) and information received from the AS (including cryptographic binding information) and call forwarding instructions.
  • Step 410 The KMS knows that the call is a call transfer according to the call forwarding indication or the information of the AS included in the information, finds the shared key Kas of the KMS and the call server according to the identifier of the AS, and obtains the binding information encrypted by Kas in the decrypted message. ID-B and ID-C, determine whether the user C identifier in the binding information is the same as the user C identifier carried in the media key request message. If the same, the user C is a legally transferred user, and further decrypts the ticket in the ticket. Media key information, used with user C The shared key encrypts the media key information and places the successful response in the RESOLVE-RESP message; when not identical, returns a failure response to the user C, terminating the call.
  • Step 411 The KMS returns the RESOLVE_RESP message to the user C in the response message.
  • Steps 412 ⁇ 415 user C receives the RESOLVE_RESP message, obtains the media key information contained in the ticket decrypted by the KMS, generates a TRANSFER_RESP message, and includes the message in the 200Ok message and replies to the user A through the IMS network.
  • step 416 user A and user C establish a connection and interact with the secure media stream.
  • user A and user C can obtain key information of the encrypted media stream, thereby performing end-to-end secure encrypted media stream communication.
  • the application server to which the called party belongs sends a call request message to the called party, where the message carries the current call transfer.
  • the call request message Carrying the encryption binding information of the called party identifier and the called party identifier in the current call transfer, and the encryption binding information of the called party identifier and the called party identifier in the previous call forwarding; the final forwarded direction key
  • the management server sends a media key request message carrying the final called identity and the encrypted binding information in the previous call forwarding; the key management server verifies the final called identity and the last call forwarding in the media key request message
  • the identifiers of the dialed parties in each encryption binding information are sequentially verified in the order from the back to the front in the order of the encryption binding information, and both are verified successfully. And determining that the final called party is a legitimate called party.
  • the encrypted binding message sent by the call server refers to the binding information of the called party identifier and the called party identifier after being encrypted by the shared key of the call server and the key management server; the key management server receives the called After the encrypted binding message sent by the party, the shared key is used to decrypt the binding message.
  • the shared keys used by each call server may be the same or different.
  • the KMS sends the called party identifier and the called party identifier to the AS to which the called party belongs, and the AS determines the legality of the called party.
  • the process of the key management server obtaining the called party information of the called party through the application server includes: the application server according to the information of the called party and the called party provided by the key management server, Determining whether the called party is a legal called party of the called party and feeding back to the key management server.
  • This first implementation is applicable to both call forwarding scenarios, one for a single call transfer and the other for multiple call transfers.
  • the called party In the case of a single call transfer, after the called party receives the call request message sent by the call server to which the called party belongs, it sends a media key request message to the key management server and carries the identifier of the called party.
  • the key management server sends an inquiry message to the call server to which the called party belongs, and carries the identifier of the called party and the called party in the inquiry message, where the called party belongs to the call server to determine the location
  • the success confirmation message is notified to the key management server, and the key management server determines that the called party is a legitimate called party .
  • Figure 5 is a schematic diagram of a method for implementing secure call forwarding in a single call transfer.
  • User A is the calling party
  • User B is the called party
  • the call forwarding destination set by User C is User B is the called party.
  • the AS is the Call the call server to which the party belongs.
  • Steps 501 to 506 are the same as steps 401 to 406.
  • Step 507 the difference between this step and step 407 is that the AS includes the called party identifier, that is, ID-B and its own identifier, ID-AS, in the INVITE message.
  • Step 508 The IMS network forwards the INVITE message to the user C.
  • Step 509 After receiving the INVITE message, the user C sends a media key request message to the KMS, and includes the user C identifier (including the public user identifier in the message. If the general authentication mechanism GBA is used in this process, the GBA identifier is also included. BTID) and information received from the AS (including Encrypted binding information) and call forwarding instructions.
  • Step 510 The KMS can notify the call forwarding scenario that the call is a call forwarding scenario, and send a query request to the corresponding AS according to the AS identifier, where the query request includes the called party identifier, ie, ID-B and the called party.
  • the party ID is ID-C.
  • Step 511 The AS returns, according to the called party ID-B, whether the ID-C is the call forwarding target set by the user B, if yes, returns a "correct” message to the KMS, and if not, returns an "error” message to the KMS. If KMS receives "correct” feedback, proceed to the next step; if you receive "error” feedback, return the corresponding error message and terminate the process.
  • Step 512 The KMS decrypts the media key information in the ticket, encrypts the media key information with the shared key of the user C, generates a RESOLVE_RESP, and returns the RESOLVE_RESP message to the user C in the response message.
  • step 517 user A and user C establish a connection and interact with the secure media stream.
  • User A and User C can obtain key information of the encrypted media stream, thereby performing end-to-end secure encrypted media stream communication.
  • the call server to which the called party belongs to the current transfer call during each transfer call of the multiple transfer call sends a call request message to the called party to which the call is transferred, carrying the call.
  • the final forwarded direction key management server sends the media key request message and carries the identity of the finally called party and the previous call forwarding process
  • the key management server sends an inquiry message to the call server to which the second party is called, carries the identifier of the finally called party, and the called party identifier in the previous call forwarding process, and the call of the called party is terminated.
  • the server determines that the final called party is the call forwarding target set by the second calling party
  • the server sends an inquiry message to the calling server of the last called party of the second-end called party, carrying the called party and the current called party. All called party identifiers during the previous call transfer process between the paging parties; performed in this order; the called party's call server receives the query cancellation And determining that the first called party is the call forwarding target set by the called party, after each call server notifies the key confirmation server of the success confirmation message, the key management server determines the most The final called party is the legal called party.
  • Figure 6 is a schematic diagram of a method for implementing secure call forwarding in multiple call forwarding, where user A is the calling party, user B is the called party, user C is the call forwarding target set by user B, and user D is the call set by user C.
  • user B user C uses the unconditional call transfer service
  • AS1 is the call server to which user B belongs
  • AS2 is the call server to which user C belongs.
  • Steps 601 to 606 are the same as steps 401 to 406.
  • Step 607 The AS1 sends a call request message to the IMS, and carries the ticket received from the user A and the ID of the user B, that is, the ID-B and the ID of the user ID, that is, the ID-AS1.
  • the AS includes the foregoing information and the ticket received from the user A in the SIP INVITE message, and forwarded through the IMS network.
  • Step 608 The IMS network forwards the INVITE message to AS2.
  • Step 609 610 because user C uses the unconditional call transfer service, AS2 notifies user B through the IMS network that the call is transferred.
  • Step 611 The AS2 sends a call request message to the IMS, and carries the information learned from the AS 1 and the ID of the user C, that is, the ID-C and the ID of the user ID, that is, ID-AS2. Specifically, the AS includes the above information in the SIP INVITE message and forwards it through the IMS network.
  • Step 612 the IMS sends the information received by the AS2 to the user D.
  • Step 613 User D sends a media key request message to the KMS, and includes the identifier of the user D (including the public user identifier, if the general authentication mechanism GBA is used in this process, and the GB A identifier, that is, the BTID) and the slave Information received at AS2 (including cryptographic binding information) and call forwarding indication.
  • the identifier of the user D including the public user identifier, if the general authentication mechanism GBA is used in this process, and the GB A identifier, that is, the BTID
  • the slave Information received at AS2 including cryptographic binding information
  • Step 614 The KMS sends the query request to the AS2 according to the AS2 identifier according to the call forwarding indication included in the information, and the query request includes at least ID-B, ID-C, ID-D, and ID-AS1.
  • Step 615 AS2 according to the user C identification to query whether the user D is the call forwarding target set by the user C, and if so, proceed to step 615b, if not, perform step 615a;
  • Step 615a AS2 returns a query feedback message indicating "error" to the KMS, and the KMS returns corresponding error information to the relevant device to terminate the process.
  • Step 615b AS2 continues to send a query request message to AS1 according to the identifier of AS1, requesting The message contains ID-B, ID-C.
  • Step 616 AS1 queries, according to the identifier of the user B, whether the user C is the call forwarding target set by the user B, and if yes, returns a query feedback message indicating “correct” to the AS2, and if not, returns an indication “error” to the AS2. Query feedback messages.
  • step 617 AS2 forwards the query result to the KMS. If KMS receives "correct” feedback, proceed to the next step; if you receive "error” feedback, return the corresponding error message and terminate the process.
  • Step 618 The KMS decrypts the media key information in the ticket, encrypts the media key information with the shared key of the user D, generates RESOLVE_RESP, and returns the RESOLVE_RESP message to the user D in the message.
  • Steps 619-621 the user D receives the RESOLVE_RESP message, obtains the media key information contained in the ticket decrypted by the KMS, generates a TRANSFER_RESP message, and includes the message in the 200Ok message and replies to the user A through the IMS network.
  • step 622 user A and user D establish a connection and interact with the secure media stream.
  • User A and User D can obtain key information of the encrypted media stream, thereby performing end-to-end secure encrypted media stream communication.
  • the KMS sends the forwarded party identifier to the AS during the call transfer process, and the AS returns the call forwarding target list set by the forwarded party, and the KMS determines that the call is forwarded according to the list.
  • the process of the key management server obtaining the called party information of the called party through the application server includes: returning, by the application server, the called party according to the called party information provided by the key management server Call forwarding user identification list; the key management server determines whether the called party is a legal called party of the called party.
  • This first implementation is applicable to both call forwarding scenarios, one for a single call transfer and the other for multiple call transfers.
  • the called party In the case of a single call transfer, after the called party receives the call request message sent by the call server to which the called party belongs, it sends a media key request message to the key management server and carries the identifier of the called party.
  • the key management server sends an inquiry message to the call server to which the called party belongs, and carries the called party identifier in the query message, where the called party belongs to the call server Sending the call forwarding target list set by the called party to the key management server, and when the key management server checks that the identifier of the called party is located in the list, determining that the called party is Legally transferred party.
  • FIG. 7 is a schematic diagram of a method for implementing secure call forwarding in a single call transfer, where user A is the calling party, user B is the called party, and user C is the call forwarding target set by user B, that is, the called party, and the AS is the Call the call server to which the party belongs.
  • Steps 701 to 709 are the same as steps 501 to 509.
  • Step 710 The KMS sends the query request to the AS according to the call forwarding indication included in the information, and the called party identifier is ID-B.
  • Step 711 The AS queries the call forwarding target list set by the user B according to the user B identifier, ID-B, and returns the list to the KMS.
  • Step 712 the KMS determines whether the identifier of the user C is in the list, and if so, proceeds to the next step; otherwise, terminates the session.
  • Step 713 The KMS decrypts the media key information in the ticket, encrypts the media key information with the shared key of the user C, generates a RESOLVE_RESP, and returns the RESOLVE_RESP message to the user C in the message.
  • Steps 714-715 user C obtains the media key information contained in the ticket decrypted by the KMS, generates a TRANSFER_RESP message, and includes the message in the 200Ok message and replies to the user A through the IMS network.
  • step 716 user A and user C establish a connection and interact with the secure media stream.
  • User A and User C can obtain key information of the encrypted media stream, thereby performing end-to-end secure encrypted media stream communication.
  • the call server to which the called party belongs in each call transfer sends a call request message to the call server to which the called party belongs to the current call, and is finally called by the calling party.
  • the media key request message is sent to the key management server and carries the identifier of the finally called party.
  • the key management server sends an inquiry message to the call server to which the second-order called party belongs and carries the second-end called party.
  • the identifier of the called party is judged according to the returned call forwarding target list; and so on; the key management server receives the call forwarding target list set by the called party returned by the called server to which the called party belongs, and determines that the first is transferred When the identity of the calling party is located in this list, it is determined that the final called party is a legitimate called party.
  • the key management server of the present invention includes:
  • a message receiving module configured to receive a media key request message of the called party of the call
  • an authentication module configured to authenticate the called party according to the call forwarding information of the called party provided by the application server.
  • the authentication module is configured to determine, according to the encrypted binding relationship information of the called party and the called party that is provided by the application server, whether the called party is the legality of the called party.
  • the called party is forwarded; the encrypted binding relationship information is carried in the media key request message.
  • the key management server further includes a message sending module, configured to send a request message carrying the called party information to the application server, requesting the application server to return a call forwarding user identifier list of the called party;
  • the authentication module is configured to determine, according to the call forwarding user identifier list of the called party returned by the application server, whether the called party is a legal called party of the called party.
  • the key management server further includes a message sending module, configured to send, to the application server, a request message that carries the called party and the called party information, requesting the application server to determine whether the called party is The legally called party of the called party;
  • the authentication module is configured to learn, according to the judgment result returned by the application server, whether the called party is a legal called party of the called party.
  • the application server of the present invention includes:
  • a determining module configured to determine, according to the information of the called party and the called party provided by the key management server, whether the called party is a legal called party of the called party;
  • the call server may directly communicate with the key management server KMS, or may communicate through the intermediate network element, for example, by a Bootstrapping Service Function (BSF) server.
  • BSF Bootstrapping Service Function
  • each user and the AS can establish a trust relationship with the KMS through the GBA.
  • each user and the AS establish a shared key with the KMS. If the GBA cannot be used, the user can use other authentication methods and KMS gets the shared key.
  • the specific implementation is a common technical means by those skilled in the art, and details are not described herein again.
  • the shared keys of the user terminals A, B, C, AS and KMS are respectively Ka, Kb, Kc, Kas, and a secure channel has been established between them and the KMS, correspondingly
  • the GBA logos are BTIDa, BTIDb, BTIDc, BTIDas.
  • the present invention provides a new key agreement mechanism for implementing secure call forwarding in an IMS system, and substantially retains the message format in the original IMS system.

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • General Engineering & Computer Science (AREA)
  • Computing Systems (AREA)
  • Computer Hardware Design (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Multimedia (AREA)
  • Technology Law (AREA)
  • Telephonic Communication Services (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

本发明公开了一种实现安全呼叫转移的方法、系统和装置，所述方法包括：主叫方呼叫被叫方，所述被叫方触发签约的呼叫转移业务；密钥管理服务器通过应用服务器获得所述被叫方合法的被转呼方信息；所述被转呼方从所述密钥管理服务器获得媒体密钥；所述主叫方与所述被转呼方建立呼叫连接。

Description

一种实现安全呼叫转移的方法、 系统及装置
技术领域
本发明涉及网络通信安全技术，尤指一种 IP多媒体子系统（ IP Multimedia Subsystem, 简称 IMS ) 中实现安全呼叫转移的方法、 系统及装置。 背景技术
在会话发起协议（ Session Initiation Protocol, 简称 SIP ) 系统中， 呼叫转 移 （communication diversion )是一项常用及实用的服务， 使得呼叫过程中启 用了此呼叫转移服务的被呼方处于不可达或忙碌或者其他状态时， 由被叫方 的呼叫服务器将此呼叫转移到被叫方事先设置的被转呼方的用户设备上， 从 而提高了呼叫的灵活可配置性。
呼叫转移包括以下几项业务类型： 遇忙呼叫转移 （CFB ) 、 无应答呼叫 转移（CFNR ) 、 无条件呼叫转移 （CFU ) 、 寻呼不可及转移 (CFNRc)、 未注 册时呼叫转移 (CFNL)和会话转移（CD )。 这项业务允许用户将其所有来话转 接到预先设置的另一个电话号码上或用户的语音信箱中。 在激活无条件呼叫 转移 （CFU ) 时系统还可以提供许可呼叫。 呼叫转移还包含特殊的多次转移 呼叫场景， 即用户 A呼叫用户 B, 用户 B使用呼叫转移业务， 呼叫被转移给 用户 C, 用户 C也使用了呼叫转移业务， 该呼叫被再次转移给用户 D。
下面简要介绍一下呼叫转移业务中呼叫服务器通过 IMS网络向被转呼方 发出的呼叫请求消息（协议中定义为 INVITE消息， 此消息基于 SIP协议） 。 发生呼叫转移时， 呼叫服务器从主叫方收到包含票据（ticket ) 的 INVITE消 息， 并将此消息转发给被转呼方， 而且在此消息中增加一用于表示呼叫转移 的类型的 CAUSE参数 ( CAUSE参数表示使用了呼叫转移业务及其类型）具 体用法及说明参见 RFC4458和 TS24.604 v9.2.0。
例如， 呼叫方为用户 1 , 其标识为 userl_publicl@homel.net, 被叫方为用 户 2, 其标识为 user2_publicl@homel.net, 用户 2启用无条件呼叫转移服务， 设置呼叫转移的目标为用户 3 , 其标识为 User-3@example.com, 用户 2所属 呼叫服务器将用户 1 对用户 2 的呼叫转发至用户 3 , 并在向用户 3发送的 INVITE消息中携带 "CAUSE=302" 中的状态量， 取值为 302的参数表示该 呼叫类型为无条件呼叫转移。
现有的 3GPP TS33.328中 IMS媒体面安全中使用密钥管理服务器（Key Management Server, 简称 KMS ) ， 图 1为现有技术中基于 KMS的 IMS媒体 安全解决方案架构示意图， 其中： 用户 A ( UE-A )和用户 B ( UE-B )分别是 媒体信息的发送方和接收方； 密钥管理服务器（KMS )作为可信任的第三方 实现密钥的管理和分发功能； P-CSCF (代理-呼叫会话控制功能）和 S-CSCF (服务-呼叫会话控制功能）为 IMS网络中的网元； 其它网元的功能介绍请参 考相关文档。
图 2中现有技术中基于 KMS的呼叫过程的示意图。在主叫方与被叫方的 呼叫建立过程中， 主叫方向 KMS发送请求消息 （ REQUEST-INT )请求相关 密钥及票据（ticket ) , KMS 向主叫方返回响应消息 （ REQUEST-RESP ) , 在此响应消息中携带主叫方所请求的票据， 此票据基于被叫方的公共用户身 份标识， 且此票据中包含加密后的相关密钥以及呼叫方标识和被叫方标识， 主叫方通过传输消息（ TRANSFER-INIT )将此票据发送给被叫方， 由于被叫 方无法解密此票据， 将此票据通过解析消息（ RESOLVE-INIT )发送至 KMS, KMS解密此票据后解密票据并将其中相关密钥返回被叫方， KMS通过票据 获知被叫方标识， 并比较此票据中的被叫方标识与发送此 TRANSFER-INIT 消息的应答方的标识是否相同，如果相同则判定此应答方即为合法的被叫方。
在普通的呼叫过程中， 向 KMS发送 RESOLVE-INIT的应答方即为此呼 叫中的被叫方，可以顺利通过 KMS对被叫用户身份的鉴定；分叉呼叫场景下， 一个主叫方同时呼叫多个被叫方， 但此多个被叫方均对应于同一公共用户身 份标识， 所以多个应答终端也可以通过用户身份鉴定； 而在呼叫转移场景下， 被转呼方可以由使用该服务的用户随时任意设定， 最终应答方可能与原始被 叫方分别拥有不同的公共用户身份标识， 此情况下， 上述基于被叫方的公共 用户身份标识的鉴权方法将不再适用， 导致无法对应答方的身份进行鉴定， 从而导致呼叫失败。 所以需要新的解决方案实现安全的呼叫转移。 发明内容
本发明要解决的技术问题是提供一种实现安全呼叫转移的方法、 系统和 装置， 实现被转呼方身份鉴定， 从而在 IMS系统中实现安全呼叫转移。
为解决上述技术问题， 本发明提供了一种实现安全呼叫转移的方法， 所 述方法包括：
主叫方呼叫被叫方， 所述被叫方触发签约的呼叫转移业务；
密钥管理服务器通过应用服务器获得所述被叫方合法的被转呼方信息； 所述被转呼方从所述密钥管理服务器获得媒体密钥； 以及
所述主叫方与所述被转呼方建立呼叫连接。
上述方法还具有以下特点：
所述密钥管理服务器通过应用服务器获得所述被叫方合法的被转呼方信 息的步骤包括：
所述应用服务器在呼叫请求消息中携带所述被叫方与所述被转呼方的加 密的绑定关系信息并将呼叫请求消息发送给所述被转呼方； 以及
所述密钥管理服务器根据被转呼方发送的携带所述加密的绑定关系信息 的消息， 判断所述被转呼方是否为所述被叫方的合法被转呼方。
上述方法还具有以下特点：
被叫方与所述被转呼方的加密的绑定关系信息包括本次呼叫转移中被叫 方标识与被转呼方标识的加密绑定信息以及之前历次呼叫转移中被叫方标识 与被转呼方标识的加密绑定信息。
上述方法还具有以下特点：
所述密钥管理服务器通过应用服务器获得所述被叫方合法的被转呼方信 息的步骤包括：
所述应用服务器根据所述密钥管理服务器提供的所述被叫方与被转呼方 的信息， 判断所述被转呼方是否为所述被叫方的合法被转呼方并将判断结果 反馈给所述密钥管理服务器。
上述方法还具有以下特点： 所述密钥管理服务器通过应用服务器获得所述被叫方合法的被转呼方信 息的步骤包括：
所述应用服务器根据所述密钥管理服务器提供的所述被叫方信息， 向所 述密钥管理服务器返回所述被叫方呼叫转移用户标识列表；
所述密钥管理服务器根据所述被叫方呼叫转移用户标识列表判断所述被 转呼方是否为所述被叫方的合法被转呼方。
为解决上述技术问题， 本发明还提供一种实现安全呼叫转移的系统， 所 述系统包括： 主叫方， 被叫方， 被转呼方， 应用服务器和密钥管理服务器； 所述主叫方设置为： 呼叫被叫方；
所述被叫方设置为： 根据所述主叫方的呼叫， 触发签约的呼叫转移业务； 所述密钥管理服务器设置为： 通过所述应用服务器获得所述被叫方合法 的被转呼方信息；
所述被转呼方设置为： 从所述密钥管理服务器获得媒体密钥。
上述系统还具有以下特点：
所述应用服务器设置为： 在呼叫请求消息中携带所述被叫方与被转呼方 的加密的绑定关系信息并将所述呼叫请求消息发送给所述被转呼方；
所述密钥管理服务器是设置为： 根据所述被转呼方发送的携带所述加密 的绑定关系信息的消息， 判断所述被转呼方是否为所述被叫方的合法被转呼 方。
上述系统还具有以下特点：
所述应用服务器是设置为： 向所述被转呼方发送呼叫请求消息， 并在此 消息中携带本次呼叫转移中所述被叫方标识与所述被转呼方标识的加密绑定 信息以及之前历次呼叫转移中被叫方标识与被转呼方标识的加密绑定信息。
上述系统还具有以下特点：
所述应用服务器设置为： 根据所述密钥管理服务器提供的所述被叫方与 被转呼方的信息， 判断所述被转呼方是否为所述被叫方的合法被转呼方并将 判断结果反馈给所述密钥管理服务器。 上述系统还具有以下特点：
所述应用服务器设置为： 根据所述密钥管理服务器提供的所述被叫方信 息， 向所述密钥管理服务器返回所述被叫方呼叫转移用户标识列表；
所述密钥管理服务器是设置为： 根据所述被叫方呼叫转移用户标识列表 判断所述被转呼方是否为所述被叫方的合法被转呼方。
为解决上述技术问题， 本发明还提供了一种密钥管理服务器， 其包括： 消息接收模块， 其设置为： 接收呼叫的被转呼方的媒体密钥请求消息； 鉴权模块， 其设置为： 根据应用服务器提供的被叫方的呼叫转接信息对 所述被转呼方进行鉴权。
上述密钥管理服务器还具有以下特点：
所述鉴权模块是设置为： 根据所述应用服务器提供的所述被叫方与被转 呼方的加密的绑定关系信息， 判断所述被转呼方是否为所述被叫方的合法被 转呼方； 所述加密的绑定关系信息携带在所述媒体密钥请求消息中。
上述密钥管理服务器还具有以下特点：
所述密钥管理服务器还包括消息发送模块；
所述消息发送模块设置为： 向所述应用服务器发送携带所述被叫方信息 的请求消息，请求所述应用服务器返回所述被叫方的呼叫转移用户标识列表； 所述鉴权模块是设置为： 根据所述应用服务器返回的所述被叫方的呼叫 转移用户标识列表判断所述被转呼方是否为所述被叫方的合法被转呼方。
上述密钥管理服务器还具有以下特点：
所述密钥管理服务器还包括消息发送模块；
所述消息发送模块设置为： 向所述应用服务器发送携带所述被叫方和所 述被转呼方信息的请求消息， 请求所述应用服务器判断所述被转呼方是否为 所述被叫方的合法被转呼方；
所述鉴权模块是设置为： 根据所述应用服务器返回的判断结果获知所述 被转呼方是否为所述被叫方的合法被转呼方。
为解决上述技术问题， 本发明还提供了一种应用服务器， 其包括： 判断 模块， 其设置为： 根据密钥管理服务器提供的被叫方与被转呼方的信息， 判 断所述被转呼方是否为所述被叫方的合法被转呼方；
发送模块， 其设置为： 将判断结果反馈给所述密钥管理服务器。
本发明提供了一种新的密钥协商机制在 IMS 系统中实现安全的呼叫转 移， 并且本发明中基本保留了原 IMS系统中的消息格式。
附图概述
图 1为现有技术中基于 KMS的 IMS媒体安全解决方案架构示意图； 图 2中现有技术中基于 KMS的呼叫过程的示意图；
图 3是实施例中实现安全呼叫转移的方法的示意图；
图 4是实施例一的单次呼叫转移中实现安全呼叫转移的方法示意图； 图 5是实施例二中使用第一种查询方式的单次呼叫转移中实现安全呼叫 转移的方法示意图；
图 6是实施例二中使用第一种查询方式的多次呼叫转移中实现安全呼叫 转移的方法示意图；
图 7是实施例二中使用第二种查询方式的单次呼叫转移中实现安全呼叫 转移的方法示意图。 本发明的较佳实施方式
本发明中实现安全呼叫转移的系统包括： 主叫方， 被叫方， 被转呼方， 应用服务器， 密钥管理服务器（此处是用于实现密钥的管理和分发的可信任 的第三方的统称） 。 被叫方将被转呼方设定为呼叫转移目标， 触发所述被叫 方签约的呼叫转移业务的情况，是以下情况之一： 无条件转移、无应答转移、 寻呼不可及转移、 用户忙转移、 会话转移业务、 未注册时呼叫转移。 应用服 务器可用为呼叫转移服务器。 应用服务器作为被叫方所属呼叫服务器时， 用 于在收到主叫方对被叫方的呼叫后向被转呼方发送呼叫请求消息。 其中： 主叫方， 用于呼叫被叫方；
被叫方， 用于根据所述主叫方的呼叫， 触发签约的呼叫转移业务； 密钥管理服务器， 用于通过应用服务器获得所述被叫方合法的被转呼方 信息；
所述被转呼方， 用于从所述密钥管理服务器获得媒体密钥。
本系统的第一种实现方式应用于单次呼叫转移情况时， 呼叫转移过程涉 及三方用户： 主叫方， 被叫方和被转呼方。 应用服务器， 用于在呼叫请求消 息中携带所述被叫方与被转呼方的加密的绑定关系信息并将呼叫请求消息发 送给所述被转呼方； 所述密钥管理服务器， 用于根据被转呼方发送的携带所 述加密的绑定关系信息的消息， 判断所述被转呼方是否为所述被叫方的合法 被转呼方。
具体应用中：
所述被转呼方用于收到所述呼叫请求消息后向所述密钥管理服务器发送 媒体密钥请求时携带此被转呼方的标识及所述加密绑定信息； 所述密钥管理 服务器， 用于验证所述加密绑定消息中的被转呼方标识与所述被转呼方发送 的媒体密钥请求中携带的被转呼方标识一致时， 确定所述被转呼方是合法的 被转呼方。
本系统的第一种实现方式中应用于多次呼叫转移情况时， 呼叫转移过程 涉及多方用户， 包括： 主叫方， 被叫方， 以及多个被转呼方。 按照多次呼叫 转移的时间先后顺序被转呼方依次为： 第一被转呼方， 第二被转呼方， ... ... , 次终被转呼方， 最终被转呼方， 其中被叫方， 第一被转呼方， 第二被转呼 方， ... ...， 次终被转呼方分别对应一呼叫服务器。
应用服务器作为多次呼叫转移中一次呼叫转移过程中被叫方的呼叫服务 器， 用于向被转呼方所属呼叫服务器发送呼叫请求消息， 并在此消息中携带 本次呼叫转移中被叫方标识与被转呼方标识的加密绑定信息， 以及之前历次 呼叫转移过程中的被叫方标识与被转呼方标识的加密绑定信息； 最终被转呼方， 用于收到呼叫请求消息后向密钥管理服务器发送媒体密 钥请求消息中携带最终被转呼标识以及历次呼叫转移中的加密绑定信息； 所述密钥管理服务器， 用于收到媒体密钥请求消息后验证所述媒体密钥 请求消息中携带的最终被转呼方标识与最后一次呼叫转移的加密绑定信息中 的最终被转呼方的标识一致时， 按照加密绑定信息生成的时间从后至前的顺 序依次验证各加密绑定信息中被转呼方的标识且均验证成功时， 确定所述最 终被转呼方是合法的被转呼方。
本系统的第二种实现方式中使用第一种查询方式时， 应用服务器用于根 据密钥管理服务器提供的所述被叫方与被转呼方的信息， 判断所述被转呼方 是否为所述被叫方的合法被转呼方并反馈给所述密钥管理服务器。
本系统的第二种实现方式中使用第一种查询方式并且应用于单次呼叫转 移情况， 呼叫转移过程涉及三方用户： 主叫方， 被叫方和被转呼方。
被转呼方， 用于收到被叫方所属呼叫服务器发送的呼叫请求消息后， 向 所述密钥管理服务器发送媒体密钥请求消息并携带被转呼方的标识；
所述密钥管理服务器， 用于收到所述媒体密钥请求消息后向所述被叫方 所属呼叫服务器发送查询消息， 并在此查询消息中携带所述被叫方和所述被 转呼方的标识； 还用于收到所述呼叫服务器返回的成功确认消息后确定所述 被转呼方是合法的被转呼方；
所述被叫方所属呼叫服务器， 用于收到所述查询消息后判断所述被转呼 方是所述被叫方设置的呼叫转移目标时将成功确认消息通知至所述密钥管理 服务器。
本系统的第二种实现方式中使用第一种查询方式并且应用于多次呼叫转 移情况， 呼叫转移过程涉及多个用户包括： 主叫方， 被叫方， 以及多个被转 呼方。 按照多次呼叫转移的时间先后顺序被转呼方依次为： 第一被转呼方， 第二被转呼方， ... ...， 次终被转呼方， 最终被转呼方， 其中被叫方， 第一被 转呼方， 第二被转呼方， ... ...， 次终被转呼方分别对应一呼叫服务器。
被叫方所属呼叫服务器， 用于收到查询消息并判定第一被转呼方是被叫 方设置的呼叫转移目标时， 通过各呼叫服务器将成功确认消息通知至密钥管 理服务器；
作为多次呼叫转移的一次呼叫转移中被叫方的呼叫服务器， 用于向本次 呼叫转移中的被转呼方发送呼叫请求消息， 并携带本次呼叫转移中被叫方标 识以及之前历次呼叫转移过程中的被叫方标识； 还用于从本次呼叫转移中的 被转呼方所属呼叫服务器收到查询消息并判定此本次呼叫转移中被转呼方为 本次呼叫转移中被叫方设置的呼叫转移目标时， 向被叫方的上一被转呼方所 属呼叫服务器发送查询消息， 携带被叫方与本次被转呼方之间历次呼呼转移 过程中所有被呼方标识；
所述最终被转呼方， 用于从次终被转呼方所属呼叫服务器收到呼叫请求 消息后向密钥管理服务器发送媒体密钥请求消息并携带最终被转呼方的标识 以及历次呼叫转移过程中的被叫方标识；
所述密钥管理服务器， 用于收到媒体密钥请求消息后向次终被转呼方所 属呼叫服务器发送查询消息并携带历次呼叫转移过程中所有被叫方标识； 还 用于收到此成功确认消息后确定所述最终被转呼方是合法的被转呼方。
本系统的第二种实现方式中使用第二种查询方式时， 应用服务器用于根 据所述密钥管理服务器提供的所述被叫方信息， 返回所述被叫方呼叫转移用 户标识列表； 所述密钥管理服务器， 用于判断所述被转呼方是否为所述被叫 方的合法被转呼方。
本系统的第二种实现方式使用第二种查询方式并且应用于单次呼叫转移 情况， 呼叫转移过程涉及三方用户： 主叫方、 被叫方及被转呼方。
所述被转呼方， 用于收到所述被叫方所属呼叫服务器发送的呼叫请求消 息后，向所述密钥管理服务器发送媒体密钥请求消息并携带被转呼方的标识； 所述密钥管理服务器， 用于从所述被转呼方收到媒体密钥请求消息后， 向所述被叫方所属呼叫服务器发送查询消息， 并在此查询消息中携带所述被 叫方标识；还用于从呼叫服务器收到所述被叫方设置的呼叫转移目标列表后， 判定所述被转呼方的标识位于此列表中时， 确定所述被转呼方是合法的被转 呼方；
所述呼叫服务器， 用于从密钥管理服务器收到查询消息后， 将所述被叫 方设置的呼叫转移目标列表发送至所述密钥管理服务器。
本系统的第二种实现方式中使用第二种查询方式并且应用于多次呼叫转 移情况， 呼叫转移过程涉及多方用户包括： 主叫方， 被叫方， 以及多个被转 呼方。 按照多次呼叫转移的时间先后顺序被转呼方依次为： 第一被转呼方， 第二被转呼方， ... ...， 次终被转呼方， 最终被转呼方， 其中被叫方， 第一被 转呼方， 第二被转呼方， ... ...， 次终被转呼方分别对应一呼叫服务器。
作为多次呼叫转移中一次呼叫转移中被叫方所属呼叫服务器， 用于向本 次呼叫转移中的被转呼方发送呼叫请求消息； 还用于收到密钥管理服务器发 送的查询消息后， 将本身执行的呼叫转移过程中的被叫方设置的呼叫转移目 标列表发送至密钥管理服务器；
所述最终被转呼方， 用于在收到呼叫请求消息后向密钥管理服务器发送 媒体密钥请求消息并携带最终被转呼方的标识；
所述密钥管理服务器， 用于从最终被转呼方收到媒体密钥请求消息后， 向次终被叫方所属呼叫服务器发送查询消息并携带次终被转呼方的标识； 还 用于在从一呼叫服务器收到列表后， 判断此呼叫服务器对应的被转呼方位于 此列表后， 按各次呼叫转移执行时间从后向前的顺序， 向此呼叫服务器的前 一呼叫服务器发送查询消息， 并携带此前一呼叫服务器对应的被转呼方的标 识； 还用于收到被叫方所属呼叫服务器返回的被叫方设置的呼叫转移目标列 表并判断第一被转呼方的标识位于此列表中时， 确定所述最终被转呼方是合 法的被转呼方。
对应于上述系统， 如图 3所示， 实现安全呼叫转移的方法包括： 主叫方 呼叫被叫方， 所述被叫方触发签约的呼叫转移业务； 密钥管理服务器通过应 用服务器获得所述被叫方合法的被转呼方信息； 所述被转呼方从所述密钥管 理服务器获得媒体密钥； 所述主叫方与所述被转呼方建立呼叫连接。
本发明中， 触发所述被叫方签约的呼叫转移业务的情况， 是以下情况之 一： 无条件转移、 无应答转移、 寻呼不可及转移、 用户忙转移、 会话转移业 务、 未注册时呼叫转移。
本发明的方法中， 由密钥管理服务器对被转呼方进行鉴权， 保证呼叫转 移的安全实现。 本发明适用一次呼叫转移以及多次呼叫转移。
下面通过多个实施例对本发明作详细的说明。
实施例一
本实施例一适用于两种呼叫转移的情况， 一种为单次呼叫转移， 另一种 为多次呼叫转移。
在单次呼叫转移情况时， 密钥管理服务器通过应用服务器获得所述被叫 方合法的被转呼方信息的过程包括： 应用服务器在呼叫请求消息中携带所述 被叫方与被转呼方的加密的绑定关系信息并将呼叫请求消息发送给所述被转 呼方； 所述密钥管理服务器根据被转呼方发送的携带所述加密的绑定关系信 息的消息， 判断所述被转呼方是否为所述被叫方的合法被转呼方。
具体应用时， 被叫方所属呼叫服务器向被转呼方发送呼叫请求消息时， 在此呼叫请求消息中携带被叫方标识与被转呼方标识的加密绑定信息， 所述 被转呼方向所述密钥管理服务器发送媒体密钥请求时携带此被转呼方的标识 及所述加密绑定信息， 所述密钥管理服务器验证所述加密绑定消息中的被转 呼方标识与所述被转呼方发送的媒体密钥请求中携带的被转呼方标识一致 时， 确定所述被转呼方是合法的被转呼方。
被叫方所属呼叫服务器发送的加密绑定消息是指用此呼叫服务器与密钥 管理服务器的共享密钥加密后的被叫方标识与被转呼方标识的绑定信息； 密 钥管理服务器收到被转呼方发送的此加密绑定消息后， 用此共享密钥解密此 绑定消息。 如图 4为单次呼叫转移中实现安全呼叫转移的方法示意图， 用户 A为主 叫方， 用户 B为被叫方， 用户 C为用户 B设置的呼叫转移目标即被转呼方， AS为被叫方所属呼叫服务器。
步骤 401 ,用户 A向 KMS发送票据请求，申请呼叫用户 B所需要的票据。 步骤 402, KMS鉴定用户 A并生成相应票据发送至用户 A。
步骤 403 , 用户 A向 IMS网络发送呼叫请求消息， 并此呼叫请求消息中 携带票据（ticket ) , 具体的， 用户 A将包含 ticket的 TRANSFER— INIT消息 置于 SIP INVITE消息中发给 IMS网络。
步骤 404 , IMS网络将收到的 INVITE消息转发到被叫方所属的 AS。 步骤 405 406, 由于用户 B使用无条件呼叫转移服务， AS通过 IMS网络 通知用户 A该呼叫被转移。
步骤 407, AS根据用户 B设定的转移号码， 向 IMS网络发送呼叫请求消 息， 在并此呼叫请求消息中携带用户 B标识和用户 C标识的加密绑定信息。 此加密绑定消息是指用此 AS与 KMS的共享密钥 Kas加密的用户 B和用户 C 的绑定信息， 即 Eas(ID-B, ID-C); 还携带此 AS的标识（包括公共用户标识， 如果此过程中使用通用认证机制 GBA,还包括 GBA标识即 BTID )。具体的， AS将上述信息以及从用户 A收到的票据包含在 SIP INVITE消息中，通过 IMS 网络转发。
步骤 408, IMS网络将此 INVITE消息转发至用户 C。
步骤 409 ,用户 C收到 INVITE消息后，向 KMS发送媒体密钥请求消息， 并在此消息中包含用户 C标识（包括公共用户标识， 如果此过程中使用通用 认证机制 GBA, 还包括 GBA标识即 BTID ) 以及从 AS处收到的信息 （包括 加密绑定信息） 以及呼叫转移指示。
步骤 410, KMS根据信息中包含的呼叫转移指示或 AS的信息可知此呼 叫为呼叫转移， 根据 AS的标识找到 KMS与呼叫服务器的共享密钥 Kas, 解 密消息中用 Kas加密的绑定信息， 获得 ID-B和 ID-C, 判断此绑定信息中的 用户 C标识与媒体密钥请求消息中携带的用户 C标识是否相同， 相同时， 表 明用户 C是合法被转用户，进一步解密 ticket中的媒体密钥信息，用与用户 C 的共享密钥加密媒体密钥信息，将成功响应置于 RESOLVE-RESP消息中； 不 相同时， 向用户 C返回失败响应， 终止此次呼叫。
步骤 411 , KMS将 RESOLVE— RESP消息置于响应报文中返回给用户 C。 步骤 412~415 ,用户 C收到 RESOLVE— RESP消息，获得 KMS解密的 ticket 中包含的媒体密钥信息， 生成 TRANSFER— RESP 消息， 并将该消息包含在 200Ok消息中通过 IMS网络回复给用户 A。
步骤 416, 用户 A和用户 C建立起连接， 交互安全媒体流。
通过以上流程， 用户 A和用户 C可获得加密媒体流的密钥信息， 从而进 行端到端安全的加密媒体流通信。
在多次转移呼叫的情况下， 当所述被叫方满足触发条件时， 所述被叫方 所属应用服务器向所述被转呼方发送呼叫请求消息， 所述消息中携带本次呼 叫转移中被叫方标识与被转呼方标识的加密绑定信息以及之前历次呼叫转移 中被叫方标识与被转呼方标识的加密绑定信息。
具体应用中， 在多次转移呼叫的每次转移呼叫过程中本次被叫方所属呼 叫服务器向本次转移呼叫中的被转呼方所属呼叫服务器发送呼叫请求消息 时， 在此呼叫请求消息中携带本次呼叫转移中被叫方标识与被转呼方标识的 加密绑定信息以及之前历次呼叫转移中被叫方标识与被转呼方标识的加密绑 定信息； 最终被转呼方向密钥管理服务器发送媒体密钥请求消息中携带最终 被转呼标识以及历次呼叫转移中的加密绑定信息； 密钥管理服务器验证所述 媒体密钥请求消息中的最终被转呼标识与最后一次呼叫转移的加密绑定信息 中的最终被转呼方的标识一致后， 按照加密绑定信息生成的时间从后至前的 顺序依次验证各加密绑定信息中被转呼方的标识且均验证成功时， 确定所述 最终被转呼方是合法的被转呼方。
呼叫服务器发送的加密绑定消息是指用此呼叫服务器与密钥管理服务器 的共享密钥加密后的被叫方标识与被转呼方标识的绑定信息； 密钥管理服务 器收到被转呼方发送的此加密绑定消息后， 用此共享密钥解密此绑定消息。 在实际应用时， 各呼叫服务器使用的共享密钥可以相同也可以不同。 实施例二
实施例二的第一种实现方式中， KMS将呼叫转移过程中被叫方标识以及 被转呼方标识发送至被叫方所属的 AS, 由 AS对被转呼方的合法性进行判定 后并通知至 KMS。 密钥管理服务器通过应用服务器获得所述被叫方合法的被 转呼方信息的过程包括： 所述应用服务器根据所述密钥管理服务器提供的所 述被叫方与被转呼方的信息， 判断所述被转呼方是否为所述被叫方的合法被 转呼方并反馈给所述密钥管理服务器。
此第一种实现方式适用于两种呼叫转移的情况， 一种为单次呼叫转移， 另一种为多次呼叫转移。
在单次呼叫转移情况中， 被转呼方收到被叫方所属呼叫服务器发送的呼 叫请求消息后， 向所述密钥管理服务器发送媒体密钥请求消息并携带被转呼 方的标识，所述密钥管理服务器向所述被叫方所属呼叫服务器发送查询消息， 并在此查询消息中携带所述被叫方和所述被转呼方的标识， 所述被叫方所属 呼叫服务器判断所述被转呼方是所述被叫方设置的呼叫转移目标时将成功确 认消息通知至所述密钥管理服务器， 所述密钥管理服务器确定所述被转呼方 是合法的被转呼方。
如图 5为单次呼叫转移中实现安全呼叫转移的方法示意图， 用户 A为主 叫方， 用户 B为被叫方， 用户 C为用户 B设置的呼叫转移目标即被转呼方， AS为被叫方所属呼叫服务器。
步骤 501~506与步骤 401~406对应相同。
步骤 507 , 此步骤与步骤 407的区别是， AS在 INVITE消息中包含被叫 方标识即 ID-B以及本身的标识即 ID-AS。
步骤 508, IMS网络将 INVITE消息转发给被用户 C。
步骤 509,用户 C收到 INVITE消息后，向 KMS发送媒体密钥请求消息， 并在此消息中包含用户 C标识（包括公共用户标识， 如果此过程中使用通用 认证机制 GBA, 还包括 GBA标识即 BTID ) 以及从 AS处收到的信息 （包括 加密绑定信息） 以及呼叫转移指示。
步骤 510, KMS才艮据信息中包含的呼叫转移指示可知该呼叫为呼叫转移 场景， 根据 AS标识向相应的 AS发送查询请求， 该查询请求中包含被叫方标 识即 ID-B和被转呼方标识即 ID-C。
步骤 511 , AS根据被叫方 ID-B查询 ID-C是否为用户 B设置的呼叫转移 目标时， 如果是， 向 KMS返回 "正确" 消息， 如果不是， 向 KMS返回 "错 误" 消息。 如果 KMS收到 "正确" 反馈， 则继续下一步骤； 如收到 "错误" 反馈， 则返回相应错误信息， 终止流程。
步骤 512, KMS解密 ticket中的媒体密钥信息， 用与用户 C的共享密钥 加密媒体密钥信息， 生成 RESOLVE— RESP, 将 RESOLVE— RESP消息在响应 报文中返回给用户 C。
步骤 513~516 ,用户 C收到 RESOLVE— RESP消息，获得 KMS解密的 ticket 中包含的媒体密钥信息， 生成 TRANSFER— RESP 消息， 并将该消息包含在 200Ok消息中通过 IMS网络回复给用户 A。
步骤 517, 用户 A和用户 C建立起连接， 交互安全媒体流。
通过以上过程， 用户 A和用户 C可获得加密媒体流的密钥信息， 从而进 行端到端安全的加密媒体流通信。
在多次转移呼叫的情况下， 多次转移呼叫的每次转移呼叫过程中本次转 移呼叫的被叫方所属呼叫服务器向本次呼叫转移的被转呼方发送呼叫请求消 息， 携带本次呼叫转移中被叫方标识以及之前历次呼叫转移过程中的被叫方 标识； 最终被转呼方向密钥管理服务器发送媒体密钥请求消息并携带最终被 转呼方的标识以及历次呼叫转移过程中的被叫方标识； 密钥管理服务器向次 终被转呼方所属呼叫服务器发送查询消息， 携带最终被转呼方的标识以及历 次呼叫转移过程中被叫方标识， 次终被转呼方所属呼叫服务器判定最终被转 呼方是次终被转呼方设置的呼叫转移目标时， 向次终被转呼方的上一被转呼 方所属呼叫服务器发送查询消息， 携带被叫方与本次被转呼方之间历次呼呼 转移过程中所有被呼方标识； 依此顺序执行； 被叫方所属呼叫服务器收到查 询消息并判定第一被转呼方是被叫方设置的呼叫转移目标时， 通过各呼叫服 务器将成功确认消息通知至密钥管理服务器后， 密钥管理服务器确定所述最 终被转呼方是合法的被转呼方。
如图 6为多次呼叫转移中实现安全呼叫转移的方法示意图， 用户 A为主 叫方， 用户 B为被叫方， 用户 C为用户 B设置的呼叫转移目标， 用户 D为用 户 C设置的呼叫转移目标， 用户 B用户 C都使用无条件呼叫转移服务， AS1 为用户 B所属呼叫服务器， AS2为用户 C所属呼叫服务器。
步骤 601~606与步骤 401~406对应相同。
步骤 607, AS1向 IMS发送呼叫请求消息， 并在此呼叫请求消息中携带 从用户 A收到的票据以及用户 B的标识即 ID-B以及本身的标识即 ID-AS1。 具体的， AS将上述信息以及从用户 A收到的票据包含在 SIP INVITE消息中， 通过 IMS网络转发。
步骤 608, IMS网络将 INVITE消息转发到 AS2。
步骤 609 610, 由于用户 C使用无条件呼叫转移服务， AS2通过 IMS网 络通知用户 B该呼叫被转移。
步骤 611 , AS2向 IMS发送呼叫请求消息， 并在此呼叫请求消息中携带 从 AS 1获知的信息以及用户 C的标识即 ID-C以及本身的标识即 ID-AS2。 具 体的， AS将上述信息包含在 SIP INVITE消息中， 通过 IMS网络转发。
步骤 612, IMS将从 AS2收到的信息发给用户 D。
步骤 613 ,用户 D向 KMS发送媒体密钥请求消息， 并在此消息中包含用 户 D的标识（包括公共用户标识， 如果此过程中使用通用认证机制 GBA, 还 包括 GB A标识即 BTID ) 以及从 AS2处收到的信息（包括加密绑定信息）以 及呼叫转移指示。
步骤 614, KMS根据信息中包含的呼叫转移指示可知此呼叫为呼叫转移， 根据 AS2标识向 AS2发送查询请求，该查询请求中至少包含 ID-B , ID-C , ID-D 和 ID-AS1。
步骤 615, AS2根据用户 C标识查询用户 D是否是用户 C设置的呼叫转 移目标， 如果是， 则继续步骤 615b, 如果不是， 执行步骤 615a;
步骤 615a, AS2向 KMS返回指示 "错误" 的查询反馈消息， KMS向相 关设备返回相应错误信息， 终止流程。
步骤 615b, AS2根据 ASl的标识向 ASl继续发送查询请求消息， 请求 消息中包含 ID-B, ID-C。
步骤 616, AS1根据用户 B的标识查询用户 C是否是用户 B设置的呼叫 转移目标， 如果是， 则向 AS2返回指示 "正确" 的查询反馈消息， 如果不是， 则向 AS2返回指示 "错误" 的查询反馈消息。
步骤 617, AS2将查询结果转发给 KMS。 如果 KMS收到 "正确" 反馈， 则继续下一步骤； 如收到 "错误" 反馈， 则返回相应错误信息， 终止流程。
步骤 618, KMS解密 ticket中的媒体密钥信息， 用与用户 D的共享密钥 加密媒体密钥信息， 产生 RESOLVE— RESP, 将 RESOLVE— RESP消息在报文 中返回给用户 D。
步骤 619-621 ,用户 D收到 RESOLVE— RESP消息 ,获得 KMS解密的 ticket 中包含的媒体密钥信息， 生成 TRANSFER— RESP 消息， 并将该消息包含在 200Ok消息中通过 IMS网络回复给用户 A。
步骤 622, 用户 A和用户 D建立起连接， 交互安全媒体流。
通过以上过程， 用户 A和用户 D可获得加密媒体流的密钥信息， 从而进 行端到端安全的加密媒体流通信。
实施例二的第二种实现方式中， KMS将呼叫转移过程中被转呼方标识发 送至 AS进行查询， AS返回此被转呼方设置的呼叫转移目标列表， KMS根据 此列表判断此被转呼方的合法性。 密钥管理服务器通过应用服务器获得所述 被叫方合法的被转呼方信息的过程包括： 所述应用服务器根据所述密钥管理 服务器提供的所述被叫方信息， 返回所述被叫方呼叫转移用户标识列表； 所 述密钥管理服务器判断所述被转呼方是否为所述被叫方的合法被转呼方。
此第一种实现方式适用于两种呼叫转移的情况， 一种为单次呼叫转移， 另一种为多次呼叫转移。
在单次呼叫转移情况下， 被转呼方收到所述被叫方所属呼叫服务器发送 的呼叫请求消息后， 向所述密钥管理服务器发送媒体密钥请求消息并携带被 转呼方的标识， 所述密钥管理服务器向所述被叫方所属呼叫服务器发送查询 消息， 并在此查询消息中携带所述被叫方标识， 所述被叫方所属呼叫服务器 将所述被叫方设置的呼叫转移目标列表发送至所述密钥管理服务器， 所述密 钥管理服务器检查所述被转呼方的标识位于此列表中时， 确定所述被转呼方 是合法的被转呼方。
如图 7为单次呼叫转移中实现安全呼叫转移的方法示意图， 用户 A为主 叫方， 用户 B为被叫方， 用户 C为用户 B设置的呼叫转移目标即被转呼方， AS为被叫方所属呼叫服务器。
步骤 701~709与步骤 501~509对应相同。
步骤 710, KMS才艮据信息中包含的呼叫转移指示可知该呼叫为呼叫转移 场景， 向 AS发送查询请求， 该请求中包括被叫方标识即 ID-B。
步骤 711 , AS才艮据用户 B标识即 ID-B查询用户 B设置的呼叫转移目标 列表， 并将此列表返回至 KMS。
步骤 712, KMS判断用户 C的标识是否在所述列表中， 如果是， 则继续 下一步骤； 否则， 终止会话。 步骤 713 , KMS解密 ticket中的媒体密钥信息， 用与用户 C的共享密钥 加密媒体密钥信息， 产生 RESOLVE— RESP, 将 RESOLVE— RESP消息在报文 中返回给用户 C。
步骤 714~715, 用户 C获得 KMS解密的 ticket中包含的媒体密钥信息， 生成 TRANSFER— RESP消息， 并将该消息包含在 200Ok消息中通过 IMS网 络回复给用户 A。
步骤 716, 用户 A和用户 C建立起连接， 交互安全媒体流。
通过以上过程， 用户 A和用户 C可获得加密媒体流的密钥信息， 从而进 行端到端安全的加密媒体流通信。
在多次转移呼叫的情况下， 在多次转移呼叫下每次呼叫转移中被叫方所 属呼叫服务器向本次呼叫转移的被转呼方所属呼叫服务器发送呼叫请求消 息， 最终被转呼方收到呼叫请求消息后向密钥管理服务器发送媒体密钥请求 消息并携带最终被转呼方的标识， 密钥管理服务器向次终被叫方所属呼叫服 务器发送查询消息并携带次终被转呼方的标识， 从次终被转呼方所属呼叫服 务器收到次终被叫方设置的呼叫转移目标列表后， 检查最终被转呼方的标识 位于此列表中时， 按各次呼叫转移执行时间从后向前的顺序， 向次终被转呼 方的前一被转呼方所属呼叫服务器发送查询消息并携带次终被转呼方的前一 被转呼方的标识， 根据返回的呼叫转移目标列表进行判断； 依次类推； 密钥 管理服务器收到被叫方所属呼叫服务器返回的被叫方设置的呼叫转移目标列 表并判断第一被转呼方的标识位于此列表中时确定所述最终被转呼方是合法 的被转呼方。
本发明的密钥管理服务器， 包括：
消息接收模块， 用于接收呼叫的被转呼方的媒体密钥请求消息； 鉴权模块， 用于根据应用服务器提供的被叫方的呼叫转接信息对所述被 转呼方进行鉴权。
其中， 鉴权模块， 是用于根据所述应用服务器提供的所述被叫方与被转 呼方的加密的绑定关系信息， 判断所述被转呼方是否为所述被叫方的合法被 转呼方； 所述加密的绑定关系信息携带在所述媒体密钥请求消息中。
密钥管理服务器还包括消息发送模块， 用于向所述应用服务器发送携带 所述被叫方信息的请求消息， 请求所述应用服务器返回所述被叫方的呼叫转 移用户标识列表；
鉴权模块， 是用于根据所述应用服务器返回的所述被叫方的呼叫转移用 户标识列表判断所述被转呼方是否为所述被叫方的合法被转呼方。
密钥管理服务器还包括消息发送模块， 用于向所述应用服务器发送携带 所述被叫方和所述被转呼方信息的请求消息， 请求所述应用服务器判断所述 被转呼方是否为所述被叫方的合法被转呼方；
鉴权模块， 是用于根据所述应用服务器返回的判断结果获知所述被转呼 方是否为所述被叫方的合法被转呼方。
本发明的应用服务器， 包括：
判断模块， 用于根据密钥管理服务器提供的被叫方与被转呼方的信息， 判断所述被转呼方是否为所述被叫方的合法被转呼方；
发送模块， 用于将判断结果反馈给所述密钥管理服务器。 本发明中， 呼叫服务器可以与密钥管理服务器 KMS直接通信，也可以通 过中间网元进行通信， 例如通过引导服务功能 ( Bootstrapping Service Function ， 简称 BSF )服务器通信。
本发明中， 每个用户及 AS可以和 KMS通过 GBA方式建立信任关系， 通过密钥协商协议， 每个用户及 AS都和 KMS建立共享密钥， 如果 GBA无 法使用，用户可以使用其它认证方式和 KMS获得共享密钥。具体实现属于本 领域技术人员惯用技术手段， 这里不再赘述。 在本发明的所有场景安全解决 方法流程中， 用户终端 A,B,C,AS与 KMS的共享密钥分别为 Ka, Kb, Kc, Kas, 他们与 KMS之间均已经建立安全通道， 相应的 GBA标识为 BTIDa, BTIDb, BTIDc, BTIDas。
以上所述， 仅为本发明的较佳实施例而已， 并非用于限定本发明的保护 范围， 凡在本发明的精神和原则之内所作的任何修改、 等同替换和改进等， 均应包含在本发明的保护范围之内。
工业实用性
本发明提供了一种新的密钥协商机制在 IMS 系统中实现安全的呼叫转 移， 且基本保留了原 IMS系统中的消息格式。

Claims

权 利 要 求 书
1、 一种实现安全呼叫转移的方法， 所述方法包括：
主叫方呼叫被叫方， 所述被叫方触发签约的呼叫转移业务；
密钥管理服务器通过应用服务器获得所述被叫方合法的被转呼方信息； 所述被转呼方从所述密钥管理服务器获得媒体密钥； 以及
所述主叫方与所述被转呼方建立呼叫连接。
2、 如权利要求 1所述的方法， 其中，
所述密钥管理服务器通过应用服务器获得所述被叫方合法的被转呼方信 息的步骤包括：
所述应用服务器在呼叫请求消息中携带所述被叫方与所述被转呼方的加 密的绑定关系信息并将呼叫请求消息发送给所述被转呼方； 以及
所述密钥管理服务器根据被转呼方发送的携带所述加密的绑定关系信息 的消息， 判断所述被转呼方是否为所述被叫方的合法被转呼方。
3、 如权利要求 2所述的方法， 其中，
被叫方与所述被转呼方的加密的绑定关系信息包括本次呼叫转移中被叫 方标识与被转呼方标识的加密绑定信息以及之前历次呼叫转移中被叫方标识 与被转呼方标识的加密绑定信息。
4、 如权利要求 1所述的方法， 其中，
所述密钥管理服务器通过应用服务器获得所述被叫方合法的被转呼方信 息的步骤包括：
所述应用服务器根据所述密钥管理服务器提供的所述被叫方与被转呼方 的信息， 判断所述被转呼方是否为所述被叫方的合法被转呼方并将判断结果 反馈给所述密钥管理服务器。
5、 如权利要求 1所述的方法， 其中， 所述密钥管理服务器通过应用服务 器获得所述被叫方合法的被转呼方信息的步骤包括：
所述应用服务器根据所述密钥管理服务器提供的所述被叫方信息， 向所 述密钥管理服务器返回所述被叫方呼叫转移用户标识列表； 所述密钥管理服务器根据所述被叫方呼叫转移用户标识列表判断所述被 转呼方是否为所述被叫方的合法被转呼方。
6、 一种实现安全呼叫转移的系统， 所述系统包括： 主叫方， 被叫方， 被 转呼方， 应用服务器和密钥管理服务器；
所述主叫方设置为： 呼叫被叫方；
所述被叫方设置为： 根据所述主叫方的呼叫， 触发签约的呼叫转移业务； 所述密钥管理服务器设置为： 通过所述应用服务器获得所述被叫方合法 的被转呼方信息；
所述被转呼方设置为： 从所述密钥管理服务器获得媒体密钥。
7、 如权利要求 6所述的系统， 其中，
所述应用服务器设置为： 在呼叫请求消息中携带所述被叫方与被转呼方 的加密的绑定关系信息并将所述呼叫请求消息发送给所述被转呼方；
所述密钥管理服务器是设置为： 根据所述被转呼方发送的携带所述加密 的绑定关系信息的消息， 判断所述被转呼方是否为所述被叫方的合法被转呼 方。
8、 如权利要求 7所述的系统， 其中，
所述应用服务器是设置为： 向所述被转呼方发送呼叫请求消息， 并在此 消息中携带本次呼叫转移中所述被叫方标识与所述被转呼方标识的加密绑定 信息以及之前历次呼叫转移中被叫方标识与被转呼方标识的加密绑定信息。
9、 如权利要求 6所述的系统， 其中，
所述应用服务器设置为： 根据所述密钥管理服务器提供的所述被叫方与 被转呼方的信息， 判断所述被转呼方是否为所述被叫方的合法被转呼方并将 判断结果反馈给所述密钥管理服务器。
10、 如权利要求 6所述的系统， 其中，
所述应用服务器设置为： 根据所述密钥管理服务器提供的所述被叫方信 息， 向所述密钥管理服务器返回所述被叫方呼叫转移用户标识列表；
所述密钥管理服务器是设置为： 根据所述被叫方呼叫转移用户标识列表 判断所述被转呼方是否为所述被叫方的合法被转呼方。
11、 一种密钥管理服务器， 其包括：
消息接收模块， 其设置为： 接收呼叫的被转呼方的媒体密钥请求消息； 鉴权模块， 其设置为： 根据应用服务器提供的被叫方的呼叫转接信息对 所述被转呼方进行鉴权。
12、 如权利要求 11所述的密钥管理服务器， 其中，
所述鉴权模块是设置为： 根据所述应用服务器提供的所述被叫方与被转 呼方的加密的绑定关系信息， 判断所述被转呼方是否为所述被叫方的合法被 转呼方； 所述加密的绑定关系信息携带在所述媒体密钥请求消息中。
13、如权利要求 11所述的密钥管理服务器， 所述密钥管理服务器还包括 消息发送模块；
所述消息发送模块设置为： 向所述应用服务器发送携带所述被叫方信息 的请求消息，请求所述应用服务器返回所述被叫方的呼叫转移用户标识列表； 所述鉴权模块是设置为： 根据所述应用服务器返回的所述被叫方的呼叫 转移用户标识列表判断所述被转呼方是否为所述被叫方的合法被转呼方。
14、如权利要求 11所述的密钥管理服务器， 所述密钥管理服务器还包括 消息发送模块；
所述消息发送模块设置为： 向所述应用服务器发送携带所述被叫方和所 述被转呼方信息的请求消息， 请求所述应用服务器判断所述被转呼方是否为 所述被叫方的合法被转呼方；
所述鉴权模块是设置为： 根据所述应用服务器返回的判断结果获知所述 被转呼方是否为所述被叫方的合法被转呼方。
15、 一种应用服务器， 其包括： 判断模块， 其设置为： 根据密钥管理服 务器提供的被叫方与被转呼方的信息， 判断所述被转呼方是否为所述被叫方 的合法被转呼方；
发送模块， 其设置为： 将判断结果反馈给所述密钥管理服务器。
PCT/CN2011/071203 2010-04-21 2011-02-23 一种实现安全呼叫转移的方法、系统及装置 WO2011131055A1 (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP11771508.6A EP2563001B1 (en) 2010-04-21 2011-02-23 Method, system and apparatus for implementing secure call forwarding
US13/258,258 US9077806B2 (en) 2010-04-21 2011-02-23 Method, system and apparatus for implementing secure call forwarding

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201010154329.5 2010-04-21
CN201010154329.5A CN102238500B (zh) 2010-04-21 2010-04-21 一种实现安全呼叫转移的方法及系统

Publications (1)

Publication Number Publication Date
WO2011131055A1 true WO2011131055A1 (zh) 2011-10-27

Family

ID=44833689

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2011/071203 WO2011131055A1 (zh) 2010-04-21 2011-02-23 一种实现安全呼叫转移的方法、系统及装置

Country Status (4)

Country Link
US (1) US9077806B2 (zh)
EP (1) EP2563001B1 (zh)
CN (1) CN102238500B (zh)
WO (1) WO2011131055A1 (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103167449A (zh) * 2011-12-15 2013-06-19 中国电信股份有限公司 为通信终端本机设置呼叫转移的方法和系统

Families Citing this family (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9258692B2 (en) * 2012-03-30 2016-02-09 Qualcomm Incorporated Relay assisted peer discovery
US9042550B2 (en) 2012-03-30 2015-05-26 Qualcomm Incorporated Methods and apparatus for base station assisted peer discovery through aggregation of expressions
CN105813035B (zh) * 2014-12-30 2019-12-17 中国移动通信集团公司 一种识别保密语音业务的方法、系统和网络设备
CN106161374A (zh) 2015-04-13 2016-11-23 阿里巴巴集团控股有限公司 订单数据的交互方法及服务器
CN106157079A (zh) 2015-04-13 2016-11-23 阿里巴巴集团控股有限公司 订单数据的交互方法及服务器
CN106161807A (zh) 2015-04-13 2016-11-23 阿里巴巴集团控股有限公司 通信方法及服务器
CN113965648B (zh) * 2020-07-21 2024-05-07 中国移动通信集团山东有限公司 一种信息隐藏方法、装置和电子设备
CN114079650A (zh) * 2020-08-11 2022-02-22 华为技术有限公司 一种基于ims数据通道的通信方法及设备
CN112019636B (zh) 2020-09-11 2022-08-12 安康鸿天科技股份有限公司 一种基于ims系统的通信呼叫转移装置及方法
CN114866519B (zh) * 2022-07-01 2022-11-01 新华三技术有限公司 一种呼叫转移方法及装置

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030177099A1 (en) * 2002-03-12 2003-09-18 Worldcom, Inc. Policy control and billing support for call transfer in a session initiation protocol (SIP) network
CN101022601A (zh) * 2007-03-27 2007-08-22 华为技术有限公司 移动终端呼叫转移方法和装置
CN101150631A (zh) * 2007-09-20 2008-03-26 华为技术有限公司 一种设置呼叫转移的方法及其装置
CN101170612A (zh) * 2006-10-26 2008-04-30 国际商业机器公司 用于转移对蜂窝电话的指定呼叫的方法和系统
CN101316384A (zh) * 2007-05-31 2008-12-03 中兴通讯股份有限公司 一种实现呼叫转移业务的方法

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7213145B2 (en) * 2002-01-10 2007-05-01 Avaya Technology Corp. Method and apparatus for secure internet protocol communication in a call processing system
US20060212933A1 (en) * 2004-02-11 2006-09-21 Texas Instruments Incorporated Surveillance implementation in a voice over packet network
JP2008544597A (ja) * 2005-06-13 2008-12-04 ノキア シーメンス ネットワークス ゲゼルシャフト ミット ベシュレンクテル ハフツング ウント コンパニー コマンディトゲゼルシャフト サービスフィーチャ「ｓｉｐコール転送」の制御方法
US20070147600A1 (en) * 2005-12-22 2007-06-28 Nortel Networks Limited Multiple call origination
US8050407B2 (en) * 2006-04-12 2011-11-01 Oracle America, Inc. Method and system for protecting keys
US9124650B2 (en) * 2006-12-13 2015-09-01 Quickplay Media Inc. Digital rights management in a mobile environment
US8694783B2 (en) * 2007-01-22 2014-04-08 Samsung Electronics Co., Ltd. Lightweight secure authentication channel
WO2008118966A1 (en) * 2007-03-26 2008-10-02 Yunzhou Zhu System and method for user authentication with exposed and hidden keys
JP4396737B2 (ja) * 2007-07-17 2010-01-13 ソニー株式会社 情報処理装置、コンテンツ提供システム、および情報処理方法、並びにコンピュータ・プログラム
US8565436B2 (en) * 2008-12-15 2013-10-22 Ebay Inc. Secure self managed data (SSMD)
CN101719825A (zh) * 2009-04-30 2010-06-02 中兴通讯股份有限公司 Ip多媒体子系统中实现安全分叉呼叫会话的方法及系统
CN101729532B (zh) * 2009-06-26 2012-09-05 中兴通讯股份有限公司 一种ip多媒体子系统延迟媒体信息传输方法及系统
WO2011071423A1 (en) * 2009-12-07 2011-06-16 Telefonaktiebolaget L M Ericsson (Publ) Method and arrangement for enabling play-out of media

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030177099A1 (en) * 2002-03-12 2003-09-18 Worldcom, Inc. Policy control and billing support for call transfer in a session initiation protocol (SIP) network
CN101170612A (zh) * 2006-10-26 2008-04-30 国际商业机器公司 用于转移对蜂窝电话的指定呼叫的方法和系统
CN101022601A (zh) * 2007-03-27 2007-08-22 华为技术有限公司 移动终端呼叫转移方法和装置
CN101316384A (zh) * 2007-05-31 2008-12-03 中兴通讯股份有限公司 一种实现呼叫转移业务的方法
CN101150631A (zh) * 2007-09-20 2008-03-26 华为技术有限公司 一种设置呼叫转移的方法及其装置

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103167449A (zh) * 2011-12-15 2013-06-19 中国电信股份有限公司 为通信终端本机设置呼叫转移的方法和系统

Also Published As

Publication number Publication date
CN102238500A (zh) 2011-11-09
EP2563001A4 (en) 2014-02-19
EP2563001B1 (en) 2016-05-11
CN102238500B (zh) 2014-07-02
US20120207297A1 (en) 2012-08-16
EP2563001A1 (en) 2013-02-27
US9077806B2 (en) 2015-07-07

Similar Documents

Publication Publication Date Title
WO2011131055A1 (zh) 一种实现安全呼叫转移的方法、系统及装置
US9628271B2 (en) Key management for secure communication
US7574735B2 (en) Method and network element for providing secure access to a packet data network
JP5881949B2 (ja) Ｉｍｓシステムにおけるエンド・ツー・エッジのメディア保護のための方法および装置
CN102006294B (zh) Ims多媒体通信方法和系统、终端及ims核心网
US8131259B2 (en) Methods, systems, and apparatus for handling secure-voice-communication sessions
US8837737B2 (en) Key management in a communication network
KR101353209B1 (ko) 무선 통신 시스템 내의 멀티캐스트 통신 세션과 연관된 메시지의 보안
US7764945B2 (en) Method and apparatus for token distribution in session for future polling or subscription
US20080263648A1 (en) Secure conferencing over ip-based networks
WO2011022999A1 (zh) 一种终端对视频会议数据进行加密的方法及系统
JP2018522512A (ja) 複数のプレーンにわたるアイデンティティ管理のための方法及びシステム
CN101420413A (zh) 会话密钥协商方法、网络系统、认证服务器及网络设备
US20090070586A1 (en) Method, Device and Computer Program Product for the Encoded Transmission of Media Data Between the Media Server and the Subscriber Terminal
WO2010124482A1 (zh) Ip多媒体子系统中实现安全分叉呼叫会话的方法及系统
WO2008022554A1 (fr) Procédé de dispositif d'émission/réception de services d'urgence
WO2008089626A1 (fr) Procédé d'identification d'un appel malveillant
CN111756726A (zh) 一种支持国密算法的sip安全认证方法
US20130212646A1 (en) Usage authentication via intercept and challege for network services
WO2011131070A1 (zh) 基于密钥管理服务器的ims媒体安全的合法监听系统
WO2010115322A1 (zh) 预定义加入群组会话的加入实现方法和系统
JP4715946B2 (ja) 通知番号検証システム
JP4433895B2 (ja) 通知番号検証システム
WO2012174843A1 (zh) 一种实现端到端安全的密钥协商方法及系统
WO2011127765A1 (zh) 一种实现单一无线语音呼叫连续性安全的方法及系统

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: 11771508

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2011771508

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 13258258

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE