KR20130041665A - Method of sip message transmission between gruu users in ims network, and device of the same - Google Patents

Abstract

PURPOSE: SIP message transmission method and device are provided to stably transmit an SIP(Session Initiation Protocol) by a subscriber in case of redial call generation between subscribers in an IMS(Internet Protocol Multimedia Subsystem) network. CONSTITUTION: An SIP(Session Initiation Protocol) message transmission method in an IMS network includes a stage of receiving a first SIP message including GRUU(Globally Routable User agent Uniform resource identifier) contact information for transmission of a transmitting terminal by a transmission side application server, a stage of maintaining the GRUU contact information in the first SIP message and adding to a record-route header including URL of the transmission side application server, a stage of transmitting a second SIP message including the GRUU contact information and record-route header to a CSCF(Call Session Control Function) by the transmission side application server and a stage of receiving the second SIP message from the CSCF by a reception side application server.

Description

Method and apparatus for transmitting SIP message in IMS network between subscribers using the network {METHOD OF SIP MESSAGE TRANSMISSION BETWEEN GRUU USERS IN IMS NETWORK, AND DEVICE OF THE SAME}

The present invention relates to an Internet Protocol Multimedia Subsystem (IMS) network, and more particularly, to a SIP message transmission method when a redial call occurs between subscribers of an IMS network.

IMS (IP Multimedia Subsystems) is a network technology that integrates wired and wireless environments and is an infrastructure for providing multimedia services such as voice, audio, video, and data based on the 3rd generation mobile communication network IP (Internet Protocol). Because IMS is based on Internet protocol, it uses a packet switched based unfixed call path to increase transmission efficiency and ensure stability. Such IMS can support not only simple one-to-one calls but also connections involving multiple users. In order to achieve access independence and to maintain smooth interactions with wireless terminals over the Internet, IMS, as specified in the 3rd Generation Partnership Project (3GPP) specification TS 24.229, is an Internet Engineering Task Force (IETF) "Internet Standards ( starndard ".

3rd Generation Partnership Project (3GPP) TS 24.229 IP multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3 RFC 5627: Obtaining and Using Globally Routable User Agent URIs

The technical problem to be achieved by the present invention is to provide a method for stably transmitting SIP messages by subscribers when a redial call occurs between subscribers in an IMS network.

In the method for transmitting a SIP message in an IMS network according to an embodiment of the present invention for achieving the technical problem, when the calling terminal generates a call, the calling application server includes the GRUU contact information of the calling terminal. Receiving an outgoing first Session Initiation Protocol (SIP) message, maintaining the GRUU contact information in the first SIP message, and adding it as a Record-Route header including a URL of the calling application server; Transmitting, by the calling application server, a second SIP message including the GRUU contact information and the record-route header to a CSCF and a calling party application server from the call session control function (CSCF). Receiving the second SIP message.

Adding a Recourd-Route header including a URL of the called application server to the second SIP message; and the called application server sends a third SIP message including the Record-Route header to the second SIP message; The method may further include transmitting to the CSCF.

Transmitting a fourth SIP message to a calling party having GRUU contact information of the calling terminal based on the third SIP message when the call is failed and a redial call is generated from the called terminal, in the calling CSCF. The method may further include searching for binding information corresponding to the GRUU contact information, and transmitting the redial call to the calling terminal having the contact address corresponding to the binding information.

According to another aspect of the present invention, there is provided a method for transmitting a SIP message in an IMS network, when an originating terminal generates a call, the originating IBCF includes the GRUU contact information of the originating terminal. Receiving a credit first SIP message, the originating IBCF generates an originating self-generated GRUU, mapping and storing the GRUU contact information and the originating self-generating GRUU, and the originating IBCF Sending to the destination IBCF a second SIP message comprising the originating self-generated GRUU.

The called party IBCF generating a called party self-generating GRUU, mapping and storing the calling party self-generating GRUU and the called party self-generating GRUU, and the called party IBCF includes the called party self-generating GRUU. The method may further include transmitting an outgoing signal to the called terminal.

When a call fails and a redial call is generated from the called terminal, the called terminal transmits a third SIP message to the called party's IBCF having the called party's self-generated GRUU. And finding the calling party self-generating GRUU corresponding to the called party self-generating GRUU at the called party IBCF.

The IMS network system according to another embodiment of the present invention for achieving the technical problem is at least one CSCF for transmitting a first SIP message having contact information including the GRUU when a call (call) of the terminal and the At least one application that maintains the contact information and generates and retransmits a second SIP message with a Record-Route header including a URL of an application server to the CSCF when the first SIP message is received from a CSCF; Include a server.

The IMS network system according to another embodiment of the present invention for achieving the above technical problem, upon receiving the first SIP message with the contact information including the GRUU from the calling CSCF, the calling party's self-made GRUU When the second SIP message is generated from the calling party's IBCF and the calling party's IBCF that transmits a second SIP message including the calling party's self-generating GRUU, the mapping is performed and stored. Generating, mapping and storing with the calling party self-generating GRUU, and including a called party IBCF transmitting and receiving a third SIP message including the called party self-generating GRUU with the called party CSCF.

According to the present invention, when an originating terminal fails an originating call in the IMS network and a called terminal generates a redial call, there is an effect that the redial call is correctly routed to the intended originating terminal.

1 is a block diagram illustrating an IMS network architecture according to an embodiment of the present invention.
2 is a flowchart of general processing of a call between UEs in an IMS network.
3A and 3B are flowcharts when an AS is included in processing of a call between UEs in an IMS network.
4A and 4B are flowcharts when an AS is included in processing of a call between UEs in an IMS network according to an embodiment of a method for transmitting a SIP message according to the present invention.
5 is a block diagram illustrating an IMS network architecture according to another embodiment of the present invention.
FIG. 6 is a flowchart illustrating call processing between UEs in the IMS network of FIG. 5.

Specific structural and functional descriptions of the embodiments of the present invention disclosed herein are for illustrative purposes only and are not to be construed as limitations of the scope of the present invention. And should not be construed as limited to the embodiments set forth herein or in the application.

The embodiments according to the present invention are susceptible to various changes and may take various forms, so that specific embodiments are illustrated in the drawings and described in detail in this specification or application. It is to be understood, however, that it is not intended to limit the embodiments according to the concepts of the present invention to the particular forms of disclosure, but includes all modifications, equivalents, and alternatives falling within the spirit and scope of the invention.

The terms first and / or second, etc. may be used to describe various components, but the components should not be limited by the terms. The terms are intended to distinguish one element from another, for example, without departing from the scope of the invention in accordance with the concepts of the present invention, the first element may be termed the second element, The second component may also be referred to as a first component.

It is to be understood that when an element is referred to as being "connected" or "connected" to another element, it may be directly connected or connected to the other element, . On the other hand, when an element is referred to as being "directly connected" or "directly connected" to another element, it should be understood that there are no other elements in between. Other expressions describing the relationship between components, such as "between" and "immediately between," or "neighboring to," and "directly neighboring to" should be interpreted as well.

The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention. Singular expressions include plural expressions unless the context clearly indicates otherwise. In this specification, the terms "comprises ", or" having ", or the like, specify that there is a stated feature, number, step, operation, , Steps, operations, components, parts, or combinations thereof, as a matter of principle.

Unless defined otherwise, all terms used herein, including technical or scientific terms, have the same meaning as commonly understood by one of ordinary skill in the art. Terms such as those defined in the commonly used dictionaries should be construed as having meanings consistent with the meanings in the context of the related art, and are not construed in ideal or excessively formal meanings unless expressly defined herein. Do not.

BEST MODE FOR CARRYING OUT THE INVENTION Hereinafter, the present invention will be described in detail with reference to the preferred embodiments of the present invention with reference to the accompanying drawings. Like reference symbols in the drawings denote like elements.

1 is a block diagram illustrating an IMS network architecture according to an embodiment of the present invention.

Referring to FIG. 1, the IMS network 1000 to which the present invention is applied includes a plurality of UEs 100, CSCF servers, HSS 500, and AS 600.

The IMS network 1000 may be configured as both a CS network and a PS network, and is connected to various access networks such as wireless technology, wired technology, and broadband access technology. The IMS standard, defined by the 3rd Generation Partnership Project (3GPP), is designed to allow service providers to manage multiple services that can be delivered over IP across any network type. IP is used to carry both bearer traffic and SIP-based signaling traffic. The IMS network 100 is a framework for managing an application and a network capable of providing a multimedia service.

The IMS network 1000 is defined by the 3GPP standard, which mainly addresses GSM networks, while the other group, 3GPP2, is involved in defining an almost analog form of architecture called the multimedia domain. Since the multimedia domain is essentially an IMS for a CDMA network, and MMD and IMS are nearly equivalent, the term "IMS" is used herein to mean quantum mode applicable IMS and MMD collectively.

The UE (User Equipment, hereinafter, referred to as UE) 100 listens for a message transmitted to the user and requests a user, and transmits a message according to a user action or the message to provide a service to the user. In addition, the UE 100 performs a user's current location information management function and call management function. The user's location information management function includes the function of registering, modifying or deleting his current location information, and the call management function includes a function of setting up, canceling or ending a call with the other party and accepting or rejecting the requested call. do.

The UE 100 may be a tethered communication device or an untethered communication diva. Personal computers (e.g. desktops, laptops, palmtops or laptops) equipped with appropriate wireless modems or mobile communication devices (e.g. cellular phones or data-enabled portable devices capable of translating messages and performing web browsing, etc.) Portable computing devices) or enhanced PDA devices or integrated information appliances capable of performing e-mail, video mail, Internet access, in-house data access, messaging calendaring and scheduling, information management, and the like. The UE 100 can operate in multiple modes in that it can participate in not only packet switched (PS) communications but also circuit switched (CS) communications, and it switches from one communication mode to another without damaging continuity. Can be.

Call Session Control Function (CSCF) performs a call session control function. The CSCF (Call Session Control Function) server provides basic functions for multimedia session control based on Session Initiation Protocol (SIP) such as subscriber registration, authentication, service triggering, routing, call control or address handling. Can be done. It can also provide SIP signaling and state management functions. On the other hand, the CSCF server is functionally provided with a proxy CSCF (P-CSCF, 200), an interrogating CSCF (I-CSCF, 300), and serving. CSCF (Serving-CSCF; S-CSCF, 400).

The P-CSCF 200 serves as a default proxy server of the UE 100 as a first access point between the mobile communication network and the mobile multimedia network and applies bearer resources. In addition, when the SIP register request is received from the UE 100 and the address of the S-CSCF 400 allocated by the I-CSCF 300 is stored, the S-CSCF is received when an INVITE request is received from the UE 100. Forward to 400.

I-CSCF (300) performs the inter-working function, firewall role. In other words, I-CSCF 300 is a contact in the operator network for all connections intended for subscribers of the network operator, or roaming users currently located within the service area of the network operator. There may be multiple I-CSCFs 300 within the operator's network. The main function of the I-CSCF 300 is to obtain an address list of the S-CSCF 400 available from the HSS 500 in the process of registering the UE 100 and refer to the S-CSCF to be in charge of actual registration. To determine 400.

The S-CSCF 400 is responsible for service control in the IMS network 1000 for the user. The main functions of the S-CSCF 400 include accepting a registration request from the UE 100 and talking to a service platform for support of a service. That is, the S-CSCF 400 registers with the HSS 500 that it is a server controlling the session of the UE 100, and then obtains a subscriber profile of the UE 100 from the HSS 500. The subscriber can be registered with and obtain a subscriber profile from the HSS 500. The S-CSCF 400 checks the type of service to be provided to the subscriber station (UE) using the subscriber profile, and sends an IMS enabler (i.e., an application server (AS)) to support the identified service. Triggering can be performed. In addition, the S-CSCF 400 may obtain an authentication vector (AV) from the HSS 500 and manage the same. In addition, the S-CSCF 400 may perform subscriber authentication using AV (authentication vector).

The HSS 500 stores all user related information in the IMS network 1000 and communicates with the S-CSCF 400 through the Cx interface. The Cx interface is for registering or unregistering a subscriber (UE, 100) between HSS 500 and S-CSCF 400, verifying authority of accessibility of subscriber (UE, 100) IMS network, and managing location information. It exchanges messages, messages for subscriber profile download and subscriber information update, and messages for subscriber authentication. One or more HSS 500 may exist according to the number of IMS network subscribers 100 and the configurability of the network. In addition, the HSS 500 may include a function of a home location register (HLR, not shown). A subscription locator function (SLF) provides the address of the appropriate HSS 500 to the CSCF when two or more HSS 500 are operated in the IMS network and each is recognized as a separate address.

In order to use the service in the IMS network as described above, a session setup is performed between subscriber stations (UE) using a Session Initiation Protocol (SIP). After the session is set up, a real bearer is formed between the subscriber stations to allow the exchange of data.

AS 600 is an application server (Application Server) is an entity for providing an application to the user, such as Voice Call Continuity (VCC), Push To Talk over CellUEr (e.g., using an email or mobile device). The AS 600 communicates with the UE 100 and the S-CSCF 400 through an interface to provide an application service (eg, a streaming service).

Session Initiation Protocol (SIP) is a signaling protocol, which is an application level that specifies the procedures for intelligent terminals that want to communicate on the Internet to identify and locate each other, and to create, delete, and change multimedia communication sessions between them. First, the SIP message will be briefly described. The SIP message is composed of a header and a body. The header includes SIP control information, and the body includes various multimedia information. SIP messages may include additional syntax components and parameters as described, for example, in RFC 3261 (SIP: Session Initiation Protocol and Internet Draft entitled Obtaining Using Globally Routable User Agent URIs (GRUU) in the Session Initiation Protocol (SIP)) standard. Can include sip: can take the form <username> @ <hostname>. The SIP message is composed of six basic methods, which are in the form of request / response.

In the SIP-based communication, the calling terminal sends a SIP message composed of a text format to the called terminal in order to create a new session with the called terminal or to join the called party in the existing session. For example, SIP messages consist of six request messages and six groups (100-600) of response messages defined in the RFC 3261 standard. That is, the SIP message includes various messages such as INVITE (session start request) message, ACK (notification) message, BYE (session end) message, CANCEL (cancel) message, REGISTER (registration request) message, OPTION (option) message, and so on. In the following, the present invention will be described in detail with reference to a session initiation request (INVITE) message related to session setup between subscriber stations.

Included within the session initiation request message include an address of record (AOR), a globally routable user agent uniform resource identifier (GRUU) and an instance identifier (ID) that identifies the call being sent, or any combination thereof. Any unique ID information that exists.

The instance ID can be an IMEI, IMEISV, MIN, ESN, UUID, MAC address, software ID (such as a mobile software terminal identifier), or any other unique layer-2 address used to uniquely identify a user terminal device. .

Globally Routable User Agent Uniform Resource Identifiers (GRUUs) include Public and Temporary GRUUs. The public GRUU receives the AOR and stores the actual value of the instance ID in the contents of the URI parameter "gr". Temporary GRUUs are required by registrars, and if session registration lasts very long, hundreds or thousands of temporary GRUUs can be created and assigned to a user application. For this purpose, the temporary GRUU has an algorithm for maintaining a constant size without additional storage.

In FIG. 1, the IMS network 1000 is illustrated to include the I-CSCF 300, the S-CSCF 400, the HSS 500, and the like. The present invention is for illustrative purposes only and is not limited thereto. Accordingly, the IMS network 1000 may include a plurality of devices or servers shown in the drawing.

That is, in FIG. 1, only one S-CSCF 400 and an I-CSCF 300 are shown, but the called party and the calling party may share one S-CSCF and I-CSCF, respectively, each of which is a separate S-CSCF. I-CSCF may be used. The embodiments of the present invention are assumed to be provided with S-CSCF and I-CSCF of the called party and the calling party, respectively, for convenience of description.

2 is a flowchart of general processing of a call between UEs in an IMS network.

In the embodiment of FIG. 2, UE1-1 101 and UE1-2 102 each perform a registration procedure with the same public ID, and UE2 103 performs a registration procedure with a different public ID. Suppose you did.

2, the originating terminal, UE1-1 (101) is the contact information (for example, Contact: "UE1" <sip: 10.10.1.1: 5060>;), the public GRUU (for example, pub-gruu : "sip: ue@example.com; gr = ue1-1") and the originating information (eg From: <sip: ue1@example.com>). Attempts to call UE2 103 by At this time, since the UE1-1 101 is already registered in the subscriber network, the P-CSCF 200 transmits an invite message to the allocated S-CSCF 400 (S11). The S-CSCF 400 transmits an invite message to the I-CSCF 300 to find the location of the called terminal and the UE2 103 (S12). The I-CSCF 300 queries the HSS 500 with the public ID or temporal ID of UE1-1 included in the invite message, and then has the S-CSCF 400 having the binding of the UE2 103. Get the name of). The I-CSCF 300 transmits an invite message including the contact information of the UE2 103 to the P-CSCF 200 through the S-CSCF 400 having the obtained name (S13, S14). Thereafter, the P-CSCF 200 transmits the invite message to the UE2 103 through the contact information of the UE2 103 included in the invite message (S15). In this case, the invite message includes contact information (eg, Contact: "UE1" <sip: 10.10.1.1: 5060>;) of the calling party UE1-1 101, and a public GRUU (eg, pub-gruu: ". sip: ue@example.com; gr = ue1-1 "). As a result, session set-up is completed between the UE1-1 101 and the UE2 103 (session set-up), and the UE1-1 101 attempts to call (Normal Call flow).

However, if UE2 103 receives a call of UE1-1 101 but fails to initiate another session (eg missed call, busy), UE2 103 calls first call to UE1-1 101. It informs that the connection has failed (S17) and leaves the contact information of the calling party UE1-1 (101) in the called party UE2 (103) so that a retry call can be made later.

When a user of UE2 103 presses redial (retry) for the missed call of UE1-1 101, UE2 103 generates a GRUU ("sip" included in the contact information of UE1-1 101). : ue1@example.com; gr = ue1-1 ") is applied to the R-URI to transmit the invite message to the UE-side P-CSCF 200 (S18). At this time, the UE2 103 has already transmitted to the subscriber network. Since the registered state, the P-CSCF 200 transmits an invite message to the allocated S-CSCF 400 (S19). The S-CSCF 400 transmits an invite message to the I-CSCF 300 to find the location of the first calling terminal and the UE1-1 101 (S20). The I-CSCF 300 queries the HSS 500 with a Public ID or Temporary ID of UE1-1 included in the invite message to perform a binding of the UE2 103 by performing a Location Information Request (LIR). Obtain the name of the S-CSCF (400) that has a (Location Information Answer (LIA). The S-CSCF (300) of the obtained name selects the binding of the first originating terminal (UE1-1) 101 through the GRUU information included in the R-URI and informs the I-CSCF (300). ) Transmits an invite message including the contact information of the UE1-1 101 to the P-CSCF 200 through the S-CSCF 400 having the obtained name (S21, S22). Thereafter, the P-CSCF 200 transmits the invite message to the UE1-1 101 through the contact information of the UE1-1 101 included in the invite message (S23).

3A and 3B are flowcharts when an AS is included in processing of a call between UEs in an IMS network.

Referring to FIG. 3A (STEP 1), the originating terminal, UE1-1 (101) is contact information (for example, Contact: "UE1" <sip: 10.10.1.1: 5060>;), public GRUU (for example , pub-gruu: "sip: ue1@example.com; gr = ue1-1") and outgoing information (e.g. From: <sip: ue1@example.com>) Attempts to call the UE2 103 by transmitting to the P-CSCF 200 (S30). At this time, since the UE1-1 101 is already registered in the subscriber network, the P-CSCF 200 transmits an invite message to the allocated S-CSCF 400 (S31).

After the originating application server (Originating Application Server; Orig-AS) receives the invite message from the S-CSCF (400) for the session initiation operation as if it is the originating terminal, UE1-1 (101) ( S32), removes the contact information (Contact: "UE1" <sip: 10.10.1.1: 5060>;) in the invite message in step S32, and creates a contact (Ortact: "AS1" <sip created by itself) : 10.10.1.2: 5060>;) transmits the invite message to the S-CSCF 400 (S33). The S-CSCF 400 transmits an invite message to the I-CSCF 300 to find the location of the called terminal and the UE2 103 (S34). The I-CSCF 300 queries the HSS 500 with a Public ID or Temporary ID of UE1-1 included in the invite message to perform a binding of the UE2 103 by performing a Location Information Request (LIR). Obtain a name of the S-CSCF (400) that has a (Location Information Answer (LIA). I-CSCF (300) selects the S-CSCF (400) of the acquired name of the Orig-AS The invite message including the contact information (Contact: "AS1" <sip: 10.10.1.2: 5060>;) is transmitted (S35).

A terminating application server (Term-AS) receives the invite message from the S-CSCF 400 to perform a session initiation operation as if it is a terminating terminal, UE2 103 (S36). ). At this time, Term-AS removes the contact information (Contact: "UE1" <sip: 10.10.1.1: 5060>;) in the invite message in step S36, and Term-AS itself creates the contact (Contact: "AS2" The invite message including <sip: 10.10.1.3: 5060>;) is transmitted to the S-CSCF 400 (S37). The S-CSCF 400 transmits an invite message to the P-CSCF 200 (S38). The P-CSCF 200 attempts to call by sending an invite message including the contact information of the Term-AS to the UE2 103 (S39 and S40).

At this time, the invite message in step S39 includes contact information of the calling UE1-1 101 (eg, Contact: "UE1" <sip: 10.10.1.1: 5060>;) and a public GRUU (eg, pub- gruu: "sip: ue@example.com; gr = ue1-1") is not included. That is, instead of the contact information (Contact: "UE1" <sip: 10.10.1.1: 5060>; and Contact: "UE2" <sip: 10.10.1.1: 5060>;) of the terminal message in step S33 and S39 The created contact information (Contact: "AS1" <sip: 10.10.1.2: 5060>; and Contact: "AS2" <sip: 10.10.1.3: 5060>;) is transmitted, and thus, the calling terminal UE1-1 (101). ) And GRUU information for the called terminal UE2 103 are not included.

Referring to FIG. 3B (STEP 2), if UE2 103 receives a call but fails to initiate a session (eg, missed call, busy), UE2 103 calls first call to UE1-1 101. It informs that the connection has failed (S41) and leaves the contact information of the calling subscriber network in the called party UE2 103 so that a retry call can be made later.

When a user of UE2 103 presses redial (retry) for the missed call of UE1-1 101, UE2 103 sends a GRUU ("sip: ue1 @ example" included in the contact information in step S41). .com ") is applied to the R-URI to transmit the invite message to the calling P-CSCF 200 (S42). At this time, since the UE2 103 is already registered in the subscriber network, the P-CSCF 200 Transmits the invite message to the allocated S-CSCF 400 (S43).

S-CSCF (400) is a Term- message to find the first call information corresponding to the contact information (Contact: "AS2" <sip: 10.10.1.3: 5060>;) of the Term-AS (600); Transmitting to the AS (600) (S44). The Term-AS 600 includes the initial originating information (Contact: "AS1" <sip: 10.10.1.2: 5060>;) in an invite message and transmits it to the S-CSCF 400.

The S-CSCF 400 transmits an invite message to the I-CSCF 300 to locate the originating terminal based on the original originating information (S46). The I-CSCF 300 queries the HSS 500 with the invite message (LIR) and selects (LIA) the S-CSCF 400 having the binding information of the calling party Orig-AS 600 (LIA). S47).

The selected S-CSCF 400 transmits an invite message including initial originating information (Contact: "AS1" <sip: 10.10.1.2: 5060>;) to the Orig-AS 600 (S48). The Ori-AS 600 transmits an invite message that selects a calling terminal corresponding to the first calling information to the S-CSCF 400 (S49). In this case, since the GRUU information of the originating terminal is not included in the invite message in step S49, the first originating terminal may be any one of UE1-1 101 and UE1-2 102 having the same public ID. That is, the S-CSCF 400 has the same public ID binding to the UE1-1 101 and the UE1-2 102, but there is no GRUU information, so that the S-CSCF 400 may select any terminal having the corresponding public ID binding. have. The S-CSCF 400 randomly selects the UE1-2 102 and transmits a message by replacing the R-URI with the contact information stored in the binding of the UE1-2 102 ("sip: 10.10.1.4: 5060"). It may be (S50). Thereafter, the P-CSCF 200 transmits the invite message to the UE1-2 102 through the contact information of the UE1-2 102 included in the invite message (S51).

As a result, there is a problem in that a redial for a missed call is connected to a terminal UE1-2 102 that is different from the actual intention of the user of the first originating terminal UE1-1.

4A and 4B are flowcharts when an AS is included in processing of a call between UEs in an IMS network according to an embodiment of a method for transmitting a SIP message according to the present invention. For convenience of explanation, differences from FIG. 3A and FIG. 3B will be mainly described.

Referring to FIG. 4A (STEP 2-1), steps S101 to S103 are the same as steps S30 to S32 of FIG. 3A when the UE1-1 101 makes an outgoing call.

However, according to an embodiment of the present invention, the Orig-AS 600 maintains the contact information and the public GRUU in the invite message as in step S32. Orig-AS 600 also adds a Record-Route header (eg, Record-Route: <sip: AS1@10.10.1.2: 5060>) containing the URL of Orig-AS 600. The invite message is transmitted to the S-CSCF 400 (S104). In this case, the record route header is used for a subsequent message after the byte message. When the interworking between servers is performed, the record route header indicates that the record route header passes through the server having the URL included in the record route header.

Steps S105 to S107 are the same as those of S34 to S36 in FIG. 3A. However, according to an embodiment of the present invention, the Term-AS 600 also maintains the contact information and the public GRUU of the Orig-AS in the invite message as in step S37. In addition, the Term-AS 600 may include the Term-AS in addition to the Record-Route header (eg, Record-Route: <sip: AS1@10.10.1.2: 5060>) containing the URL of the Orig-AS 600. A record route header (eg, Record-Route: <sip: AS2@10.10.1.3: 5060>) including the URL of the AS 600 is added to transmit the invite message to the S-CSCF 400 (S108). ).

Hereinafter, steps S109 to S111 are the same as steps S38 to S40 of FIG. 3A.

Referring to FIG. 4B, when UE2 103 receives a call but fails to initiate a session (eg, missed call, busy), UE2 103 has failed to connect first call to UE1-1 101. (S112) and leaves the contact information of the calling subscriber network in the destination terminal UE2 (103) to make a retry later.

When the user of UE2 103 presses redial (retry) for the missed call of UE1-1 101, UE2 103 determines that the GRUU ("sip: ue1 @ example" included in the contact information in step S112). .com; gr = ue1 ") is applied to the R-URI to transmit the invite message to the calling party P-CSCF 200 (S113).

According to an embodiment of the present invention, steps S113 to S120 are similar to those of FIG. 3B. Unlike in FIG. 3B, however, contact information of the originating subscriber network from the original originating call is maintained in the invite message generated by the redial call. That is, the invite message of steps S115 to S120 is based on record route header information about the server URL related to the contact information of the calling party, the public GRUU, and the call according to steps S104 and S108. That is, the S-CSCF 300 may select binding information of the UE1-1 101 through the public GRUU (gr = ue1-1) of the calling party in the subscriber network of the UE1 (S120).

The S-CSCF 300 replaces the R-URI with the contact information obtained from the binding information of the UE1-1 101 and sends an invite message to the UE1-1 101 via the P-CSCF 200 to redial. Request session initiation by call.

As a result, the called terminal UE2 can connect the redial call for the missed call to the calling terminal UE1-1 101 according to the actual intention of the user UE1-1 who originated the first outgoing call.

5 is a block diagram illustrating an IMS network architecture according to another embodiment of the present invention.

Referring to FIG. 5, the IMS system 2000 may include a plurality of IMS networks (Operator A and Operator B). In this case, each IMS network includes CSCFs 601 and 602, HSS 501, and IBCFs 701 and 702, which are connected to a plurality of terminals 111, 112, and 12, respectively. For convenience of explanation, the differences from FIG. 1 will be mainly described.

Interconnection Border Control Function (IBCF, 701, 702) serves as a border controller between an operator A and an operator B when interworking between IP Multimedia Subsystem (IMS) networks and various networks. It handles security and interlocking issues when interworking with.

The Call Session Control Function (601, 602) performs a call session control function. The CSCF (Call Session Control Function) server provides basic functions for multimedia session control based on Session Initiation Protocol (SIP) such as subscriber registration, authentication, service triggering, routing, call control or address handling. Can be done. It can also provide SIP signaling and state management. The CSCFs 601 and 602 are shown as one block in each network for convenience of description, but functionally include a P-CSCF, an S-CSCF, and an I-CSCF.

UE (UE), CSCF (601, 602), CSCF (601, 602) and IBCF (701, 702) are connected in a Session Initiation Protocol (SIP) scheme. In this case, the SIP method is a method for transmitting / receiving messages related to registration of the subscriber's IMS network, performance of a call control function for a subscriber's service request, and session establishment and release for voice, data, and multimedia.

The HSSs 501 and 502 manage the IMS subscriber profile, service profile, etc. as a central database for subscribers.

The HSS 501 and 502 and the CSCF 601 and 602, the HSS 501 and 502 and the IBCF 701 and 702 are connected in a DIAMETER manner. In this case, the DIAMETER method is a message transmission / reception method used to perform an authentication function for a subscriber's IMS network.

FIG. 6 is a flowchart illustrating call processing between UEs in the IMS network of FIG. 5.

When the IBCF 701, 702 acts as a B2B UA (Back-to-Back User Agent) between the network A and the network B, as shown in FIG. 3A and FIG. Otherwise, when a redial call occurs, a called terminal UE2 may be connected to another terminal UE1-2.

Since the IBCFs 701 and 702 act as gateways between different networks of IP types (IPv4, IPv6, etc.), unlike the embodiments illustrated in FIGS. 4A and 4B, the IBCFs 701 and 702 maintain new contact messages by maintaining contact information of the UE 100. It cannot be created.

Referring to FIG. 6, the UE1-1 111 transmits an initial invite message including its GRUU to the CSCF 601 (S201). If Orig-CSCF (Originating CSCF, Originating CSCF, 601) determines that UE2 (120) belongs to another network based on the invite message, Orig-IBCF (Originating IBCF, Originating IBCF, 701) to UE1- 1 (111) contact information (e.g. Contact: "UE1" <sip: 10.10.1.1: 5060>;), public GRUU (e.g. pub-gruu: "sip: ue1@example.com; gr = ue1-1 ") is transmitted (S202).

After receiving the invite message, Orig-IBCF 701 generates a calling party self-made GRUU (for example, IBC1@10.10.1.2: 5060) and the GRUU of the UE1-1 (111). Map and store self-generated GRUUs (eg ibc1_ue1@example1.com; gr = ibc1_ue1-1). The self-generated GRUU is then in accordance with RFC 5627. Orig-IBCF 701 may include contact information (eg Contact: <sip: IBC1@10.10.1.2: 5060>;) including publicly generated GRUUs and public GRUUs (eg pub-gruu = "sip: ibc1_ue1 @ example1 .com; gr = ibc1_ue1-1 ") and transmits the invite message to Term-IBCF (Terminating IBCF, called party IBCF, 702) (S203).

When the Term-IBCF 702 receives the invite message, the Term-IBCF 702 generates a self-made GRUU (for example, IBC2@10.10.1.3: 5060) of the called party and the GRUU of the UE1-1 (111). The called party's self-generated GRUU is mapped and stored (for example, ibc2_ue1@example1.com; gr = ibc2_ue1-1). The self-generated GRUU is then in accordance with RFC 5627. Term-IBCF 702 may include contact information (eg Contact: <sip: IBC2@10.10.1.3: 5060>;) including publicly generated GRUUs and public GRUUs (eg pub-gruu = "sip: ibc2_ue1 @ example1 .com; gr = ibc2_ue1-1 ") and transmits the invite message to Term-CSCF (receiving side CSCF) 602 (S204).

The Term-CSCF 602 attempts to make an outgoing call by transmitting the contact information including the self-generated GRUU and the invite message including the public GRUU to the UE2 120 (S205 and S206).

However, if UE2 120 receives a call of UE1-1 111 but fails to initiate a session (eg, missed call, on a call), UE2 120 connects to first call to UE1-1 111. It informs that it has failed (S207) and leaves the contact information of the Term-IBCF 702 in the destination UE2 (120) so that a retry call can be made later.

When a user of UE2 120 presses redial (retry) for a missed call of UE1-1 111, UE2 120 determines GRUU (“sip: ibc2_ue1@example.com;) included in the contact information; gr = ibc2_ue1-1 ") is applied to the R-URI to transmit the invite message to the Term-CSCF 602 (S208). At this time, the invite message must pass through the IBCF 702 and 701 to route to the UE1 registered in the other network.

That is, the Term-IBCF 702 is a destination self-generated GRUU (eg, ibc2_ue1 @ example2) generated by the GRUU included in the R-URI of the invite message S209 received from the Term-CSCF 602. com; gr = ibc2_ue1-1), send an invite message by modifying the R-URI to the original GRUU (eg ibc1_ue1@example1.com; gr = ibc1_ue1-1) that was mapped to the called party's self-generated GRUU. (S210).

Orig-IBCF 701 is a GRUU included in the R-URI of the invite message (S210) received from the Term-IBCF 702, the originating self-generated GRUU (eg ibc1_ue1@example1.com; gr = ibc1_ue1-1), sends an invite message by modifying the R-URI to the original GRUU (eg ue1@example1.com; gr = ue1-1) that was mapped to the called party's self-generated GRUU ( S211).

As a result, the Orig-CSCF 601 receives the invite message in step S211 and transmits the invite message to the UE1-1 111 correctly through the GRUU information of the UE1-1 111 (S212). You can make a session start request.

The SIP message transmission method in the IMS network according to the embodiments of the present invention may be implemented in the form of program instructions that can be executed by various computer means and recorded in a computer readable medium. The computer readable medium may include program instructions, data files, data structures, etc. alone or in combination. The program instructions recorded on the medium may be those specially designed and constructed for the present invention or may be available to those skilled in the art of computer software. Examples of computer-readable media include magnetic media such as hard disks, floppy disks and magnetic tape; optical media such as CD-ROMs and DVDs; magnetic media such as floppy disks; Includes hardware devices that are specially configured to store and execute program instructions such as magneto-optical media and ROM, RAM, flash memory, and the like. Examples of program instructions include machine language code such as those generated by a compiler, as well as high-level language code that can be executed by a computer using an interpreter or the like. The hardware device described above may be configured to operate as one or more software modules to perform the operations of the present invention, and vice versa.

The following 3rd Generation Partnership Project (3GPP) Technical Specification (TS), ie TS 24.229V7.8.0 (2007-12), is incorporated herein by reference.

Also included herein by reference is "Obtaining and Using Globally Toutable User Agent URIs (GRUUs) in the Session Initiation Protocol (SIP)" (RFC 5627), "Session Initiation Protocol", RFC 3261, June 2002. do.

Although the present invention has been described with reference to one embodiment shown in the drawings, this is merely exemplary, and those skilled in the art will understand that various modifications and equivalent other embodiments are possible therefrom. Therefore, the true technical protection scope of the present invention will be defined by the technical spirit of the appended claims.

1000: IMS Network
100,101,102,103,111,112,120: subscriber terminal
200: P-CSCF
300: I-CSCF
400: S-CSCF
500,501,502: HSS
600: AS
601,602: CSCF
701,702: IBCF

Claims (9)

When the originating terminal makes a call, the originating application server receives a first Session Initiation Protocol (SIP) message including a globally routable user agent uniform resource identifier (GRUU) contact information of the originating terminal. ;
Maintaining the GRUU contact information in the first SIP message and adding the GRUU contact information as a Record-Route header including a URL of the calling application server;
Sending, by the calling application server, a second SIP message including the GRUU contact information and the Record-Route header to a CSCF; And
Receiving a second SIP message by a called application server from the call session control function (CSCF). The method of claim 1,
Adding a Recourd-Route header including a URL of the called application server to the second SIP message; And
Sending, by the called application server, a third SIP message including the record-route header to the CSCF. The method of claim 2, wherein the redial call is generated from the called terminal because the call fails.
Transmitting a fourth SIP message to the calling party having the GRUU contact information of the calling terminal based on the third SIP message;
Finding binding information corresponding to the GRUU contact information in an originating CSCF; And
And transmitting the redial call to the calling terminal having the contact address corresponding to the binding information. When the calling terminal makes a call, receiving, by the calling IBCF, a first SIP message for calling including GRUU contact information of the calling terminal;
Generating, by the calling party IBCF, a calling party self-generating GRUU and mapping and storing the GRUU contact information and the calling party self-generating GRUU; And
Sending, by the originating IBCF, a second SIP message including the originating self-generating GRUU to the called party's IBCF. 5. The method of claim 4,
Generating, by the called party IBCF, a called party self-generating GRUU and mapping and storing the calling party self-generating GRUU and the called party self-generating GRUU; And
And sending, by the called party's IBCF, the outgoing signal including the called party's self-generated GRUU to a called terminal. The method as claimed in claim 5, wherein the re-dial call is generated from the called terminal because the call fails.
Sending, by the called terminal, a third SIP message to the called party IBCF having the called party self-generating GRUU; And
Searching for the calling party's self-generated GRUU corresponding to the called party's self-generated GRUU at the called party's IBCF. The method according to claim 6,
Sending, by the called IBCF, a fourth SIP message to the calling IBCF corresponding to the calling self-generating GRUU;
The originating IBCF finding the GRUU contact information mapped to the originating self-generating GRUU; And
And transmitting the redial call to the originating terminal corresponding to the GRUU contact information. In an IMS network system comprising at least one CSCF and at least one application system,
A CSCF for transmitting a first SIP message having contact information including a GRUU when a call of the terminal is generated; And
Upon receiving the first SIP message from the CSCF, the application server maintains the contact information and generates a second SIP message added with a record-route header including a URL of the application server and retransmits it to the CSCF. IMS network system comprising a. In an IMS network system including a calling CSCF, a called CSCF, a calling IBCF, and a called IBCF,
Upon receiving the first SIP message with the contact information including the GRUU from the calling CSCF, the calling party generates a self-made GRUU, maps and stores the received GRUU, and generates the calling self. The originating IBCF for transmitting a second SIP message including a GRUU; And
When the second SIP message is received from the calling party IBCF, a called party self-generated GRUU is generated, mapped with the calling party self-generated GRUU, and stored, and the third SIP message including the called party self-generated GRUU. IMS network system comprising the called party IBCF for transmitting and receiving with the called party CSCF.

Images