WO2006048925A1 - 通信中継方法、通信中継プログラムおよび通信中継装置 - Google Patents

通信中継方法、通信中継プログラムおよび通信中継装置 Download PDF

Info

Publication number
WO2006048925A1
WO2006048925A1 PCT/JP2004/016265 JP2004016265W WO2006048925A1 WO 2006048925 A1 WO2006048925 A1 WO 2006048925A1 JP 2004016265 W JP2004016265 W JP 2004016265W WO 2006048925 A1 WO2006048925 A1 WO 2006048925A1
Authority
WO
WIPO (PCT)
Prior art keywords
connection request
voice call
call device
network
communication
Prior art date
Application number
PCT/JP2004/016265
Other languages
English (en)
French (fr)
Inventor
Shigeki Fukuta
Shinichiro Mori
Nobutsugu Fujino
Original Assignee
Fujitsu Limited
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Fujitsu Limited filed Critical Fujitsu Limited
Priority to JP2006542195A priority Critical patent/JP4627760B2/ja
Priority to PCT/JP2004/016265 priority patent/WO2006048925A1/ja
Priority to EP04799468A priority patent/EP1809010A4/en
Publication of WO2006048925A1 publication Critical patent/WO2006048925A1/ja
Priority to US11/797,363 priority patent/US20080212764A1/en

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M7/00—Arrangements for interconnection between switching centres
    • H04M7/12—Arrangements for interconnection between switching centres for working between exchanges having different types of switching equipment, e.g. power-driven and step by step or decimal and non-decimal
    • H04M7/1205—Arrangements for interconnection between switching centres for working between exchanges having different types of switching equipment, e.g. power-driven and step by step or decimal and non-decimal where the types of switching equipement comprises PSTN/ISDN equipment and switching equipment of networks other than PSTN/ISDN, e.g. Internet Protocol networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/66—Arrangements for connecting between networks having differing types of switching systems, e.g. gateways
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M11/00—Telephonic communication systems specially adapted for combination with other electrical systems
    • H04M11/007—Telephonic communication systems specially adapted for combination with other electrical systems with remote control systems
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M15/00—Arrangements for metering, time-control or time indication ; Metering, charging or billing arrangements for voice wireline or wireless communications, e.g. VoIP
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M3/00—Automatic or semi-automatic exchanges
    • H04M3/42—Systems providing special services or facilities to subscribers
    • H04M3/42195—Arrangements for calling back a calling subscriber
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/24—Accounting or billing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1101—Session protocols
    • H04L65/1104—Session initiation protocol [SIP]
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D30/00—Reducing energy consumption in communication networks
    • Y02D30/70—Reducing energy consumption in communication networks in wireless communication networks

Definitions

  • the present invention relates to a communication relay method, a communication relay program, and a communication relay device that relay communication between a first voice call device and a second voice call device.
  • PSTN Public Switched Telephone Network
  • IP networks such as PCs, PDAs, landline phones, mobile phones, and PHS
  • the applicant assigns a phone call to any of a plurality of devices used by the user at the point of time using a transfer destination selection function of a “call transfer server” (specifically, a SIP server).
  • a “call transfer server” specifically, a SIP server.
  • Propose a "Ubiquitous IP phone system” that can be transferred to the most suitable device with!! Japanese Patent Application No. 20 04-079590.
  • the call forwarding destination is determined based on the current location of the user and preset preferences. For example, even if the phone is working on the same phone number, the user is still present.
  • the device that is actually called such as an extension telephone for the person's seat, or a mobile phone when going out, will change from time to time.
  • the present applicant has proposed a mobile phone type dual terminal equipped with a plurality of wireless communication devices, for example, PHS power WLAN (Japanese Patent Application No. 2004-199333). And on this device,
  • the above dual terminal waits with PHS as long as PHS can be used and supplies power to the WLAN as much as possible.
  • the terminal is within the PHS range, it turns off the WLAN regardless of whether it is within or outside the WLAN range.
  • the above terminals are dual terminals, they are virtually equivalent to PHS when waiting in the PHS area. Therefore, in order to call this from the IP network, it is necessary to first turn on the WLAN and connect it to the IP network, and then to register the necessary items (IP address, etc.) in the SIP server 2000.
  • PPPhone system of “International System Research Co., Ltd.” (more specifically, WakeOn Ring technology “PPPush” adopted in the system).
  • PPPush WakeOn Ring technology
  • the caller places an IP phone call from the calling terminal 2001 via the PSTN, and through its telephone strength SP_S (PSTN ⁇ SIP) gateway 2003 and SIP server 2000, Furthermore, if the call is transferred to the receiving terminal 2002 via the PSTN,
  • the present invention has been made in view of the above, and a communication relay method, a communication relay program, and the like capable of relaying communication between a calling terminal and a receiving terminal on a relatively inexpensive route, And it aims at providing a communication relay apparatus.
  • the present invention transfers the first connection request from the first voice call device to the second voice call device, and sends the connection request to the second voice call device.
  • the connection request is transferred to the first voice call device.
  • the present invention transfers the first connection request from the first voice communication device to the second voice communication device through the first network, and from the second voice communication device to the second voice communication device. Net ⁇ When the second connection request is received through the network, the first connection request is transferred to the second voice communication device through the second network.
  • connection request for is routed through B.
  • the present invention transfers the first connection request received through the predetermined network to the second voice communication device through the network, cancels the connection request, and When the second connection request is received from the voice call device, the connection request is transferred to the first voice call device.
  • connection request in which a charge is generated twice due to passing through the same network twice between a calling terminal and a receiving terminal is Canceled before one charge is incurred.
  • the present invention receives a connection request from the first voice communication device through the first network, specifies a second network to which the connection request is transferred, and And the second network is not identical, the connection request is transferred to the second voice communication device through the second network.
  • connection request that causes a double charge due to passing the same network twice between the calling terminal and the receiving terminal is Discarded before charges are incurred.
  • the communication relay method, the communication relay program, and the communication relay device according to the present invention have an effect that the communication between the transmitting terminal and the receiving terminal can be relayed on the relatively cheapest route.
  • FIG. 1 is an explanatory diagram showing an outline of a “call back method” realized by the communication relay device according to the first embodiment of the present invention.
  • FIG. 2 is an explanatory diagram showing an outline of a “callback method” realized by the communication relay device according to the first embodiment of the present invention.
  • FIG. 3 is an explanatory diagram of a hardware configuration of the communication relay device according to the first embodiment of the present invention.
  • FIG. 4 is an explanatory diagram of a functional configuration of the communication relay device according to the first embodiment of the present invention.
  • FIG. 5 is a flowchart of various request processing procedures in the communication relay device according to the first embodiment of the present invention.
  • FIG. 6 is a flowchart showing a procedure of an incoming call process in the incoming call terminal 102 according to the first embodiment of the present invention.
  • FIG. 7 is an explanatory diagram showing an outline of the “reconnecting method” realized by the communication relay device according to the second embodiment of the present invention.
  • FIG. 8 is an explanatory diagram showing an outline of a “reconnecting method” realized by the communication relay device according to the second embodiment of the present invention.
  • FIG. 9 is an explanatory diagram of a functional configuration of the communication relay device according to the second embodiment of the present invention.
  • FIG. 10 is a flowchart of a process procedure of various requests in the communication relay device according to the second embodiment of the present invention.
  • Fig. 11 is a flowchart showing a procedure of an incoming call process in the incoming call terminal 702 according to the second embodiment of the present invention.
  • FIG. 12 is an explanatory diagram showing an outline of the “reconnect + reconnect scheme” realized by the communication relay device according to the third embodiment of the present invention.
  • FIG. 13 is an explanatory diagram showing an outline of the “reconnect + reconnect scheme” realized by the communication relay device according to the third embodiment of the present invention.
  • FIG. 14 is a flowchart illustrating processing procedures of various requests in the communication relay device according to the third embodiment of the present invention.
  • FIG. 15 is a flowchart of the incoming call processing procedure at the incoming call terminal 1202 according to the third embodiment of the present invention.
  • FIG. 16 is a flowchart showing the procedure of the calling process in the calling terminal 1201 according to the third embodiment of the present invention.
  • FIG. 17 is an explanatory diagram showing an outline of the “recall method” realized by the communication relay device according to the fourth embodiment of the present invention.
  • FIG. 18 is an explanatory diagram of a functional configuration of the communication relay device according to the fourth embodiment of the present invention.
  • FIG. 19 is a flowchart of processing procedures of various requests in the communication relay device according to Embodiment 4 of the present invention.
  • FIG. 20 is an explanatory view showing a problem of the prior art.
  • FIG. 21 is an explanatory view showing another problem of the prior art.
  • FIG. 1 and FIG. 2 are explanatory diagrams showing an outline of the “callback method” realized by the communication relay device according to the first embodiment of the present invention.
  • the calling terminal 101 may be any device capable of VoIP calls using SIP (Session Initia tion Protocol), but here it is a telephone (IP phone) connected to the IP network via a VoIP adapter, for example.
  • SIP Session Initia tion Protocol
  • IP phone IP phone
  • a caller makes a call to a representative number previously assigned to each called party from the calling terminal 101, for example, “050—XXXX—XXXX”, a SIP URI (Uniform Resource Identifier) that means the number, For example, an INVITE request destined for “sip: + 81—050—XXXX—XXXX @ •••” is sent to the SIP server 100 via the IP network ((1) in the figure).
  • the URI is referred to as a “virtual URI”.
  • the SIP server 100 has the transfer destination selection function described above, and sends an INVITE request to the callee's virtual URI to any one of the callee's actual SIP URIs (at least one). Forward to.
  • the above actual SIP URI is referred to as “incoming terminal URI”, and one selected as the forwarding destination is particularly referred to as “selected URI”.
  • the correspondence relationship between the virtual URI and the receiving terminal URI and which of the receiving terminal URIs is the currently selected URI are held in the “forwarding destination table” of the SIP server 100.
  • the receiving terminal URI to which “*” is added is the selected URI.
  • the INVITE request from the calling terminal 101 is transferred to the receiving terminal 102 uniquely identified by the selected URI after the SIP server 100 changes the destination to the virtual URI power selecting URI.
  • the selected URI is a SIP URI that means an identifier (specifically a telephone number) on the PSTN, such as “tel: + 81—070—XXXX—XXXX”
  • the above request is first sent to the SP gateway 104 (2 in the figure) is converted into a PSTN call and then transferred to the receiving terminal 102 via the PSTN ((3) in the figure).
  • a call charge between the SP gateway 104 and the call receiving terminal 102 is generated even when the call charge is not normally generated, specifically, even when the call receiving terminal 102, which is a dual terminal, is within the WLAN range. End up.
  • the selected URI is (a) a SIP URI corresponding to a device that can be connected to a relatively expensive (high communication cost) network and an inexpensive (low communication cost) network.
  • SIP URI meaning the former identifier
  • SIP URI meaning the PHS number of a dual terminal that can be connected to the PSTN or IP network
  • SIP URI meaning the PHS number of a general PHS is (b).
  • a SIP URI meaning a PHS number corresponds to (a) if the number is a dual-terminal PHS number, or (b) if it is a general PHS PHS number.
  • the type of SIP URI corresponding to (b) is called ⁇ normal ''.
  • the caller must pay the call charge that should not be borne by the caller (specifically, the call charge between the S-P gateway 104 and the receiving terminal 102). This is the case when the selected URI is (a), that is, when the type is not “normal”. There In Example 1, if the selected URI type is not “normal”, the CANCEL request is sent immediately after the INVITE request is transferred from the SIP server 100 to the S—P gateway 104 ((2) in the figure). As a result, the call from the SP gateway 104 to the receiving terminal 102 is disconnected before the call charge is generated (specifically, about one call) ((3) in the figure).
  • the SIP server 100 also forwards the INVITE request from the calling terminal 101 to the announcement service 105 together with the SP gateway 104 ((4) in the figure), and the announcement service 105 to the calling terminal 101
  • the 2XX response (success) and the ACK request from the calling terminal 101 to the announcement service 105 are sequentially transferred.
  • the announcement service 105 calls the caller to answer the caller's power, and is instructed to hang up and wait.
  • a BYE request is transmitted from the calling terminal 101 to the announcement service 105 ((5) in the figure), the call from the calling terminal 101 is disconnected.
  • the called terminal 102 that is so-called “one-off” from the S-P gateway 104 connects to the IP network by the WLA N or connects to the PSTN by the PHS and immediately calls back.
  • SIP is used.
  • the “transfer source table” of the server 100 the correspondence relationship between the receiving terminal 102 and the calling terminal 101 as the callback destination is held.
  • the SIP Sano 100 transfers the INVITE request received from the calling terminal 101 to the SP gateway 104 and the announcement service 105, the virtual URI described in the To header of the request ((1) in the figure) "Receiver Virtual”) and the URI of the calling terminal 101 described in the From header (calling terminal URI; "Caller VoIP”) is registered in the "transfer source table” that holds it.
  • the receiving terminal 102 connects to the IP network via the WLAN and calls back to the SP gateway 104
  • the INVITE request from the receiving terminal 102 is the destination SP gateway 104. Is transferred to the SIP server 100 (Fig. 1 (6)).
  • the INVITE request received by the SIP server 100 includes (a) a normal INVITE request (such as (1) in the figure) and (b) an INVITE request triggered by a past phone call.
  • a normal INVITE request such as (1) in the figure
  • b an INVITE request triggered by a past phone call.
  • the type of I NVITE request corresponding to (a) is called “normal”, and the type of INVITE request corresponding to (b) is called “callback”.
  • it can be specified by referring to the transfer destination table and the transfer source table above whether an INVITE request is the above. Specifically, in the forwarding destination table, if the virtual URI associated with the SIP URI described in the From header of the request is also registered in the forwarding source table (b), it is not registered. (A).
  • the SIP server 100 specifies the destination of the request as a source terminal URI (corresponding to the virtual URI in the transfer source table).
  • “Caller VoIPj” is substituted and transferred to the calling terminal 101 (Fig. 1 (7)).
  • 2XX response (success) and ACK request RTP connection is established between the called terminal 102 and one calling terminal 101. (Fig. 1 (8)).
  • the SP gateway 104 is the destination.
  • An INVITE request is transmitted from the SP gateway 104 to the SIP server 100 (FIG. 2 (7)).
  • the SIP server determines whether or not it is a callback in the same manner as described above.
  • the destination of the request is transferred to the originating terminal URI retrieved from the transfer source table and transferred (Fig. 2 (8)). ).
  • 2XX response uccess
  • ACK request RTP connection is established between SP gateway 104 and calling terminal 101 (Fig. 2 (9)).
  • the PS gateway 103 of FIG. 1 and FIG. 2 may be omitted (the invention of the first embodiment can be implemented without the PS gateway 103). It is shown for comparison.
  • FIG. 3 is an explanatory diagram showing the hardware configuration of the communication relay device (specifically, the SIP server 100 shown in FIG. 1) according to the first embodiment of the present invention.
  • CPU 301 controls the entire device.
  • the ROM 302 stores a boot program and the like.
  • the RAM 303 is used as a work area for the CP 301.
  • the HDD 304 controls the read Z write of data to the HD 305 in accordance with the control of the CPU 301.
  • HD305 stores data written according to the control of HDD304 To do.
  • the FDD 306 controls data read Z write to the FD 307 according to the control of the CPU 301.
  • the FD 307 stores data written according to the control of the FDD 306.
  • the FD307 is an example of a detachable recording medium. Instead of the FD307, a CD-ROM (CD-R, CD-RW), MO, DVD (Digital Versatile Disk), memory force, etc. may be used. .
  • the network IZF 308 is connected to a network such as LANZWAN, and controls transmission and reception of data between the network and the inside of the apparatus.
  • the bus 300 connects the above-described units.
  • this device may have consoles such as a display, a mouse, and a keyboard.
  • FIG. 4 is an explanatory diagram showing a functional configuration of the communication relay device according to the first embodiment of the present invention (specifically, the SIP server 100 shown in FIG. 1), and FIG. It is a flowchart which shows the process sequence of various requests. The function of each part in Fig. 4 will be explained in sequence in the flowchart of Fig. 5.
  • step S501 When the proxy 402 of the SIP server 100 receives the NVITE request (step S501: Yes), the request is output to the transfer destination specifying unit 403 and the INVITE type specifying unit 403a of the transfer destination specifying unit 403 Specify the request type. If the type is “normal” (step S502: Yes), the type of the selected URI associated with the virtual URI of the destination of the above request is specified. Is identified.
  • the transfer destination specifying unit 403 is the proxy 402.
  • the INVITE request, the selected URI, and the SIP URI of the announcement service 105 input from are output to the request generation unit 404.
  • Step S504 and these are sequentially transferred by the proxy 402 (Step S504).
  • P505 A CANCEL request destined for the selected URI is transferred after the SP gateway 104 calls the receiving terminal 102 in response to an INVITE request destined for the URI.
  • the transfer destination specifying unit 403 instructs the transfer source table update unit 405 to register the pair of the virtual URI of the INVITE request input to the proxy 402 and the calling terminal URI in the transfer source table 401 ( Step S506).
  • step S503 when the type of the selected URI is “normal” (step S503: Yes), the forwarding destination specifying unit 403 sends the INVITE request input from the proxy 402 and the selected URI to the request generating unit 404.
  • the request generation unit 404 generates an INVITE request with the URI as the destination by replacing the destination of the request with the URI (step S507).
  • the request generation unit 404 outputs the above request to the proxy 402, and after the request is transferred (step S508), the normal processing after the INVITE request transfer such as the response transfer or the ACK request transfer is performed. Perform (Step S509).
  • step S502 if the type of INVITE request input from proxy 402 is "callback" (step S502: No), that is, the request is triggered by another INVITE request previously transferred in steps S501-S506. If the request is received, the transfer destination specifying unit 403 outputs the request and the originating terminal URI registered in the transfer source table 401 when transferring the other request to the request generation unit 404. Then, the request generation unit 404 generates an INVITE request with the URI as the destination by replacing the destination of the request with the URI (step S510), and the request is transferred to the calling terminal 101 by the proxy 402 (step S510). S 511).
  • the transfer destination specifying unit 403 instructs the transfer source table update unit 405 to check the virtual URI and the originating terminal URI registered in the transfer source table 401 when transferring another INVITE request that has been triggered. Delete the pair (step S512). Thereafter, the proxy 402 performs normal processing after transferring the INVITE request, such as transferring a response or transferring an ACK request (step S509).
  • step S501 No
  • step S5 server 100 performs other processing corresponding to the received request (step S513).
  • FIG. 6 is a flowchart showing the procedure of the incoming call process in the incoming call terminal 102 according to the first embodiment of the present invention.
  • Step S601 If there is an incoming call from the S—P gateway 104 while waiting by PHS (Step S601: Yes, Step S602: Yes. Note that the incoming call from the S—P gateway 104 can be identified by the telephone number). 102 waits for call disconnection without outputting a ring tone, turns on the WLAN that is turned off (step S603), determines whether it is outside the zone Z of the WLAN (step S604), and based on this result, the WLA Select one of NZPHS as the communication method. In addition to the above judgment results, you may select one of the communication methods based on the communication cost, call quality, preset preferences, etc.
  • step S605 If the WLAN is selected (step S605: Yes), the receiving terminal 102 connects to the IP network via the WLAN, and sends an INVITE request to the S-P gateway 104 (step S606).
  • SIP call (step S607) is started.
  • the WLAN that was turned on at the incoming call is turned off again (step S608).
  • a REGISTER request is sent to the SIP server 100 before the INVITE request.
  • step S605 when PHS is selected (step S605: No), the receiving terminal 102 turns off the WLAN that has been turned on again (step S609).
  • step S610 connect to the PSTN with PHS and place a call to the telephone number of S—P gateway 104 (step S610), so that a normal PHS call (step S611. To become a call).
  • a force other than the SP gateway 104 is applied to the telephone strength S, a ring tone is output (Step S602: No, Step S612), and after the called party answers the phone, it becomes a normal PHS call (Step S602). S611).
  • FIG. 1 and FIG. 2, and FIG. 5 and FIG. 6 will be described in association with each other.
  • the SIP server 100 since the call forwarding destination from the calling terminal 101 is not “normal”, the SIP server 100 The gateway 104 is instructed to call the incoming terminal 102 with a so-called “one-off” method that does not involve the power of call charges, and the outgoing terminal 101 is connected to the announcement service 105 (FIG. 5, steps S501 to S506).
  • the receiving terminal 102 connected to the IP network via the WLAN and returned an INVITE request.
  • steps S601-S606 or as a result of terminating terminal 102 connecting to PSTN via PHS and calling S-P gateway 104 (Fig. 6, steps S601-S605, S609-S610), S-P gateway
  • the SIP server 100 identifies that the request is a callback and transfers the destination after changing the destination to the calling terminal 101 (step S501 in FIG. 5). — S502, S510— S512).
  • the SIP server 100 transfers the response to the receiving terminal 102 or the SP gateway 104 and receives an ACK request from the receiving terminal 102 or the SP gateway 104. Then, the request is transferred to the calling terminal 101 (step S509 in FIG. 5).
  • the PSTN is used only (3).
  • the communication path is the same as the dotted line arrow in Fig. 20 (however, the direction of the arrow is reversed due to the callback), and compared to the conventional solid line arrow, the call charge between S-P gateway 2004 and receiving terminal 2002 Can be reduced.
  • Example 1 in addition to making the caller feel uncomfortable (because the phone call must be hung up), the caller and the caller can actually talk. It takes time to become. Therefore, the caller power is also called back as in the first embodiment. As in the second embodiment described below, if the caller is connected in the conventional manner, the communication path is relatively expensive. Try to reconnect the call from the calling party to the called party via the relatively inexpensive communication path B.
  • FIG. 7 and FIG. 8 are explanatory diagrams showing an outline of the “reconnection method” realized by the communication relay device according to the second embodiment of the present invention.
  • the SIP server 700 searches the forwarding destination table for the selected URI associated with the virtual URI, and determines the destination of the request. Replace with the selected URI and transfer. If this selected URI is a SIP URI that means the PHS number of a dual terminal, the above request is forwarded to the SP gateway 704 ((2) in the figure) and converted to a PSTN call, via the PSTN. Is transferred to the receiving terminal 702 ((3) in the figure). The steps so far are the same as in the callback method of the first embodiment.
  • the terminating terminal 702 called from the S—P gateway 704 selects one of the WLAN ZPHS as a communication means, and when selecting the WLAN, transmits a REGISTER request to the SIP server 700 as shown in FIG. 7 ( (4) in the figure).
  • the REGISTER request received by the SIP server 700 includes (a) a normal REGISTER request and (b) a REGISTER (such as (4) in the figure) triggered by a past phone call.
  • a REGISTER request is the above or not can be specified by referring to the transfer destination table and transfer source table described above.
  • the virtual URI associated with the SIP URI (the SIP URI where the IP address is registered) described in the To header and From header of the above request is stored in the forwarding source table. Is also registered (b), otherwise (a).
  • the type of REGISTER request corresponding to (a) is called “normal”.
  • the SIP server 700 sends a CANCEL request to the S-P gateway 704 ((5) in the figure).
  • the call to the receiving terminal 702 is disconnected ((6) in the figure).
  • the destination of the INVITE request received from the calling terminal 701 is transferred to the SIP URI in which the receiving terminal 702 has registered the IP address ((4) in the figure) (Fig. Medium (7)).
  • the SP gateway 704 Upon receiving the above signal, the SP gateway 704 transmits a 2XX response to the SIP server 700 ((5) in the figure), and the SIP server 700 further forwards the response to the calling terminal 701 (in the figure). (6)). After an ACK request is transferred, an RTP connection is established between the calling terminal 701—S—P gateway 704 ((7) in the figure).
  • FIG. 9 is an explanatory diagram showing the functional configuration of the device
  • FIG. 10 is a flowchart showing the processing procedure of various requests in the device. The function of each part in FIG. 9 will be described in sequence in the flowchart of FIG.
  • step S1001 When the proxy 902 power NVITE request of the SIP server 700 is received (step S1001: Yes), the request is output to the transfer destination specifying unit 903 at any time, and the transfer destination type specifying unit 903a of the transfer destination specifying unit 903 With reference to the forwarding destination table 900, the type of the selected URI associated with the virtual URI of the destination of the request is specified.
  • step S1002 If the selected URI type is "normal” (step S1002: No), the transfer source table update unit 905 is instructed to set the combination of the virtual URI of the request and the calling terminal URI. It is registered in the transfer source table 901 (step S 1003). If the selected URI type is “normal” (step S 1002: Yes), the process of step S 1003 is omitted.
  • the request and the selected URI are output to the request generation unit 904, and the request generation unit 904 replaces the destination of the request with the URI, so that the URI is the destination.
  • An INVITE request is generated (step S1004).
  • the proxy 902 performs normal processing after transferring the INVITE request, such as transferring a response or transferring an ACK request (step S1006).
  • the registrar 906 of the SIP server 700 receives the REGISTER request (step S1007: Yes)
  • the R of the registrar 906 follows the normal SIP registration process (step S1008).
  • the EGISTER type specifying unit 906a specifies the type of the request.
  • step S 1009: Yes If the type is “normal” (step S 1009: Yes), the process directly returns to step S 100 1. On the other hand, if the type is not “normal” (step S 1009: No), that is, if the above request is triggered by the previous INVITE request transferred in steps S1001 to S1006, the registrar 906 Outputs the INVITE request, the selected URI that is the transfer destination of the INVITE request, and the originating terminal URI registered in the transfer source table 901 when the INVITE request is transferred to the request generation unit 904.
  • step S1010 are generated (step S1010), and these are sequentially transferred by the proxy 902 (step S1011).
  • the registrar 906 instructs the transfer source table update unit 905 to delete the pair of the virtual URI and the transmission terminal URI registered in the transfer source table 901 when the triggered IN VITE request is transferred.
  • the proxy 902 performs normal processing after transferring the INVITE request, such as transferring a response or transferring an ACK request (step S1006). If a request other than an INVITE request or a REGISTER request is received (step S1001: No, step S1007: No), the SIP server 700 performs other processing corresponding to the received request (step S1013).
  • FIG. 11 is a flowchart showing the procedure of the incoming call process in the incoming call terminal 702 according to the second embodiment of the present invention. If there is an incoming call from the S—P gateway 704 while waiting by PHS (step S1101: Yes, step SI 102: Yes), the receiving terminal 702 turns OFF the WL AN that is OFF (step S 1103). ) Determine whether the zone is outside the Z zone of WL AN (step S1104), and select one of the WLANZPHS as a communication method based on the result. In addition to the above judgment results, communication means may be selected based on communication costs, call quality, and pre-set preferences.
  • step S1105 If the WLAN is selected (step S1105: Yes), the receiving terminal 702 is the WLAN. To connect to the IP network and send a REGISTER request to the SIP server 700 (step S 110). On the other hand, when PHS is selected (Step S1105: No), the WLAN that is turned on is set to OF F (Step S1107) and a ring tone is output (Step S1108). After the called party answers the call, it is normal. (Step S 1109).
  • step S 1101 Yes, step S1102: No
  • the receiving terminal 702 outputs a ring tone (step S1108), and the callee After answering the call, it becomes a normal PHS call (step S 1109).
  • step S1111 When an INVITE request is received by the WLAN that was turned ON in step S 1103 (step S1101: No, step SI 110: Yes), the receiving terminal 702 outputs a ring tone (step S1111), and the incoming call is received. After the person answers the call, it becomes a normal SIP call (step S1112). At the end of the call, turn off the WLAN that was turned on when the call was received (step S1113)
  • FIG. 7 and FIG. 8, and FIG. 10 and FIG. 11 are explained in correspondence with each other.
  • the SIP server 700 first receives a call from the calling terminal 701 to the receiving terminal 702 via the PSTN. However, if there is a REGISTER request from the receiving terminal 702 (FIG. 11, step S1101—S 1106), it is canceled and then transferred to the receiving terminal 702 via the IP network (see figure S1001—S1005). 10 steps S1007—S1012). When there is a 2X X response from the receiving terminal 702, the response is transferred to the calling terminal 701, and when there is an ACK request from the calling terminal 701, the request is transferred to the receiving terminal 702 (FIG. 10 step S10 06). ).
  • the S-P gateway 704 force ⁇ SIP Sano 7 00 Since the 2XX response is returned, the SIP server 700 transfers the response to the calling terminal 701 and, when receiving an ACK request from the calling terminal 701, transfers the request to the SP gateway 704 (step S1006 in FIG. 10).
  • step S1006 in FIG. 10 is performed when the SIP server 700 receives a 3XX-6XX response from the S—P gateway 704, on the condition that there is no REGISTER request from the receiving terminal 702 within a predetermined time. It may be modified to forward to. In other words, even if a connection failure is notified from the SP gateway 704, it is not immediately notified to the transmitting terminal 701, but the registration from the receiving terminal 702 is waited for the predetermined time.
  • the telephone made by the SP gateway 704 in (3) is disconnected before the incoming terminal 702 responds. Call charges are not incurred throughout 10).
  • the communication path is the same as the dotted line arrow in FIG. 20, and the call charge between the SP gateway 2004 and the receiving terminal 2002 can be reduced compared to the solid line arrow in the prior art.
  • FIG. 8 is the same as the solid line arrow of FIG. 20, that is, in the above-mentioned ubiquitous IP telephone system, it is the same as the case where a call from an IP terminal to a representative number is transferred to a non-IP terminal.
  • S-P gateway 2004—calling terminal 2002 is charged to the caller.
  • the REGISTER request transmitted from the receiving terminal 702 to the SIP server 700 is essentially a request for SIP registration.
  • this is a kind of connection request, that is, a transmitting terminal. It is regarded as a request from the incoming terminal 702 that it should be connected to the 701 via the IP network.
  • the SIP server 700 can be said to be redirecting the telephone once transferred via the PSTN via the IP network. it can.
  • the above connection request must be a REGISTER request from the receiving terminal 702, not necessarily some kind of notification (not necessarily an incoming call) indicating that the receiving terminal 702 is ready to receive calls on the WLAN. It may not be a notification from the terminal 702 itself, etc.).
  • FIG. 12 and FIG. 13 are explanatory diagrams showing an outline of the “reconnect + reconnect scheme” realized by the communication relay device according to the third embodiment of the present invention.
  • Example 2 described above is a case where a call is made from an IP terminal (for example, an IP phone), but Example 3 is a non-IP terminal, specifically, This is the case when making a power call such as a conventional phone or dual terminals when outside the WLAN area.
  • Example 3 is a non-IP terminal, specifically, This is the case when making a power call such as a conventional phone or dual terminals when outside the WLAN area.
  • the calling terminal 2001 makes a call via the PSTN and the called terminal 2002 also receives a call via the PSTN, the call charge between the calling terminal 2001—PS gateway 2003 and the S—P Call charges between gateway 2004 and receiving terminal 2002 are doubled.
  • the calling terminal 1201 makes a call via the PSTN ((1) in the figure), and the PS gateway 1203 force and the SIP Sano 1200 are passed through.
  • the PS gateway 1204 power is further transmitted from the SIP server 1200 immediately after the INVITE request is transferred when the call is made via the PSTN ((4) in the figure).
  • the call from the S—P gateway 1204 to the receiving terminal 1202 is disconnected before the call charge is incurred (specifically, about one call). ((4) in the figure).
  • the receiving terminal 1202 transmits a REGISTER request to the SIP server 1200 as shown in FIG. 12 ((5) in the figure). If the above request type is not normal, the SIP server 1200 will register the destination of the INVITE request received from the PS gateway 1203 ((2) in the figure) and the destination terminal 1202 will register the IP address. ((5) in the figure) Transfer to the SIP URI that was changed ((6) in the figure).
  • the 2XX response is received from the receiving terminal 1202 ((7) in the figure), the response is transferred to the PS gateway 1203 ((8) in the figure), and further, after the ACK request is transferred, An RTP connection is established between P—S gateway 1203—receiving terminal 1202 ((9) in the figure). After that, a response signal is returned from the P-S gateway 1203 to the calling terminal 1201 via the PSTN ((10) in the figure).
  • the receiving terminal 1202 receives a call from the SP gateway 1204 as shown in FIG. 13 ((4) in the figure). Wait for the phone to come up (do nothing from you). S—P gateway 1204 Because the phone with 1204 power is cut off by one time, it is not enough to answer with PHS, and neither power nor WL AN can be used Z Because it is not used, the incoming terminal 1202 is PHS with S—P gateway 12 04 There is no choice but to call back S-P gateway 1204 to SIP server 1 If the INVITE request is transferred to the PS gateway 1203 via 200 and the calling terminal 1201 is called from the PS gateway 1203 via the PSTN, the above-mentioned double charging problem may occur.
  • the calling terminal 1201 instead of the receiving terminal 1202 doing nothing, the calling terminal 1201 automatically makes a call again.
  • the calling terminal 1201 according to the third embodiment does not connect the call to the called party's representative number within the predetermined time (the response signal is not returned from the PS gateway 1203 within the predetermined time), Select another caller's phone number and try again.
  • the other telephone number may be stored in advance in the calling terminal 1201, or may be acquired in real time from the SIP server 1200 or the like.
  • the hardware configuration of the communication relay device according to the third embodiment of the present invention (specifically, the SIP server 1200 shown in FIGS. 12 and 13) is the same as that of the first embodiment shown in FIG. Since there is, explanation is omitted.
  • the functional configuration of the above apparatus is almost the same as that of the second embodiment shown in FIG. 9, and the differences will be sequentially described in the flowchart of FIG.
  • FIG. 14 is a flowchart showing a processing procedure for various requests in the apparatus.
  • Example 2 shown in Fig. 10 The difference from Example 2 shown in Fig. 10 is that the CANCEL request generation and transfer processing is in the processing loop when receiving a REGISTER request in Fig. 10 (steps S 1010 ⁇ S 1 011). In Fig. 14, it is the point (steps S 1404 ⁇ S 1405) in the processing loop when receiving the INVITE request that triggered the request. (If a request other than an INVITE request or a REGISTER request is received, SIP The server 1200 performs other processing corresponding to the received request (Step S1401: No, Step SI409: No, Step S1415)).
  • the request generation unit 904 for the IN VITE request received by the SIP server 1200, the type of the selected URI specified by the transfer destination type specification unit 903a. Is not “normal”, an INVITE request and a CANCEL request with the URI as the destination are generated, and these are sequentially transferred by the proxy 902 (steps S 14 01 to S 1405). If the selected URI type is “Normal”, an INVITE request is generated with the URI as the destination, and after this is forwarded by the proxy 902, the proxy 902 forwards the response, ACK request, etc. Then, normal processing is performed after the INVITE request is transferred (steps S1401 to S1402, S1406 to S1408).
  • the request generation unit 904 for the REGI STER request received by the SIP server 1200, if the type power S specified by the REGISTER type specification unit 906a is not "normal", the IP address An INVITE request whose destination is the registered SIP URI is generated and transferred to the receiving terminal 1202 by the proxy 902 (steps S1409 to S1414).
  • FIG. 15 is a flowchart showing the procedure of the incoming call process in the incoming call terminal 1202 according to the third embodiment of the present invention.
  • the processing in steps S 1501 to S 1513 in the figure is the same as the processing in steps S 1101 to S 1113 shown in FIG.
  • step S1505 No, step S1507
  • the call of the S-P gateway 1 204 is disconnected! Because PHS calls are not possible, step S 1501 [Return!
  • FIG. 16 is a flowchart showing the procedure of the calling process in the calling terminal 1201 according to the third embodiment of the present invention.
  • a calling instruction is issued for a specific telephone number, for example, a representative number of the called party (step S1601: Yes)
  • the calling terminal 1201 calls the number via the PSTN (step S1602).
  • the above call is converted to an I NVITE request by the PS gateway 1203, transferred to the SIP server 1200, and when a 2XX response is returned from the SIP server 1200, a response signal is sent from the PS gateway 1203 to the calling terminal 1201. Is returned (step S 1603: Yes), and then a normal voice call is made (step S 1604).
  • Step S1603: No, Step S1605: No the calling terminal 1201 waits for the above signal for a predetermined time from the call (Step S1603: No, Step S1605: No), and responds from the PS gateway 1203 even if the time has elapsed. If there is no phone number (Step S1603: No, Step S1605: Yes), if there is another phone number (Step S1606: Yes), it is still possible to make a call to the above called party. Above (step S1607), the corresponding number is called (step S1602). If all the telephone numbers of the called party are called and there is still no response (step S 1606: No), the process ends at that point.
  • FIG. 12 and FIG. 13 are related to FIG. 14 and FIG. 16.
  • the SIP server 1200 does not wait for a REGISTER request from the receiving terminal 1202, and If the incoming terminal 1202 receives a REGISTER request ( Figure 15 steps S 1501-S 1506), the IP address is sent to the registered SIP URI. The request is transferred (steps S1409 to S1414 in Fig. 14).
  • the SIP server 1200 force NVITE request is canceled (FIG. 14 Steps S1401 to S1405).
  • Terminal 1201 selects the other telephone number of the called party, in this case the PHS number of the dual terminal, and makes a call again (steps S 1601 to S 1607 in FIG. 16).
  • FIG. 17 is an explanatory diagram illustrating an outline of the “recall method” realized by the communication relay device according to the fourth embodiment of the present invention.
  • Example 4 causes double charging.
  • the INVITE request (specifically (2) in the figure) that is transferred from the P-S gateway 1703 to the S-P gateway 1704 via the SIP server 1700 is discarded by the SIP server 1700. Do not forward to that destination.
  • the calling terminal 1701 selects another telephone number of the called party, for example, a PHS number of a dual terminal.
  • the call is corrected 4 times ((3) in the figure) and a response signal is returned from the receiving terminal 1702 ((4) in the figure), it becomes a normal PHS call.
  • FIG. 18 is an explanatory diagram showing the functional configuration of the device, and FIG. The function of each part in FIG. 18 will be described in sequence in the flowchart of FIG.
  • the proxy 1801 of the SIP server 1700 receives the INVITE request (step S19 01: Yes)
  • the request is output to the transfer destination specifying unit 1802 at any time, and the transfer availability determining unit 1802a of the transfer destination specifying unit 1802
  • the transfer destination table 1800 is referenced to determine whether the request can be transferred (step S 1902).
  • a SIP URI indicating a telephone number is described in the To header and From header.
  • step S1902 If transfer is not possible (step S1902: No), the process returns to step S1901 to wait for reception of another request, while if transfer is possible (step S 1902: Yes), the request generation unit 1803 By changing the destination of the request to the selected URI in the transfer destination table 1800, an INVITE request for the URI is generated (step 1903). After this is transferred by the proxy 1801 (step S1904), the proxy 1801 performs normal processing after the INVITE request transfer, such as a response transfer or an ACK request transfer (step S 1905).
  • step S1901 If a request other than an INVITE request is received (step S1901: No)
  • the SIP server 1700 performs other processing corresponding to the received request (step S1 906).
  • the receiving terminal 1702 of the fourth embodiment may be any device capable of receiving a call on the PSTN, and the processing in the device is the same as that of the conventional technology.
  • the calling terminal 1701 of the fourth embodiment may be any device that can make a call on the PSTN, but, as with the calling terminal 1201 of the third embodiment, a telephone call for a predetermined time or more is performed according to the procedure of FIG. It is assumed that it has a function to call back to another number when it is not connected.
  • Example 4 INVITE requests that cause double billing when transferred are limited to SIP server 1700, and calling terminal 1701 will make another call over another route. Double charge does not occur. More generally speaking, if there is a relatively expensive communication path A and an inexpensive communication path B, if the telephone power S is applied via A first, the power on the path (for example, Since the SIP server 1700) discards it as shown in Example 4 and makes a call via B again, the communication path when the call is finally connected is always the cheapest.
  • calling terminal 101Z701 is an IP terminal
  • calling terminal 1201 Z 1701 is a non-IP terminal.
  • the INVITE request received by the SIP server includes (a) an INVITE request sent by the calling terminal itself, and (b) an INVITE request transferred by the PS gateway after converting the call from the calling terminal.
  • a SIP server having both functions of the SIP server 700 of the second embodiment and the SIP server 1200 of the third embodiment is prepared, and when (a) is received, the procedure of FIG. When (b) is received, it is processed according to the procedure shown in Fig. 14.
  • S of Example 1 Prepare a SIP server that has the functions of both the IP server 100 and the SIP server 1700 of the fourth embodiment. When (a) is received, the procedure of FIG. 5 is performed. When (b) is received, the procedure of FIG. 19 is performed. Make sure to do it.
  • the communication relay method, the communication relay program, and the communication relay device that are effective in the present invention are useful for selecting an optimum route when there are a plurality of communication routes between the calling terminal and the receiving terminal.
  • it is suitable for a case where a relatively inexpensive communication path becomes practically unusable for some reason (for example, power saving).

Abstract

　ＷＬＡＮとＰＨＳの双方を搭載する携帯型のデュアル端末は、省電力の観点から、ＰＨＳ圏内にある限りはたとえＷＬＡＮ圏内でもＷＬＡＮをＯＦＦにしている。そのため電話がかかってくると、通常はＳ−Ｐゲートウェイ（１０４）からＰＳＴＮ経由で呼び出されることになり、発呼者に通話料が発生してしまう。そこで本発明では、Ｓ−Ｐゲートウェイ（１０４）から着信端末（１０２）（デュアル端末）への呼を通話料の発生前に切断するとともに、着信端末（１０２）からＩＰ網またはＰＳＴＮ経由でＳ−Ｐゲートウェイ（１０４）へコールバックする。そして着信端末（１０２）の代わりに、ＳＩＰサーバ（１００）でコールバック先となる発信端末（１０１）を特定し、これにより着信端末（１０２）からの電話が発信端末（１０１）に接続される。なおこの「コールバック方式」のほか、本発明では「繋ぎ直し方式」「繋ぎ直し＋かけ直し方式」「かけ直し方式」の４方式を提案する。

Description

通信中継方法、通信中継プログラムおよび通信中継装置
技術分野
[0001] 本発明は、第 1の音声通話装置と第 2の音声通話装置との間の通信を中継する通 信中継方法、通信中継プログラムおよび通信中継装置に関するものである。
背景技術
[0002] PSTN (Public Switched Telephone Network:公衆電話回線網）や IP網な どのネットワークに接続された各種情報機器、たとえば PC、 PDA,固定電話、携帯 電話、 PHSなどを一人のユーザが複数台所有して、仕事の状況や通信環境などに 応じて使い分けることはもはや当たり前の時代となっている。ただ、いつでもどこでも 仕事ができるということは、その反面、いつどこで仕事をしているか分力もないというこ とでもあり、たとえばあるユーザと今すぐ話がしたいとき、どの機器をどう呼び出せば 最もスムーズに連絡がつくか分力 な 、と 、う問題がある。
[0003] そこで本出願人は、ユーザが使用する複数の機器のいずれかにかかってきた電話 を、「呼転送サーバ」（具体的には SIPサーバを想定)の転送先選択機能により、その 時点で最適な機器に転送する「ュビキタス IP電話システム」を提案して!/ヽる（特願 20 04— 079590)。上記システムにおいては、ユーザの現在位置や事前に設定された プリファレンスにもとづいて電話の転送先が決定されるので、たとえば同一の電話番 号に力かってきた電話でも、ユーザが在席中であればその自席の内線電話、外出中 であれば携帯電話というように、実際に呼び出される機器はその時々で変化すること になる。
[0004] 一方、本出願人は複数の無線通信装置、たとえば PHSのほ力 WLANもあわせて 搭載する携帯電話型のデュアル端末を提案している（特願 2004— 199333)。そして この端末では、
• WLANの圏内にあるときは、 WLANで IP網に接続（基本的には無料）
• WLANの圏外にあるときは、 PHSで PSTNに接続（基本的には有料） というように、通信環境などに応じて使用する通信装置や接続するネットワークを切り 換えることで、通信コストを抑制することができる。
[0005] しかしながら図 20に示すように、上記「ュビキタス IP電話システム」において、着信 端末 2002が特に上記デュアル端末であった場合には、発信端末 2001が PSTNを 経由しないで電話をかけた場合でも、着信端末 2002へは破線矢印ではなぐ実線 矢印すなわち PSTN経由で接続されてしまう。そして、破線矢印の場合は通話料が 発生しないのに対して、実線矢印の場合は、
• S-P (SIP→PSTN)ゲートウェイ 2004—着信端末 2002間の通話料
が発呼者に発生してしまう。
[0006] これは省電力の観点から、上記デュアル端末は PHSが使える限りはもっぱら PHS で待ち受けを行 、、 WLANにはできるだけ電力を供給しな 、ようにして 、るためであ る。すなわち上記端末は、 PHS圏内でさえあれば、 WLANの圏内か圏外かに力か わらず WLANを OFFにしている。言い換えると上記端末は、デュアル端末とはいうも のの、 PHS圏内での待ち受け時には実質的に PHS相当となっている。このためこれ を IP網から呼び出すには、まずその WLANを ONにして IP網に接続させ、さらに SIP サーバ 2000に必要事項 (IPアドレスなど）を登録させるためのしくみが必要である。
[0007] ちなみにこのしくみの一例としては、「株式会社インターナショナルシステムリサーチ 」の「PPPhone」システム（さらに詳細には、当該システムで採用されて 、る WakeOn Ringテクノロジ「PPPush」）がある。これは電源 OFFの状態にある PDAが、「Wake Onトリガー」と呼ばれる本体起動用のメッセージを PHSで受信すると、自己の電源を ONにするとともに WLANで IP網に接続し、 SIPサーバへ必要事項を登録するもの である。
[0008] また、たとえば図 21の実線矢印で示すように、発呼者が発信端末 2001から PSTN 経由で IP電話をかけ、その電話力 SP_S (PSTN→SIP)ゲートウェイ 2003および SIP サーバ 2000を経て、さらに PSTN経由で着信端末 2002に転送された場合、
'発信端末 2001— P— Sゲートウェイ 2003間の通話料
• S— Pゲートウェイ 2004—着信端末 2002間の通話料
の両者が発呼者に発生してしまう（二重課金)。この場合は結果的に、図中実線矢印 の経路で IP電話をかけるより、破線矢印の経路で普通に電話をかけたほうが安価だ つたことになり、上記システムを利用するメリットが減殺されてしまう。なお、この問題は 発信端末 2001や着信端末 2002がデュアル端末でなくとも、双方ともに PSTNを利 用する機器である場合に発生する。
発明の開示
発明が解決しょうとする課題
[0009] まとめると、上記従来技術においては、本来負担しなくてもよいはずの通話料を発 呼者が負担しなければならな ヽ場合があった。具体的には、
(1)ュビキタス IP電話システムを IP網経由で利用した場合、当該システムが着呼者を PSTN経由で呼び出したことが原因で、 IP網経由で呼び出せば無料だつたはずの 通話に料金が力かってしまう
(2)ュビキタス IP電話システムを PSTN経由で利用した場合、当該システムが着呼者 を PSTN経由で呼び出したことが原因で、当該システムを介さず直接 PSTN経由で 呼び出すのに比べて余分に料金が力かってしまう
などである。
[0010] 本発明は、上記に鑑みてなされたものであって、発信端末一着信端末間の通信を 相対的に最も安価な経路で中継することが可能な通信中継方法、通信中継プロダラ ム、および通信中継装置を提供することを目的とする。
課題を解決するための手段
[0011] 上述した課題を解決し、目的を達成するために、本発明は第 1の音声通話装置か らの第 1の接続要求を第 2の音声通話装置に転送するとともに、当該接続要求をキヤ ンセルし、第 2の音声通話装置から第 2の接続要求を受信すると、当該接続要求を第 1の音声通話装置に転送することを特徴とする。
[0012] 上記発明（後述する「コールバック方式」）によれば、発信端末一着信端末間に相 対的に高価な通信経路 Aと安価な通信経路 Bとがある場合、発信端末からの A経由 の接続要求はキャンセルされ、あらためて着信端末カゝら B経由で接続要求がなされる
[0013] また、本発明は第 1の音声通話装置からの第 1の接続要求を第 1のネットワークを通 じて第 2の音声通話装置に転送するとともに、第 2の音声通話装置から第 2のネットヮ ークを通じて第 2の接続要求を受信した場合には、第 1の接続要求を第 2のネットヮ ークを通じて第 2の音声通話装置に転送することを特徴とする。
[0014] 上記発明（後述する「繋ぎ直し方式」）によれば、発信端末一着信端末間に相対的 に高価な通信経路 Aと安価な通信経路 Bとがある場合、発信端末力 の A経由の接 続要求は B経由となるようその経路を変更される。
[0015] また、本発明は第 1の音声通話装置力も所定のネットワークを通じて受信した第 1の 接続要求を当該ネットワークを通じて第 2の音声通話装置に転送するとともに、当該 接続要求をキャンセルし、第 2の音声通話装置から第 2の接続要求を受信すると当該 接続要求を第 1の音声通話装置に転送することを特徴とする。
[0016] 上記発明（後述する「繋ぎ直し +かけ直し方式」）によれば、発信端末一着信端末 間で同一ネットワークを二回経由するために料金が二重に発生するような接続要求 は、一方の料金が発生する前にキャンセルされる。
[0017] また、本発明は第 1の音声通話装置からの接続要求を第 1のネットワークを通じて 受信するとともに、当該接続要求が転送されることになる第 2のネットワークを特定し、 第 1のネットワークと第 2のネットワークとが同一でない場合に当該接続要求を第 2の ネットワークを通じて第 2の音声通話装置に転送することを特徴とする。
[0018] 上記発明（後述する「かけ直し方式」 )によれば、発信端末一着信端末間で同一ネ ットワークを二回経由するために料金が二重に発生するような接続要求は、一方の料 金が発生する前に破棄される。
発明の効果
[0019] 本発明にかかる通信中継方法、通信中継プログラム、および通信中継装置は、発 信端末一着信端末間の通信を相対的に最も安価な経路で中継することができるとい う効果を奏する。
図面の簡単な説明
[0020] [図 1]図 1は、本発明の実施例 1にかかる通信中継装置により実現される、「コールバ ック方式」の概略を示す説明図である。
[図 2]図 2は、本発明の実施例 1にかかる通信中継装置により実現される、「コールバ ック方式」の概略を示す説明図である。 [図 3]図 3は、本発明の実施例 1にかかる通信中継装置のハードウェア構成を示す説 明図である。
[図 4]図 4は、本発明の実施例 1にかかる通信中継装置の機能的構成を示す説明図 である。
[図 5]図 5は、本発明の実施例 1にかかる通信中継装置における、各種リクエストの処 理手順を示すフローチャートである。
[図 6]図 6は、本発明の実施例 1にかかる着信端末 102における、着信処理の手順を 示すフローチャートである。
[図 7]図 7は、本発明の実施例 2にかかる通信中継装置により実現される、「繋ぎ直し 方式」の概略を示す説明図である。
[図 8]図 8は、本発明の実施例 2にかかる通信中継装置により実現される、「繋ぎ直し 方式」の概略を示す説明図である。
[図 9]図 9は、本発明の実施例 2にかかる通信中継装置の機能的構成を示す説明図 である。
[図 10]図 10は、本発明の実施例 2にかかる通信中継装置における、各種リクエストの 処理手順を示すフローチャートである。
[図 11]図 11は、本発明の実施例 2にかかる着信端末 702における、着信処理の手順 を示すフローチャートである。
[図 12]図 12は、本発明の実施例 3にかかる通信中継装置により実現される、「繋ぎ直 し +かけ直し方式」の概略を示す説明図である。
[図 13]図 13は、本発明の実施例 3にかかる通信中継装置により実現される、「繋ぎ直 し +かけ直し方式」の概略を示す説明図である。
[図 14]図 14は、本発明の実施例 3にかかる通信中継装置における、各種リクエストの 処理手順を示すフローチャートである。
[図 15]図 15は、本発明の実施例 3にかかる着信端末 1202における、着信処理の手 順を示すフローチャートである。
[図 16]図 16は、本発明の実施例 3にかかる発信端末 1201における、発信処理の手 順を示すフローチャートである。 [図 17]図 17は、本発明の実施例 4にかかる通信中継装置により実現される、「かけ直 し方式」の概略を示す説明図である。
〇
[図 18〇]図 18は、本発明の実施例 4にかかる通信中継装置の機能的構成を示す説明 図である。
[図 19]図 19は、本発明の実施例 4にかかる通信中継装置における、各種リクエストの 処理手順を示すフローチャートである。
[図 20]図 20は、従来技術の問題点を示す説明図である。
[図 21]図 21は、従来技術の他の問題点を示す説明図である。
符号の説明
700, 1200, 1700 SIPサーノ
101, 701, 1201, 1701 発信端末
102, 702, 1202, 1702 着信端末
103, 703, 1203, 1703 P— Sゲートゥ
104, 704, 1204, 1704 S— Pゲー卜ゥ
105 アナウンスサービス
300 バス
301 CPU
302 ROM
303 RAM
304 HDD
305 HD
306 FDD
307 FD
308 ネットワーク IZF
400, 900, 1800 転送先テーブル
401, 901 転送元テーブル
402, 902, 1801 プロキシ
403, 903, 1802 転送先特定部 403a INVITE種別特定部
403b, 903a 転送先種別特定部
404, 904, 1803 ジクエス卜生成部
405, 905 転送先テーブル更新部
906 レジストラ
906a REGISTER種別特定部
1802a 転送可否判定部
発明を実施するための最良の形態
[0022] 以下に、本発明にかかる通信中継方法、通信中継プログラム、および通信中継装 置の実施例を図面に基づいて詳細に説明する。なお、この実施例によりこの発明が 限定されるものではない。
[0023] 本発明では上述した従来技術の問題点（1) (2)を解決するため、
•実施例 1：コールバック方式 問題点（1)を解決
•実施例 2：繋ぎ直し方式 問題点（1)を解決
•実施例 3 :繋ぎ直し +かけ直し方式' · ·問題点（2)を解決
•実施例 4：かけ直し方式 問題点（2)を解決
の 4方式を提案する。以下、順次説明する。
実施例 1
[0024] (コールバック方式）
図 1および図 2は、本発明の実施例 1にかかる通信中継装置により実現される、「コ ールバック方式」の概略を示す説明図である。発信端末 101は SIP (Session Initia tion Protocol)による VoIP通話の可能な機器なら何であってもよいが、ここではた とえば VoIPアダプタを介して IP網に接続された電話機 (IP電話)であるものとする。 発呼者がこの発信端末 101から、あらかじめ着呼者ごとに付与されている代表番号、 たとえば「050— XXXX— XXXX」へ電話をかけると、当該番号を意味する SIP URI ( Uniform Resource Identifier)、たとえば「sip : +81—050— XXXX— XXXX@ · • ·」を宛先とする INVITEリクエストが、 IP網を経て SIPサーバ 100へ送信される（図 中（1) )。なお、以下では上記 URIを「バーチャル URI」と呼ぶ。 [0025] SIPサーバ 100は上述の転送先選択機能を備えており、着呼者のバーチャル URI あての INVITEリクエストを、当該着呼者の現実の SIP URI (少なくとも一つ）のうち いずれか一つに転送する。なお、以下では上記現実の SIP URIを「着信端末 URI」 と呼び、そのうち転送先として選択された一つを特に「選択中 URI」と呼ぶ。なお、バ 一チャル URIと着信端末 URIとの対応関係、および着信端末 URIのうちどれが選択 中 URIであるかは、 SIPサーバ 100の「転送先テーブル」に保持されている。図中、「 *」印の付加された着信端末 URIが選択中 URIである。
[0026] そして発信端末 101からの INVITEリクエストは、 SIPサーバ 100でその宛先をバ 一チャル URI力 選択中 URIに付け替えられた後、選択中 URIにより一意に特定さ れる着信端末 102へ転送される。ただし、選択中 URIが PSTN上の識別子 (具体的 には電話番号）を意味する SIP URI、たとえば「tel: +81— 070— XXXX— XXXX」 であった場合は、上記リクエストはまず S-Pゲートウェイ 104に転送（図中（2) )されて PSTNの呼に変換の上、 PSTN経由で着信端末 102に転送（図中（3) )される。この ため上述のように、本来なら通話料が発生しない状況、具体的にはデュアル端末で ある着信端末 102が WLAN圏内にあるときでも、 S-Pゲートウェイ 104—着信端末 1 02間の通話料が発生してしまう。
[0027] ここで、選択中 URIは（a)相対的に高価な (通信コストの高い)ネットワークにも安価 な（通信コストの低い)ネットワークにも接続可能な機器に対応する SIP URIのうち、 前者における識別子を意味する SIP URIである場合と、（b)上記以外の SIP URI である場合とがある。たとえば、 PSTNにも IP網にも接続可能なデュアル端末の PHS 番号を意味する SIP URIは（a)であり、一般の PHSの PHS番号を意味する SIP U RIは（b)である。別の言い方をすると、 PHS番号を意味する SIP URIは、上記番号 がデュアル端末の PHS番号であれば（a)、一般の PHSの PHS番号であれば（b)に 該当することになる。なお、以下では (b)に該当する SIP URIの種別を「通常」と呼
[0028] そして、発呼者が本来負担しなくてもよいはずの通話料 (具体的には S— Pゲートゥ エイ 104—着信端末 102間の通話料)を負担しなければならなくなるのは、選択中 U RIが特に（a)だった場合、すなわちその種別が「通常」ではな力つた場合である。そこ で実施例 1では、選択中 URIの種別が「通常」でない場合は、 SIPサーバ 100から S —Pゲートウェイ 104へ INVITEリクエストを転送した直後に、 CANCELリクエストを送 信する（図中（2) )ことで、 S-Pゲートウェイ 104から着信端末 102への呼を通話料の 発生前 (具体的にはワンコール程度)で切断してしまう（図中（3) )。
[0029] また、 SIPサーバ 100は発信端末 101からの INVITEリクエストを、 S— Pゲートゥェ ィ 104とともにアナウンスサービス 105へも転送し（図中（4) )、アナウンスサービス 10 5から発信端末 101への 2XX応答 (成功）と、発信端末 101からアナウンスサービス 1 05への ACKリクエストとを順次転送する。これにより、発信端末 101—アナウンスサ 一ビス 105間で RTPコネクションが確立されると、アナウンスサービス 105から発呼者 へ、着呼者力 コールバックするのでいったん電話を切って待つよう指示がなされ、 発信端末 101からアナウンスサービス 105へ BYEリクエストが送信（図中（5) )された 時点で、発信端末 101からの電話は切断される。
[0030] 一方、 S—Pゲートウェイ 104からいわゆる「ワン切り」された着信端末 102は、 WLA Nで IP網に接続、あるいは PHSで PSTNに接続してただちにコールバックする。もつ とも、着信端末 102ではコールバック先となるべき発信端末 101を特定できないので (着信履歴には発信端末 101ではなぐ S— Pゲートウェイ 104の電話番号し力残らな いため）、実施例 1では SIPサーバ 100の「転送元テーブル」に、着信端末 102とコー ルバック先となる発信端末 101との対応関係を保持しておくようにする。
[0031] すなわち SIPサーノ 100は、発信端末 101から受信した INVITEリクエストを S— P ゲートウェイ 104およびアナウンスサービス 105に転送する際に、当該リクエストの To ヘッダに記述されたバーチャル URI (図中（1)の「Receiver Virtual] )と、 Fromへ ッダに記述された発信端末 101の URI (発信端末 URI。同「Caller VoIP」）との組 を、その保持する「転送元テーブル」に登録する。
[0032] その後図 1のように、着信端末 102が WLANで IP網に接続して S— Pゲートウェイ 1 04へコールバックした場合、着信端末 102からの INVITEリクエストは、その宛先で ある S-Pゲートウェイ 104を通過して SIPサーバ 100に転送される（図 1 (6) )。
[0033] したがって図 1の場合、 SIPサーバ 100が受信する INVITEリクエストには、（a)通 常の INVITEリクエスト（図中（1)など）と、（b)過去の電話をトリガーとする INVITEリ タエスト（図中（6)など）との 2種類があることになる。なお、以下では（a)に該当する I NVITEリクエストの種別を「通常」、 (b)に該当する INVITEリクエストの種別を「コー ルバック」と呼ぶ。そして、ある INVITEリクエストが上記のいずれであるかは、上述の 転送先テーブルおよび転送元テーブルを参照することで特定できる。具体的には転 送先テーブルで、上記リクエストの Fromヘッダに記述された SIP URIと対応づけら れたバーチャル URIが、転送元テーブルにも登録されていれば (b)、登録されてい なければ（a)である。
[0034] そして、受信した INVITEリクエストの種別が「コールバック」だった場合、 SIPサー ノ 100は上記リクエストの宛先を、転送元テーブルで上記バーチャル URIに対応づ けられて 、る発信端末 URI (図中「Caller VoIPj )に付け替えて、発信端末 101へ 転送する（図 1 (7) )。その後 2XX応答 (成功）と ACKリクエストを経て、着信端末 102 一発信端末 101間で RTPコネクションが確立される（図 1 (8) )。
[0035] 一方、図 2のように、着信端末 102が PHSで PSTNに接続して S— Pゲートウェイ 10 4へコールバックした場合（図 2 (6) )、 S— Pゲートウェイ 104を宛先とする INVITEリク ェストが S-Pゲートウェイ 104から SIPサーバ 100に送信される（図 2 (7) )。そして SI Pサーバ 100力 上記と同様にコールバックか否かを判定し、コールバックの場合は 上記リクエストの宛先を、転送元テーブルから検索した発信端末 URIに付け替えて 転送する（図 2 (8) )。その後 2XX応答 (成功）と ACKリクエストを経て、 S— Pゲートゥ ヱイ 104—発信端末 101間で RTPコネクションが確立される（図 2 (9) )。なお、図 1お よび図 2の P—Sゲートウェイ 103はなくても構わない（P—Sゲートウェイ 103がなくても 実施例 1の発明は実施可能である）力 ここでは後述する他の実施例との比較のため に示している。
[0036] 次に、図 3は本発明の実施例 1にかかる通信中継装置 (具体的には図 1に示した SI Pサーバ 100)のハードウェア構成を示す説明図である。図中、 CPU301は装置全 体の制御を司る。 ROM302はブートプログラムなどを記憶している。 RAM303は CP U301のワークエリアとして使用される。
[0037] HDD304は、 CPU301の制御にしたがって HD305に対するデータのリード Zライ トを制御する。 HD305は、 HDD304の制御にしたがって書き込まれたデータを記憶 する。 FDD306は、 CPU301の制御にしたがって FD307に対するデータのリード Z ライトを制御する。 FD307は、 FDD306の制御にしたがって書き込まれたデータを 記憶する。なお、 FD307は着脱可能な記録媒体の一例であり、 FD307の代わりに C D— ROM (CD-R, CD-RW)、 MO、 DVD (Digital Versatile Disk)、メモリー力 ードなどであってもよい。
[0038] ネットワーク IZF308は LANZWANなどのネットワークに接続され、当該ネットヮ ークと装置内部とのデータの送受信を司る。また、バス 300は上記各部を接続する。 なお、上記のほか本装置はディスプレイ、マウス、キーボードなどのコンソール類を備 えていてもよい。
[0039] 次に、図 4は本発明の実施例 1にかかる通信中継装置 (具体的には図 1に示した SI Pサーバ 100)の機能的構成を示す説明図、図 5は当該装置における各種リクエスト の処理手順を示すフローチャートである。図 4中の各部の機能は、図 5のフローチヤ ートにおいて順次説明する。
[0040] SIPサーバ 100のプロキシ 402力 NVITEリクエストを受信すると（ステップ S501： Yes) ,当該リクエストはいつたん転送先特定部 403に出力され、転送先特定部 403 の INVITE種別特定部 403aが、当該リクエストの種別を特定する。そして種別が「通 常」だった場合は (ステップ S502： Yes)、転送先特定部 403の転送先種別特定部 4 03b力 上記リクエストの宛先のバーチャル URIに対応づけられた選択中 URIの種 別を特定する。
[0041] そして、選択中 URIの種別が「通常」でなかった場合、たとえばデュアル端末の PH S番号を意味する SIP URIだった場合は (ステップ S503： No)、転送先特定部 403 はプロキシ 402から入力した INVITEリクエスト、選択中 URI、およびアナウンスサー ビス 105の SIP URIをリクエスト生成部 404に出力する。
[0042] そしてリクエスト生成部 404が、
•選択中 URIを宛先とする INVITEリクエスト
'選択中 URIを宛先とする CANCELリクエスト
'アナウンスサービス 105の SIP URIを宛先とする INVITEリクエスト
の 3つを生成し (ステップ S504)、これらがプロキシ 402により順次転送される（ステツ プ S505)。なお、選択中 URIを宛先とする CANCELリクエストは、当該 URIを宛先と する INVITEリクエストを受けて、 S-Pゲートウェイ 104が着信端末 102を呼び出した 後に転送されるものとする。
[0043] また、転送先特定部 403は転送元テーブル更新部 405に指示して、プロキシ 402 力 入力した INVITEリクエストのバーチャル URIと発信端末 URIとの組を転送元テ 一ブル 401に登録させる（ステップ S 506)。
[0044] 一方、選択中 URIの種別が「通常」だった場合は (ステップ S503： Yes)、転送先特 定部 403はプロキシ 402から入力した INVITEリクエストと選択中 URIとをリクエスト 生成部 404に出力し、リクエスト生成部 404が上記リクエストの宛先を上記 URIで置 換することで、上記 URIを宛先とする INVITEリクエストを生成する（ステップ S507)。 次に、リクエスト生成部 404が上記リクエストをプロキシ 402に出力し、プロキシ 402力 S 上記リクエストの転送 (ステップ S508)後、応答の転送や ACKリクエストの転送など、 INVITEリクエスト転送後の通常の処理を行う（ステップ S509)。
[0045] 一方、プロキシ 402から入力した INVITEリクエストの種別が「コールバック」だった 場合 (ステップ S502 :No)、すなわち当該リクエストが以前ステップ S501— S506で 転送された他の INVITEリクエストをトリガーとしてなされたものである場合は、転送先 特定部 403は当該リクエストと、当該他のリクエストの転送時に転送元テーブル 401 に登録された発信端末 URIとをリクエスト生成部 404に出力する。そしてリクエスト生 成部 404が、上記リクエストの宛先を上記 URIで置換することで、上記 URIを宛先と する INVITEリクエストを生成し (ステップ S510)、これがプロキシ 402により発信端末 101へ転送される（ステップ S 511)。
[0046] また、転送先特定部 403は転送元テーブル更新部 405に指示して、トリガーとなつ た他の INVITEリクエストの転送時に転送元テーブル 401に登録された、バーチャル URIと発信端末 URIとの組を削除させる (ステップ S512)。その後はプロキシ 402が 、応答の転送や ACKリクエストの転送など、 INVITEリクエスト転送後の通常の処理 を行う（ステップ S509)。なお、 INVITEリクエスト以外のリクエストを受信した場合は（ ステップ S501 :No)、 SIPサーバ 100は受信したリクエストに対応するその他の処理 を行う（ステップ S 513)。 [0047] 次に、図 6は本発明の実施例 1にかかる着信端末 102における、着信処理の手順 を示すフローチャートである。 PHSによる待ち受け中に S—Pゲートウェイ 104から着 信があった場合 (ステップ S601 :Yes、ステップ S602 :Yes。なお、 S—Pゲートウェイ 104からの着信かどうかは電話番号により特定できる）、着信端末 102は着信音は出 力せずに呼の切断を待つとともに、 OFFになっている WLANを ONにして（ステップ S603) WLANの圏内 Z圏外を判定し (ステップ S604)、この結果にもとづいて WLA NZPHSのいずれかを通信手段として選択する。なお、上記判定結果のほか通信コ ストや通話の品質、あら力じめ設定されているプリファレンスなどにもとづいて、いず れかの通信手段を選択するようにしてもょ ヽ。
[0048] そして WLANを選択した場合は（ステップ S605： Yes)、着信端末 102は WLAN で IP網に接続し、 S—Pゲートウェイ 104あての INVITEリクエストを送信（ステップ S6 06)することで、通常の SIP通話 (ステップ S607)を開始する。そして通話終了時に は、着信時に ONにした WLANを再び OFFにする（ステップ S608)。なお同図では 省略している力 実際には INVITEリクエストの前に、 SIPサーバ 100へ REGISTER リクエストを送信する。
[0049] 一方、 PHSを選択した場合は（ステップ S605 :No)、着信端末 102は ONにした W LANを再び OFFにする（ステップ S609)。次に PHSで PSTNに接続して、 S— Pゲ 一トウエイ 104の電話番号に発呼 (ステップ S610)することで、通常の PHS通話 (ステ ップ S611。なお、 S-Pゲートウェイ 104から先は SIP通話となる）を開始する。また、 S Pゲートウェイ 104以外力も電話力 Sかかってきた場合には着信音を出力し (ステップ S602 :No、ステップ S612)、着呼者が電話に出た後は通常の PHS通話となる（ステ ップ S611)。
[0050] 図 1および図 2と、図 5および図 6とを対応づけて説明すると、まず図 1の場合、発信 端末 101からの電話の転送先が「通常」でないので、 SIPサーバ 100は S-Pゲートゥ エイ 104に指示して、通話料の力からないいわゆる「ワン切り」で着信端末 102を呼び 出させるとともに、発信端末 101をいつたんアナウンスサービス 105に接続する（図 5 ステップ S501— S506)。
[0051] その後、着信端末 102が WLANで IP網に接続して INVITEリクエストを返してきた 場合（図 6ステップ S601— S606)、あるいは着信端末 102が PHSで PSTNに接続 して S— Pゲートウェイ 104を発呼（図 6ステップ S601— S605、 S609— S610)した結 果、 S— Pゲートウェイ 104力 NVITEリクエストを返してきた場合のいずれも、 SIPサ ーバ 100は上記リクエストがコールバックであることを特定して、その宛先を発信端末 101に付け替えの上で転送する（図 5ステップ S501— S502、 S510— S512)。
[0052] そして発信端末 101から 2XX応答が返ってくると、 SIPサーバ 100は当該応答を着 信端末 102あるいは S-Pゲートウェイ 104に転送するとともに、着信端末 102あるい は S-Pゲートウェイ 104から ACKリクエストがあると、当該リクエストを発信端末 101に 転送する（図 5ステップ S 509)。
[0053] 以上説明した実施例 1によれば、まず図 1の場合、唯一 PSTNを利用する（3)でも ワン切りしているため、（1)一（8)の全体を通じて通話料が発生しない。通信経路は 図 20の点線矢印と同等になり（ただしコールバックのため、矢印の向きは逆となる）、 従来技術の実線矢印に比べて、 S— Pゲートウェイ 2004—着信端末 2002間の通話 料が削減できていることになる。
[0054] 一方、図 2の場合は（3)および（6)で PSTNを利用しており、前者はワン切りのため 無料であるが、後者は有料である。通信経路は図 20の実線矢印と同等であり（ただし コールバックのため、矢印の向きは逆となる）、通話料は従来技術と同様に発生する 。もっとも課金先は発呼者でなく着呼者となるため、無料で電話をかけることはできて も力かってきた電話を無料にすることはできないという、デュアル端末の従来の弱点 をネ ΐうことができる。
[0055] ただ、実施例 1では発呼者に違和感を覚えさせてしまう（かけた電話を 、つたん切ら なければならないため）ことのほか、発呼者と着呼者が実際に通話できるようになるま での時間もかかってしまう。そこで、実施例 1のように着呼者力もコールバックするの でなぐ次に説明する実施例 2のように、従来のやり方で着呼者につないだのでは相 対的に高価な通信経路 Αとなってしまう発呼者からの電話を、相対的に安価な通信 経路 Bで着呼者に繋ぎ直すようにしてもょ ヽ。
実施例 2
[0056] (繋ぎ直し方式） 図 7および図 8は、本発明の実施例 2にかかる通信中継装置により実現される、「繋 ぎ直し方式」の概略を示す説明図である。バーチャル URIあての INVITEリクエストを 発信端末 701から受信（図中（1) )すると、 SIPサーバ 700は転送先テーブルから、 当該バーチャル URIに対応づけられた選択中 URIを検索し、当該リクエストの宛先を 当該選択中 URIに付け替えて転送する。そして、この選択中 URIがデュアル端末の PHS番号を意味する SIP URIだった場合、上記リクエストは S— Pゲートウェイ 704 に転送（図中（2) )されて PSTNの呼に変換の上、 PSTN経由で着信端末 702に転 送（図中（3) )される。そして、ここまでは実施例 1のコールバック方式と同様である。
[0057] S— Pゲートウェイ 704から呼び出された着信端末 702は、通信手段として WLAN ZPHSのいずれかを選択し、 WLANを選択した場合、図 7のように SIPサーバ 700 へ REGISTERリクエストを送信する（図中（4) )。
[0058] したがって図 7の場合、 SIPサーバ 700が受信する REGISTERリクエストには、（a) 通常の REGISTERリクエストと、（b)過去の電話をトリガーとする REGISTER (図中（ 4)など）との 2種類があることになる。そして、ある REGISTERリクエストが上記のい ずれであるかは、上述の転送先テーブルおよび転送元テーブルを参照することで特 定できる。具体的には転送先テーブルで、上記リクエストの Toヘッダおよび Fromへ ッダに記述された SIP URI (IPアドレスを登録される SIP URI)と対応づけられたバ 一チャル URIが、転送元テーブルにも登録されていれば (b)、登録されていなけれ ば (a)である。なお、以下では（a)に該当する REGISTERリクエストの種別を「通常」 と呼ぶ。
[0059] そして、受信した REGISTERリクエストの種別が「通常」でなかった場合、 SIPサー ノ 700は S—Pゲートウェイ 704に CANCELリクエストを送信（図中（5) )することで、 S Pゲートウェイ 704から着信端末 702への呼を切断させる（図中（6) )。またその一方 で、発信端末 701から受信（図中（1) )した INVITEリクエストの宛先を、着信端末 70 2が IPアドレスを登録（図中（4) )した SIP URIに付け替えて転送する（図中（7) )。 そして着信端末 702から 2XX応答 (成功)を受信すると（図中（8) )、当該応答を発信 端末 701へ転送し（図中（9) )、さらに ACKリクエストの転送を経て、発信端末 701— 着信端末 702間で RTPコネクションが確立される（図中（10) )。 [0060] 一方、 S— Pゲートウェイ 704から呼び出された着信端末 702が、通信手段として PH Sを選択した場合は、着呼者が電話に出た時点で、図 8のように着信端末 702から P STN経由で応答信号が返される（図中 (4) )。そして上記信号を受信した S— Pゲート ウェイ 704は、 SIPサーバ 700へ 2XX応答を送信し（図中（5) )、 SIPサーバ 700がさ らに発信端末 701へ当該応答を転送する（図中（6) )。その後 ACKリクエストの転送 を経て、発信端末 701— S— Pゲートウェイ 704間で RTPコネクションが確立される（図 中 (7) )。
[0061] 本発明の実施例 2にかかる通信中継装置 (具体的には図 7および図 8に示した SIP サーバ 700)のハードウェア構成は、図 3に示した実施例 1のそれと同様であるので 説明を省略する。図 9は上記装置の機能的構成を示す説明図、図 10は上記装置に おける各種リクエストの処理手順を示すフローチャートである。図 9中の各部の機能は 、図 10のフローチャートにおいて順次説明する。
[0062] SIPサーバ 700のプロキシ 902力 NVITEリクエストを受信すると（ステップ S1001： Yes) ,当該リクエストはいつたん転送先特定部 903に出力され、転送先特定部 903 の転送先種別特定部 903aが、転送先テーブル 900を参照して、当該リクエストの宛 先のバーチャル URIに対応づけられた選択中 URIの種別を特定する。
[0063] そして、選択中 URIの種別が「通常」でな力つた場合 (ステップ S1002 :No)、転送 元テーブル更新部 905に指示して、上記リクエストのバーチャル URIと発信端末 URI との組を転送元テーブル 901に登録させる（ステップ S 1003)。なお、選択中 URIの 種別が「通常」だった場合は（ステップ S 1002 : Yes)、ステップ S 1003の処理は省略 される。
[0064] そしていずれの場合も、上記リクエストと選択中 URIとをリクエスト生成部 904に出 力し、リクエスト生成部 904が上記リクエストの宛先を上記 URIで置換することで、上 記 URIを宛先とする INVITEリクエストを生成する（ステップ S1004)。次に、プロキシ 902が上記リクエストの転送 (ステップ S1005)後、応答の転送や ACKリクエストの転 送など、 INVITEリクエスト転送後の通常の処理を行う（ステップ S 1006)。
[0065] 一方、 SIPサーバ 700のレジストラ 906が REGISTERリクエストを受信すると（ステ ップ S1007 :Yes)、通常の SIP登録処理 (ステップ S1008)の後、レジストラ 906の R EGISTER種別特定部 906aが、上記リクエストの種別を特定する。
[0066] そして、種別が「通常」だった場合は (ステップ S 1009 : Yes)そのままステップ S 100 1に戻る。一方、種別が「通常」でな力 た場合 (ステップ S 1009 : No)、すなわち上 記リクエストが以前ステップ S1001— S1006で転送された INVITEリクエストをトリガ 一としてなされたものである場合は、レジストラ 906は当該 INVITEリクエスト、当該 IN VITEリクエストの転送先となった選択中 URI、および当該 INVITEリクエストの転送 時に転送元テーブル 901に登録された発信端末 URIをリクエスト生成部 904に出力 する。
[0067] そしてリクエスト生成部 904が、
'発信端末 URIを宛先とする INVITEリクエスト
'選択中 URIを宛先とする CANCELリクエスト
の 2つを生成し (ステップ S1010)、これらがプロキシ 902により順次転送される（ステ ップ S 1011)。
[0068] また、レジストラ 906は転送元テーブル更新部 905に指示して、トリガーとなった IN VITEリクエストの転送時に転送元テーブル 901に登録された、バーチャル URIと発 信端末 URIとの組を削除させる (ステップ S1012)。その後はプロキシ 902が、応答 の転送や ACKリクエストの転送など、 INVITEリクエスト転送後の通常の処理を行う（ ステップ S 1006)。なお、 INVITEリクエストや REGISTERリクエスト以外のリクエスト を受信した場合は（ステップ S1001 :No、ステップ S 1007 : No)、 SIPサーバ 700は 受信したリクエストに対応するその他の処理を行う（ステップ S 1013)。
[0069] 次に、図 11は本発明の実施例 2にかかる着信端末 702における、着信処理の手順 を示すフローチャートである。 PHSによる待ち受け中に S—Pゲートウェイ 704から着 信があった場合 (ステップ S1101 :Yes、ステップ SI 102 : Yes)、着信端末 702は O FFになっている WL ANを ONにして（ステップ S 1103) WL ANの圏内 Z圏外を判定 し (ステップ S 1104)、この結果にもとづいて WLANZPHSのいずれかを通信手段と して選択する。なお、上記判定結果のほか通信コストや通話の品質、あら力じめ設定 されて 、るプリファレンスなどにもとづ 、て、通信手段を選択するようにしてもょ 、。
[0070] そして WLANを選択した場合は（ステップ S1105： Yes)、着信端末 702は WLAN で IP網に接続し、 SIPサーバ 700へ REGISTERリクエストを送信する（ステップ S 11 06)。一方、 PHSを選択した場合は（ステップS1105 :No)、ONにしたWLANをOF Fにするとともに (ステップ S1107)着信音を出力し (ステップ S1108)、着呼者が電話 に出た後は通常の PHS通話となる (ステップ S 1109)。なお、 PHSによる待ち受け中 に S—Pゲートウェイ 704以外力も着信があった場合 (ステップ S 1101： Yes,ステップ S1102 :No)も、着信端末 702は着信音を出力し (ステップ S1108)、着呼者が電話 に出た後は通常の PHS通話となる (ステップ S 1109)。
[0071] また、ステップ S 1103で ONにした WLANへ INVITEリクエストが着信すると（ステ ップ S1101 :No、ステップ SI 110 : Yes)、着信端末 702は着信音を出力し (ステップ S1111)、着呼者が電話に出た後は通常の SIP通話となる (ステップ S1112)。なお 通話終了時には、着信時に ONにした WLANを再び OFFにする（ステップ S1113)
[0072] 図 7および図 8と、図 10および図 11とを対応づけて説明すると、まず図 7の場合、 S IPサーバ 700は発信端末 701からの電話を、まず PSTN経由で着信端末 702に転 送するが（図 10ステップ S1001— S1005)、着信端末 702から REGISTERリクエス トがあると（図 11ステップ S1101— S 1106)、それは取り消して次は IP網経由で着信 端末 702に転送する（図 10ステップ S1007— S1012)。そして着信端末 702から 2X X応答があると、当該応答を発信端末 701に転送するとともに、発信端末 701から A CKリクエストがあると、当該リクエストを着信端末 702に転送する（図 10ステップ S 10 06)。
[0073] 一方図 8の場合、着信端末 702が S— Pゲートウェイ 704に応答信号を返すと（図 11 ステップ S1101一 S1105、 SI 107一 SI 109)、 S— Pゲートウェイ 704力 ^SIPサーノ 7 00に 2XX応答を返すので、 SIPサーバ 700は当該応答を発信端末 701に転送する とともに、発信端末 701から ACKリクエストがあると、当該リクエストを S— Pゲートウェイ 704に転送する（図 10ステップ S1006)。
[0074] なお、図 7の場合、 SIPサーバ 700が着信端末 702からの REGISTERリクエストを 受信する前に、 S-Pゲートウェイ 704から 3XX— 6XX応答を受信してしまうと、当該 応答が発信端末 701に転送された時点で発信端末 701からの電話は切断されてし まい、その後に着信端末 702が登録してきても発信端末 701と接続することができな くなる。そこで図 10のステップ S1006における処理を、 SIPサーバ 700が S—Pゲート ウェイ 704から 3XX— 6XX応答を受信した場合は、所定時間内に着信端末 702から REGISTERリクエストがないことを条件として発信端末 701へ転送するよう修正して もよい。すなわち S-Pゲートウェイ 704から接続失敗が通知されてきても、すぐには発 信端末 701へ通知せず、上記所定時間だけは着信端末 702からの登録を待つよう にする。
[0075] 以上説明した実施例 2によれば、まず図 7の場合、（3)で S— Pゲートウェイ 704がか けた電話は着信端末 702の応答前に切断されるので、 (1)一 (10)の全体を通じて 通話料が発生しない。通信経路は図 20の点線矢印と同一になり、従来技術の実線 矢印に比べて、 S— Pゲートウェイ 2004—着信端末 2002間の通話料が削減できてい ることになる。一方、図 8の場合は図 20の実線矢印と同一、すなわち上述のュビキタ ス IP電話システムにお 、て、 IP端末から代表番号へかけた電話が非 IP端末へ転送 されるケースと同一であり、 S— Pゲートウェイ 2004—着信端末 2002間の通話料が発 呼者に課金される。
[0076] なお、図 7で着信端末 702が SIPサーバ 700へ送信する REGISTERリクエストは、 本来的には SIP登録のためのリクエストである力 実施例 2ではこれを一種の接続要 求、すなわち発信端末 701と IP網経由で接続すべき旨の着信端末 702からの要求と みなし、この要求に応じて SIPサーバ 700力 いったん PSTN経由で転送した電話を IP網経由で転送し直していると言うこともできる。逆に言うと、上記接続要求は必ずし も着信端末 702からの REGISTERリクエストでなければならな 、わけではなぐ着信 端末 702が WLANで着信可能な状態になったことを示す何らかの通知（必ずしも着 信端末 702自身からの通知でなくともよ 、）などであってもよ 、。
実施例 3
[0077] (繋ぎ直し +かけ直し方式）
図 12および図 13は、本発明の実施例 3にかかる通信中継装置により実現される、「 繋ぎ直し +かけ直し方式」の概略を示す説明図である。上述した実施例 2は IP端末（ たとえば IP電話)から電話をかける場合であるが、実施例 3は非 IP端末、具体的には 従来の電話機や、 WLAN圏外にあるときのデュアル端末など力 電話をかける場合 である。そして図 21に示したように、発信端末 2001が PSTN経由で発呼し、着信端 末 2002も PSTN経由で着呼すると、発信端末 2001— P— Sゲートウェイ 2003間の 通話料と、 S— Pゲートウェイ 2004—着信端末 2002間の通話料とが二重に発生して しまう。
[0078] そこで実施例 3では、図 12および図 13に示すように、発信端末 1201が PSTN経 由で発呼し（図中（ 1) )、 P—Sゲートウェイ 1203力ら SIPサーノ 1200を経て INVITE リクエストを転送（図中（2) (3) )された P— Sゲートウェイ 1204力 さらに PSTN経由で 発呼する（図中（4) )場合、 INVITEリクエストの転送直後に SIPサーバ 1200から S— Pゲートウェイ 1204へ CANCELリクエストを送信する（図中（3) )ことで、 S— Pゲート ウェイ 1204から着信端末 1202への呼を通話料の発生前 (具体的にはワンコール程 度)で切断してしまう（図中（4) )。
[0079] そして着信端末 1202は、通信手段として WLANを選択した場合、図 12に示すよう に SIPサーバ 1200へ REGISTERリクエストを送信する（図中（5) )。 SIPサーバ 120 0は、上記リクエストの種別が「通常」でな力つた場合、 P— Sゲートウェイ 1203から受 信（図中（2) )した INVITEリクエストの宛先を、着信端末 1202が IPアドレスを登録（ 図中（5) )した SIP URIに付け替えて転送する（図中（6) )。
[0080] そして着信端末 1202から 2XX応答を受信すると（図中（7) )、当該応答を P— Sゲ 一トウエイ 1203へ転送し（図中（8) )、さらに ACKリクエストの転送を経て、 P— Sゲー トウヱイ 1203—着信端末 1202間で RTPコネクションが確立される（図中（9) )。その 後、 P-Sゲートウェイ 1203から発信端末 1201へ、 PSTN経由で応答信号を返す（ 図中（10) )。
[0081] 一方、着信端末 1202は通信手段として PHSを選択した場合、図 13に示すように、 S-Pゲートウェイ 1204から電話が力かってきた（図中（4) )後は続いて発信端末 120 1から電話が力かってくるのを待つ（自分からは何もしない）。 S—Pゲートウェイ 1204 力 の電話はワン切りされてしまうので PHSで応答しょうにも間に合わず、し力も WL ANも使えない Z使わないので、着信端末 1202としては PHSで S— Pゲートウェイ 12 04にコールバックするしかないのであるが、 S—Pゲートウェイ 1204から SIPサーバ 1 200を経て P—Sゲートウェイ 1203へ INVITEリクエストが転送され、 P—Sゲートウェイ 1203から PSTN経由で発信端末 1201が呼び出されると、上述の二重課金の問題 力 こでも発生してしまう。
[0082] これを避けるため実施例 3では、着信端末 1202が何もしない代わりに、発信端末 1 201が電話を自動的にかけ直すようにする。すなわち実施例 3にかかる発信端末 12 01は、着呼者の代表番号あてにかけた電話が所定時間内につながらない (所定時 間内に P— Sゲートウェイ 1203から応答信号が返ってこない）ときは、着呼者の別の電 話番号を一つ選択して電話をかけ直す。なお、この別の電話番号はあらかじめ発信 端末 1201に保持しているのでも、あるいは SIPサーバ 1200などからリアルタイムに 取得するのでもよい。
[0083] そしてこの別の電話番号の中にデュアル端末の PHS番号があれば、 S— Pゲートゥ イ 704からの着信後しばらく経ってから、着信端末 1202へ今度は発信端末 1201 力も直接電話力 Sかかってくることになる（図中（5) )。そして着信端末 1202が応答信 号を返した（図中（6) )後は、通常の PHS通話となる。
[0084] 本発明の実施例 3にかかる通信中継装置 (具体的には図 12および図 13に示した S IPサーバ 1200)のハードウェア構成は、図 3に示した実施例 1のそれと同様であるの で説明を省略する。また上記装置の機能的構成は、図 9に示した実施例 2のそれとほ ぼ同様であり、異なる点は図 14のフローチャートにおいて順次説明する。
[0085] 図 14は、上記装置における各種リクエストの処理手順を示すフローチャートである。
図 10に示した実施例 2のそれとの差異は、 CANCELリクエストの生成 ·転送処理が、 図 10では REGISTERリクエスト受信時の処理ループ内にある（ステップ S 1010 · S 1 011)のに対して、図 14では当該リクエストのトリガーとなった INVITEリクエスト受信 時の処理ループ内にある（ステップ S 1404· S 1405)点である（なお、 INVITEリクェ ストや REGISTERリクエスト以外のリクエストを受信した場合は、 SIPサーバ 1200は 受信したリクエストに対応するその他の処理を行う（ステップ S1401 :No、ステップ SI 409 :No、ステップ S1415) )。
[0086] すなわち実施例 3にかかるリクエスト生成部 904は、 SIPサーバ 1200が受信した IN VITEリクエストにつ ヽて、転送先種別特定部 903aで特定された選択中 URIの種別 が「通常」でなかった場合、当該 URIを宛先とする INVITEリクエストおよび CANCE Lリクエストの 2つを生成し、これらがプロキシ 902により順次転送される（ステップ S 14 01— S1405)。なお、選択中 URIの種別が「通常」だった場合は、当該 URIを宛先と する INVITEリクエストを生成し、これがプロキシ 902により転送された後は、プロキシ 902が応答の転送や ACKリクエストの転送など、 INVITEリクエスト転送後の通常の 処理を行う（ステップ S1401— S1402、 S1406— S1408)。
[0087] また、実施例 3にかかるリクエスト生成部 904は、 SIPサーバ 1200が受信した REGI STERリクエストについて、 REGISTER種別特定部 906aにより特定されたその種別 力 S「通常」でなかった場合、 IPアドレスが登録された SIP URIを宛先とする INVITE リクエストを生成し、これがプロキシ 902により着信端末 1202へ転送される (ステップ S1409— S1414)。
[0088] 次に、図 15は本発明の実施例 3にかかる着信端末 1202における、着信処理の手 順を示すフローチャートである。図中ステップ S 1501— S1513のそれぞれにおける 処理は、図 11に示したステップ S1101— S1113のそれぞれにおける処理と同一で ある。ただし実施例 3では、着信端末 1202が通信手段として PHSを選択し、 WLAN を OFFにした (ステップ S1505 :No、ステップ S1507)時点では、 S—Pゲートウェイ 1 204力らの呼は切断されて!、て PHS通話が不可能なため、ステップ S 1507の後そ のままステップ S 1501【こ戻って!/ヽる。
[0089] 次に、図 16は本発明の実施例 3にかかる発信端末 1201における、発信処理の手 順を示すフローチャートである。発呼者力も特定の電話番号、たとえば着呼者の代表 番号に対する発呼指示があると (ステップ S 1601 : Yes) ,発信端末 1201は PSTN 経由で当該番号に発呼する（ステップ S1602)。上記呼は P— Sゲートウェイ 1203で I NVITEリクエストに変換の上、 SIPサーバ 1200に転送され、 SIPサーノ 1200力ら 2 XX応答が返されると、さらに P— Sゲートウェイ 1203から発信端末 1201へ応答信号 が返され (ステップ S 1603： Yes)、その後は通常の音声通話となる（ステップ S 1604
) o
[0090] そして、発信端末 1201は発呼から所定時間だけ上記信号を待ち (ステップ S1603 ： No、ステップ S 1605 : No)、当該時間が経過しても P—Sゲートウェイ 1203から応答 がない場合 (ステップ S1603 :No、ステップ S1605 : Yes)、上記着呼者にまだ発呼 して ヽな 、他の電話番号があれば (ステップ S 1606： Yes)、その中力 一つを選択 の上 (ステップ S1607)当該番号へ発呼する（ステップ S 1602)。なお、着呼者のす ベての電話番号を発呼して、それでも応答がない場合は (ステップ S 1606 : No)、そ の時点で処理を終了する。
[0091] 図 12および図 13と、図 14一図 16とを対応づけて説明すると、まず図 12の場合、 S IPサーバ 1200は着信端末 1202からの REGISTERリクエストを待たずに、そのトリ ガーとなる INVITEリクエストをキャンセルし（図 14ステップ S1401— S1405)、着信 端末 1202から REGISTERリクエストがあると（図 15ステップ S 1501— S 1506)、 IP アドレスを登録された SIP URIへ発信端末 1201からの INVITEリクエストを転送す る（図 14ステップ S1409— S1414)。
[0092] 一方図 13の場合、 SIPサーバ 1200力 NVITEリクエストをキャンセルする（図 14ス テツプ S1401— S1405)結果、 P—Sゲートウェイ 1203からの応答信号がないまま所 定時間が経過するので、発信端末 1201は着呼者の他の電話番号、ここではデュア ル端末の PHS番号を選択して電話をかけ直す（図 16ステップ S 1601— S1607)。
[0093] 以上説明した実施例 3によれば、図 12の場合も図 13の場合も、図 21のような通信 経路となる電話は SIPサーバ 1200の制御によって常にワン切り（すなわち通話料の 発生前に切断)されるので、上述の二重課金が発生しな!、。
[0094] ただ、 WLANの使える場所が PHSの使える場所に比べてまだまだ限られており、 そもそもデュアル端末もまだ普及が始まったば力りである現状から、実際には図 12の ように SIPサーバ 1200が電話を繋ぎ直すのでなく、図 13のように発信端末 1201が 電話をかけ直すことになるケースがほとんどと考えられる。そして図 13の場合は、図 中（3) (4)がなくても特に支障がない。そこで実施例 3の「繋ぎ直し +かけ直し方式」 を、次に説明する実施例 4の「かけ直し方式」のように簡略ィ匕してしまってもよい。 実施例 4
[0095] (かけ直し方式）
図 17は、本発明の実施例 4にかかる通信中継装置により実現される、「かけ直し方 式」の概略を示す説明図である。図示するように実施例 4では、二重課金の原因とな る INVITEリクエスト、具体的には P—Sゲートウェイ 1703から SIPサーバ 1700を経て S— Pゲートウェイ 1704に転送されることになる INVITEリクエスト（図中（2) )を、 SIP サーバ 1700で破棄してしまい、その先へ転送しないようにする。その結果、発呼から 所定時間が経過しても P— Sゲートウェイ 1703から応答信号が返ってこないので、発 信端末 1701は着呼者の他の電話番号、たとえばデュアル端末の PHS番号を選択 して電話を力 4ナ直し (図中（3) )、着信端末 1702から応答信号が返ってきた (図中 (4 ) )後は通常の PHS通話となる。
[0096] 本発明の実施例 4にかかる通信中継装置 (具体的には図 17に示した SIPサーバ 1 700)のハードウェア構成は、図 3に示した実施例 1のそれと同様であるので説明を省 略する。図 18は上記装置の機能的構成を示す説明図、図 19は上記装置における 各種リクエストの処理手順を示すフローチャートである。図 18中の各部の機能は、図 19のフローチャートにおいて順次説明する。
[0097] SIPサーバ 1700のプロキシ 1801が INVITEリクエストを受信すると（ステップ S19 01 : Yes) ,当該リクエストはいつたん転送先特定部 1802に出力され、転送先特定部 1802の転送可否判定部 1802aが、転送先テーブル 1800を参照して当該リクエスト の転送可否を判定する (ステップ S 1902)。具体的には、 S-Pゲートウェイ 1704に転 送されることになる INVITEリクエストで、その Toヘッダにも Fromヘッダにも電話番 号 (PSTN上での識別子）を意味する SIP URIが記述されることになる場合、すなわ ち上記リクエストが SIPサーバ 1700の前にも後にも PSTNを経由することになる場合 は転送不可、それ以外の場合は転送可とする。
[0098] そして転送不可の場合は（ステップ S1902 :No)、ステップ S1901に戻って他のリク ェストの受信待ちとなる一方、転送可の場合は (ステップ S 1902 : Yes)リクエスト生成 部 1803で、上記リクエストの宛先を転送先テーブル 1800の選択中 URIに付け替え ることで、当該 URIあての INVITEリクエストを生成する（ステップ 1903)。そしてこれ がプロキシ 1801により転送 (ステップ S1904)された後は、プロキシ 1801が応答の 転送や ACKリクエストの転送など、 INVITEリクエスト転送後の通常の処理を行う（ス テツプ S 1905)。
[0099] なお、 INVITEリクエスト以外のリクエストを受信した場合は（ステップ S1901 :No) 、 SIPサーバ 1700は受信したリクエストに対応するその他の処理を行う（ステップ S1 906)。
[0100] なお、実施例 4の着信端末 1702は PSTNでの着呼が可能な機器であれば何であ つてもよく、当該装置における処理も従来技術と同一である。また、実施例 4の発信 端末 1701も PSTNでの発呼が可能な機器であれば何であってもよ 、が、実施例 3 の発信端末 1201と同様、図 16の手順により、所定時間以上電話がつながらないとき は他の番号へ電話をかけ直す機能を備えているものとする。
[0101] 以上説明した実施例 4によれば、転送すると二重課金が発生するような INVITEリ タエストは SIPサーバ 1700どまりとなり、発信端末 1701は別の経路で電話をかけ直 すことになるため、二重課金が発生しない。より一般的に言えば、相対的に高価な通 信経路 Aと安価な通信経路 Bとがあった場合に、先に A経由で電話力 Sかかってきたと きは経路上のどこ力 (たとえば実施例 4のように SIPサーバ 1700)でそれを破棄し、あ らためて B経由で電話をかけさせるので、最終的に電話がつながったときの通信経路 は常に最も安価なものとなる。
[0102] もっとも、上記では図 21の実線矢印のような経路による通話は、破線矢印のような 経路による通話より割高であることを前提としたが、発信端末 2001と着信端末 2002 との機器の組み合わせによって通話料は異なるため、二重課金が発生するとしても 実線矢印のほうが破線矢印より安価となる場合もある。そしてその場合は、たとえば 発信端末 2001から点線矢印の経路で電話力 Sかかってきても、着信端末 2002で着 信を拒否し、あらためて実線矢印の経路で電話をかけさせるようにしてもょ 、。
[0103] なお、上述した実施例 1および 2では発信端末 101Z701が IP端末、実施例 3およ び 4では発信端末 1201 Z 1701が非 IP端末であることをそれぞれ前提としたが、現 実の SIPサーバが受信する INVITEリクエストの中には、（a)発信端末自身が発信し た INVITEリクエストと、 (b)発信端末からの呼を変換して P— Sゲートウェイが転送し てきた INVITEリクエストとが混在して!/、る。
[0104] そのため実際には、たとえば実施例 2の SIPサーバ 700と実施例 3の SIPサーバ 12 00の双方の機能を併せ持つ SIPサーバを用意し、 (a)を受信したときは図 10の手順 、（b)を受信したときは図 14の手順により処理するようにする。あるいは、実施例 1の S IPサーバ 100と実施例 4の SIPサーバ 1700の双方の機能を併せ持つ SIPサーバを 用意し、（a)を受信したときは図 5の手順、（b)を受信したときは図 19の手順により処 理するようにしてちょい。
産業上の利用可能性
以上のように、本発明に力かる通信中継方法、通信中継プログラム、および通信中 継装置は、発信端末一着信端末間に複数の通信経路がある場合の最適な経路の選 択に有用であり、特に、相対的に安価な通信経路が何らかの事情 (たとえば省電力 など)で事実上使用不能となって 、るケースに適して 、る。

Claims

請求の範囲
[1] 第 1の音声通話装置と第 2の音声通話装置との間の通信を中継する通信中継方法 であって、
前記第 1の音声通話装置からの第 1の接続要求を前記第 2の音声通話装置に転送 する第 1の転送工程と、
前記第 1の転送工程で転送された前記第 1の接続要求をキャンセルするキャンセル 工程と、
前記第 1の転送工程で前記第 1の接続要求を転送された前記第 2の音声通話装置 から第 2の接続要求を受信する受信工程と、
前記受信工程で受信された前記第 2の接続要求を前記第 1の音声通話装置に転 送する第 2の転送工程と、
を含むことを特徴とする通信中継方法。
[2] 第 1の音声通話装置と複数のネットワークに接続可能な第 2の音声通話装置との間 の通信を中継する通信中継方法であって、
前記第 1の音声通話装置力 の第 1の接続要求を前記ネットワークのうち第 1のネッ トワークを通じて前記第 2の音声通話装置に転送する第 1の転送工程と、
前記第 1の転送工程で前記第 1の接続要求を転送された前記第 2の音声通話装置 力 前記ネットワークのうち第 2のネットワークを通じて第 2の接続要求を受信する受 信工程と、
前記受信工程で前記第 2の接続要求を受信した場合に、前記第 1の接続要求を前 記第 2のネットワークを通じて前記第 2の音声通話装置に転送する第 2の転送工程と を含むことを特徴とする通信中継方法。
[3] 第 1の音声通話装置と第 2の音声通話装置との間の通話を中継する通信中継方法 であって、
前記第 1の音声通話装置から所定のネットワークを通じて受信した第 1の接続要求 を前記所定のネットワークを通じて前記第 2の音声通話装置に転送する第 1の転送 工程と、 前記第 1の転送工程で転送された前記第 1の接続要求をキャンセルするキャンセル 工程と、
前記第 1の転送工程で前記第 1の接続要求を転送された前記第 2の音声通話装置 から第 2の接続要求を受信する受信工程と、
前記受信工程で受信された前記第 2の接続要求を前記第 1の音声通話装置に転 送する第 2の転送工程と、
を含むことを特徴とする通信中継方法。
[4] 第 1の音声通話装置と第 2の音声通話装置との間の通話を中継する通信中継方法 であって、
前記第 1の音声通話装置力 の接続要求を第 1のネットワークを通じて受信する受 信工程と、
前記受信工程で受信された前記接続要求が転送されることになる第 2のネットヮー クを特定する特定工程と、
前記第 1のネットワークと前記特定工程で特定された第 2のネットワークとが同一で ない場合に前記接続要求を前記第 2のネットワークを通じて前記第 2の音声通話装 置に転送する転送工程と、
を含むことを特徴とする通信中継方法。
[5] 前記第 1の音声通話装置は、前記接続要求から所定時間内に前記第 2の音声通 話装置と接続できな力つた場合に、前記接続要求の宛先とは異なる宛先に他の接続 要求を送信することを特徴とする前記請求項 3または請求項 4に記載の通信中継方 法。
[6] 第 1の音声通話装置と第 2の音声通話装置との間の通信を中継する通信中継プロ グラムであって、
前記第 1の音声通話装置からの第 1の接続要求を前記第 2の音声通話装置に転送 する第 1の転送工程と、
前記第 1の転送工程で転送された前記第 1の接続要求をキャンセルするキャンセル 工程と、
前記第 1の転送工程で前記第 1の接続要求を転送された前記第 2の音声通話装置 から第 2の接続要求を受信する受信工程と、
前記受信工程で受信された前記第 2の接続要求を前記第 1の音声通話装置に転 送する第 2の転送工程と、
をコンピュータに実行させることを特徴とする通信中継プログラム。
[7] 第 1の音声通話装置と複数のネットワークに接続可能な第 2の音声通話装置との間 の通信を中継する通信中継プログラムであって、
前記第 1の音声通話装置力 の第 1の接続要求を前記ネットワークのうち第 1のネッ トワークを通じて前記第 2の音声通話装置に転送する第 1の転送工程と、
前記第 1の転送工程で前記第 1の接続要求を転送された前記第 2の音声通話装置 力 前記ネットワークのうち第 2のネットワークを通じて第 2の接続要求を受信する受 信工程と、
前記受信工程で前記第 2の接続要求を受信した場合に、前記第 1の接続要求を前 記第 2のネットワークを通じて前記第 2の音声通話装置に転送する第 2の転送工程と をコンピュータに実行させることを特徴とする通信中継プログラム。
[8] 第 1の音声通話装置と第 2の音声通話装置との間の通話を中継する通信中継プロ グラムであって、
前記第 1の音声通話装置から所定のネットワークを通じて受信した第 1の接続要求 を前記所定のネットワークを通じて前記第 2の音声通話装置に転送する第 1の転送 工程と、
前記第 1の転送工程で転送された前記第 1の接続要求をキャンセルするキャンセル 工程と、
前記第 1の転送工程で前記第 1の接続要求を転送された前記第 2の音声通話装置 から第 2の接続要求を受信する受信工程と、
前記受信工程で受信された前記第 2の接続要求を前記第 1の音声通話装置に転 送する第 2の転送工程と、
をコンピュータに実行させることを特徴とする通信中継プログラム。
[9] 第 1の音声通話装置と第 2の音声通話装置との間の通話を中継する通信中継プロ グラムであって、
前記第 1の音声通話装置力 の接続要求を第 1のネットワークを通じて受信する受 信工程と、
前記受信工程で受信された前記接続要求が転送されることになる第 2のネットヮー クを特定する特定工程と、
前記第 1のネットワークと前記特定工程で特定された第 2のネットワークとが同一で ない場合に前記接続要求を前記第 2のネットワークを通じて前記第 2の音声通話装 置に転送する転送工程と、
をコンピュータに実行させることを特徴とする通信中継プログラム。
[10] 前記第 1の音声通話装置は、前記接続要求から所定時間内に前記第 2の音声通 話装置と接続できな力つた場合に、前記接続要求の宛先とは異なる宛先に他の接続 要求を送信することを特徴とする前記請求項 8または請求項 9に記載の通信中継プ ログラム。
[11] 第 1の音声通話装置と第 2の音声通話装置との間の通信を中継する通信中継装置 であって、
前記第 1の音声通話装置からの第 1の接続要求を前記第 2の音声通話装置に転送 する第 1の転送手段と、
前記第 1の転送手段により転送された前記第 1の接続要求をキャンセルするキャン セル手段と、
前記第 1の転送手段により前記第 1の接続要求を転送された前記第 2の音声通話 装置から第 2の接続要求を受信する受信手段と、
前記受信手段により受信された前記第 2の接続要求を前記第 1の音声通話装置に 転送する第 2の転送手段と、
を備えることを特徴とする通信中継装置。
[12] 第 1の音声通話装置と複数のネットワークに接続可能な第 2の音声通話装置との間 の通信を中継する通信中継装置であって、
前記第 1の音声通話装置力 の第 1の接続要求を前記ネットワークのうち第 1のネッ トワークを通じて前記第 2の音声通話装置に転送する第 1の転送手段と、 前記第 1の転送手段により前記第 1の接続要求を転送された前記第 2の音声通話 装置力 前記ネットワークのうち第 2のネットワークを通じて第 2の接続要求を受信す る受信手段と、
前記受信手段により前記第 2の接続要求を受信した場合に、前記第 1の接続要求 を前記第 2のネットワークを通じて前記第 2の音声通話装置に転送する第 2の転送手 段と、
を備えることを特徴とする通信中継装置。
[13] 第 1の音声通話装置と第 2の音声通話装置との間の通話を中継する通信中継装置 であって、
前記第 1の音声通話装置から所定のネットワークを通じて受信した第 1の接続要求 を前記所定のネットワークを通じて前記第 2の音声通話装置に転送する第 1の転送 手段と、
前記第 1の転送手段により転送された前記第 1の接続要求をキャンセルするキャン セル手段と、
前記第 1の転送手段により前記第 1の接続要求を転送された前記第 2の音声通話 装置から第 2の接続要求を受信する受信手段と、
前記受信手段により受信された前記第 2の接続要求を前記第 1の音声通話装置に 転送する第 2の転送手段と、
を備えることを特徴とする通信中継装置。
[14] 第 1の音声通話装置と第 2の音声通話装置との間の通話を中継する通信中継装置 であって、
前記第 1の音声通話装置力 の接続要求を第 1のネットワークを通じて受信する受 信手段と、
前記受信手段により受信された前記接続要求が転送されることになる第 2のネットヮ ークを特定する特定手段と、
前記第 1のネットワークと前記特定手段により特定された第 2のネットワークとが同一 でない場合に前記接続要求を前記第 2のネットワークを通じて前記第 2の音声通話 装置に転送する転送手段と、 を備えることを特徴とする通信中継装置。
前記第 1の音声通話装置は、前記接続要求から所定時間内に前記第 2の音声通 話装置と接続できな力つた場合に、前記接続要求の宛先とは異なる宛先に他の接続 要求を送信することを特徴とする前記請求項 13または請求項 14に記載の通信中継 装置。
PCT/JP2004/016265 2004-11-02 2004-11-02 通信中継方法、通信中継プログラムおよび通信中継装置 WO2006048925A1 (ja)

Priority Applications (4)

Application Number Priority Date Filing Date Title
JP2006542195A JP4627760B2 (ja) 2004-11-02 2004-11-02 通信中継方法、通信中継プログラムおよび通信中継装置
PCT/JP2004/016265 WO2006048925A1 (ja) 2004-11-02 2004-11-02 通信中継方法、通信中継プログラムおよび通信中継装置
EP04799468A EP1809010A4 (en) 2004-11-02 2004-11-02 COMMUNICATION RELAY METHOD, COMMUNICATION RELAY PROGRAM, AND COMMUNICATION RELAY APPARATUS
US11/797,363 US20080212764A1 (en) 2004-11-02 2007-05-02 Communication relay apparatus, communication relay method, and computer product

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2004/016265 WO2006048925A1 (ja) 2004-11-02 2004-11-02 通信中継方法、通信中継プログラムおよび通信中継装置

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US11/797,363 Continuation US20080212764A1 (en) 2004-11-02 2007-05-02 Communication relay apparatus, communication relay method, and computer product

Publications (1)

Publication Number Publication Date
WO2006048925A1 true WO2006048925A1 (ja) 2006-05-11

Family

ID=36318945

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2004/016265 WO2006048925A1 (ja) 2004-11-02 2004-11-02 通信中継方法、通信中継プログラムおよび通信中継装置

Country Status (4)

Country Link
US (1) US20080212764A1 (ja)
EP (1) EP1809010A4 (ja)
JP (1) JP4627760B2 (ja)
WO (1) WO2006048925A1 (ja)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2008109191A (ja) * 2006-10-23 2008-05-08 Nec Infrontia Corp 携帯電話端末および電話制御方法
JP2008219733A (ja) * 2007-03-07 2008-09-18 Softbank Mobile Corp 移動無線電話による通信と無線ｌａｎアクセスポイントによる通信の選択方法及びシステム
JP2020150296A (ja) * 2019-03-11 2020-09-17 三菱自動車工業株式会社 車両の無線通信装置
JP2020198636A (ja) * 2015-09-25 2020-12-10 Ｌｉｎｅ株式会社 効率的な呼処理のためのシステムおよび方法

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7212615B2 (en) * 2002-05-31 2007-05-01 Scott Wolmuth Criteria based marketing for telephone directory assistance
US9367846B2 (en) * 2004-11-29 2016-06-14 Jingle Networks, Inc. Telephone search supported by advertising based on past history of requests
US9363228B2 (en) * 2009-12-15 2016-06-07 Qualcomm Innovation Center, Inc. Apparatus and method of peer-to-peer communication
KR101909982B1 (ko) * 2011-12-22 2018-10-23 삼성전자 주식회사 ＶｏＩＰ 게이트웨이 장치, 이의 제어방법 및 이를 포함하는 시스템
US9762628B2 (en) 2013-02-19 2017-09-12 Avaya Inc. Implementation of the semi-attended transfer in SIP for IP-multimedia subsystem environments
US9467570B2 (en) * 2013-11-20 2016-10-11 Avaya Inc. Call transfer with network spanning back-to-back user agents
KR102231859B1 (ko) * 2014-09-01 2021-03-26 삼성전자주식회사 무선 통신 시스템에서 단말이 서비스 연결을 유지하는 장치 및 방법
US11233831B2 (en) * 2019-07-31 2022-01-25 Centurylink Intellectual Property Llc In-line, in-call AI virtual assistant for teleconferencing

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH09261337A (ja) * 1996-03-22 1997-10-03 Nippon Telegr & Teleph Corp <Ntt> リルーチング接続方法
JPH10322391A (ja) * 1997-05-15 1998-12-04 Sony Corp 通信端末および通信方法
JP2000125041A (ja) * 1998-10-19 2000-04-28 Yamaha Corp 電話接続方法及び電話端末装置
JP2003060713A (ja) * 2001-08-16 2003-02-28 Ntt Docomo Inc 通信システム及び通信接続確立方法、並びに、ゲートウェイ装置、及び通信端末装置
JP2004070581A (ja) * 2002-08-05 2004-03-04 Ntt Docomo Inc 情報通信端末、情報通信装置、情報通信システム、情報通信方法、情報通信プログラム、及び、コンピュータ読取可能な記録媒体
JP2004242090A (ja) * 2003-02-06 2004-08-26 Hitachi Ltd Ｉｐ電話システムの代理応答制御方法

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH0918594A (ja) * 1995-07-03 1997-01-17 Kozo Kaneko コールバック中継システム
US5712900A (en) * 1996-05-21 1998-01-27 Ericsson, Inc. Emergency call back for roaming mobile subscribers
JP2001520820A (ja) * 1997-02-03 2001-10-30 エムシーアイ・ワールドコム・インコーポレーテッド 通信システム構造
KR20010006455A (ko) * 1997-04-15 2001-01-26 엠씨아이 월드콤 인코포레이티드 교환 전화 통신용 시스템, 방법 및 그 제조물
KR19980086889A (ko) * 1997-05-15 1998-12-05 이데이 노부유끼 데이터 통신방법, 데이터 통신단말, 데이터 통신시스템 및 통신 제어시스템
JPH11122360A (ja) * 1997-10-13 1999-04-30 Canon Inc コールバックシステム及び通信装置
EP1135906A1 (en) * 1998-12-03 2001-09-26 Telefonaktiebolaget LM Ericsson (publ) System and method for mobile terminal registration in an integrated wireless packet-switched network
JP3546946B2 (ja) * 1999-11-12 2004-07-28 日本電気株式会社 コールバック通信方法及びそのシステム
JP4113342B2 (ja) * 2001-07-31 2008-07-09 インターナショナル・ビジネス・マシーンズ・コーポレーション コンピュータシステム間でジョブを通知するための方法、コンピュータシステムおよびプログラム
JP4588271B2 (ja) * 2001-09-18 2010-11-24 富士通株式会社 データ同期システム、データ同期方法、データセンタ及びクライアント端末
KR100456123B1 (ko) * 2001-11-06 2004-11-15 하경림 사용자의 통신수단정보에 따라 최적 통신경로를 설정하는통신 통합 시스템 및 이를 이용한 통화방법
US20030227939A1 (en) * 2002-06-05 2003-12-11 Satoru Yukie Establishing a connection using a hybrid receiver
JP4155920B2 (ja) * 2003-12-25 2008-09-24 株式会社日立コミュニケーションテクノロジー メディアゲートウェイおよび自動電話転送サービスシステム

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH09261337A (ja) * 1996-03-22 1997-10-03 Nippon Telegr & Teleph Corp <Ntt> リルーチング接続方法
JPH10322391A (ja) * 1997-05-15 1998-12-04 Sony Corp 通信端末および通信方法
JP2000125041A (ja) * 1998-10-19 2000-04-28 Yamaha Corp 電話接続方法及び電話端末装置
JP2003060713A (ja) * 2001-08-16 2003-02-28 Ntt Docomo Inc 通信システム及び通信接続確立方法、並びに、ゲートウェイ装置、及び通信端末装置
JP2004070581A (ja) * 2002-08-05 2004-03-04 Ntt Docomo Inc 情報通信端末、情報通信装置、情報通信システム、情報通信方法、情報通信プログラム、及び、コンピュータ読取可能な記録媒体
JP2004242090A (ja) * 2003-02-06 2004-08-26 Hitachi Ltd Ｉｐ電話システムの代理応答制御方法

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP1809010A4 *

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2008109191A (ja) * 2006-10-23 2008-05-08 Nec Infrontia Corp 携帯電話端末および電話制御方法
JP2008219733A (ja) * 2007-03-07 2008-09-18 Softbank Mobile Corp 移動無線電話による通信と無線ｌａｎアクセスポイントによる通信の選択方法及びシステム
JP2020198636A (ja) * 2015-09-25 2020-12-10 Ｌｉｎｅ株式会社 効率的な呼処理のためのシステムおよび方法
JP2020150296A (ja) * 2019-03-11 2020-09-17 三菱自動車工業株式会社 車両の無線通信装置

Also Published As

Publication number Publication date
EP1809010A1 (en) 2007-07-18
JP4627760B2 (ja) 2011-02-09
JPWO2006048925A1 (ja) 2008-05-22
EP1809010A4 (en) 2010-01-27
US20080212764A1 (en) 2008-09-04

Similar Documents

Publication Publication Date Title
JP4548242B2 (ja) 音声ｉｐ電話方法と装置。
JP3436471B2 (ja) 電話通信方法及び電話通信システム
JP5000215B2 (ja) Ｓｉｐを用いたボタン電話装置およびそのグループ代表着信および着信応答方法
JP2002118594A (ja) エミュレーションクライアントを有するスイッチ
US20100128707A1 (en) Call control device, relay device, call control method, and storage medium
US20080212764A1 (en) Communication relay apparatus, communication relay method, and computer product
JP4602046B2 (ja) 管理サーバ
JP4628966B2 (ja) セッション制御方法、通信システム、及び、接続指示装置
WO2006100751A1 (ja) 電話装置
WO2009107800A1 (ja) 通話中継サーバおよび音声通話システムならびに音声通話中継方法
EP2936750A1 (en) Systems and methods of conducting conference calls
JP2007013616A (ja) プレゼンスサーバ、情報提供システム及び情報提供方法
JP6933128B2 (ja) Ｉｐ電話システム、ｉｐ電話システムに対応する携帯電話機およびデジタル電話交換機、並びに通信方法
JP4679483B2 (ja) Ｉｐ通話端末切り替え装置及び方法
JP4044082B2 (ja) 選択装置、変換装置、選択方法、変換方法、コンピュータプログラム
JP5182297B2 (ja) 通信中継方法、通信中継プログラムおよび通信中継装置
JP5769909B2 (ja) 無線通信装置およびサーバ装置
JP4840101B2 (ja) Ｉｐコールセンタシステム
JP2008085901A (ja) 電話交換システム及びこの電話交換システムで使用されるサービス提供方法
JP2008113381A (ja) 通信システム
JP5447591B2 (ja) 通信中継方法、通信中継プログラムおよび通信中継装置
JP2008028654A (ja) 交換装置
JP4308237B2 (ja) 交換装置、通信システム、通信制御方法
US8630254B2 (en) Telephone line switching apparatus, telephone line switching system, telephone relay system, telephone relay method, telephone relay program
JP4586713B2 (ja) 電話通信システム

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NA NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): BW GH GM KE LS MW MZ NA SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LU MC NL PL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
WWE Wipo information: entry into national phase

Ref document number: 2006542195

Country of ref document: JP

WWE Wipo information: entry into national phase

Ref document number: 2004799468

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: DE

WWP Wipo information: published in national office

Ref document number: 2004799468

Country of ref document: EP