JP2008311764A - Ip communication apparatus and method, and call control server - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To achieve NAT traversal through a simple configuration while reducing the processing load of an SBC regardless of the type of NAT of relay equipment, in a communication system having an SBC which achieves data communicate without being influenced by the NAT. <P>SOLUTION: The IP communication apparatus 2 and 3 performing data communications with the other apparatus by call connection through an SIP server comprise, respectively, a signaling management section 21 for transmitting/receiving a call control message in order to establish connection with the other apparatus, a voice processing control section 12 for transmitting/receiving media data after establishing connection with the partner apparatus, a voice arrival monitoring section 23 for monitoring whether media data from the other apparatus are received normally or not during peer-to-peer connection, and a communication path management section 22 for requesting the SIP server to switch from peer-to-peer connection to connection through an SBC when data are not received normally. <P>COPYRIGHT: (C)2009,JPO&INPIT

Description

  The present invention relates to an IP (Internet Protocol) communication apparatus and an IP communication method connected to a wide area network via a relay device having a NAT (Network Address Translation) function, and a call control server for relaying a call between IP communication apparatuses.

  2. Description of the Related Art Conventionally, IP communication devices (IP telephones, etc.) connected to a company or home LAN (Local Area Network) are generally connected to a WAN (Wide-Area Network) via a relay device such as a router. It is. As such a relay device, there is a device equipped with a NAT function for transparently converting between a private IP address that can be used only in a LAN and a global IP address that can be used to access an external WAN. Exists. According to this NAT function, there is an advantage that the degree of freedom of assigning an IP address to a device connected to the LAN increases and the security of the LAN also increases.

  However, for example, when using an IP telephone service by an IP communication device connected to a relay device having a NAT function, a SIP (Session Initiation Protocol) used as a call control protocol or the like has a private IP address or port in the data portion of the IP packet. Since the communication is performed with the number added, the NAT function that converts only the IP address in the header portion of the IP packet cannot be used, and even if the global IP address is added to the data portion of the IP packet, the IP communication There is a problem that the device cannot grasp information on the global address and port number used by itself. As a result, a so-called NAT traversal problem has occurred, in which a communication packet from the WAN side does not reach the LAN side because the relay device becomes a wall.

  As a means for solving the NAT traversal problem, a method using STUN (Simple Traversal of User Datagram Protocol) is known. In this method, NAT traversal can be realized by installing on the network a STUN server that provides necessary information (global IP address, port number, NAT type, etc.) in response to a request from the IP communication apparatus. However, in this method, NAT type (for example, when a symmetric type NAT is present) and device characteristics such as a router having a NAT function (for example, when NAT traversal is inhibited by a device-specific security function) ) May not function properly.

Therefore, as a technique for realizing NAT traversal regardless of the NAT type and device characteristics, for example, a relay device that forms a pair across a network firewall (NAT) is provided, and a firewall is provided on the relay device. There is known a communication system that realizes NAT traversal by mediating intercommunicating communications (see Patent Document 1).
JP 2006-254160 A

  However, in the conventional technique described in Patent Document 1, it is necessary to provide a relay device that mediates communication inside and outside the firewall (NAT) in each network to which a terminal that performs communication belongs, which increases the cost of the system. In addition, there was a problem that the versatility was poor.

  As a technique for realizing NAT traversal regardless of NAT type and device characteristics, relay of SIP messages and media data (for example, voice, image, video, etc.) to a relay server such as SBC (Session Border Controller) There is also a method for processing. However, when transferring SIP messages and media data executed between IP communication devices via a relay server, there is a problem that an increase in traffic and an excessive processing load on the relay server may occur.

  The present invention has been devised in view of the problems of the prior art, and in a communication system having a relay server that enables communication of media data without being affected by NAT, the processing load of the relay server An IP communication device and an IP communication method capable of realizing NAT traversal regardless of the NAT type and device characteristics of a relay device with a simple configuration, and a call control server for relaying a call between IP communication devices The main purpose is to provide.

  The IP communication apparatus of the present invention is an IP communication apparatus that performs data communication with a partner apparatus by performing a call connection via a call control server, and is configured to establish a connection with the partner apparatus. A signaling means for transmitting and receiving a call control message to and from the counterpart apparatus via a control server; and a data communication means for transmitting and receiving data to and from the counterpart apparatus after establishing a connection with the counterpart apparatus; Data reception monitoring means for monitoring whether or not the reception of the data from the counterpart device is normally performed in a peer-to-peer connection with the counterpart device, and normal reception of the data from the counterpart device. If not, connection switching means for requesting the call control server to switch from the peer-to-peer connection to a connection via a predetermined relay server is provided. .

  As described above, according to the present invention, in a communication system having a relay server that enables data communication without being affected by NAT, the NAT of the relay device can be reduced with a simple configuration while reducing the processing load of the relay server. There is an excellent effect that NAT traversal can be realized regardless of the type and device characteristics.

  A first invention made to solve the above problems is an IP communication device that performs data communication with a partner device by performing a call connection via a call control server, Signaling means for transmitting / receiving a call control message to / from the counterpart device via the call control server to establish a connection, and transmission / reception of data to / from the counterpart device after establishing the connection with the counterpart device Data communication means for performing data reception monitoring means for monitoring whether or not reception of the data from the counterpart device is normally performed in a peer-to-peer connection with the counterpart device, and the data from the counterpart device Connection switching means for requesting the call control server to switch from the peer-to-peer connection to a connection via a predetermined relay server when data reception is not normally performed; A configuration with.

  According to this, in a communication system having a relay server (such as SBC (Session Border Controller)) that enables data communication without being affected by NAT of a relay device such as a router, the processing load of the relay server is reduced. With a simple configuration, NAT traversal can be realized regardless of the NAT type and device characteristics of the relay device.

  According to a second aspect of the present invention, the connection switching unit adds the predetermined processing command to the call control message transmitted by the signaling unit, thereby switching the connection. It can be configured to request the server.

  According to this, since it is possible to request the call control server to switch from the peer-to-peer connection to the connection via the relay server while maintaining the connection state with the other device, it is possible to switch the connection with a simple process. Become.

  According to a third aspect of the present invention, the data reception monitoring means receives data from the counterpart device when the data reception monitoring means does not receive data from the counterpart device for a certain period after establishing the connection with the counterpart device. It can be set as the structure which judges that is not performed normally.

  According to this, it becomes easy to determine whether or not reception of data from the counterpart device is normally performed by a simple process.

  A fourth invention made to solve the above-mentioned problem further comprises storage means for storing destination information of a counterpart device that needs to be switched from the peer-to-peer connection to the connection via the relay server, and the connection switching means When starting data communication with the counterpart device, the destination information of the counterpart device is checked against the destination information stored in the storage means, and if they match, the call control server It can be set as the structure which requests | requires the connection via the said relay server.

  According to this, for a partner device that is clearly required to be connected via a relay server (that is, communication is impossible via peer-to-peer connection), unnecessary connections can be made by connecting via the relay server from the beginning. This switching process can be avoided. In this case, the connection switching unit can appropriately store the destination information of the partner device that has switched from the peer-to-peer connection to the connection through the relay server in the storage unit, and can use it when executing a new communication. is there.

  A fifth invention made to solve the above problem is an IP communication device that performs data communication with a partner device by performing a call connection via a call control server, and the communication device is connected via a relay server. When data communication is started between a storage unit that stores destination information of a partner device that needs connection and the partner device, the destination information of the partner device is checked against the destination information stored in the storage unit. If they match, the call control server requests connection via the relay server, and if they do not match, the connection means for requesting the call control server for peer-to-peer connection, and the partner device And a data communication means for transmitting and receiving data to and from the counterpart device after the connection is established.

  A sixth invention made to solve the above-mentioned problem is an IP communication method of an IP communication device for performing data communication with a counterpart device by performing a call connection via a call control server, A signaling step for transmitting / receiving a call control message to / from the counterpart device via the call control server to establish a peer-to-peer connection with the counterpart device; and after establishing the peer-to-peer connection with the counterpart device, A data communication step for transmitting and receiving data, a data reception monitoring step for monitoring whether or not the data reception from the counterpart device is normally performed in the data communication step, and from the counterpart device If the data is not normally received, the call control server is connected from the peer-to-peer connection via a predetermined relay server. A structure having a connection switching requesting a switch to connect.

  A seventh invention made to solve the above problem is an IP communication method of an IP communication device for performing data communication with a counterpart device by performing a call connection via a call control server, wherein When storing destination information of a partner device that needs to be connected via a server and starting data communication with the partner device, the destination information of the partner device is checked against the stored destination information. If they match, the call control server is requested to connect via the relay server, and if they do not match, the call control server is requested to make a peer-to-peer connection, and after establishing a connection with the counterpart device, The data transmission / reception is performed with the counterpart device.

  An eighth invention made to solve the above problem is a call control server that relays a call between the IP communication device and the counterpart device according to the second or fifth invention, and is received from the IP communication device. Determining means for determining whether or not a processing command for requesting connection via the relay server is added to the call control message to be transmitted, and when the processing command is added to the call control message, the IP communication device And transfer means for transferring a call control message from the counterpart device to the relay server.

  Hereinafter, embodiments of the present invention will be described with reference to the drawings.

  FIG. 1 is a configuration diagram showing an outline of an IP communication system including an IP terminal and a SIP server according to the present invention, FIG. 2 is a functional block diagram of the IP terminal, and FIG. 3 is a functional block diagram of the SIP server. .

  In this IP communication system 1, a plurality of IP terminals (IP communication devices) 2, 3, a SIP server (call connection server) 4, and an SBC (relay server) 5 are connected via an IP network 6 so as to be able to communicate with each other. Have a configuration. The IP terminals 2 and 3 belong to LANs (Local Area Networks) 7 and 8, respectively, and are connected to the IP network 6 through NAT routers (relay devices having a NAT function) 9 and 10. Hereinafter, the configuration and operation of each device will be described by taking the case where the IP terminals 2 and 3 function as an IP telephone as an example.

  The IP terminals 2 and 3 function as UAC (User Agent Client) of SIP (Session Initiation Protocol), and include a call control unit 11, a voice processing control unit 12, a telephone control unit 13, a network I / F (interface) unit 14, A storage unit 15 and an operation unit 16 are provided.

  The call control unit 11 includes a signaling management unit (signaling unit) 21 that manages a signaling operation, a communication path management unit (connection switching unit) 22 that manages a communication path of voice data (media data), and a voice from a partner device. And a voice arrival monitoring unit (data reception monitoring means) 23 for monitoring the arrival of data.

  In order to establish a session, the signaling manager 21 performs transmission / reception of an SIP message (call control message) performed with the partner apparatus via the SIP server 4.

  The communication path management unit 22 appropriately selects a communication path when audio data is transmitted / received to / from the partner apparatus after the session is established. More specifically, the communication path management unit 22 normally performs peer-to-peer connection from the viewpoint of preventing traffic increase and reducing the processing load of the SBC 5, while normally performing communication by peer-to-peer connection. If it is determined that it is not possible (that is, NAT traversal cannot be realized), the SIP server 4 is requested to switch from the peer-to-peer connection to the connection via the SBC 5.

  In the connection via the SBC 5, all transmission / reception of voice data between the IP terminals 2 and 3 is performed via the SBC 5. At this time, the SBC 5 performs address conversion of the SIP message transferred from the SIP server 4 to establish a session, and relays the session by performing address conversion of voice data transmitted from the IP terminals 2 and 3. As a result, the IP terminals 2 and 3 can communicate voice data without being affected by NAT.

  Further, when switching to the connection via the SBC 5 is performed, the communication path management unit 22 stores the destination information of the counterpart device in the storage unit 15 as information on the destination that needs to be connected via the SBC 5. In the present embodiment, the destination number used for making a call is registered in the storage unit 15 as a number that needs to be connected via the SBC 5 (hereinafter referred to as “SBC registration number”). When making a new call, the communication path management unit 22 checks the destination number of the partner device against the SBC registration number stored in the storage unit 15 and, if they match, does not perform peer-to-peer connection from the beginning. Connect via SBC5. This makes it possible to avoid unnecessary connection switching processing.

  The voice arrival monitoring unit 23 monitors whether or not the voice packet is normally received from the counterpart device in the peer-to-peer connection in order to determine whether or not the peer-to-peer connection is successful. More specifically, when the voice arrival monitoring unit 23 measures the elapsed time after starting the reception monitoring of the voice packet by the timer function and receives the voice packet from the partner apparatus within a preset time, It is determined that the voice packet is normally received.

  The voice processing control unit 12 performs A / D and D / A conversion processing of voice data of a call, codec processing based on a predetermined voice encoding method (for example, ITU-T recommendation G.711, G.729a, etc.) and the like. At the same time, transmission / reception of voice packets (RTP (Realtime Transport Protocol) packets) obtained by packetizing voice data is executed.

  The telephone control unit 13 sends out processing instructions regarding outgoing and incoming calls to the call control unit 11 based on the operation commands from the operation unit 16 including the handset used by the user, and the operation from the call control unit 11. Based on the command, the ringback tone is output and stopped.

  Note that transmission / reception of voice packets, SIP messages, and the like is executed via the network I / F unit 14 connected to the LAN 7 and 8 lines.

  The SIP server 4 functions as a SIP UAS (User Agent Server), and includes a SIP control unit 31, a registrar unit 32, and a network I / F unit 33.

  The SIP control unit 31 relays SIP messages transmitted and received between the IP terminals 2 and 3 and processes these SIP messages to perform session control. The SIP control unit 31 has a function of comprehensively controlling the operation of the SIP server 4. As will be described later, the SIP control unit 31 switches the connection between the IP terminals 2 and 3 from the peer-to-peer connection to the connection via the SBC 5 by transferring the SIP message to the SBC 5 in response to a request from the IP terminals 2 and 3. Execute the process.

  The registrar unit 32 receives registration requests (REGISTER messages) from the IP terminals 2 and 3, and manages the location information (IP addresses and the like) of these IP terminals 2 and 3 as a location database.

  Note that transmission / reception of SIP messages and the like is executed via the network I / F unit 33 connected to the line of the IP network 6. Although not shown here, for example, the SIP server 4 has a redirect function that allows a message to be transferred to the location even when the IP terminals 2 and 3 move, and an event function that provides an instant message and presence service. Etc. can also be added.

  Next, details of a method in which the IP terminals 2 and 3 perform a call by appropriately selecting a peer-to-peer connection or a connection via the SBC 5 will be described.

  FIG. 4 is a flowchart showing an operation procedure up to the start of a call in the IP terminal on the calling side. Here, the main processes of the call control unit 11, the voice processing control unit 12, and the telephone control unit 13 will be described, but actually, in addition to these processes, as well as the conventional IP phone as well known as well known Is executed (the same applies to the case of FIG. 5). For convenience of explanation, FIG. 4 shows a case where the caller side IP terminal determines the success or failure of the peer-to-peer connection and executes the switching process to the connection via the SBC 5, but as will be described later, There may be a case where the switching process from the call side) to the connection via the SBC 5 is started.

  First, the telephone control unit 13 makes a call request to the call control unit 11 based on the input of the user's destination number (call operation) on the operation unit 16 (ST101). Based on the call request, the call control unit 11 collates the input destination number with the SBC registration number (ST102). If they do not match (that is, the destination number needs to be connected via the SBC 5). If it is not registered as a number), processing for establishing a peer-to-peer connection with the counterpart device is started (ST103). As will be described later, at this time, the call control unit 11 establishes a session by exchanging a predetermined SIP message with the partner apparatus via the SIP server 4.

  Next, the call control unit 11 starts voice arrival monitoring for determining whether or not the voice packet from the partner apparatus is normally received by the voice arrival monitoring unit 23 (ST104), and performs voice processing control. A communication start request is sent to unit 12 (ST105).

  When receiving a communication start request from call control unit 11 (ST106: YES), voice processing control unit 12 starts transmission / reception of voice packets (transmission / reception of media data) in a peer-to-peer connection with the counterpart device (ST107). Subsequently, the voice processing control unit 12 determines whether or not a voice packet has been received from the partner apparatus (ST108).

  When the voice processing control unit 12 receives a voice packet in ST108, the voice processing control unit 12 sends a voice arrival notification for notifying the call control unit 11 that the voice packet has been received (ST109). The voice communication state in which voice packets are continuously transmitted and received is established. On the other hand, if a voice packet is not received in ST108, voice processing control section 12 determines whether or not a communication stop request has been received from call control section 11 (ST110). At this time, if a communication stop request from the call control unit 11 has not been received, the process returns to ST108 again to perform voice packet reception determination.

  The call control unit 11 determines the success or failure of the peer-to-peer connection after sending a communication start request in ST105 (ST111). This determination is made based on whether or not a voice arrival notification is received from the voice processing control unit 12 in ST109. When the call control unit 11 receives the voice arrival notification, the call control unit 11 stops the voice arrival monitoring (ST112), and thereafter enters a call state by peer-to-peer connection. On the other hand, when the voice arrival notification is not received, the call control unit 11 determines whether or not the voice arrival monitoring has expired (that is, whether or not a predetermined set time has elapsed after the start of the voice arrival monitoring). (ST113). At this time, if the voice arrival monitoring has not expired, the process returns to ST111 again to determine whether or not a voice arrival notification has been received. When the voice arrival monitoring expires, the call control unit 11 sends a communication stop request to the voice processing control unit 12 (ST114).

  When the voice processing control unit 12 receives a communication stop request from the call control unit 11 (ST110: YES), the voice processing control unit 12 stops transmission / reception of voice packets with the counterpart device (ST115), and waits until a new communication start request is received. (ST116).

  After sending the communication stop request in ST114, the call control unit 11 executes processing for switching from peer-to-peer connection to connection via SBC5 (ST117). Although details will be described later, when switching to the connection via the SBC 5, the call control unit 11 adds a connection request (processing instruction) to the SBC 5 to the SIP message (INVITE message), and sends the request to the SIP server 4. Send it out.

  When the switching to the connection via the SBC 5 is completed and a new session is established, the call control unit 11 stores the destination number of the counterpart device in the storage unit 15 as the SBC registration number (ST118), and voice processing control A communication start request is sent to unit 12 (ST119), and thereafter, a call state is established.

  When the voice processing control unit 12 receives a communication start request from the call control unit 11 (ST116: YES), the voice processing control unit 12 starts transmission / reception of voice packets (transmission / reception of media data) with the connection via the SBC 5 (ST120), and then Is in a call state.

  In ST102, when the destination number and the registration number match, connection via SBC 5 can be executed from the beginning without executing the peer-to-peer connection as described above (ST121). At this time, the call control unit 11 sends the SIP message to which the connection request to the SBC 5 is added to the SIP server 4 as described above. Thereafter, the process proceeds to ST119, and the same operation as described above is executed.

  During the operation of the IP terminal on the calling side as described above (for example, it is determined that the call control unit 11 has transmitted the ST105 communication start request before the expiration of the voice arrival monitoring in ST113 or that the peer-to-peer connection has been successful in ST111. After that, the partner device may start the process of switching to the connection via the SBC 5. In that case, the call control unit 11 proceeds to ST114 and performs the same operation as described above. Similarly, in the voice processing control unit 12, the partner apparatus may start the process of switching to the connection via the SBC 5 after the voice arrival notification in ST109. In that case, the voice processing control unit 12 proceeds to ST110 and performs the same operation as described above.

  FIG. 5 is a flowchart showing an operation procedure up to the start of a call in the called IP terminal.

  First, the call control unit 11 receives a SIP message (INVITE message) from the partner apparatus (calling side), and starts processing for establishing a connection of the partner apparatus (ST201). At this time, the call control unit 11 sends an incoming call notification notifying the telephone control unit 13 of the incoming call, and then the telephone control unit 13 receives the incoming call to the call control unit 11 based on the user's off-hook operation. A request is transmitted (ST202). Subsequently, the call control unit 11 determines whether or not a connection request to the SBC is added to the SIP message from the partner apparatus (ST203).

  In ST203, when the SBC connection request is not added to the SIP message, voice arrival monitoring is started in the same manner as ST104 shown in FIG. 4 (ST204). Subsequent ST205 to ST220 are the same processes as ST105 to ST120 shown in FIG. 4, and detailed description thereof will be omitted. If an SBC connection request is added to the SIP message in ST203, the call control unit 11 proceeds to ST219 and executes connection via SBC5 without executing peer-to-peer connection.

  FIG. 6 is a flowchart showing the operation procedure of the SIP server. Here, a process is shown in which the SIP server 4 executes a peer-to-peer connection or a connection via the SBC 5 by transferring a SIP message.

  First, when receiving a SIP message from an IP terminal (ST301), the SIP control unit 31 analyzes the header of the SIP message and acquires information (ST302). Subsequently, the SIP control unit 31 determines whether or not the acquired information includes a connection request to the SBC 5 (information requesting a change in the communication path) (ST303). Therefore, when the connection request to the SBC 5 is not included, the SIP control unit 31 acquires the location information of the partner device from the registrar unit 32 (ST304), adds a necessary header (ST305), (ST307). Thereby, the connection between IP terminals becomes a peer-to-peer connection.

  On the other hand, if the SIP control unit 31 determines in ST303 that the connection request information to the SBC5 is included, the SIP request unit 31 deletes the connection request information to the SBC5 (ST308) and adds a necessary header (ST309), Transfer to SBC 5 (ST310). Thereby, the connection between IP terminals becomes a connection via SBC5.

  7 and 8 are sequence diagrams showing a first communication processing example between IP terminals in the IP communication system shown in FIG. Here, a case is shown in which it is determined that communication by the peer-to-peer connection cannot be normally performed in the IP terminal on the calling side. FIG. 7 shows a process for executing communication by peer-to-peer connection and determining that the communication cannot be normally performed. FIG. 8 shows a process for switching from peer-to-peer connection to a connection via SBC5. The process which performs communication is shown, and these are a series of operations. Examples of the start line and the plurality of headers of the SIP message transferred in the processing of FIGS. 7 and 8 are shown in FIGS.

  First, an IP terminal on the calling side (hereinafter referred to as “calling side device”) checks the destination number input based on the user's call operation with the SBC registration number and confirms that it is unregistered. (ST401). Subsequently, the calling side device starts SIP connection, transmits an INVITE message to the SIP server 4 (ST402), and the SIP server 4 transmits a 100 Trying message to the calling side device (ST403). .

  Next, the SIP server 4 analyzes the header of the received INVITE message and determines whether or not a connection request to the SBC 5 is included. This INVITE message is sent to the SBC 5 as shown in FIG. No connection request is added (ST404). Therefore, the SIP server 4 determines that peer-to-peer connection is required, and transfers the INVITE message to the called IP terminal (hereinafter referred to as “called device”) (ST405).

  Here, it is determined that the peer-to-peer connection is requested when the header of the received INVITE message does not include the connection request to the SBC 5, but the character indicating the connection request for the peer-to-peer connection is included in the header of the INVITE message. A column may be added.

  The called side device that has received the INVITE message transmits a 100 Trying message to the SIP server 4 (ST406), and further sends a 180 Ringing message and a 200 OK message to the calling side device. Sequentially transmitted (ST407, ST408). Finally, the calling side device transmits an ACK message to the called side device via the SIP server 4 (ST409), whereby the calling side and the called side device are peer-to-peer connected.

  Subsequently, the calling side device and the called side device start voice arrival monitoring with each other (ST410, ST411) and also start sending voice packets. Here, the voice packet from the calling side device reaches the called side device through the NAT router (ST412), but the voice packet from the called side device does not pass through the NAT router and goes to the calling side device. It is assumed that it does not reach (ST413). Therefore, the calling side device determines that the voice packet has not arrived after a predetermined time has elapsed after the start of the voice arrival monitoring (ST414), and then from the peer-to-peer connection as shown in FIG. Execute processing to switch to connection.

  As shown in FIG. 7, a special configuration for determining whether or not NAT traversal is possible by determining whether or not NAT traversal in NAT routers 9 and 10 is based on the reception state of voice packets in peer-to-peer connection. There is an advantage that it is not necessary to perform a simple process (such as sending a test packet).

  In FIG. 8, the calling device transmits an INVITE message for changing the session to the SIP server 4 (ST501). Here, the SIP server 4 analyzes the header of the received INVITE message and determines whether or not the connection request information to the SBC 5 is included. In this INVITE message, as shown in FIG. 12, the SBC 5 A connection request to is added (ST502). In the INVITE message of FIG. 12, “route = RelayServer” 101 is added to the Contact header as a connection request to the SBC 5. Alternatively, as shown in FIG. 13, a unique header “X-Status-Route: RelayServer” 102 may be provided as a connection request to the SBC 5.

  As long as a connection request to the SBC 5 can be added to the INVITE message, a description method other than that shown in FIGS. 12 and 13 may be used.

  Therefore, the SIP server 4 transfers the INVITE message to the SBC 5, and the INVITE message is transmitted to the called device via the SBC 5 (ST503). At this time, the SBC 5 converts the transmission destination address of the media data in the INVITE message into its own address so that a voice packet transmitted later from the called device can be relayed. The called device that has received the INVITE message transmits a 200 OK message to the SIP server 4, and the 200 OK message is also transferred to the SBC 5 and then transmitted to the calling device (ST504). At this time, the SBC 5 converts the destination address of the media data in the 200 OK message into its own address so that the voice packet transmitted later from the calling side device can be relayed. Finally, the calling side device transmits an ACK message to the called side device via the SIP server 4 and SBC 5 (ST505), so that the calling side and the called side device are connected via the SBC 5. The Thereafter, the calling device registers the current destination number as the SBC registration number (ST506).

  As a result, the calling side and called side devices can mutually transmit and receive voice packets via the SBC 5 (ST507).

  FIG. 9 is a sequence diagram illustrating a second communication processing example between IP terminals. Here, a case is shown in which it is determined at the called device that communication by peer-to-peer connection cannot be normally performed. In addition, before the process shown in FIG. 9, the process similar to FIG. 7 shall be implemented (however, as for the process of ST412-ST413, a caller side and a callee side are reverse processes). .

  In FIG. 9, the called device transmits an INVITE message for changing the session to the SIP server 4 (ST601). This INVITE message is the same as that shown in FIGS. The SIP server 4 analyzes the header of the received INVITE message and determines that a connection request to the SBC 5 has been added, as in ST502 of FIG. 8 (ST602). Therefore, the SIP server 4 transfers the INVITE message to the SBC 5 similarly to ST503 in FIG. 8, and this INVITE message is transmitted to the called device via the SBC 5 (ST603). Subsequently, the 200 OK message and the ACK message are respectively exchanged as in ST504 and ST505 of FIG. 8 (ST604, ST605). Thereafter, the calling device registers the destination number as the SBC registration number (ST606).

  As a result, the calling side and called side devices can mutually transmit and receive voice packets via the SBC 5 (ST607).

  FIG. 10 is a sequence diagram illustrating a third communication processing example between IP terminals. Here, a case is shown in which the calling side apparatus executes connection via SBC 5 from the beginning without performing peer-to-peer connection.

  In FIG. 10, the calling side device first checks the input destination number against the SBC registration number and confirms that they match (ST701). Subsequently, the calling side device starts SIP connection, transmits an INVITE message to the SIP server 4 (ST702), and the SIP server 4 transmits a 100 Trying message to the calling side device (ST703). . This INVITE message is the same as that shown in FIGS.

  The SIP server 4 analyzes the header of the received INVITE message and determines that a connection request to the SBC 5 has been added as in ST502 of FIG. 8 (ST704). Therefore, the SIP server 4 transfers the INVITE message to the SBC 5 as in ST503 of FIG. 8, and this INVITE message is transmitted to the called device via the SBC 5 (ST705).

  The called device that has received the INVITE message transmits a 100 Trying message to the SIP server 4 (ST706), and then transmits a 180 Ringing message to the SIP server 4, and the 180 Ringing message is sent to the SBC5. And then transmitted to the calling side device (ST707). Thereafter, the 200 OK message and the ACK message are respectively exchanged as in ST504 and ST505 in FIG. 8 (ST708, ST709).

  As a result, the calling side and called side devices can mutually transmit and receive voice packets via the SBC 5 (ST710).

  Although the present invention has been described in detail based on specific embodiments, these embodiments are merely examples, and the present invention is not limited to these embodiments. For example, the present invention can be applied not only to IP telephones but also to various IP communication devices. Also, the call control protocol is not limited to SIP, and other protocols may be used.

  An IP communication apparatus, an IP communication method, and a call control server according to the present invention, in a communication system having a relay server that enables communication of media data without being affected by NAT, With a simple configuration, it is possible to realize NAT traversal regardless of the NAT type and device characteristics of the relay device, so that an IP communication device connected to a wide area network via a relay device having a NAT function and an IP provided with the same It is useful as a communication system and these IP communication methods.

Configuration diagram of an IP communication system including an IP terminal and a SIP server according to the present invention Functional block diagram of IP terminal Functional block diagram of SIP server Flow chart showing operation procedure of calling side IP terminal Flow chart showing operation procedure of called-side IP terminal Flow chart showing the operation procedure of the SIP server Sequence diagram showing a first communication processing example between IP terminals Sequence diagram showing a first communication processing example between IP terminals Sequence diagram showing a second communication processing example between IP terminals Sequence diagram showing a third communication processing example between IP terminals Diagram showing details of SIP message Diagram showing details of SIP message Diagram showing details of SIP message

Explanation of symbols

1 IP communication system 2, 3 IP terminal (IP communication device)
4 SIP server (call control server)
5 SBC (relay server)
6 IP network 9, 10 NAT router 11 Call control unit 12 Voice processing control unit 13 Telephone control unit 15 Storage unit 21 Signaling management unit (signaling means)
22 Communication path manager (connection switching means)
23 Voice arrival monitoring unit (data reception monitoring means)
31 SIP control unit (determination means, transfer means)

Claims (8)

An IP communication device that performs data communication with a partner device by performing a call connection via a call control server,
Signaling means for sending and receiving call control messages to and from the counterpart device via the call control server to establish a connection with the counterpart device;
Data communication means for transmitting and receiving data to and from the counterpart device after establishing a connection with the counterpart device;
Data reception monitoring means for monitoring whether or not reception of the data from the counterpart device is normally performed in a peer-to-peer connection with the counterpart device;
Connection switching means for requesting the call control server to switch from the peer-to-peer connection to a connection through a predetermined relay server when the data from the counterpart device is not normally received. An IP communication apparatus.   The connection switching unit requests the call control server to switch the connection by adding a predetermined processing instruction to the call control message transmitted by the signaling unit. IP communication device.   The data reception monitoring means determines that reception of data from the counterpart device is not normally performed when data is not received from the counterpart device for a certain period after the connection with the counterpart device is established. The IP communication apparatus according to claim 1. Storage means for storing destination information of a counterpart device that needs to be switched from the peer-to-peer connection to the connection through the relay server;
The connection switching means, when starting data communication with the counterpart device, collates the destination information of the counterpart device with the destination information stored in the storage means, and if they match, the call control The IP communication apparatus according to claim 1, wherein the server requests a connection via the relay server. An IP communication device that performs data communication with a partner device by performing a call connection via a call control server,
Storage means for storing destination information of a partner apparatus that needs to be connected via a relay server;
When starting data communication with the counterpart device, the destination information of the counterpart device is checked against the destination information stored in the storage means, and if they match, the relay to the call control server A connection means for requesting a connection through a server and, if not matched, requesting a peer-to-peer connection to the call control server;
Data communication means for transmitting and receiving data to and from the counterpart device after establishing a connection with the counterpart device;
An IP communication apparatus comprising: An IP communication method for an IP communication device that performs data communication with a counterpart device by performing a call connection via a call control server,
A signaling step for transmitting and receiving call control messages to and from the counterpart device via the call control server to establish a peer-to-peer connection with the counterpart device;
A data communication step of transmitting and receiving data to and from the counterpart device after establishing a peer-to-peer connection with the counterpart device;
In the data communication step, a data reception monitoring step for monitoring whether or not reception of data from the counterpart device is normally performed;
A connection switching step of requesting the call control server to switch from the peer-to-peer connection to a connection through a predetermined relay server when the data from the counterpart device is not normally received. An IP communication method characterized by the above. An IP communication method for an IP communication device that performs data communication with a counterpart device by performing a call connection via a call control server,
Stores the destination information of the partner device that needs to be connected via the relay server,
When starting data communication with the counterpart device, the destination information of the counterpart device is checked against the stored destination information, and if they match, the call control server is passed through the relay server. And if it does not match, request a call-to-peer connection to the call control server,
An IP communication method, comprising: transmitting and receiving data to and from the partner device after establishing a connection with the partner device. A call control server that relays a call between the IP communication device according to claim 2 or claim 5 and a counterpart device,
Determining means for determining whether or not a processing command for requesting connection via the relay server is added to a call control message received from the IP communication device;
A call control server comprising transfer means for transferring a call control message from the IP communication device and the counterpart device to the relay server when the processing command is added to the call control message.

Images