WO2009021453A1 - Procédé, système et dispositif de traitement pour réaliser une communication de service de différents types de messages - Google Patents

Procédé, système et dispositif de traitement pour réaliser une communication de service de différents types de messages Download PDF

Info

Publication number
WO2009021453A1
WO2009021453A1 PCT/CN2008/071955 CN2008071955W WO2009021453A1 WO 2009021453 A1 WO2009021453 A1 WO 2009021453A1 CN 2008071955 W CN2008071955 W CN 2008071955W WO 2009021453 A1 WO2009021453 A1 WO 2009021453A1
Authority
WO
WIPO (PCT)
Prior art keywords
sip message
type
called
message
interworking
Prior art date
Application number
PCT/CN2008/071955
Other languages
English (en)
Chinese (zh)
Inventor
Fang Chen
Original Assignee
Huawei Technologies Co., Ltd.
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 Huawei Technologies Co., Ltd. filed Critical Huawei Technologies Co., Ltd.
Publication of WO2009021453A1 publication Critical patent/WO2009021453A1/fr

Links

Classifications

    • 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]

Definitions

  • the present invention relates to the field of communications technologies, and in particular, to a method, system, and device for implementing service communication based on different types of messages of a Session Initiation Protocol (SIP).
  • SIP Session Initiation Protocol
  • IP Multimedia Subsystem is a subsystem supporting IP multimedia services proposed by the 3rd Generation Partnership Project Standardization Organization (3GPP) in Phase 5 (Release 5). Its core feature is the use of SIP protocol and The independence of access, so IMS is a multimedia control/call control platform on the IP domain, supporting both session and non-session multimedia services, providing a common service enabling platform for future multimedia applications. An important step in the evolution of the IP network (All IP Network) service provision system. With the rise and development of IMS-based access technologies, how to transform the existing traditional mobile terminal's message service into the service that the IMS terminal can provide, and reuse the existing mobile network short message service function entity and protocol as much as possible.
  • 3GPP 3rd Generation Partnership Project Standardization Organization
  • IMS IMS framework-based SIP based messaging services
  • IMS instant messaging
  • OMA Open Mobile Alliance
  • SMS Short Message Service
  • EMS Enhanced Short Message Service
  • 3GPP Inter-service interoperability is also a common concern of operators and a goal of the 3GPP standardization organization.
  • the short message in the traditional circuit/packet (CS/PS) domain described herein includes both SMS and EMS message services.
  • FIG. 1 is a network framework for implementing a traditional short message service using an IP terminal, which is proposed by the 3GPP, wherein a short message entity (SME), a short message service center (SM-SC), a short message mobile switching center gateway/short message interworking mobile switching center ( SMS-GMSC/SMS-IWMSC), home subscriber service
  • SME short message entity
  • SM-SC short message service center
  • SMS-GMSC/SMS-IWMSC short message mobile switching center gateway/short message interworking mobile switching center
  • HSS/HLR Home/Home Location Register
  • the SM-SC is used to store short messages
  • the SMS-GMSC is used to query the HSS/HLR for routing information when the terminal receives the short message
  • the SMS-IWMSC is used for authentication when the terminal sends the short message.
  • the short message centers applied in the network are all three devices integrating SM-SC, SMS-GMSC and SMS-IWMSC, and the three functional entities are not implemented as separate physical devices, so in the following, If there is no special description, the short message center or the traditional short message center represents the three integrated devices of SM-SC, SMS-GMSC and SMS-IWMSC.
  • the HSS/HLR is used to store user data information, including subscriber subscription data and routing information.
  • the network framework shown in Figure 1 also includes a charging gateway function/billing data function (CGF/CDF) and an online charging system (OCS).
  • CGF/CDF charging gateway function/billing data function
  • OCS online charging system
  • the IP Messaging Gateway (IP-Message-GW, hereinafter also referred to as IP-SM-GW in the figure) is a function of the Short Message/IMS messaging interworking Application Server.
  • IP-Message-GW hereinafter also referred to as IP-SM-GW in the figure
  • the message protocol (that is, the MAP protocol used between the IP-Message-GW and the GMSC/SMS-IWMSC, similar to the current MAP protocol, the MAP protocol between the MSC and the SGSN and the GMSC/SMS-IWMSC) Interworking including transport layer and service layer.
  • the interworking of the transport layer is the interworking of the SIP message service of the mobile application part protocol (MAP) short message and the traditional MAP short message service implemented by the original IP-SM-GW; the service level interworking is implemented by the SMI AS.
  • SIMPLE IM extended session initiation protocol
  • a user who supports IP access applies the short message service, it must first register with the IP-SM-GW.
  • the IP-SM-GW notifies the HSS that the user has registered and the IP-SM-GW address.
  • the HSS saves the user status as an IP connection. Status (IP Connected) and store the IP-SM-GW address of the corresponding user registration.
  • IP-SM-GW IP message gateway
  • CS/PS domain circuit domain and packet domain
  • the interworking gateway implements interworking between the SIP-based message and the traditional short message, such as decapsulating the SIP message encapsulating the MAP short message and encapsulating the MAP short message in the SIP message body.
  • the communication between the SIP-based message and the traditional short message service layer is realized, such as converting the message format of the SIP-based message and the MAP short message, and the processed message is correspondingly forwarded, and at the same time, the IP message For the received message, the gateway can also route the corresponding domain of the message according to the operator's policy and the user's preference setting.
  • Figure 2 shows the existing registration process for the interworking between SIP messages and traditional short messages at the transport layer.
  • Step 1 The user equipment (UE), that is, the IP client establishes an IP connection.
  • UE user equipment
  • Step 2 After the IP connection is established, the user registers with the Service Call Control Function (S-CSCF) entity through the IMS registration process.
  • S-CSCF Service Call Control Function
  • Step 3 During the registration process, the S-CSCF checks the initial filtering rules downloaded from the HSS.
  • the initial filtering rules are already specified in the existing protocol and will not be described in detail here.
  • Step 4 After successfully completing the IMS registration, the S-CSCF notifies the IP message gateway user of the registration status based on the initial filtering rule.
  • Step 5 The IP message gateway returns a successful response to the S-CSCF.
  • Step 6 The IP Messaging Gateway sends a third-party registration request to the HSS.
  • Step 7 The HSS stores the received information, and returns an IP-IWF (IP interworking function) registration response to the IP message gateway, including providing service-related subscription data.
  • IP-IWF IP interworking function
  • the UE has registered to the IP Messaging Gateway, and the IP Messaging Gateway has obtained service-related subscription data from the HSS.
  • the process of interworking between the traditional short message service and the SIP-based message service service level in the IMS-MO is as shown in FIG. 3.
  • Step 1 According to the IMS registration procedure, the UE is registered in the S-CSCF.
  • the IMS core such as the I-CSCF and the P-CSCF, are not displayed in the figure;
  • the registration process the UE has registered to the IP message gateway.
  • Step 2 The UE sends the SIP-based message to the S-CSCF through the IMS domain, in the message body.
  • a communication service identity (CSID) is used to identify whether the user has subscribed to the message interworking service.
  • Step 3 The S-CSCF performs an initial filtering rule check on the received SIP-based message, where the check includes that the feature tag of the SIP message is a pure IMS message "+g.oma.sip-im" , or the encapsulated IMS message "+g.3g p.smsip,,, or check whether the calling user has subscribed to the interworking service at the service level, or check whether the information identifier of the CSID carried in the SIP message is an interworking service at the service level. .
  • Step 4 When the feature tag carried by the SIP message is "+g.3gpp.smsip", that is, the encapsulated IMS message, the subsequent processing continues according to the processing of the IMS message encapsulated in the prior art; in other three cases, S- The CSCF4 BA SIP message is routed to the IP Messaging Gateway of the calling network.
  • Step 5 The IP message gateway of the calling network determines whether service level interworking is required according to the calling user preference and the operator policy. There are three possible situations: Interworking at the service level, processing by default, no service required. Interoperability at the level.
  • the IP message gateway authenticates the interworking service. If the authentication succeeds, the IP message gateway of the calling network converts the SIP-based message into a traditional short message format, and forwards the message after the conversion format. To the traditional short message system, the subsequent forwarding process is completed by the traditional short message system.
  • the IP address gateway of the calling network selects the network of the called domain to be delivered according to the identifier of the called user. If the called user is in the form of a TEL-URI, the IP message gateway of the calling network can have the configured number segment information or ENUM (Telephone).
  • the result of the query is whether the message is sent through IMSi or through the CS/PS domain.
  • the IP message gateway of the calling network authenticates the interworking service. If the authentication succeeds, the IP message gateway of the calling network converts the SIP-based message into a traditional short message format. Forwarding the converted format message to the traditional short message system, the traditional short message system completes the subsequent forwarding process. If the authentication is not successful, the IP message gateway of the calling network returns a failure report to the S-CSCF of the calling network; The delivered domain is selected as the IMS domain, and the message is forwarded to the called IMS network according to the existing IMS specification.
  • the IP message gateway selects the IMS domain according to the self-configured number segment information or the ENUM query result, and forwards the message to the called IMS network according to the existing IMS specification, if the IP message gateway cannot select the IMS.
  • the domain returns a failure report to the S-CSCF of the calling network. That is to say, if the service level interworking is not required, the IP message gateway cannot select the CS/PS domain, and only the IMS domain can send the message. If the IMS domain selection is unsuccessful, the failure report is returned.
  • Step 6 ⁇ 7 the IP message gateway sends the converted SIP-based message to the UE via the IMS network, where the response message can be directly returned after the IP message gateway completes the interworking service, or can wait in the IP message gateway.
  • the report sent by the called user returns (the delivery report) and returns.
  • the embodiments of the present invention provide a method, a system, and a device for processing a service communication based on different types of messages, so as to implement interworking between different types of SIP messages.
  • a method for processing different types of message service communication based on Session Initiation Protocol SIP comprising:
  • the interworking function entity in the called network side receives the first type of SIP message from the calling user terminal UE transmitted by the called side service call control function S-CSCF; converting the SIP message based on the first type into The second type of SIP message is transmitted to the called UE based on the second type of SIP message.
  • An interworking functional entity including:
  • a receiving unit configured to receive a first type of SIP message from the called side S-CSCF, and a message converting unit, configured to convert the first type of SIP message into a second type based SIP message;
  • a SIP-based system for communicating different types of message services including a primary called UE, an S-CSCF in a primary called network, where the called side S-CSCF is configured to receive a second from the calling user terminal UE
  • a type of SIP message the system further includes:
  • An interworking function entity located in the called network side, for receiving the base from the called side S-CSCF
  • the first type of SIP message converts the first type of SIP message into a second type based SIP message, and transmits the second type based SIP message to the called UE.
  • the interworking function format is converted by the interworking function entity in the called network, so that communication between different types of messages based on SIP is realized.
  • FIG. 1 is a schematic diagram of a network framework for implementing a conventional short message service using an IP terminal proposed by the existing 3GPP;
  • FIG. 2 is a schematic diagram of a registration process of an existing SIP-based message and a conventional short message interworking at a transport layer;
  • FIG. 3 is a schematic diagram of an existing IMS-MO process for interworking between a SIP message and a legacy short message at a service service level;
  • FIG. 4 is a schematic flowchart of a SIP-based different type of message implementation service communication processing method according to Embodiment 1 of the present invention.
  • Figure 5 is a specific embodiment of the first embodiment
  • Figure 6 is another embodiment of the first embodiment
  • Figure 7 is a specific embodiment of the second embodiment.
  • Embodiment 1 is a diagrammatic representation of Embodiment 1:
  • the SIP-based different type of message implementation processing method for the service communication includes: the called side S-CSCF receives the SIP message based on the first type from the calling user terminal UE, and the first type is based on the first type The SIP message is transmitted to the interworking function entity in the called network side; the interworking function entity in the called network side converts the SIP message based on the first type into a SIP message based on the second type, and the second message is based on the second A type of SIP message is transmitted to the called UE.
  • the interworking function entity located in the called network side can determine whether the service level interworking needs to be performed according to the obtained called user information (such as the called terminal capability/called user preference) or the operator policy, and the interworking service is checked.
  • the function of the conversion of the message format which may be located in an entity in the existing network, such as an IP message gateway, an SMI AS, or the like, or a newly added independent network. Body, or a new functional module on an existing network entity. It provides services to users through third-party registration of users.
  • the S-CSCF of the called side may further include: Determining, according to an initial filtering rule, whether the SIP message based on the first type needs to be transmitted to an interworking function entity in the called network side, and if so, performing a transfer operation; otherwise, directly according to the prior art
  • the SIP message is transmitted to the called UE.
  • the method further includes: determining whether service level interworking is required, and if yes, performing the The UE is called to perform interworking service authentication. After the service authentication succeeds, the SIP message based on the first type is converted into a SIP message based on the second type.
  • the method further includes: the called UE returns the response information to the calling UE.
  • FIG. 4 is a schematic flow chart showing a SIP-based different type of message implementation service communication processing method according to Embodiment 1 of the present invention.
  • the network entities related to the present embodiment are provided in the figure, and other network entities, such as the IMS core network entity S-CSCF, P-CSCF, etc., are associated with the prior art, and are not used again. Repeat the narrative.
  • Step 1 The calling IMS user constructs a message based on the first type of SIP, and sends a message to the interworking function (IWF) entity through the IMS Core, where the interworking function entity is located in the IMS network on the called side.
  • IWF interworking function
  • Step 2 The interworking function entity performs the interworking service processing, specifically: the interworking function entity has the obtained called user information, such as the capability of the called terminal and/or the called user preference, or the operator policy, etc., determining whether The service level interworking function is required. Therefore, the interworking function entity of the called side network can obtain related information through the capability information carried by the user when the third party is registered, or the information configured by the user through the Ut interface, to determine whether the service needs to be performed. Level of interoperability. If service level interworking is required, the interworking function entity also performs authentication of the interworking service. If the authentication succeeds, the interworking function entity can convert the message format, that is, the first type of SIP message is converted into the second type based.
  • Step 3 The interworking function entity forwards the formatted SIP message to the called IMS user based on the second type of SIP message through the IMS core.
  • Steps 4 ⁇ 5 the called IMS user receives the formatted SIP message and returns a response to the calling IMS user.
  • An interworking function entity is configured on the network side where the UE is located, and the interworking function entity is implemented by an IP message gateway.
  • the calling UE is an IMS registered user supporting the MAP protocol stack, and sends a SIP message encapsulating the MAP short message to the called UE (such as the SIMPLE IM user) that does not support the MAP protocol stack.
  • the entity in the calling network is recorded as "entity name #1", and the entity in the called network is recorded as "entity name #2".
  • the calling UE is recorded as UE#1, and the called UE is recorded.
  • the S-CSCF in the calling network is denoted as S-CSCF#1
  • the S-CSCF in the called network is denoted as S-CSCF#2, and so on.
  • Steps 1 to 7 are similar to steps 1 to 7 in FIG. 3, except that the IP-message gateway on the calling side, ie, IP-SM-GW#1, after receiving the SIP message from UE#1, confirms the The message is a SIP message encapsulating the MAP message, but the calling user does not subscribe to any interworking service, including the interworking of the transport layer and/or the service layer, and the called terminal identifier carried according to the message can be routed in the called IMS network, and thus the IP -SM-GW#1 returns the encapsulated SIP message to S-CSCF#1, and the SIP message of the encapsulated MAP message is routed by S-CSCF#1 to S-CSCF#2 through the IMS core.
  • the IP-message gateway on the calling side ie, IP-SM-GW#1
  • After receiving the SIP message from UE#1 confirms the The message is a SIP message encapsulating the MAP message, but the calling user does not subscribe to any inter
  • Step 8 ⁇ 9 S-CSCF#2 checks the initial filtering rule of the received SIP message, including whether the SIP message carries the feature tag of "+g.3gpp.smsip,", etc. The result of the initial filtering rule is checked. If the 81? message carries "+8.3.811 ⁇ 6 ⁇ 1 8 , it identifies that the SIP message body carries the MAP short message, and the S-CSCF #2 routes the encapsulated SIP message to the called IP message gateway. IP-SM-GW#2.
  • Step 10 After receiving the SIP message encapsulating the MAP short message, the IP-SM-GW#2 determines whether the service level interworking needs to be performed according to the obtained called user information or the operator's policy.
  • the called user information includes the ability of the called terminal, the service subscription of the called user, or the called user preference.
  • IP-SM-GW#2 authenticates the interworking service of UE#2. After the authentication succeeds, the message format is converted, that is, the encapsulated SIP message is decapsulated to obtain the MAP short message. , then convert the MAP short message into a pure SIP message format, in the case of authentication failure Then, the error response is returned to the UE#1; if the service level interworking is not required, the message is sent to the called user terminal through the IMS core.
  • Steps 11 to 12 after IP-SM-GW#2 completes the processing of the interworking service, the translated pure SIP message is delivered to UE#2 through the IMS core.
  • Step 13-19 UE#2 returns a message successfully received by IP-SM-GW#2. 200 OK to
  • S-CSCF# 1 The SIP message encapsulating the MAP short message can be directly routed to the S-CSCF#2 through the IMS core. After the S-CSCF#2 receives the SIP message encapsulating the MAP message, the subsequent processing is the same as the steps 8 to 19 in FIG. 5, and details are not described herein.
  • the interworking function entity is configured on the network side where the primary called UE is located, and the interworking function entity is implemented by the IP message gateway.
  • the calling UE sends a SIMPLE IM to the called IMS network, and the called UE is not an IM user, and prefers to receive SIP messages in the form of MAP signaling.
  • the entity in the calling network is recorded as "Entity Name #1”
  • the entity in the called network is recorded as "Entity Name #2”.
  • the calling UE is recorded as UE#1, and the called UE is recorded. For UE#2.
  • Steps 1 to 7 are similar to steps 1 to 7 in FIG. 3, except that the IP-message gateway on the calling side, that is, IP-SM-GW#1, after receiving the SIMPLE IM message from UE#1, confirms The user preference of UE#1 and the configuration of the operator policy are not inclined to communicate at the service level, and the called terminal identifier carried according to the message can be routed in the called IMS network, so IP-SM-GW#1 returns to SIMPLE IM.
  • the message is sent to S-CSCF#1, which is routed by S-CSCF#1 through the IMS core to S-CSCF#2.
  • Steps 8-9 S-CSCF#2 checks the initial filtering rules of the received SIP message, including whether the SIP message carries the feature tag of "+g.oma.sip-im," or whether it carries the service layer. Interworking service identifier CSID, etc. Based on the result of the initial filtering rule, if the SIP message carries the feature tag of "+g.oma.sip-im," or carries the interworking service identifier indicating that the service level needs to be performed The CSID, S-CSCF#2 routes the received SIMPLE IM message to the called IP message gateway, IP-SM-GW#2.
  • Step 10 After receiving the SIMPLE IM message, the IP-SM-GW#2 determines whether the service level interworking needs to be performed according to the obtained called user information or the operator's policy.
  • the called user information includes the capabilities of the called terminal, the service subscription of the called user, or the called user preference.
  • IP-SM-GW#2 authenticates the interworking service of UE#2, and after the authentication succeeds, the message format is converted, that is, the SIMPLE IM message is converted into a MAP short message and encapsulated in the SIP message. In the case of the authentication failure, the error response is returned to the UE#1; if the service level interworking is not required, the message is delivered to the called user terminal through the IMS core.
  • Steps 11 to 12 after the IP-SM-GW#2 completes the processing of the interworking service, the SIP message encapsulating the MAP short message is delivered to the UE#2 through the IMS core.
  • step 13-19 UE#2 returns a response 200 OK of the message successfully received by UE-to-UE#1 through IP-SM-GW#2.
  • S-CSCF# 1 The SIMPLE IM message can be directly routed to S-CSCF#2 through the IMS core. After the S-CSCF#2 receives the SIMPLE IM message, its subsequent processing is completely the same as steps 8 to 19 in Figure 6, and will not be described again.
  • the calling UE sends a SIP message encapsulating the MAP short message to an IMS user (such as a SIMPLE IM user) that does not support the MAP protocol stack.
  • an IMS user such as a SIMPLE IM user
  • the calling UE sends a SIMPLE IM to the called IMS network, and the called UE is not an IM user, and prefers to receive the SIP message in the form of MAP signaling. If the calling UE is located on the calling network side, the interworking function is set.
  • the interworking function entity in the calling network side receives the first type of SIP message from the autonomous calling side S-CSCF, and determines that the calling user does not subscribe to the interworking service or does not need to perform service level interworking, The first type of SIP message is transmitted to the calling side S-CSCF; at this time, the calling side S-CSCF transmits the first type based SIP message to the called side S-CSCF. If the calling party is located on the calling network side, the interworking function is not set. After receiving the SIP message based on the first type from the calling UE, the calling side S-CSCF may directly transmit the SIP message based on the first type to the called party according to an existing protocol. Side S-CSCF.
  • the SIP message based on the first type is a SIP message encapsulating the MAP; the SIP message based on the second type is a pure SIP message; or the SIP message based on the first type is a pure SIP message, and the The second type of SIP message is a SIP message encapsulating the MAP; the pure SIP message includes a SIMPLE IM message.
  • the embodiment of the present invention further provides a system for different types of message service communication based on SIP, including a primary called UE, an S-CSCF in a primary called network, where the called side The S-CSCF is configured to receive the first type of SIP message from the calling user terminal UE, where the system further includes:
  • An interworking function entity located in the called network side, configured to receive a first type of SIP message from the called side S-CSCF, and convert the first type of SIP message into a second type based
  • the SIP message transmits the SIP message based on the second type to the called UE.
  • the interworking function entity in the called network side is further configured to determine whether service level interworking is required before converting the first type of SIP message to the second type of SIP message, and if yes, The called UE performs interworking service authentication, and after the service authentication succeeds, the SIP message based on the first type is converted into a SIP message based on the second type.
  • the system further includes: an interworking function entity in the calling network side, configured to receive the first type of SIP message from the calling side S-CSCF, and determine that the calling user does not subscribe to the interworking service or does not need to perform When the service level is interconnected, the first type of SIP message is transmitted to the calling side S-CSCF;
  • the calling side S-CSCF is configured to transmit the SIP message based on the first type to the called side S-CSCF.
  • the called UE After receiving the SIP message based on the second type, the called UE is further configured to return response information to the calling UE.
  • the interworking function entity in the called network side is an IP message gateway, or an entity SMI AS that communicates with the message, or a newly added network entity, or a newly added function module on the existing network entity.
  • the embodiment of the present invention further provides an interworking function entity, including:
  • a receiving unit configured to receive a first type of SIP message from the called side S-CSCF, and a message converting unit, configured to convert the first type of SIP message into a second type based SIP message;
  • the interworking function entity further includes: an interworking detecting unit and an interworking authorization unit.
  • the interworking detection unit is configured to: after the interworking of the service layer is required, the notification that the service level is required to be communicated is sent; the interworking authorization unit is configured to perform the service level interworking notification according to the received requirement, and perform the interworking service check on the called UE. After the service authentication succeeds, the message conversion unit is notified to perform the conversion.
  • the method for processing the service communication of the different types of messages based on the SIP includes: the calling UE sends a SIP message based on the first type to the network side; the SIP message includes the UE that needs to be supported by the UE. An identifier of a protocol stack required for a type of SIP message; after the calling UE receives response information from a protocol stack required by the called UE on the network side that does not support the first type of SIP message, reconstructing the called UE can The supported second type of SIP message is transmitted, and the reconstructed message is sent again.
  • the response information of the protocol stack required by the called UE that does not support the first type of SIP message is from the S-CSCF of the called network side; the S-CSCF of the called network side returns the The process of responding to the information includes: after the called network side S-CSCF receives a SIP message from the calling UE that includes an identifier of a protocol stack required for the called UE to support the first type of SIP message, acquiring the The capability information of the UE is determined, according to the capability information of the called UE, after determining that the called UE does not support the protocol stack required by the first type of SIP message, and returning the response information to the calling UE.
  • the called side If the calling party on the network side of the calling UE is provided with an interworking function entity, the called side
  • the process of receiving, by the S-CSCF, the first type of SIP message from the calling user terminal UE includes: after the interworking function entity in the calling network side receives the first type of SIP message from the autonomous calling side S-CSCF, When it is determined that the calling user does not subscribe to the interworking service or does not need to perform service level interworking, Transmitting the SIP message based on the first type to the calling side S-CSCF; the calling side S-CSCF transmitting the SIP message based on the first type to the called side S-CSCF.
  • the process in which the called side S-CSCF receives the first type of SIP message from the calling user terminal UE includes: the calling side S- After receiving the SIP message based on the first type from the calling UE, the CSCF transmits the SIP message based on the first type to the called side S-CSCF.
  • the calling UE is a MAP-capable UE
  • the called UE is a UE that supports only pure SIP.
  • the calling UE that is required to be called by the calling UE to support the first type of SIP message is included in the first type of SIP message.
  • the identifier of the required protocol stack is an identifier that requires the called UE to support the MAP protocol stack; the second type-based SIP message reconstructed by the calling UE is a pure SIP message.
  • the SIP message and the pure SIP message (such as OMA SIMPLE IM) for encapsulating the MAP short message can be implemented without any modification to the existing IMS core.
  • the IMS core network entity such as the S-CSCF
  • the calling UE is an IMS registered user supporting the MAP protocol stack, and sends a SIP message encapsulating the MAP short message to the called UE (such as the SIMPLE IM user) that does not support the MAP protocol stack.
  • the entity in the calling network is recorded as "entity name #1”
  • the entity in the called network is recorded as "entity name #2”.
  • the calling UE is recorded as UE#1, and the called UE is recorded.
  • Steps 1-7 are similar to steps 1-7 in FIG. 3, except that: UE#1 encapsulates the MAP short message in the SIP message body, and carries the required UE in the SIP message header, such as "require". #2 supports the identifier of the MAP protocol stack, and forwards the SIP message to the calling IP message gateway, IP-SM-GW#1, through the IMS core. After receiving the SIP message from UE#1, IP-SM-GW#1 confirms that the message is a SIP message encapsulating the MAP short message, but the calling user does not sign any interworking service, including the transport layer and/or the service layer.
  • Interworking and the called terminal identifier carried according to the message can be in the called IMS
  • the network routes, and IP-SM-GW#1 returns the encapsulated SIP message to S-CSCF#1, which routes the SIP message to S-CSCF#2 through the IMS core.
  • the S-CSCF#2 After receiving the encapsulated SIP message, the S-CSCF#2 detects that the message header of the message carries the identifier of the called party supporting the MAP protocol, and is obtained according to the third party registration.
  • the called terminal capability information learns that the called terminal does not support the MAP protocol stack. Therefore, it decides to reject the encapsulated SIP message, and constructs an error response, which carries the failure reason and the capability information of the called terminal.
  • Steps 10 ⁇ 12 S-CSCF#2 returns an error response to UE#1.
  • Step 13 After receiving the error response, UE#1 constructs a SIP message that does not encapsulate the MAP short message and sends it to the called terminal according to the called terminal capability information carried in the response.
  • S-CSCF# 1 The SIP message encapsulating the MAP short message can be directly routed to the S-CSCF#2 through the IMS core. After the S-CSCF#2 receives the SIP message encapsulating the MAP message, the subsequent processing is the same as the steps 8 to 13 in FIG. 7, and details are not described herein.
  • the embodiment of the present invention further provides a UE, including: a sending unit, configured to send, according to a first type of SIP message, a network message to the network side; An identifier of a protocol stack required for the first type of SIP message; sending, according to the received notification, a SIP message based on the second type;
  • a receiving unit configured to receive, from the network side, the response information of the protocol stack required by the called UE that does not support the first type of SIP message, to notify the constructing unit;
  • a constructing unit configured to reconstruct a second type-based SIP message that the called UE can support, and notify the sending unit to resend.
  • the method for processing different types of SIP message service communication provided by the second embodiment of the present invention can implement service interworking between different types of SIP messages, such as when the called network does not support the message interworking entity or the function module. Communication between SIP messages encapsulating MAP short messages and pure SIP messages.

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Telephonic Communication Services (AREA)

Abstract

L'invention concerne un procédé de traitement réalisant une communication de services sur la base d'un protocole d'ouverture de session SIP de différents types de messages comprenant les étapes suivantes : la réception du message SIP sur la base du premier type depuis le terminal utilisateur appelant UE, transmis sur la fonction de commande d'appel de service S-CSF côté appelé par l'entité d'interfonctionnement côté réseau appelé ; la conversion du message SIP basé sur le premier type en message SIP basé sur le second type ;, la transmission du message basé sur le second type à l'UE appelé. L'invention concerne également un système et un dispositif pour la communication de service de différents types de messages.
PCT/CN2008/071955 2007-08-13 2008-08-12 Procédé, système et dispositif de traitement pour réaliser une communication de service de différents types de messages WO2009021453A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN200710142001.XA CN101370172B (zh) 2007-08-13 2007-08-13 不同类型的消息业务通信的处理方法、系统和设备
CN200710142001.X 2007-08-13

Publications (1)

Publication Number Publication Date
WO2009021453A1 true WO2009021453A1 (fr) 2009-02-19

Family

ID=40350392

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2008/071955 WO2009021453A1 (fr) 2007-08-13 2008-08-12 Procédé, système et dispositif de traitement pour réaliser une communication de service de différents types de messages

Country Status (2)

Country Link
CN (1) CN101370172B (fr)
WO (1) WO2009021453A1 (fr)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103384238B (zh) * 2012-10-30 2016-09-28 深圳海联讯科技股份有限公司 一种sip补偿的方法及装置
CN105337953A (zh) * 2014-08-15 2016-02-17 中国移动通信集团公司 一种基于ims的非结构化补充数据业务下发方法和系统
CN111371724B (zh) * 2018-12-25 2022-05-17 中国电信股份有限公司 实现ims业务的通信系统、设备和方法
CN110601965B (zh) * 2019-09-24 2022-03-15 Oppo广东移动通信有限公司 消息分发方法、装置、系统以及消息网关
CN115515083B (zh) * 2021-06-07 2024-03-15 中国移动通信集团浙江有限公司 消息发放方法、装置、服务器及存储介质

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1487700A (zh) * 2001-03-10 2004-04-07 华为技术有限公司 互通代理装置及不同协议网络之间进行互通的系统和方法
CN1838649A (zh) * 2005-03-25 2006-09-27 华为技术有限公司 一种电路交换网络到ims网络呼叫路由的建立方法
CN1897578A (zh) * 2005-07-14 2007-01-17 华为技术有限公司 一种消息转换方法与系统
WO2007042620A1 (fr) * 2005-10-11 2007-04-19 Teliasonera Ab Procédé, système et proxy pour réseau fédérateur ip inter fournisseurs de services
CN1984366A (zh) * 2006-04-03 2007-06-20 华为技术有限公司 一种实现异网信令互通的方法及系统

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1487700A (zh) * 2001-03-10 2004-04-07 华为技术有限公司 互通代理装置及不同协议网络之间进行互通的系统和方法
CN1838649A (zh) * 2005-03-25 2006-09-27 华为技术有限公司 一种电路交换网络到ims网络呼叫路由的建立方法
CN1897578A (zh) * 2005-07-14 2007-01-17 华为技术有限公司 一种消息转换方法与系统
WO2007042620A1 (fr) * 2005-10-11 2007-04-19 Teliasonera Ab Procédé, système et proxy pour réseau fédérateur ip inter fournisseurs de services
CN1984366A (zh) * 2006-04-03 2007-06-20 华为技术有限公司 一种实现异网信令互通的方法及系统

Also Published As

Publication number Publication date
CN101370172A (zh) 2009-02-18
CN101370172B (zh) 2012-04-25

Similar Documents

Publication Publication Date Title
JP5080465B2 (ja) メッセージを変換するための方法及びシステム
EP1798933B1 (fr) Méthode pour réaliser un service de messagerie basé sur un sous-système multimédia en réseau ip
EP2081348A1 (fr) Procédé d'interfonctionnement de message, système, entité et procédé de traitement de rapport de distribution de message, système, entité, terminal pour un interfonctionnement de message
US8499082B2 (en) Methods, systems, and computer readable media for providing services in a telecommunications network using interoperability specification/session initiation protocol (IOS/SIP) adapter
JP5199461B2 (ja) Ｉｍｓおよび回路交換ネットワークにおけるメッセージルーティングの方法およびシステム
KR100974258B1 (ko) 모바일 네트워크의 네트워크 데이터베이스 노드에 인스턴스식별자를 제공하는 장치 및 관련 방법
US9125030B2 (en) Apparatus, and associated method, for supporting SMS messaging by way of an IP network
US20090075684A1 (en) Apparatus and method for routing message service
US20100087215A1 (en) Method, system, and message service interworking module for implementing message service interworking
EP2028815A1 (fr) Procédé et système de délivrance de données de services de messagerie
CA2592357C (fr) Dispositif et methode associee de prise en charge de messagerie sms par reseau ip
US20090213826A1 (en) Method, system and apparatus for transferring short messages in an ims
TW200527861A (en) Method and architecture for accessing an Internet protocol multimedia subsystem (IMS) over a wireless local area network (WLAN)
WO2007128221A1 (fr) Procédé et système d'acheminement et d'adressage de message court
WO2008025257A1 (fr) Procédé d'intercommunication et système de communication entre différents réseaux
EP2441280A1 (fr) Service de messages courts sur une évolution 3gpp à long terme
WO2013044882A1 (fr) Procédé de traitement de messages courts et système connexe
WO2009021453A1 (fr) Procédé, système et dispositif de traitement pour réaliser une communication de service de différents types de messages
WO2007000110A1 (fr) Procede de transmission de message par protocole ip a base de protocole de transfert de message
WO2008017235A1 (fr) Système, périphérique et procédé de routage sms
CN100421430C (zh) 一种基于ip网多媒体子系统的消息业务实现方法
CN101202710A (zh) 消息发送报告处理方法、系统及用于消息互通实体、终端
WO2008148355A1 (fr) Procédé, système et appareil de facturation
WO2007006234A1 (fr) Procédé et appareil de transmission de message
WO2006116941A1 (fr) Méthode et système de réalisation d’un service de messages de zone de réseau basé sur ip

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

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 08783948

Country of ref document: EP

Kind code of ref document: A1