WO2006100751A1 - 電話装置 - Google Patents

電話装置 Download PDF

Info

Publication number
WO2006100751A1
WO2006100751A1 PCT/JP2005/005120 JP2005005120W WO2006100751A1 WO 2006100751 A1 WO2006100751 A1 WO 2006100751A1 JP 2005005120 W JP2005005120 W JP 2005005120W WO 2006100751 A1 WO2006100751 A1 WO 2006100751A1
Authority
WO
WIPO (PCT)
Prior art keywords
line
telephone
telephone device
line state
notification
Prior art date
Application number
PCT/JP2005/005120
Other languages
English (en)
French (fr)
Inventor
Yasukazu Tsujino
Hideyuki Sugihashi
Kiyoko Yamamoto
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 CN2005800492166A priority Critical patent/CN101167344B/zh
Priority to JP2007509105A priority patent/JP4522449B2/ja
Priority to KR1020077024281A priority patent/KR100956925B1/ko
Priority to PCT/JP2005/005120 priority patent/WO2006100751A1/ja
Priority to EP05727037A priority patent/EP1863265A4/en
Publication of WO2006100751A1 publication Critical patent/WO2006100751A1/ja
Priority to US11/858,248 priority patent/US20080049724A1/en

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M1/00—Substation equipment, e.g. for use by subscribers
    • H04M1/253—Telephone sets using digital voice transmission
    • H04M1/2535—Telephone sets using digital voice transmission adapted for voice communication over an Internet Protocol [IP] network
    • 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]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M1/00—Substation equipment, e.g. for use by subscribers
    • H04M1/71—Substation extension arrangements
    • H04M1/715—Substation extension arrangements using two or more extensions per line
    • 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/42314—Systems providing special services or facilities to subscribers in private branch exchanges
    • H04M3/42323—PBX's with CTI arrangements

Definitions

  • the present invention relates to a telephone device such as an IP (Internet Protocol) telephone that is compatible with SIP (Session Initiation Protocol).
  • IP Internet Protocol
  • SIP Session Initiation Protocol
  • a conventional telephone system using line switching accommodates a plurality of lines (prime lines) mainly used by the terminal itself and prime lines (other lines) of other terminals, and a line used by operating a button or the like.
  • lines primary lines
  • other lines other lines
  • An IP telephone system that has a multi-line service function has been proposed for IP telephone systems that use SIP to meet these needs.
  • Fig. 1 is a conceptual diagram of a multi-line service on a conventional SIP.
  • An IP phone 3a 3c is connected to a SIP server 1 via a network 2 such as LAN (Local Area Network) / WAN (Wide Area Network).
  • LAN Local Area Network
  • WAN Wide Area Network
  • IP telephones 3a to 3c constitute a multi-line gnole 4.
  • a multi-line service function was realized between the SIP server 1 and each IP phone 3a 3c, which is a SIP user agent, by using a unique message or unique procedure in addition to the standard SIP message. Les.
  • FIG. 2 is a diagram showing an example of a conventional system configuration that focuses on the realization means.
  • the line status notification means for notifying the line status of each line ac is included in the SIP server 1, and each SIP user agent
  • the IP telephones 3a and 3c have other line status requesting means for requesting notification of other line status.
  • FIG. 3 is a diagram showing a configuration example of a SIP user agent focusing on one IP phone.
  • a line status request for obtaining accommodation line information from the SIP server 1 is shown.
  • Patent Documents 1 and 2 disclose techniques for controlling incoming calls in an IP telephone using the function of a main device (corresponding to a SIP server).
  • Patent Document 1 Japanese Unexamined Patent Publication No. 2003-283658
  • Patent Document 2 JP 2004-266437 A
  • the conventional IP telephone is provided with a line state notification means for notifying the line state of each line on the SIP server, and by communication using a unique message or a unique procedure in addition to a standard SIP message. Since the multi-line service function was realized, there were the following problems.
  • the present invention has been proposed in view of the above-described conventional problems, and the object of the present invention is to realize a multiline service by an original message / procedure only between telephone devices such as IP telephones. It is to provide a telephone device that can use a connection management server according to a standard connection protocol without using a unique message / procedure between the connection management server such as a SIP server and the telephone device.
  • the present invention provides a predetermined communication protocol and connection.
  • a telephone device for making a call using a protocol characterized in that it comprises means for mutually notifying the line status with a different interface from the above connection protocol with other telephone devices constituting a multi-line group. .
  • the unique message for controlling the multi-line service is transmitted and received only between the telephone devices, and the problem is determined.
  • a system can be constructed using a connection management server such as a supported SIP server (standard SIP server).
  • FIG. 1 is a conceptual diagram of a conventional multi-line service on SIP.
  • FIG. 2 is a diagram showing an example of a conventional system configuration focusing on realizing means.
  • FIG. 3 is a diagram showing a configuration example of a SIP user agent focusing on one IP phone.
  • FIG. 4 is a conceptual diagram at the time of an incoming call to an IP telephone in the present invention.
  • FIG. 5 is a conceptual diagram when making a call from an IP telephone in the present invention.
  • FIG. 6 is a conceptual diagram at the time of hold / hold response from the IP telephone in the present invention.
  • FIG. 7 is a diagram showing an example of a system configuration of the present invention focusing on realizing means.
  • FIG. 8 A diagram showing an example of the internal configuration of a SIP user agent focusing on one IP phone.
  • FIG. 9 is a functional block diagram of an IP telephone.
  • FIG. 10 is a diagram showing an example of control data.
  • FIG. 11 is a diagram showing a specific example of control data.
  • FIG. 12 is a diagram (part 1) illustrating an example of a restart sequence.
  • FIG. 13 is a second diagram showing an example of a restart sequence.
  • FIG. 14 is a diagram (part 3) illustrating an example of a restart sequence.
  • FIG. 15 is a diagram showing an example of a sequence of leaving from a multi-line group and joining.
  • FIG. 16 is a diagram showing a sequence example of rejecting acceptance due to exceeding the maximum number of notification destinations.
  • FIG. 17 is a diagram showing a sequence example of participation authentication.
  • FIG. 18 is a diagram showing an example of an incoming call sequence.
  • Sono is a diagram showing an example of a transmission sequence.
  • FIG. 20A is a diagram (part 1) showing an example of a line hold / response sequence.
  • FIG. 4 is a conceptual diagram at the time of an incoming call to the IP telephone in the present invention. It is assumed that IP telephones 3a-3c are connected to the SIP server 1 via a network 2 such as a LAN / WAN, and the IP telephones 3a-3c constitute a multiline group 4. Where SIP server 1 to IP phone When receiving a call to the machine 3a, the IP telephone 3a notifies the IP telephone 3b and the IP telephone 3c of the incoming call with a unique message, thereby realizing multi-line incoming call processing.
  • FIG. 5 is a conceptual diagram when making a call from an IP telephone in the present invention.
  • the IP telephone 3b makes a call using the prime line (line a) of the IP telephone 3a
  • the IP telephone 3a notifies the IP telephone 3a of the use of the line a by an original message
  • the IP telephone 3a notifies the IP telephone 3c of this.
  • multi-line transmission processing is realized.
  • FIG. 6 is a conceptual diagram at the time of hold / hold response from the IP telephone in the present invention.
  • the IP phone 3b notifies the IP phone 3a that the call is being held by a unique message when the call is being held, and the IP phone 3a notifies the IP phone 3c of this.
  • the hold response process is realized by notifying the response by the original message in response to the response from the IP telephone 3a.
  • the original procedure / message is not included between the SIP server 1 and the IP telephone 3a 3c, and the original procedure is used between the IP telephones 3a 3c to solve the problem.
  • FIG. 7 is a diagram showing a system configuration example of the present invention focusing on the realization means.
  • SIP server 1 consists of a SIP server (standard SIP server) that supports only RFC / Internet drafts related to SIP, manages the prime line as a normal line, and that line constitutes a multiline. I'm not conscious of whether or not.
  • a park server 7 is provided for line holding as needed.
  • the IP telephones 3a to 3c are provided with own line state notifying means for notifying the state of the prime line and other line state requesting means for requesting notification of the line state.
  • FIG. 8 is a diagram showing an example of the internal configuration of a SIP user agent focusing on one IP phone.
  • the figure shows the power shown for IP phone 3a Within each IP phone, the line status notification means for the prime line (own line status notification means) and the line status request means for obtaining other line information for each line (other line status) Request means).
  • the line status requesting means is realized as a component by providing the line status requesting means for the prime line inside the IP telephone.
  • FIG. 9 is a functional block diagram of the IP telephone.
  • IP telephone 3 (3a-3c) includes a call control unit 50, a multiline control unit 51, an RTP (Real-time Transport Protocol) control unit 52, A SIP protocol control unit 53, an input / output interface unit 54, a LAN interface unit 55, and a data management unit 56 are provided.
  • the data management unit 56 includes terminal management data 60, a function button management table 61, a function button state management tape knob 62, and a multiline management table 63 as control data.
  • command data issued via the network or by button operation of the IP telephone is sent to the data management unit 56 via the LAN interface unit 55 or the input / output interface unit 54. Be notified.
  • the data management unit 56 registers the input data in the terminal management data 60, the function button management table 61, and the multiline management table 63.
  • FIG. 11 shows a specific example of the control data of the IP telephones 3a, 3b, and 3c when the line 3000 is registered.
  • the function button state management tape No. 62 is dynamic control data and is not registered in the command, and thus is excluded from FIG.
  • the own line state notification destination address group of the multiline management table 63 shows the state after the completion of the line state notification request from the IP telephones 3b and 3c.
  • Figures 12-14 show an example restart sequence.
  • the IP telephone 3a is a prime terminal of the line 3000, and the IP telephones 3b and 3c are registered in advance by means such as a command using the line 3000 as the other line.
  • SIMPLE Session Initiation Protocol
  • FIG. 12 shows a restart sequence of the IP telephone 3b that accommodates the other line.
  • the IP telephone 3b inquires of the IP telephone 3a about the line state using the other line state request means (steps S102 and S103).
  • the IP phone 3a that has received the inquiry notifies the latest line status of the line 3000 by its own line status notifying means. (Steps S104, S105).
  • the line state notification is performed only to the IP telephone 3b that has made the request.
  • FIG. 13 shows a restart sequence of IP telephone 3a which is a prime terminal equipped with a notification destination dynamic generation method.
  • the IP telephone 3a initializes the other line information to be notified of a change in the state of the line 3000 when resumption occurs (step S111).
  • the IP phone 3b, 3c that accommodates the other line periodically implements other line status request means (step SI 12, SI 13, step SI 17, SI 18), and the IP phone 3a uses the request source as the status notification destination.
  • step S 114, step S 119 it has a function of refreshing the status notification destination information on line 3000.
  • FIG. 14 shows a restart sequence of IP telephone 3a which is a prime terminal equipped with a notification destination dynamic correction method.
  • the IP telephone 3a stores information necessary for state change notification in its own line state notification means as information that is not initialized when the nonvolatile memory or the like is restarted.
  • the dialog information is stored in the SUBSCRIBE reception trigger (steps S131, S132, S136, S137) (steps S133, S138), and the IP phone 3a is connected to the IP phone 3b and the IP phone.
  • the process resumes with the dialog information for 3c stored (step S141).
  • the IP telephone 3a notifies the line state based on the dialog information recovered from the memory (Step S142) when the restart occurs (Steps S144, S145), and promptly stores the line state stored in each other line terminal. Synchronize with the state managed by the prime terminal. If the IP telephone 3c resumes at the same time (step S143) and the dialog information stored in the IP telephone 3a becomes invalid, the other line status request means in the IP telephone 3c NG is returned in response to the line status notification from the IP telephone 3a (steps S148 and S149).
  • the IP phone 3a that has received NG updates (deletes) the stored dialog information (step S150), and thereafter receives a new line status notification request from the IP phone 3c. Line status notification is not performed until When a new line state notification request is received from the IP telephone 3c (steps S151 and S152), a new dialog is stored (step S153), and a line state notification is performed (steps S154 and S155).
  • the multiline control unit 51 Upon completion of the restart, the multiline control unit 51 generates a SUBSCRIBE message for all destination addresses registered in the multiline management table 63 of the data management unit 56, and sets the SIP protocol control unit 53 and the LAN interface unit 55. To send out.
  • the SUBSCRIBE message is sent to the SIP protocol control unit 53 and the multiline control unit 51 via the LAN interface unit 55 to the IP telephone 3a which is the prime terminal of the line 3000.
  • the multiline control unit 51 searches the multiline management table 63 of the data management unit 56 with the destination address of the SUBSCRIBE message, adds the address of the IP phone 3b to the group 3000's own line status notification address group, and adds the IP phone 3b.
  • a NOTIFY message is generated and sent via the SIP protocol control unit 53 and the LAN interface unit 55.
  • the NOTIFY message describes the current line state of the line obtained by indexing the function button state management table 62 with the button position information obtained from the multiline management table 63 of the data management unit 56.
  • the multiline control unit 51 of the IP telephone 3b Upon receiving the NOTIFY message, the multiline control unit 51 of the IP telephone 3b searches the multiline management table 63 on the line 3000, extracts the button position information, and uses the extracted button position information to store the function button state management table 62. Index and set the received line status.
  • FIG. 15 is a diagram showing an example of a sequence for leaving and joining a multi-line group.
  • the IP telephone 3b having other line status request means has a function of requesting the user to leave or join the multi-line norpe by operating a button or inputting a command.
  • the IP phone 3a which is a prime terminal having its own line status notification means, deletes information related to the IP phone 3b (step S210 S212) when there is a disconnection request from the IP phone 3b which is a notification destination terminal (step S210 S212). If there is a participation request again (steps S218 to S220), information on the IP telephone 3b is regenerated (step S221).
  • the withdrawal request means is realized by the UNSUBSCRIBE method in the example of FIG.
  • FIG. 16 is a diagram showing a sequence example of rejecting acceptance due to exceeding the maximum number of notification destinations.
  • the maximum number m of notification destinations is registered in advance by means such as a command.
  • IP telephone 3a rejects acceptance by sending NG ( Step S311).
  • the system configuration corresponding to the processing capability can be maintained.
  • FIG. 17 is a diagram showing a sequence example of participation authentication.
  • the IP telephone 3a which is a prime terminal having its own line status notification means, recognizes authentication information related to the line a in advance by means of a command or the like.
  • the IP telephone 3b having the other line state request means notifies the authentication information on the line a to the IP telephone 3a which is the prime terminal at the time of the line state request (step S401).
  • the IP phone 3a which is the prime terminal, examines the authentication information received from the IP phone 3b, and if it is determined that the authentication information is correct (step S402), transmits OK (step S403). Add to notification destination. If there is a line status request from IP phone X that does not know the correct authentication information (step S404), it is not determined that the authentication information is correct (step S405), and NG is transmitted (step S406).
  • FIG. 18 shows an example of an incoming call sequence.
  • IP phone 3a which is the prime terminal that has received an incoming call from SIP server 1 (step S50 1), branches the INVITE request to its own line state notification destination (step S502). "Incoming" (Step S503).
  • the IP telephones 3b and 3c that performed the response operation request a response from the IP telephone 3a.
  • the IP telephone 3a determines a response terminal from among a plurality of response requests, and returns “response possible” to the IP telephone 3b (step S504).
  • the IP telephone 3a returns “response impossible” to the IP telephone 3c that has not responded to the response request (step S5 05).
  • the IP phone 3b that received "response possible" responds to the INVITE address to the IP phone 3a "
  • the IP telephone 3a that has received "200 OK:” returns a "200 OK" response that sets the address of the IP telephone 3b that responded to the Contact header to the SIP server 1 (step S506). ).
  • SIP messages that subsequently arrive at line a via SIP server 1 will now reach IP phone 3b directly without going through prime phone IP phone 3a.
  • the IP telephone 3a sends a CANCEL method to the other IP telephone 3c to stop the incoming call (step S507).
  • the response terminal IP telephone 3b that has received the ACK for “200 0K” from the SIP server 1 notifies the IP telephone 3a that the ACK has been received (step S508). Recognizing the reception of ACK, the IP telephone 3a notifies its own line state notification destination that the line state is “in use” (step S509).
  • the IP telephone 3b When the SIP session is terminated due to the end of the conversation, the IP telephone 3b as a response terminal notifies the IP telephone 3a as a prime terminal that the line state has become “free” (steps S510, S511). Recognizing that the line status is “free”, the IP telephone 3a notifies its own line status notification destination that the line status is “free” (step S512).
  • the branching state notification destination includes other line state requesting means in the prime terminal, and the same message exchange in steps S504 and S505 is performed in the prime terminal. The response operation by the prime terminal is realized.
  • step S503 in FIG. 18 by assigning a ringer ringing method to the " ⁇ ⁇ ⁇ ⁇ " message for each other line terminal, it is possible to control the ringing of all the other line terminals from the prime terminal. .
  • step S503 in FIG. By giving a ringer ringing start time to the message, for example, it is possible to preferentially ring the ringer of the prime terminal, and to enable operation such that the ringer of the other line terminal starts ringing when the response is delayed.
  • step S502 in FIG. 18 by controlling the INVITE message transmission timing to each other line terminal, for example, the ringer of the prime terminal is preferentially ringed, and the ringer of the other line terminal is delayed when the response is delayed. Operation that starts to ring is possible.
  • An incoming call notification (INVITE request) from the SIP server 1 to the line 3000 is notified to the SIP protocol control unit 53 and the call control unit 50 via the LAN interface unit 55 of the IP telephone 3a.
  • the call control unit 50 compares the own address of the terminal management data 60 of the data management unit 56 with the destination address of the INVITE request message, and if they match, extracts the prime line button position and indexes the function button state management table 62. If the line state is “empty”, the line is changed to “incoming”, and the INVITE request message is delivered to the multiline control unit 51 to notify the incoming call. If it is not “empty”, it recognizes “unavailable” and responds to SIP server 1 to that effect.
  • the multiline control unit 51 Upon receiving the incoming call notification, the multiline control unit 51 searches the multiline management table 63 of the data management unit 56 with the destination address of the INVITE request message, acquires its own line state notification destination address group, and receives the INVITE request. Branch distribution.
  • the INVITE request is sent via the SIP protocol control unit 53 and the LAN interface unit 55.
  • the multi-line control unit 51 generates a NOTIFY message for the own line state notification destination address group and sends it through the SIP protocol control unit 53 and the LAN interface unit 55.
  • the NO TIFY message describes “incoming” as the line status of the line obtained by indexing the function button status management table 62 with the button position information obtained from the multiline management table 63 of the data management unit 56. .
  • the operation as the other line state requesting means at the time of incoming to the line 3000 will be described.
  • the INVITE request sent by the IP telephone 3a's own line status notification means is sent via the LAN interface 55 of the IP telephones 3b and 3c, which are the other line terminals on the line 3000. This is notified to the p protocol control unit 53 and the call control unit 50.
  • the call control unit 50 compares the self-address of the terminal management data 60 of the data management unit 56 with the destination address of the INVITE request message, and the multi-line management table 63 of the data management unit 56 is not matched.
  • the function button state management table 62 of the data management unit 56 is indexed with the extracted button position information, and the corresponding line state is changed to “incoming”, and the “180 Ringing” message is received for the INVITE request. Return the ring and ring the ringer.
  • each SIP message including an INVITE request is sent from the own line state notifying means within the multiline control unit 51 when the destination registered in the own line state notifying address group is the own terminal. Delivered to the line status request means to realize the incoming call to the prime terminal.
  • the call control unit 50 indexes the function button state management table 62 at the notified button position. If the line state is "incoming”, the call control unit 50 changes to "waiting for response confirmation", and the multi-line control unit 51 Request response request transmission. If the line status is other than “incoming”, the operation is invalid.
  • the multiline control unit 51 indexes the function button management table 61, extracts the address information of the prime terminal from the button position information, generates a MESSAGE (response request), the SIP protocol control unit 53, the LAN interface unit 55 To send out.
  • MESSAGE response request
  • the multiline control unit 51 of the IP telephone 3a After returning “OK”, a “response request” is made to the call control unit 50.
  • the call control unit 50 extracts the prime line button position from the terminal management data 60 and indexes the function button state management table 62 at the extracted button position. Notify the controller 51 that “response is possible”. If it is already “in use”, “response impossible” is notified.
  • the multi-line control unit 51 that has received the result notification for the response request from the call control unit 50 returns the result to the response request source in the MESS AGE.
  • the multi-line control unit 51 generates a NOTI FY message for the own line state notification destination address group, and sends it through the SIP protocol control unit 53 and the LAN interface unit 55.
  • the NOTIFY message “in use” is described as the line state of the line obtained by indexing the function button state management table 62 with the button position information obtained from the multiline management table 63 of the data management unit 56.
  • the call control unit 50 of the IP telephone 3b that has received MESSAGE (response possible) returns “200 ⁇ K”, searches the multiline management table 63 by the called number, and calls the extracted button position information. Notify the department 50.
  • the call control unit 50 indexes the function button state management table 62 with the button position information, and changes the state to “in use”.
  • the multiline control unit 51 of the IP telephone 3a that has received "200 OK:” for MESSAGE (response possible) notifies the call control unit 50 to that effect.
  • the call control unit 50 sets the destination address (3100) from which “response is possible” is sent to “Contact” and sends “200 0K” to the SIP server 1.
  • multiline control unit 51 of IP telephone 3c Upon receiving a NOTIFY message, multiline control unit 51 of IP telephone 3c that has not performed a response operation returns “200 OK” and then searches multiline management table 63 by source number (3000). Then, the extracted button position information is notified to the call control unit 50. The call control unit 50 indexes the function button state management table 62 with the button position information, and changes the line state to the state notified by NOTIFY (“in use”). Also, stop the ringer when the INVITE method is canceled.
  • FIG. 19 shows an example of a transmission sequence.
  • the IP phone 3b that made the call operation on the line a which is the prime line of the IP phone 3a makes a call request to the IP phone 3a which is the prime terminal, and the IP phone 3a has a line status of “free”. For example, “call ready” is returned to the call originator (IP telephone 3b in this example) (step S601). Further, IP telephone 3a returns "call not possible” unless the line status requested for call is "free” (step S602). Next, IP phone 3a notifies its own line state notification destination that the line has become “in use” (step S603).
  • the IP phone 3b that has received “OK” sets the address of line a instead of its own address in the From header of the INVITE request, and sets its own address in the Contact header, and sends an INVITE request to the SIP server 1. , Transition to a call state (step S604).
  • step S601 of Fig. 19 by receiving a call request from each other line terminal and taking a certain timing until the call is considered to be possible, for example, simultaneous transmission operation of prime terminal and other line terminal power Operation that gives priority to outgoing calls from prime terminals is possible.
  • a transmission process from the IP telephone 3b that accommodates the line as another line using the line 3000 will be described.
  • the calling operation is performed by pressing the function button corresponding to the other user line to be used for calling, and is notified to the call control unit 50 through the input / output interface unit 54 together with the button position information.
  • the call control unit 50 indexes the function button state management table 62 at the notified button position. If the line state is "free”, the call control unit 50 changes the state to "waiting for call confirmation" and sends it to the multiline control unit 51. Requests transmission of outgoing request. If the line status is other than “free”, the operation is invalidated.
  • the multiline control unit 51 indexes the function button management table 61, extracts the address information of the video terminal from the button position information, generates MESSAGE (call request), and generates the SIP protocol.
  • the data is transmitted via the control unit 53 and the LAN interface unit 55.
  • a “call request” is made to the call control unit 50.
  • the call control unit 50 extracts the prime line button position from the terminal management data 60, indexes the function button state management table 62 at the extracted button position, and changes it to “in use” if it is “empty”. Notify the control unit 51 that “communication is possible”. Also, if it is already “in use”, “not callable” is notified.
  • the multi-line control unit 51 that has received the result notification for the call request from the call control unit 50 returns the result to the call request source on the MESS AGE.
  • the multiline control unit 51 generates a NOTI FY message for the own line state notification destination address group, and sends it through the SIP protocol control unit 53 and the LAN interface unit 55.
  • the NOTIFY message “in use” is described as the line state of the line obtained by indexing the function button state management table 62 with the button position information obtained from the multiline management table 63 of the data management unit 56.
  • the call control unit 50 of the IP telephone 3b that has received MESSAGE (transmission is possible) returns “200 ⁇ K”, searches the multiline management table 63 by the called number, and calls the extracted button position information. Notify the department 50.
  • the call control unit 50 indexes the function button state management table 62 by the button position information, changes the state to “in use”, generates an INVITE request message, and passes through the SIP protocol control unit 53 and the LAN interface unit 55. And send it out.
  • the multi-line control unit 51 of the IP telephone 3c that has not made a call operation receives the NOTIFY message, it returns "200 OK" and then searches the multi-line management table 63 using the source number (3000). Then, the extracted button position information is notified to the call control unit 50. The call control unit 50 indexes the function button state management table 62 with the button position information, and changes the line state to the state notified by NOTIFY (“in use”). [0075] ⁇ Line Hold 'Response Sequence>
  • FIGS. 20A and 20B are diagrams showing an example of a line hold / response sequence.
  • Line hold and response processing is realized by general call park service processing using SIP.
  • the IP phone 3b during the call is given a call park number ("park number") during line hold operation and executes a service that responds by dialing "answer special number" + "park number” (step S701, S702).
  • a call park number is a number that is uniquely assigned to a held call within the system.
  • the line number to be held is used.
  • the IP telephone 3b that has placed the line on hold notifies the IP telephone 3a, which is the prime terminal, that the line has been held and the “park number” (step S703).
  • the IP phone 3a notifies the “line on hold” state and the “park number” to the destination of the own line state notification (step S704).
  • the IP telephone 3c that has made a response to the line hold requests the IP telephone 3a to respond.
  • the IP telephone 3a returns “response possible” and “park number” to the response terminal (step S705).
  • IP telephone 3a notifies its own line state notification destination that the line state is “in use” (step S706).
  • the IP phone 3c that has received “response possible” sets the call park response special number in the To header, the address of line a instead of its own address in the From header, and sends an INVITE request to the SIP server 1 (steps S707, S708). ).
  • the call control unit 50 indexes the function button state management table 62 at the notified button position. If the line state is "in use”, the call control unit 50 changes the state to "on hold request”. -Generates an INVITE message and sends it via the SIP protocol control unit 53 and the LAN interface unit 55.
  • the call control unit 50 of the IP telephone 3b extracts the call park execution number from the terminal management data 60, and notifies the SIP server 1 by the INVITE method.
  • SIP server 1 is this INVIT
  • the IP telephone 3b and the partner SIP user agent are each connected to the park server 7, and the connection between the IP telephone 3b and the partner SIP user agent is terminated.
  • the call control unit 50 of the IP telephone 3b that is in a communication state with the park server 7 notifies the park server 7 of the line number (3000) used as a park number and also to the multi-line control unit 51. Perform “park notification”.
  • the multi-line control unit 51 generates a MESSAGE (park notification) for the IP telephone 3a which is the prime terminal of the line 3000, and transmits the MESSAGE via the SIP protocol control unit 53 and the LAN interface unit 55.
  • the multi-line control unit 51 of the IP telephone 3a that has received MESSAGE (park notification) returns “20 0 OK” and then performs “park notification” to the call control unit 50.
  • the call control unit 50 extracts the prime line button position from the terminal management data 60, indexes the function button state management table 62 at the extracted button position, and changes it to “pending” if “used”.
  • the received park number is stored in the function button state management table 62.
  • the multi-line control unit 51 generates a NOTIFY message for the own line state notification destination address group and sends it through the SIP protocol control unit 53 and the LAN interface unit 55.
  • “pending” is described as the line state of the line obtained by indexing the function button state management table 62 with the button position information obtained from the multiline management table 63 of the data management unit 56. .
  • the call control unit 50 indexes the function button state management table 62 at the notified button position. If the line state is "pending”, the call control unit 50 changes to "waiting for hold response confirmation", and the multiline control unit Requests 51 to send a response request. If the line status is other than “pending”, the operation is invalidated.
  • the multi-line control unit 51 indexes the function button management table 61, extracts the address information of the video terminal from the button position information, generates a MESSAGE (response request), and generates the SIP protocol control.
  • the data is transmitted via the control unit 53 and the LAN interface unit 55.
  • the multiline control unit 51 of the IP telephone 3a is "200
  • a “response request” is made to the call control unit 50.
  • the call control unit 50 extracts the prime line button position from the terminal management data 60, indexes the function button state management table 62 at the extracted button position, and changes it to “in use” if “pending”.
  • the line control unit 51 is notified of “response possible”. If it is already “in use”, “response impossible” is notified.
  • the multiline control unit 51 that has received the result notification for the response request from the call control unit 50 returns the result and the park number to MESSAGE and returns it to the response request source.
  • the multiline control unit 51 generates a NOTIFY message for the own line state notification destination address group and sends it through the SIP protocol control unit 53 and the LAN interface unit 55.
  • the NOTIFY message describes “in use” as the line state of the line obtained by indexing the function button state management table 62 with the button position information obtained from the multiline management table 63 of the data management unit 56. .
  • the call control unit 50 of the IP telephone 3c Upon receiving MESSAGE (response possible), the call control unit 50 of the IP telephone 3c returns “200 K”, searches the multiline management table 63 by the called number, and calls the extracted button position information. Notify the department 50. The call control unit 50 indexes the function button state management table 62 with the button position information, and changes the state to “in use”. Subsequently, the call control unit 50 of the IP telephone 3c extracts the call park response special number from the terminal management data 60, and notifies the SIP server 1 by the INVITE method. SIP server 1 forms a connection between IP phone 3c and park server 7 by this INVITE method.
  • the call control unit 50 of the IP telephone 3c that is in a communication state with the park server 7 notifies the park server 7 of the number notified from the IP telephone 3a by MESSAGE as the park number.
  • the park server 7 notified of the park number executes a park response process, and a connection between the IP telephone 3c and the partner SIP user agent is set up.
  • the line information of the IP telephone 3a is registered in advance in the IP telephones 3b and 3c by means of commands or the like.
  • IP phone 3a When there is an incoming call to IP phone 3a, IP phone 3a registered in IP phones 3b and 3c The line button of the incoming call is incoming and the incoming ringer rings.
  • IP telephone 3b responds by pressing the line button of the IP telephone 3a, the ringer of the IP telephones 3b and 3c stops and the line button of the IP telephone 3a of the IP telephones 3a and 3c is in use. If the ringer ring start time is set, the ringer will ring after the timeout.
  • IP phone 3c When 3c presses the line button of IP phone 3a, IP phone 3c becomes unable to answer and listens to the busy tone.
  • the line button of Pphone 3a is in use. When the IP telephone 3b is disconnected, the buttons of the IP telephones 3a and 3c of the IP telephone 3a are empty.
  • the line is put on hold by pressing the line button on the IP telephone 3a while the IP telephone 3a is talking. Call The other party listens to the hold tone.
  • the IP phone 3a line button of IP phones 3a, 3b, 3c is put on hold.
  • the IP telephone 3b presses the line button of the IP telephone 3a the telephone is on a call with the partner terminal on hold.
  • the IP telephone 3a line button of the IP telephones 3a, 3b, 3c is in use.
  • a SIP server (standard SIP server) that supports only RFC / Internet drafts related to SIP ), Etc.
  • SIP server standard SIP server
  • Etc. can be used to build a system.
  • SIP user agents etc. other than those used for multi-line services without being particularly aware of connectivity with the server.
  • the multi-line service can be realized by the original message Z procedure only between the telephone devices, it is only necessary to arrange the number of telephone devices reflecting the function of the present invention for the number of participating multi-line services.
  • Customers who have existing SIP systems, IP Centrex, etc. A multi-line system can be provided for customers who use it.
  • a telephone device that forms a multi-line can be connected even across networks, it is possible to easily assemble a multi-line that connects multiple bases.
  • connection management server since the sequence between the connection management server and the telephone device is simple, the traffic load between WANs can be reduced. In addition, since multiline control processing is distributed to prime line storage terminals, it is possible to add multiple lines without being affected by the capacity of the connection management server.

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Telephonic Communication Services (AREA)

Abstract

　ＩＰ電話機等の電話装置間のみの独自メッセージ／手順にてマルチラインサービスを実現し、ＳＩＰサーバ等の接続管理サーバと電話装置との間に独自メッセージ／手順を用いず、標準的な接続プロトコルに従った接続管理サーバを用いることができるようにする。 　所定の通信プロトコルおよび接続プロトコルにより通話を行う電話装置であって、マルチライングループを構成する他の電話装置との間で、上記接続プロトコルと異なる独自のインタフェースにより回線状態を相互に通知する手段を備える。

Description

明 細 書
電話装置
技術分野
[0001] 本発明は SIP (Session Initiation Protocol)に対応した IP (Internet Protocol)電話機 等の電話装置に関する。
背景技術
[0002] 従来の回線交換による電話システムには、自端末が主として使用する回線 (プライ ムライン）と他端末のプライムライン (ァザ一ライン）を複数収容し、釦などの操作により 使用する回線を特定することのできるマルチラインサービス機能を有する電話システ ムが多く存在し、複数の回線を収容した事業所等においては不可欠の機能であった 。このようなニーズに対応すベぐ SIPを使用した IP電話システムでもマルチラインサ 一ビス機能を有する IP電話システムが提案されている。
[0003] 図 1は従来の SIP上でのマルチラインサービスの概念図であり、 SIPサーバ 1に LA N (Local Area Network) /WAN (Wide Area Network)等のネットワーク 2を介して IP 電話機 3a 3cが接続され、 IP電話機 3a— 3cはマルチライングノレープ 4を構成して レ、るものとする。ここで、従来は SIPサーバ 1と SIPユーザエージェントである各 IP電 話機 3a 3cの間で標準の SIPメッセージに加えて独自メッセージまたは独自手順を 用レ、た通信によりマルチラインサービス機能を実現してレ、る。
[0004] 図 2は実現手段に着目した従来のシステム構成例を示す図であり、各ライン a cの 回線状態を通知する回線状態通知手段は SIPサーバ 1が有し、 SIPユーザエージェ ントである各 IP電話機 3a 3cは他回線状態の通知を要求する他回線状態要求手 段を有している。
[0005] 図 3は IP電話機一台に着目した SIPユーザエージヱントの構成例を示す図であり、 例えば、 IP電話機 3a内部には、収容ライン情報を SIPサーバ 1から得るための回線 状態要求手段をライン a— c毎に有してレ、る。
[0006] 一方、 IP電話機における着信の制御を主装置（SIPサーバに相当）の機能により行 う技術が特許文献 1、 2に開示されている。 特許文献 1 :特開 2003 - 283658号公報
特許文献 2：特開 2004 - 266437号公報
発明の開示
発明が解決しょうとする課題
[0007] 上述したように、従来の IP電話機は SIPサーバ上に各ラインの回線状態を通知する 回線状態通知手段が設けられ、標準の SIPメッセージに加えて独自メッセージまたは 独自手順を用いた通信によりマルチラインサービス機能を実現していたため、次のよ うな問題があった。
[0008] 第 1に、マルチラインサービス機能を実現するためには、 SIPサーバと IP電話機の 両方に開発が必要になり開発コストが増大する。
[0009] 第 2に、 SIPサーバからのメッセージ Z手順に独自のメッセージ Z手順が含まれる ため、マルチラインサービスに使用しない他の SIPユーザエージェントとの接続性が 低下する。
[0010] 第 3に、マルチラインサービスを使用したい利用者はマルチラインサービス機能を 有する SIPサーバの設置が必要である力 IP電話機の備える独自のメッセージ Z手 順に対応した SIPサーバが必要となるため、機器の選択肢が制限される。また、既に 所有する SIPサーバや安価な SIPサーバを用いることができないため、システム構築 費用も嵩む。
[0011] 第 4に、マルチラインサービス対応端末の増設撤去時には、マルチラインサービス を制御する SIPサーバにおいてもデータ変更工事が必要であるため、容易にサービ ス変更ができない。
[0012] 本発明は上記の従来の問題点に鑑み提案されたものであり、その目的とするところ は、 IP電話機等の電話装置間のみの独自メッセージ/手順にてマルチラインサービ スを実現し、 SIPサーバ等の接続管理サーバと電話装置との間に独自メッセージ/ 手順を用いず、標準的な接続プロトコルに従った接続管理サーバを用いることのでき る電話装置を提供することにある。
課題を解決するための手段
[0013] 上記の課題を解決するため、本発明にあっては、所定の通信プロトコルおよび接続 プロトコルにより通話を行う電話装置であって、マルチライングループを構成する他の 電話装置との間で、上記接続プロトコルと異なる独自のインタフェースにより回線状態 を相互に通知する手段を備えることを特徴とする。すなわち、マルチラインサービスを 制御するための独自のメッセージを電話装置間のみで送受信するようにすることで課 題の角決を図っている。
発明の効果
[0014] 本発明の電話装置にあっては、 IP電話機等の電話装置間のみの独自メッセージ/ 手順にてマルチラインサービスが実現可能となるため、 SIPに関連する RFC/インタ 一ネットドラフトのみをサポートする SIPサーバ（標準 SIPサーバ）等の接続管理サー バを用いてシステム構築ができる。
図面の簡単な説明
[0015] [図 1]従来の SIP上でのマルチラインサービスの概念図である。
[図 2]実現手段に着目した従来のシステム構成例を示す図である。
[図 3]IP電話機一台に着目した SIPユーザエージェントの構成例を示す図である。
[図 4]本発明における IP電話機への着信時の概念図である。
[図 5]本発明における IP電話機からの発信時の概念図である。
[図 6]本発明における IP電話機からの保留 ·保留応答時の概念図である。
[図 7]実現手段に着目した本発明のシステム構成例を示す図である。
[図 8]IP電話機一台に着目した SIPユーザエージェント内部の構成例を示す図であ る。
[図 9]IP電話機の機能ブロック図である。
[図 10]制御データの例を示す図である。
[図 11]制御データの具体例を示す図である。
[図 12]再開シーケンス例を示す図（その 1)である。
[図 13]再開シーケンス例を示す図（その 2)である。
[図 14]再開シーケンス例を示す図（その 3)である。
[図 15]マルチライングループからの離脱.参加のシーケンス例を示す図である。
[図 16]通知先最大数オーバによる受付拒否のシーケンス例を示す図である。 [図 17]参加認証のシーケンス例を示す図である。
園 18]着信シーケンス例を示す図である。
園 19]発信シーケンス例を示す図である。
[図 20A]回線保留 ·応答シーケンス例を示す図（その 1 )である
園 20B]回線保留 ·応答シーケンス例を示す図（その 2)である,
符号の説明
1 SIPサーバ
2 ネットワーク
ύ、 3a一 3c IP電話機
4 マルチライングループ
50 呼制御部
51 マルチライン制御部
52 RTP制御部
53 SIPプロトコル制御部
54 人出力インタフェース部
55 LANインタフェース部
56 データ管理部
60 端末管理データ
61 機能釦管理テーブル
62 機能釦状態管理テーブル
63 マルチライン管理テーブル
7 ノ ークサーバ
発明を実施するための最良の形態
[0017] 以下、本発明の好適な実施形態につき詳細に説明する。
[0018] く動作原理〉
図 4は本発明における IP電話機への着信時の概念図である。 SIPサーバ 1に LAN /WAN等のネットワーク 2を介して IP電話機 3a— 3cが接続され、 IP電話機 3a— 3c はマルチライングループ 4を構成しているものとする。ここで、 SIPサーバ 1から IP電話 機 3aに着信した時、独自メッセージにて IP電話機 3aが IP電話機 3bおよび IP電話機 3cに着信を通知することにより、マルチライン着信処理を実現している。
[0019] 図 5は本発明における IP電話機からの発信時の概念図である。 IP電話機 3bは IP 電話機 3aのプライムライン (ライン a)を使用して発信した時、独自メッセージにて、 IP 電話機 3aにライン aの使用を通知し、 IP電話機 3aはこれを IP電話機 3cに通知するこ とにより、マルチライン発信処理を実現している。
[0020] 図 6は本発明における IP電話機からの保留 ·保留応答時の概念図である。 IP電話 機 3bは通話中力も保留実施時、独自メッセージにて、 IP電話機 3aに保留中を通知 し、 IP電話機 3aは IP電話機 3cにこれを通知する。 IP電話機 3aの応答により、独自メ ッセージにて応答を通知することにて、保留応答処理を実現している。
[0021] このように、 SIPサーバ 1と IP電話機 3a 3c間に独自の手順/メッセージを含まず 、 IP電話機 3a 3c間にて独自手順を用レ、ることによって、課題を解決している。
[0022] ぐンステム構成〉
図 7は実現手段に着目した本発明のシステム構成例を示す図である。 SIPサーバ 1 は SIPに関連する RFC/インターネットドラフトのみをサポートする SIPサーバ（標準 SIPサーバ）により構成されるものであり、プライムラインを通常の回線として管理して おり、該回線がマルチラインを構成しているか否かは意識していなレ、。また、必要に 応じて、回線保留のためにパークサーバ 7が設けられる。一方、 IP電話機 3a— 3cに は、 自己のプライムラインの状態を通知する自回線状態通知手段と、回線状態の通 知を要求する他回線状態要求手段とが設けられている。
[0023] 図 8は IP電話機一台に着目した SIPユーザエージェント内部の構成例を示す図で ある。図は IP電話機 3aについて示してある力 各 IP電話機内部には、プライムライン の回線状態通知手段（自回線状態通知手段）と、ライン毎にァザーライン情報を得る ための回線状態要求手段 (他回線状態要求手段）とを有する。本例では、 IP電話機 内部において更にプライムラインについても回線状態要求手段を持つことにより、回 線状態要求手段の部品化を実現している。
[0024] 図 9は IP電話機の機能ブロック図である。 IP電話機 3 (3a— 3c)は、それぞれ呼制 御部 50、マルチライン制御部 51、 RTP (Real-time Transport Protocol)制御部 52、 SIPプロトコル制御部 53、入出力インタフェース部 54、 LANインタフェース部 55、デ ータ管理部 56を備えている。また、データ管理部 56には、図 10に示すように、制御 データとして端末管理データ 60、機能釦管理テーブル 61、機能釦状態管理テープ ノレ 62、マルチライン管理テーブル 63を備えている。
[0025] 制御データの登録処理としては、図 9において、ネットワーク経由もしくは IP電話機 の釦操作などにより発行されたコマンドデータは、 LANインタフェース部 55もしくは 入出力インタフェース部 54を介してデータ管理部 56に通知される。データ管理部 56 は端末管理データ 60、機能釦管理テーブル 61、マルチライン管理テーブル 63に、 入力されたデータを登録する。図 11はライン 3000登録時における IP電話機 3a、 3b 、 3cの各制御データの具体例を示している。本例において機能釦状態管理テープ ノレ 62はダイナミック制御データでありコマンドでの登録対象ではないため、図 11から は除いている。また、図 11において、マルチライン管理テーブル 63の自回線状態通 知先アドレス群は IP電話機 3b、 3cからの回線状態通知要求完了後の状態を示して いる。
[0026] く再開シーケンス〉
図 12—図 14は再開シーケンス例を示したものである。
[0027] 図 12—図 14において、 IP電話機 3aはライン 3000のプライム端末であり、 IP電話 機 3b、 3cにはライン 3000をァザーラインとしてコマンド等の手段にて予め登録して いる。
[0028] また、各図において自回線状態通知手段、他回線状態要求手段の具体的実現例 として SIMPLE (SIP for Instant Messaging and Presence Leveraging Extensions)で 定義されている、 SUBSCRIBE, NOTIFY, MESSAGEメソッドを用いている。 SI MPLEについては RFC3856を始めとする IETFのインターネット標準で示されて いる。
[0029] 図 12はァザーラインを収容する IP電話機 3bの再開シーケンスを示す。 IP電話機 3 bはダウン状態からの再開完了時 (ステップ S101)に他回線状態要求手段にて IP電 話機 3aに回線状態を問合わせる (ステップ S102、 S103)。問合せを受信した IP電 話機 3aは、自回線状態通知手段にて、ライン 3000の最新回線状態を通知する (ス テツプ S104、 S105)。このとき、ライン 3000の状態が変化したわけではないので、 回線状態通知は要求を行った IP電話機 3bに対してのみ実施される。
[0030] 図 13は通知先ダイナミック生成方式を備えたプライム端末である IP電話機 3aの再 開シーケンスを示す。 IP電話機 3aは再開発生時 (ステップ S111)においてライン 30 00の状態変化を通知すべきァザーライン情報を初期化する。一方、ァザーラインを 収容する IP電話機 3b、 3cでは他回線状態要求手段を定期的に実施し (ステップ SI 12、 SI 13、ステップ SI 17、 SI 18)、 IP電話機 3aでは要求元を状態通知先として認 識することで (ステップ S 114、ステップ S 119)、ライン 3000の状態通知先情報をリフ レッシュする機能を有する。このため、 IP電話機 3aの再開完了から一定時間経過後 には、 IP電話機 3aにおけるァザーライン情報が再構築される。ァザーラインからの自 発的参加方式であるため、プライム端末側からのマルチキャストやブロードキャストで の再開発生通知手段は必要なぐ従ってプライム端末とァザ一端末が異なるネットヮ ーク上に配置されていてもマルチラインサービスを提供することができる。
[0031] 図 14は通知先ダイナミック補正方式を備えたプライム端末である IP電話機 3aの再 開シーケンスを示す。 IP電話機 3aは自回線状態通知手段において状態変化通知に 必要な情報を不揮発性メモリ等の再開時に初期化されない情報として記憶する。図 1 4の例では SUBSCRIBE受信契機（ステップ S131、 S132、ステップ S136、 S137) にそのダイアログ情報を記憶しており（ステップ S 133、ステップ S 138)、 IP電話機 3a は、 IP電話機 3bおよび IP電話機 3cに対するダイアログ情報を記憶した状態で再開 している（ステップ S 141)。
[0032] IP電話機 3aは再開発生契機に記憶からリカバリ（ステップ S 142)したダイアログ情 報を元に回線状態通知を行い (ステップ S144、 S145)、各ァザーライン端末で記憶 している回線状態を速やかにプライム端末で管理している状態と同期させる。仮に IP 電話機 3cにおいても同時期に再開が発生し (ステップ S143)、 IP電話機 3aが記憶し ていたダイアログ情報が無効となってしまった場合には、 IP電話機 3cにおける他回 線状態要求手段は IP電話機 3aからの回線状態通知に対し NGを返送する (ステップ S148、 S149)。 NGを受信した IP電話機 3aは記憶しているダイアログ情報を更新（ 削除)し (ステップ S150)、以後 IP電話機 3cから新たな回線状態通知要求を受信す るまで回線状態通知を行わない。 IP電話機 3cから新たな回線状態通知要求を受信 した場合は（ステップ S151、 S152)、新しいダイアログを記憶し (ステップ S153)、回 線状態通知を行う（ステップ S 154、 S155)。
[0033] これにより、ネットワーク負荷軽減等の理由でリフレッシュ周期を長く設定していても
、状態アンマッチによる回線の二重使用などの問題発生を回避することができる。
[0034] 図 9の機能ブロックによる上記の再開シーケンスの動作は次のようになる。
[0035] ライン 3000をァザーラインとして収容する IP電話機 3bの再開時の処理を説明する 。再開完了時、マルチライン制御部 51は、データ管理部 56のマルチライン管理テー ブル 63に登録されている全宛先アドレスに対し、 SUBSCRIBEメッセージを生成し、 SIPプロトコル制御部 53、 LANインタフェース部 55を介して送出する。 SUBSCRIB Eメッセージは、ライン 3000のプライム端末である IP電話機 3aにおレ、て LANインタ フェース部 55を介して SIPプロトコル制御部 53、マルチライン制御部 51に通知され る。マルチライン制御部 51は、データ管理部 56のマルチライン管理テーブル 63を S UBSCRIBEメッセージの宛先アドレスで検索し、ライン 3000の自回線状態通知アド レス群に IP電話機 3bのアドレスを加え、 IP電話機 3bに対する NOTIFYメッセージを 生成し、 SIPプロトコル制御部 53、 LANインタフェース部 55を介して送出する。 NO TIFYメッセージには、データ管理部 56のマルチライン管理テーブル 63から得た釦 位置情報で機能釦状態管理テーブル 62を索引して得た該回線の現回線状態が記 述されている。 NOTIFYメッセージを受信した IP電話機 3bのマルチライン制御部 51 は、マルチライン管理テーブル 63をライン 3000で検索し、釦位置情報を抽出し、抽 出した釦位置情報にて機能釦状態管理テーブル 62を索引し、受信した回線状態を 設定する。
[0036] くマルチライングループからの離脱 '参加〉
図 15はマルチライングループからの離脱.参加のシーケンス例を示す図である。他 回線状態要求手段を持つ IP電話機 3bは、釦操作やコマンド投入等によりマルチライ ングノレープからの離脱、参加を要求する機能を有する。 自回線状態通知手段を持つ プライム端末である IP電話機 3aは、通知先端末である IP電話機 3bから離脱要求が あった場合 (ステップ S210 S212)、 IP電話機 3bに関する情報を抹消し (ステップ S213)、再び参加要求があった場合には（ステップ S218— S220)、 IP電話機 3bに 関する情報を再生成する（ステップ S221)。ここで、離脱要求手段は図 15の例では UNSUBSCRIBEメソッドにより実現してレ、る。
[0037] これにより、オペレータの一時離席や夜間担当者切替などのサービスを IP電話機 のみで実現することができる。
[0038] く通知先最大数オーバによる受付拒否〉
図 16は通知先最大数オーバによる受付拒否のシーケンス例を示す図である。 自回 線状態通知手段を持つプライム端末である IP電話機 3aには、通知先最大数 mがコ マンド等の手段により予め登録されている。他回線状態要求手段を持つ IP電話機 3b 群から要求があり（ステップ S301 309)、通知先最大数 mを超えた場合 (ステップ S 310)、 IP電話機 3aは NGを送信して受付を拒否する (ステップ S311)。これにより処 理能力に応じたシステム構成を維持することができる。
[0039] く参加認証〉
図 17は参加認証のシーケンス例を示す図である。 自回線状態通知手段を持つプ ライム端末である IP電話機 3aは、ライン aに関する認証情報をコマンド等の手段によ り予め認識してレ、る。他回線状態要求手段を持つ IP電話機 3bは回線状態要求時に おいてライン aに関する認証情報をプライム端末である IP電話機 3aに通知する (ステ ップ S401)。プライム端末である IP電話機 3aは IP電話機 3bから受信した認証情報 を精査し、正しい認証情報であると判断できた場合 (ステップ S402)に OKを送信し（ ステップ S403)、 自回線状態通知手段の通知先に加える。正しい認証情報を知らな い IP電話機 Xから回線状態要求があった場合は (ステップ S404)、正しい認証情報 であると判断されず（ステップ S405)、 NGを送信する（ステップ S406)。
[0040] このように、正しレ、認証情報を送信してきた端末のみ自回線状態通知手段の通知 先に加えることで、不正な端末がグループに参加することを防止することができる。
[0041] く着信シーケンス〉
図 18は着信シーケンス例を示したものである。 SIPサーバ 1から着信（ステップ S50 1)があったプライム端末である IP電話機 3aは、 INVITEリクエストを自回線状態通知 先に分岐し (ステップ S502)、さらに、同通知先に対して回線状態が「着信中」になつ たことを通知する（ステップ S503)。応答操作を行った IP電話機 3b、 3cは IP電話機 3 aに対して応答を要求する。 IP電話機 3aは複数の応答要求の中から応答端末を決 定し、 IP電話機 3bに対して「応答可」を返す (ステップ S 504)。また、 IP電話機 3aは 応答要求に応じられなかった IP電話機 3cに対しては「応答不可」を返す (ステップ S5 05)。
[0042] 「応答可」を受信した IP電話機 3bは IP電話機 3a宛に INVITEに対するレスポンス「
200 OK：」を返し、「200 OK：」を受信した IP電話機 3aは、 Contactヘッダに応答し た IP電話機 3bのアドレスを設定した「200 OK」レスポンスを SIPサーバ 1に対して 返す（ステップ S506)。これにより以後 SIPサーバ 1経由でライン aへ届く SIPメッセ一 ジはプライム端末である IP電話機 3aを経由せず直接に IP電話機 3bへ届くようになる
[0043] また、 IP電話機 3aは、他の IP電話機 3cに CANCELメソッド送出し、着信を停止さ せる（ステップ S507)。 「200 〇K」に対する ACKを SIPサーバ 1から受信した応答 端末の IP電話機 3bは、 IP電話機 3aに対して ACKを受信したことを通知する（ステツ プ S508)。 ACK受信を認識した IP電話機 3aは自回線状態通知先に対して回線状 態が「使用中」になったことを通知する（ステップ S509)。
[0044] 応答端末である IP電話機 3bは終話により SIPセッションが終了したらプライム端末 である IP電話機 3aに対して回線状態が「空き」になったことを通知する (ステップ S51 0、 S511)。回線状態が「空き」になったことを認識した IP電話機 3aは自回線状態通 知先に対して回線状態が「空き」になったことを通知する (ステップ S512)。
[0045] なお、図 18のステップ S502, S503において、分岐する自回線状態通知先にはプ ライム端末内の他回線状態要求手段を含み、プライム端末内部においてステップ S5 04, S505と同じメッセージのやり取りを行うことでプライム端末による応答操作を実 現する。
[0046] また、図 18のステップ S503において、各ァザーライン端末に対する「^^〇丁 丫」メ ッセージにリンガー鳴動方法を付与することにより、プライム端末から全ァザーライン 端末の鳴り分けを制御することができる。
[0047] 同様に、図 18のステップ S503において、各ァザーライン端末に対する「N〇TIFY 」メッセージにリンガー鳴動開始時間を付与することにより、例えばプライム端末のリン ガーを優先的に鳴動させ、応答が遅れる場合にァザーライン端末のリンガーが鳴動 し始めるような運用を可能とすることができる。
[0048] 同様に、図 18のステップ S502において、各ァザーライン端末に対する INVITEメ ッセージ送信タイミングを制御することにより、例えばプライム端末のリンガーを優先 的に鳴動させ、応答が遅れる場合にァザーライン端末のリンガーが鳴動し始めるよう な運用を可能とする。
[0049] 図 9の機能ブロックによる上記の着信シーケンスの動作は次のようになる。
[0050] ライン 3000への着信時における自回線状態通知手段としての動作を説明する。 SI Pサーバ 1からライン 3000への着信通知（INVITEリクエスト）は、 IP電話機 3aの LA Nインタフェース部 55を介して SIPプロトコル制御部 53、呼制御部 50に通知される。 呼制御部 50は、データ管理部 56の端末管理データ 60の自アドレスと INVITEリクェ ストメッセージの宛先アドレスを比較し、一致すれば、プライムライン釦位置を抽出し、 機能釦状態管理テーブル 62を索引し、回線状態が「空」であれば、「着信中」に変更 し、マルチライン制御部 51に対し INVITEリクエストメッセージを引き渡し、着信を通 知する。「空」以外であれば、「着信不可」を認識し、 SIPサーバ 1へその旨応答する。
[0051] 着信通知を受信したマルチライン制御部 51は、データ管理部 56のマルチライン管 理テーブル 63を INVITEリクエストメッセージの宛先アドレスで検索し、自回線状態 通知先アドレス群を取得し、 INVITEリクエストを分岐配信する。 INVITEリクエストは SIPプロトコル制御部 53、 LANインタフェース部 55を介して送出する。また、マルチ ライン制御部 51は前記自回線状態通知先アドレス群に対する NOTIFYメッセージを 生成し、 SIPプロトコル制御部 53、 LANインタフェース部 55を介して送出する。 NO TIFYメッセージには、データ管理部 56のマルチライン管理テーブル 63から得た釦 位置情報で機能釦状態管理テーブル 62を索引して得た該回線の回線状態として「 着信中」が記述されている。
[0052] ライン 3000への着信時における他回線状態要求手段としての動作を説明する。 IP 電話機 3aの自回線状態通知手段により送信された INVITEリクエストは、ライン 300 0のァザーライン端末である IP電話機 3b、 3cの LANインタフェース部 55を介して SI pプロトコル制御部 53、呼制御部 50に通知される。
[0053] 呼制御部 50は、データ管理部 56の端末管理データ 60の自アドレスと INVITEリク ェストメッセージの宛先アドレスを比較し、一致しないのでデータ管理部 56のマルチ ライン管理テーブル 63を INVITEリクエストメッセージの宛先アドレスで検索し、抽出 した釦位置情報でデータ管理部 56の機能釦状態管理テーブル 62を索引し、該当 回線状態を「着信中」に変更し、 INVITEリクエストに対して「180 Ringing」メッセ一 ジを返し、リンガーを鳴動させる。
[0054] なお、 INVITEリクエストを始めとする各 SIPメッセージは、 自回線状態通知先アド レス群に登録された宛先が自端末である場合、マルチライン制御部 51内部において 自回線状態通知手段から他回線状態要求手段へと引き渡され、プライム端末への着 信を実現する。
[0055] また、着信リンガーの鳴動方法や鳴動開始時間の着信制御が有効な場合には、 N OTIFYメッセージには機能釦管理テーブル 61を索引して得たリンガー制御情報や リンガー鳴動開始時間を制御付カ卩情報として記述し、「180 Ringing」メッセージの 返送時ではなぐ NOTIFYメッセージ受信を契機にリンガー鳴動制御を開始する。 なお、これらの着信制御を有効とするか否かは、コマンドなどの手段により設定する。
[0056] ライン 3000への着信に対し、該回線をァザーラインとして収容する IP電話機 3bか らの応答処理について説明する。この場合、応答操作は着信のあったァザーライン に対応する機能釦の押下によって行われ、釦位置情報とともに入出力インタフェース 部 54を介して、呼制御部 50に通知される。
[0057] 呼制御部 50は、通知された釦位置で機能釦状態管理テーブル 62を索引し、回線 状態が「着信中」であれば、「応答確認待ち」に変更し、マルチライン制御部 51に対し 応答要求送信を要求する。また、回線状態が「着信中」以外の場合は、該操作を無 効とする。
マルチライン制御部 51は、機能釦管理テーブル 61を索引し、釦位置情報からプライ ム端末のアドレス情報を抽出し、 MESSAGEを生成 (応答要求）し、 SIPプロトコル制 御部 53、 LANインタフェース部 55を介して送出する。
[0058] MESSAGE (応答要求）を受信した IP電話機 3aのマルチライン制御部 51は「200 OK」を返送後、呼制御部 50に対し「応答要求」を行う。呼制御部 50は、端末管理 データ 60からプライムライン釦位置を抽出し、機能釦状態管理テーブル 62を抽出釦 位置にて索引し、「着信中」であれば「使用中」に変更しマルチライン制御部 51に「応 答可」を通知する。また、既に「使用中」であれば「応答不可」を通知する。呼制御部 5 0から応答要求に対する結果通知を受けたマルチライン制御部 51は、結果を MESS AGEに乗せて応答要求元へ返送する。
[0059] また、マルチライン制御部 51は前記自回線状態通知先アドレス群に対する NOTI FYメッセージを生成し、 SIPプロトコル制御部 53、 LANインタフェース部 55を介して 送出する。 NOTIFYメッセージには、データ管理部 56のマルチライン管理テーブル 63から得た釦位置情報で機能釦状態管理テーブル 62を索引して得た該回線の回 線状態として「使用中」が記述されてレ、る。
[0060] MESSAGE (応答可）を受信した IP電話機 3bの呼制御部 50は「200 〇K」を返 送後、着番号でマルチライン管理テーブル 63を検索し、抽出した釦位置情報を呼制 御部 50に通知する。呼制御部 50は機能釦状態管理テーブル 62を釦位置情報にて 索引し、状態を「使用中」に変更する。
[0061] MESSAGE (応答可）に対する「200 OK：」を受信した IP電話機 3aのマルチライン 制御部 51はその旨を呼制御部 50に通知する。呼制御部 50は「応答可」を送出した 宛先アドレス（3100)を Contactに設定し、「200 〇K」を SIPサーバ 1に送出する。
[0062] 以後、 SIPサーバ 1および発信者からの SIPメッセージは IP電話機 3aを経ず、 Con tactで指定された IP電話機 3bに対して直接着信する。また、コネクション設定後は E nd to End (発信者と IP電話機 3bの間）で RTPパケットの送受信を行う。
[0063] 応答操作を行っていない IP電話機 3cのマルチライン制御部 51は NOTIFYメッセ ージを受信すると「200 OK」を返送後、送信元番号（3000)でマルチライン管理テ 一ブル 63を検索し、抽出した釦位置情報を呼制御部 50に通知する。呼制御部 50は 機能釦状態管理テーブル 62を釦位置情報にて索引し、回線状態として NOTIFYで 通知された状態（「使用中」）に変更する。また、 INVITEメソッドがキャンセルされた 時点でリンガーを停止する。
[0064] く発信シーケンス〉 図 19は発信シーケンス例を示したものである。 IP電話機 3aのプライムラインである ライン aでの発信操作を行った IP電話機 3bは、プライム端末である IP電話機 3aに対 して発信要求を行い、 IP電話機 3aは回線状態が「空き」であれば、発信要求元（この 例では IP電話機 3b)に対して「発信可」を返す (ステップ S601)。また、 IP電話機 3a は発信要求のあった回線状態が「空き」でなければ「発信不可」を返す (ステップ S60 2)。次いで、 IP電話機 3aは自回線状態通知先に対して回線が「使用中」になったこ とを通知する（ステップ S603)。 「発信可」を受信した IP電話機 3bは INVITEリクエス トの Fromヘッダに自アドレスではなくライン aのアドレスを、また Contactヘッダには 自アドレスを設定し、 SIPサーバ 1に対して INVITEリクエストを送信し、通話状態に 移行する（ステップ S604)。
[0065] なお、図 19において、プライム端末内部においてステップ S601、 S602と同じメッ セージのやり取りによって回線捕捉を行うことにより、プライム端末による発信操作を 実現する。
[0066] また、図 19のステップ S601において、各ァザーライン端末からの発信要求受信後 、発信可とみなすまでに一定のタイミングを取ることにより、例えばプライム端末とァザ 一ライン端末力 の同時発信操作時においてプライム端末からの発信を優先させる ような運用を可能とする。
[0067] 図 9の機能ブロックによる上記の発信シーケンスの動作は次のようになる。
[0068] ライン 3000を用いた、該回線をァザーラインとして収容する IP電話機 3bからの発 信処理を説明する。この場合、発信操作は発信に使用したいァザーラインに対応す る機能釦の押下によって行われ、釦位置情報とともに入出力インタフェース部 54を介 して、呼制御部 50に通知される。
[0069] 呼制御部 50は、通知された釦位置で機能釦状態管理テーブル 62を索引し、回線 状態が「空き」であれば、「発信確認待ち」に変更し、マルチライン制御部 51に対し発 信要求送信を要求する。また、回線状態が「空き」以外の場合は、該操作を無効とす る。
[0070] マルチライン制御部 51は、機能釦管理テーブル 61を索引し、釦位置情報からブラ ィム端末のアドレス情報を抽出し、 MESSAGEを生成（発信要求）し、 SIPプロトコル 制御部 53、 LANインタフェース部 55を介して送出する。
[0071] MESSAGE (発信要求）を受信した IP電話機 3aのマルチライン制御部 51は「200
OK」を返送後、呼制御部 50に対し「発信要求」を行う。呼制御部 50は、端末管理 データ 60からプライムライン釦位置を抽出し、機能釦状態管理テーブル 62を抽出釦 位置にて索引し、「空き」であれば「使用中」に変更し、マルチライン制御部 51に「発 信可」を通知する。また、既に「使用中」であれば「発信不可」を通知する。呼制御部 5 0から発信要求に対する結果通知を受けたマルチライン制御部 51は、結果を MESS AGEに乗せて発信要求元へ返送する。
[0072] また、マルチライン制御部 51は前記自回線状態通知先アドレス群に対する NOTI FYメッセージを生成し、 SIPプロトコル制御部 53、 LANインタフェース部 55を介して 送出する。 NOTIFYメッセージには、データ管理部 56のマルチライン管理テーブル 63から得た釦位置情報で機能釦状態管理テーブル 62を索引して得た該回線の回 線状態として「使用中」が記述されてレ、る。
[0073] MESSAGE (発信可）を受信した IP電話機 3bの呼制御部 50は「200 〇K」を返 送後、着番号でマルチライン管理テーブル 63を検索し、抽出した釦位置情報を呼制 御部 50に通知する。呼制御部 50は機能釦状態管理テーブル 62を釦位置情報にて 索引し、状態を「使用中」に変更し、 INVITEリクエストメッセージを生成し、 SIPプロト コル制御部 53、 LANインタフェース部 55を介して送出する。このとき、 INVITEリク ェストメッセージの From行には使用するラインのプライム端末である IP電話機 3aの アドレス（3000)を指定し、 Contactアドレスに自アドレス（3100)を指定し、以後の S IPサーバ 1および発信者からの SIPメッセージは IP電話機 3aを経ず、 Contactで指 定された IP電話機 3bが直接受信する。また、コネクション設定後は End to End ( 発信者と IP電話機 3bの間）で RTPパケットの送受信を行う。
[0074] 発信操作を行っていない IP電話機 3cのマルチライン制御部 51は NOTIFYメッセ ージを受信すると「200 OK」を返送後、送信元番号（3000)でマルチライン管理テ 一ブル 63を検索し、抽出した釦位置情報を呼制御部 50に通知する。呼制御部 50は 機能釦状態管理テーブル 62を釦位置情報にて索引し、回線状態として NOTIFYで 通知された状態（「使用中」）に変更する。 [0075] く回線保留'応答シーケンス〉
図 20Aおよび図 20Bは回線保留 ·応答シーケンス例を示す図である。回線保留 · 応答処理は、 SIPによる一般的なコールパークサービス処理にて実現する。通話中 の IP電話機 3bは回線保留操作時にコールパーク番号（「パーク番号」））を付与し、「 応答特番」 +「パーク番号」をダイヤルすることにより応答するサービスを実行する（ス テツプ S701、 S702)。コールパーク番号とは保留呼に対してシステム内で一意に付 与する番号であり、図 20Aおよび図 20Bでは保留対象となるライン番号を使用してい る。回線保留を行った IP電話機 3bはプライム端末である IP電話機 3aに対して、回線 を保留したことと「パーク番号」を通知する (ステップ S703)。 IP電話機 3aは自回線状 態通知先に対して「保留中」状態と「パーク番号」を通知する（ステップ S704)。回線 保留に対して応答操作を行った IP電話機 3cは IP電話機 3aに対して応答を要求する 。 IP電話機 3aは応答端末に対して「応答可」と「パーク番号」を返す (ステップ S705) 。また、 IP電話機 3aは自回線状態通知先に対して回線状態が「使用中」になったこと を通知する（ステップ S706)。 「応答可」を受信した IP電話機 3cは Toヘッダにコール パーク応答特番、 Fromヘッダに自アドレスではなくライン aのアドレスを設定し、 SIP サーバ 1に対して INVITEリクエストを送信する（ステップ S707、 S708)。
[0076] 図 9の機能ブロックによる上記の回線保留 ·応答シーケンスの動作は次のようになる
[0077] ライン 3000をァザーラインとして収容する IP電話機 3bがライン 3000を用いて通話 中状態にあるときの回線保留処理を説明する。この場合、回線保留操作は使用中の ァザーラインに対応する機能釦の押下によって行われ、釦位置情報とともに入出力ィ ンタフェース部 54を介して、呼制御部 50に通知される。
[0078] 呼制御部 50は、通知された釦位置で機能釦状態管理テーブル 62を索引し、回線 状態が「使用中」であれば、「保留要求中」に変更し、 SIPサーバ 1に対する re-INVI TEメッセージを生成し、 SIPプロトコル制御部 53、 LANインタフェース部 55を介して 送出する。
[0079] 続いて、 IP電話機 3bの呼制御部 50は端末管理データ 60からコールパーク実行特 番を抽出し、 INVITEメソッドにて SIPサーバ 1に通知する。 SIPサーバ 1は本 INVIT Eメソッド終了時に、 IP電話機 3b、並びに相手 SIPユーザエージェントを各々パーク サーバ 7に接続し、 IP電話機 3bと相手 SIPユーザエージェント間のコネクションを終 了させる。
[0080] パークサーバ 7と通話中状態となった IP電話機 3bの呼制御部 50はパークサーバ 7 に対し使用していたライン番号（3000)をパーク番号として通知するとともに、マルチ ライン制御部 51へ「パーク通知」を行う。マルチライン制御部 51は、ライン 3000のプ ライム端末である IP電話機 3aに対する MESSAGE (パーク通知）を生成し、 SIPプロ トコル制御部 53、 LANインタフェース部 55を介して送出する。
[0081] MESSAGE (パーク通知）を受信した IP電話機 3aのマルチライン制御部 51は「20 0 OK」を返送後、呼制御部 50に対し「パーク通知」を行う。呼制御部 50は、端末管 理データ 60からプライムライン釦位置を抽出し、機能釦状態管理テーブル 62を抽出 釦位置にて索引し、「使用中」であれば「保留中」に変更するとともに、受信したパー ク番号を機能釦状態管理テーブル 62に格納する。その後、マルチライン制御部 51 は前記自回線状態通知先アドレス群に対する NOTIFYメッセージを生成し、 SIPプ ロトコル制御部 53、 LANインタフェース部 55を介して送出する。 NOTIFYメッセージ には、データ管理部 56のマルチライン管理テーブル 63から得た釦位置情報で機能 釦状態管理テーブル 62を索引して得た該回線の回線状態として「保留中」が記述さ れている。
[0082] ライン 3000をァザーラインとして収容する IP電話機 3cが 3bによって回線保留され たライン 3000に対して応答する場合の処理を説明する。この場合、回線保留応答は 保留中のァザーラインに対応する機能釦の押下によって行われ、釦位置情報ととも に入出力インタフェース部 54を介して、呼制御部 50に通知される。
[0083] 呼制御部 50は、通知された釦位置で機能釦状態管理テーブル 62を索引し、回線 状態が「保留中」であれば、「保留応答確認待ち」に変更し、マルチライン制御部 51 に対し応答要求送信を要求する。また、回線状態が「保留中」以外の場合は、該操 作を無効とする。
[0084] マルチライン制御部 51は、機能釦管理テーブル 61を索引し、釦位置情報からブラ ィム端末のアドレス情報を抽出し、 MESSAGEを生成（応答要求）し、 SIPプロトコノレ 制御部 53、 LANインタフェース部 55を介して送出する。
[0085] MESSAGE (応答要求）を受信した IP電話機 3aのマルチライン制御部 51は「200
OK」を返送後、呼制御部 50に対し「応答要求」を行う。呼制御部 50は、端末管理 データ 60からプライムライン釦位置を抽出し、機能釦状態管理テーブル 62を抽出釦 位置にて索引し、「保留中」であれば「使用中」に変更し、マルチライン制御部 51に「 応答可」を通知する。また、既に「使用中」であれば「応答不可」を通知する。呼制御 部 50から応答要求に対する結果通知を受けたマルチライン制御部 51は、結果およ びパーク番号を MESSAGEに乗せて応答要求元へ返送する。また、マルチライン 制御部 51は前記自回線状態通知先アドレス群に対する NOTIFYメッセージを生成 し、 SIPプロトコル制御部 53、 LANインタフェース部 55を介して送出する。 NOTIFY メッセージには、データ管理部 56のマルチライン管理テーブル 63から得た釦位置情 報で機能釦状態管理テーブル 62を索引して得た該回線の回線状態として「使用中」 が記述されている。
[0086] MESSAGE (応答可）を受信した IP電話機 3cの呼制御部 50は「200 〇K」を返 送後、着番号でマルチライン管理テーブル 63を検索し、抽出した釦位置情報を呼制 御部 50に通知する。呼制御部 50は機能釦状態管理テーブル 62を釦位置情報にて 索引し、状態を「使用中」に変更する。続いて、 IP電話機 3cの呼制御部 50は端末管 理データ 60力らコールパーク応答特番を抽出し、 INVITEメソッドにて SIPサーバ 1 に通知する。 SIPサーバ 1は本 INVITEメソッドにより、 IP電話機 3cとパークサーバ 7 間のコネクションを形成する。
[0087] パークサーバ 7と通話中状態となった IP電話機 3cの呼制御部 50は MESSAGEで IP電話機 3aから通知された番号をパーク番号としてパークサーバ 7に通知する。
[0088] パーク番号を通知されたパークサーバ 7はパーク応答処理を実行し、 IP電話機 3c と相手 SIPユーザエージェント間のコネクションが設定される。
[0089] く一般的動作〉
IP電話機 3aの回線情報は、 IP電話機 3b、 3cにコマンド等の手段によって、あらか じめ登録されている。
[0090] IP電話機 3aに着信があった場合、 IP電話機 3b、 3cに登録されている IP電話機 3a の回線釦が着信中となるとともに、着信リンガーが鳴動する。 IP電話機 3bが IP電話 機 3aの回線釦押下により応答すると、 IP電話機 3b、 3cのリンガーが停止するとともに 、IP電話機 3a， 3cの IP電話機 3aの回線釦が使用中となる。リンガー鳴動開始時間 が設定されている場合は、タイムアウト後にリンガーが鳴動する。
[0091] 上記の動作において、 IP電話機 3bが IP電話機 3a回線釦押下と同時に、 IP電話機
3cが IP電話機 3aの回線釦を押下した場合、 IP電話機 3cは応答不可となり、ビジート ーンを聴取する。
[0092] IP電話機 3bが IP電話機 3aの回線釦押下にて発信した場合、 IP電話機 3a， 3cの I
P電話機 3aの回線釦が使用中となる。 IP電話機 3bが切断した場合、 IP釦電話 3a, 3 cの IP電話機 3aの釦が空となる。
[0093] 上記の動作において、 IP電話機 3bが IP電話機 3a回線釦押下にて発信と同時に、
IP電話機 3cが IP電話機 3a回線釦押下により発信した場合、発信不可となり、ビジー トーンを聴取する。
[0094] IP電話機 3aの通話中から IP電話機 3aの回線釦押下により、回線保留を行う。通話 相手端末は保留音を聴取する。 IP電話機 3a， 3b, 3cの IP電話機 3a回線釦が保留 中となる。 IP電話機 3bが IP電話機 3a回線釦押下により、保留されている相手端末と 通話中となる。 IP電話機 3a, 3b, 3cの IP電話機 3a回線釦が使用中となる。
[0095] く実施形態の効果〉
上述した実施形態には次のような効果がある。
[0096] 第 1に、 IP電話機等の電話装置間のみの独自メッセージ/手順にてマルチライン サービスが実現可能となるため、 SIPに関連する RFC/インターネットドラフトのみを サポートする SIPサーバ（標準 SIPサーバ）等の接続管理サーバを用いてシステム構 築ができる。また、標準 SIPサーバ等を用いることにより、マルチラインサービスで使 用する以外の SIPユーザエージェント等についてもサーバとの接続性を特に意識せ ず手配することができる。
[0097] 第 2に、電話装置間のみの独自メッセージ Z手順にてマルチラインサービスが実現 可能となるため、本発明の機能を反映させた電話装置をマルチラインサービス参加 台数分手配するのみで、既設の SIPシステム等を有する顧客や IPセントレックス等を 利用している顧客についてもマルチラインシステムを提供できる。また、マルチライン を組む電話装置は、ネットワークを跨っても接続できるため、複数の拠点間を結ぶマ ルチラインを容易に組むことが可能となる。
[0098] 第 3に、標準 SIPサーバ等が使用できるため、開発コスト並びに導入コストを軽減す ること力 Sできる。また、センター工事なしに端末側の設定のみでマルチラインを増設、 撤去できるため保守コストを軽減することができる。
[0099] 第 4に、 SIPサーバ等の開発が不要なため、実現するソフトウェア規模が小さくなる
[0100] 第 5に、接続管理サーバと電話装置の間のシーケンスがシンプルであるため、 WA N間のトラフィック負荷が削減できる。また、マルチライン制御処理をプライムライン収 容端末に分散させる方式であるため、接続管理サーバの能力に影響されることなくマ ルチラインの増設ができる。
[0101] 以上、本発明の好適な実施の形態により本発明を説明した。ここでは特定の具体 例を示して本発明を説明したが、特許請求の範囲に定義された本発明の広範な趣 旨および範囲から逸脱することなぐこれら具体例に様々な修正および変更を加える ことができることは明らかである。すなわち、具体例の詳細および添付の図面により本 発明が限定されるものと解釈してはならない。

Claims

請求の範囲
[1] 所定の通信プロトコルおよび接続プロトコルにより通話を行う電話装置であって、 マルチライングノレープを構成する他の電話装置との間で、上記接続プロトコルと異 なる独自のインタフェースにより回線状態を相互に通知する手段を備えたことを特徴 とする電話装置。
[2] 上記通信プロトコルはインターネットプロトコルであり、上記接続プロトコルはセッショ ンイニシエーションプロトコルであることを特徴とする請求項 1に記載の電話装置。
[3] 他の電話装置に自回線状態を通知する自回線状態通知手段と、
他の電話装置に回線状態の通知を要求する他回線状態要求手段とを備えたことを 特徴とする請求項 1に記載の電話装置。
[4] 上記自回線状態通知手段は、他の電話装置から自発的かつ定期的に回線状態通 知の要求があった場合に、 自回線状態を通知する通知先一覧をダイナミックに生成 もしくはリフレッシュを行うことを特徴とする請求項 1に記載の電話装置。
[5] 上記自回線状態通知手段は、 自回線状態を通知する通知先一覧をスタティックに 保持し、他の電話装置から自発的かつ定期的に回線状態通知の要求があった場合 にダイナミックに上記通知先一覧の補正を行うことを特徴とする請求項 1に記載の電 話装置。
[6] 上記他回線状態要求手段は、他の電話装置への回線状態通知要求の活性/非 活性を制御し、マルチライングループの構成を変更することを特徴とする請求項 1に 記載の電話装置。
[7] 上記自回線状態通知手段は、通知先数の上限値を保持し、上限値以上の回線状 態通知要求に対し通知不可とすることを特徴とする請求項 1に記載の電話装置。
[8] 上記他回線状態要求手段は、回線状態通知の要求時に他の電話装置との間で予 め取り決めた認証情報を通知し、
上記自回線状態通知手段は、他の電話装置からの回線状態通知の要求に含めら れた認証情報により正当な電話装置であることを認証することを特徴とする請求項 1 に記載の電話装置。
[9] 上記自回線状態通知手段は、接続管理サーバから着信要求を受信した際、回線 状態通知を要求した他の電話装置に対し着信要求を送信し、 自回線に対する着信 に対して他の電話装置からの応答を可能としたことを特徴とする請求項 1に記載の電 話装置。
[10] 上記自回線状態通知手段は、他の電話装置からの応答が 2つ以上あった場合、 1 つの電話装置に対してのみ応答可を通知することを特徴とする請求項 9に記載の電 話装置。
[11] 上記自回線状態通知手段は、他の電話装置が自回線を使った発信要求を受け付 けることを特徴とする請求項 1に記載の電話装置。
[12] 上記自回線状態通知手段は、他の電話装置から発信要求が 2つ以上あった場合、
1つの電話装置に対してのみ発信可を通知することを特徴とする請求項 11に記載の 電話装置。
[13] 上記自回線状態通知手段は、通話中からの保留操作により回線を保留状態にし、 回線状態通知を要求した他の電話装置に対し保留要求を送信し、他の電話装置か らの応答を可能としたことを特徴とする請求項 1に記載の電話装置。
[14] 上記自回線状態通知手段は、回線状態の通知先端末毎に着信リンガーの鳴動方 法を制御することを特徴とする請求項 1に記載の電話装置。
[15] 上記自回線状態通知手段は、回線状態の付加情報にリンガー鳴動開始時間を設 定し、通知先端末毎にリンガー鳴動開始時間を制御することを特徴とする請求項 1に 記載の電話装置。
[16] 上記自回線状態通知手段は、回線状態の通知先毎に着信通知タイミングを制御 することを特徴とする請求項 1に記載の電話装置。
[17] 上記自回線状態通知手段は、回線状態の通知先毎に発信可通知タイミングを制 御することを特徴とする請求項 1に記載の電話装置。
PCT/JP2005/005120 2005-03-22 2005-03-22 電話装置 WO2006100751A1 (ja)

Priority Applications (6)

Application Number Priority Date Filing Date Title
CN2005800492166A CN101167344B (zh) 2005-03-22 2005-03-22 电话装置
JP2007509105A JP4522449B2 (ja) 2005-03-22 2005-03-22 電話装置
KR1020077024281A KR100956925B1 (ko) 2005-03-22 2005-03-22 전화 장치
PCT/JP2005/005120 WO2006100751A1 (ja) 2005-03-22 2005-03-22 電話装置
EP05727037A EP1863265A4 (en) 2005-03-22 2005-03-22 TELEPHONE APPARATUS
US11/858,248 US20080049724A1 (en) 2005-03-22 2007-09-20 Telephone apparatus

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2005/005120 WO2006100751A1 (ja) 2005-03-22 2005-03-22 電話装置

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US11/858,248 Continuation US20080049724A1 (en) 2005-03-22 2007-09-20 Telephone apparatus

Publications (1)

Publication Number Publication Date
WO2006100751A1 true WO2006100751A1 (ja) 2006-09-28

Family

ID=37023448

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2005/005120 WO2006100751A1 (ja) 2005-03-22 2005-03-22 電話装置

Country Status (6)

Country Link
US (1) US20080049724A1 (ja)
EP (1) EP1863265A4 (ja)
JP (1) JP4522449B2 (ja)
KR (1) KR100956925B1 (ja)
CN (1) CN101167344B (ja)
WO (1) WO2006100751A1 (ja)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2008048180A (ja) * 2006-08-17 2008-02-28 Nec Engineering Ltd ＳＩＰベースの交換機並びにＶｏＩＰシステムの制御方法及び制御プログラム
JP2014135671A (ja) * 2013-01-11 2014-07-24 Nakayo Telecommun Inc 電話端末および電話システムのラインキー制御方法
JP2016158178A (ja) * 2015-02-25 2016-09-01 株式会社ナカヨ Ｉｐ電話端末、プログラム、および外線状態共有方法

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8144693B1 (en) * 2005-09-22 2012-03-27 Verizon Services Organization Inc. Method and system for providing telemetry, verification and/or other access in a SIP-based network
WO2007126029A1 (ja) * 2006-04-27 2007-11-08 Kyocera Corporation 携帯電話端末、サーバ及びグループ通話システム
US20100080217A1 (en) * 2008-09-26 2010-04-01 Kabushiki Kaisha Toshiba Sip Telephone System and Method for Controlling Line Key Display
US8787362B2 (en) * 2009-04-01 2014-07-22 Qualcomm Incorporated Fall back using mobile device assisted terminating access domain selection
FR2998123A1 (fr) * 2012-11-13 2014-05-16 France Telecom Selection de periodes de rafraichissement dans un reseau ip

Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPS6074796A (ja) * 1983-09-30 1985-04-27 Nec Corp 分散型多機能電話機マルチライン制御方式
JPH01255395A (ja) * 1988-04-05 1989-10-12 Nec Corp 内線呼び出し方式
JPH03145299A (ja) * 1989-10-31 1991-06-20 Matsushita Electric Ind Co Ltd ボタン電話装置
JPH04165723A (ja) * 1990-10-29 1992-06-11 Taiko Denki Seisakusho:Kk コードレスボタン電話装置
JPH04352551A (ja) * 1991-05-30 1992-12-07 Nec Corp 電子式自動構内交換機の着信音送出方式
JPH11275619A (ja) * 1998-03-19 1999-10-08 Nec Eng Ltd ボタン電話装置
JP2003283658A (ja) 2002-03-26 2003-10-03 Tamura Electric Works Ltd ボタン電話装置およびプログラム
US6765902B1 (en) 1999-08-27 2004-07-20 Cisco Technology, Inc. Method and apparatus for network-based telephone communication without a separate call manager unit
JP2004266437A (ja) 2003-02-28 2004-09-24 Saxa Inc ボタン電話システム、ボタン電話装置およびプログラム

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6967972B1 (en) * 1997-07-31 2005-11-22 Cisco Technology, Inc. Universal protocol conversion
IL121501A (en) * 1997-08-08 2003-04-10 Icq Inc Telephone-status notification system
CA2274205A1 (en) * 1999-06-11 2000-12-11 Nortel Networks Corporation Method and apparatus for providing interoperability between remote key system units
JP3887548B2 (ja) * 2001-07-13 2007-02-28 サクサ株式会社 ＶｏＩＰ電話システム、ＶｏＩＰ電話システム用電話通信管理装置および電話端末
US20030215080A1 (en) * 2002-05-17 2003-11-20 Wengrovitz Michael S. Presence-aware private branch exchange (PBX)
US7706359B2 (en) * 2002-07-01 2010-04-27 Converged Data Solutions, Inc. Systems and methods for voice and data communications including a network drop and insert interface for an external data routing resource
JP2004088513A (ja) * 2002-08-27 2004-03-18 Nec Corp 同報配信システムおよび同報配信方法
KR100475187B1 (ko) * 2002-12-13 2005-03-10 삼성전자주식회사 접속 설정 프로토콜 방식을 지원하는 키폰 시스템 및 그호 설정 방법
JP4017592B2 (ja) * 2003-12-25 2007-12-05 三洋電機株式会社 ＶｏＩＰシステム及びＶｏＩＰ電話機
US20050141479A1 (en) * 2003-12-31 2005-06-30 Timucin Ozugur Presence-based routing in a communications network environment
KR100693040B1 (ko) * 2004-10-11 2007-03-12 삼성전자주식회사 통신 단말 시스템, 및 그 시스템의 무선 단말 상태 표시방법
JP2006180104A (ja) * 2004-12-21 2006-07-06 Oki Techno Creation:Kk Ｉｐ−ｐｂｘ装置

Patent Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPS6074796A (ja) * 1983-09-30 1985-04-27 Nec Corp 分散型多機能電話機マルチライン制御方式
JPH01255395A (ja) * 1988-04-05 1989-10-12 Nec Corp 内線呼び出し方式
JPH03145299A (ja) * 1989-10-31 1991-06-20 Matsushita Electric Ind Co Ltd ボタン電話装置
JPH04165723A (ja) * 1990-10-29 1992-06-11 Taiko Denki Seisakusho:Kk コードレスボタン電話装置
JPH04352551A (ja) * 1991-05-30 1992-12-07 Nec Corp 電子式自動構内交換機の着信音送出方式
JPH11275619A (ja) * 1998-03-19 1999-10-08 Nec Eng Ltd ボタン電話装置
US6765902B1 (en) 1999-08-27 2004-07-20 Cisco Technology, Inc. Method and apparatus for network-based telephone communication without a separate call manager unit
JP2003283658A (ja) 2002-03-26 2003-10-03 Tamura Electric Works Ltd ボタン電話装置およびプログラム
JP2004266437A (ja) 2003-02-28 2004-09-24 Saxa Inc ボタン電話システム、ボタン電話装置およびプログラム

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
"Industrial-Strength P2P SIP; draft-matthews-sipping-p2p-indusrtial-strength-OO.txt", MATTHEWS NIMCAT NETWORKS B POUSTCHI NIMCAT NETWORKS P, vol. 16-3.200
JOINT COLLABORATIVE TEAM ON VIDEO CODING OF ISO/IEC JTC1/SC29/WG11 AND ITU-T SG.16, 11 February 2005 (2005-02-11), ISSN: 0000-0004, Retrieved from the Internet <URL:HTTP://WFTP3.ITU.INT/AV-ARCH/JC TVC-SITE>
See also references of EP1863265A4

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2008048180A (ja) * 2006-08-17 2008-02-28 Nec Engineering Ltd ＳＩＰベースの交換機並びにＶｏＩＰシステムの制御方法及び制御プログラム
JP2014135671A (ja) * 2013-01-11 2014-07-24 Nakayo Telecommun Inc 電話端末および電話システムのラインキー制御方法
JP2016158178A (ja) * 2015-02-25 2016-09-01 株式会社ナカヨ Ｉｐ電話端末、プログラム、および外線状態共有方法

Also Published As

Publication number Publication date
US20080049724A1 (en) 2008-02-28
JPWO2006100751A1 (ja) 2008-08-28
EP1863265A1 (en) 2007-12-05
KR100956925B1 (ko) 2010-05-11
CN101167344B (zh) 2010-09-29
KR20070114830A (ko) 2007-12-04
CN101167344A (zh) 2008-04-23
JP4522449B2 (ja) 2010-08-11
EP1863265A4 (en) 2012-01-04

Similar Documents

Publication Publication Date Title
JP4522449B2 (ja) 電話装置
CA2581203C (en) System and method for bridge call appearance in distributed peer-to-peer network
JP2001186240A (ja) 通話者情報表示方式及び記録媒体
JP2005136993A (ja) 使用者移動性を支援するマルチメディアメールボックスのサービス提供方法
JP2006191608A (ja) 移動通信端末機を用いたモバイルインスタントメッセンジャーサービスシステム及びモバイルインスタントメッセンジャーサービスの提供方法
JP2006094369A (ja) メッセージ自動通知システムとその方法、及び、通信端末装置とそのプログラム
US6603965B1 (en) Pervasive voice handset system
CN100481769C (zh) 字符/数据发送/接收系统、终端管理装置及其方法
WO2006048925A1 (ja) 通信中継方法、通信中継プログラムおよび通信中継装置
JP2008067083A (ja) グループ通話制御システム、グループ通話制御方法および移動通信端末
WO2021235149A1 (ja) 中継装置、通信システム、中継方法及びプログラム
JP2004242090A (ja) Ｉｐ電話システムの代理応答制御方法
JP4175940B2 (ja) ＶｏＩＰ電話システムおよびＶｏＩＰ電話システムにおける通信制御方法
JP2011097469A (ja) 電話システムとその交換装置
US8630254B2 (en) Telephone line switching apparatus, telephone line switching system, telephone relay system, telephone relay method, telephone relay program
JP2007150841A (ja) 電話交換システム及び電話交換方法及び電話交換プログラム
JP5311479B2 (ja) Ｓｉｐ対応交換装置、及びこれを用いたｓｉｐ対応交換システム
JP2003283653A (ja) インターネット電話装置及びプログラム
JP5182297B2 (ja) 通信中継方法、通信中継プログラムおよび通信中継装置
JP4472390B2 (ja) 会議電話システム，接続方法，電話交換機およびプログラム
JP2003309651A (ja) 公衆回線網を利用したインターネット通信システム、及びインターネット通信の接続方法、及び接続装置
JPWO2003073714A1 (ja) ネットワーク電話システム
JP2001313671A (ja) ネットワーク通話システム
JP2010239387A (ja) 留守番電話装置、及び、接続方法
JP5447591B2 (ja) 通信中継方法、通信中継プログラムおよび通信中継装置

Legal Events

Date Code Title Description
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: 2007509105

Country of ref document: JP

WWE Wipo information: entry into national phase

Ref document number: 2005727037

Country of ref document: EP

Ref document number: 11858248

Country of ref document: US

WWE Wipo information: entry into national phase

Ref document number: 200580049216.6

Country of ref document: CN

NENP Non-entry into the national phase

Ref country code: DE

NENP Non-entry into the national phase

Ref country code: RU

WWE Wipo information: entry into national phase

Ref document number: 1020077024281

Country of ref document: KR

WWW Wipo information: withdrawn in national office

Ref document number: RU

WWP Wipo information: published in national office

Ref document number: 2005727037

Country of ref document: EP

WWP Wipo information: published in national office

Ref document number: 11858248

Country of ref document: US