Source: https://patents.google.com/patent/US8737385B2/en
Timestamp: 2020-01-26 17:25:05
Document Index: 175007914

Matched Legal Cases: ['arty 155', 'arty 155', 'arty 155', 'arty 155', 'arty 155', 'arty 155', 'arty 155', 'arty 155', 'arty 155']

US8737385B2 - PBX call management - Google Patents
US8737385B2
US8737385B2 US13/045,199 US201113045199A US8737385B2 US 8737385 B2 US8737385 B2 US 8737385B2 US 201113045199 A US201113045199 A US 201113045199A US 8737385 B2 US8737385 B2 US 8737385B2
US13/045,199
US20110164744A1 (en
2011-03-10 Application filed by Verizon Data Services LLC filed Critical Verizon Data Services LLC
2011-03-10 Priority to US13/045,199 priority patent/US8737385B2/en
2011-07-07 Publication of US20110164744A1 publication Critical patent/US20110164744A1/en
2014-05-27 Publication of US8737385B2 publication Critical patent/US8737385B2/en
2014-07-03 Assigned to VERIZON DATA SERVICES INC. reassignment VERIZON DATA SERVICES INC. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: CHANG, SUJIN C, FLYNN, JAMES, LIAO, ROBERT H, MITSUMORI, DEREK, OLSHANSKY, ROBERT, SPOREL, ERIC R
This application is a continuation of U.S. patent application Ser. No. 11/240,599, filed on Oct. 3, 2005, the contents of which are hereby incorporated by reference in its entirety.
Presently, to enable external access of a PBX for the purpose of providing call management functionality such as that described above, it is necessary to couple a gateway server to the PBX. The gateway server may communicate with the PBX using known telecommunications services such as a Primary-Rate ISDN interface (PRI). The gateway server may in turn communicate with an application server using Session Initiation Protocol (SIP), Voice over Internet Protocol (VoIP), or some other known protocol. SIP is fully discussed in J. Rosenberg et at, RFC 3261, “SIP: Session Initiation Protocol,” June 2002, published by the Internet Society of Reston, Virginia, presently available on the World Wide Web (e.g., via the faqs.org web site), and fully incorporated herein by reference in its entirety.
Telecommunications network 125 represents one or more known networks over which telecommunications services such as telephony may be provided, e.g., the PSTN for circuit-switched calls, a cellular telephone network, the Internet or some other IP network for VoIP communications, etc. In some embodiments, networks 125 and 140 will in fact be the same network, e.g., a packet-switched network such as the Internet, whereas in other embodiments, such as the embodiment represented in FIG. 1, networks 125 and 140 will be different networks, e.g., network 125 may be the PSTN and network 140 may be the Internet. Further, FIG. 1 shows network 125 connected to 140, but those skilled in the art will recognize that different kinds of networks 125 and 140 may require various known types of bridges or interfaces between them.
A calling party 155 may place a call accessing a network 125 and/or 140 in a variety of different ways known to those skilled in the art. For example, calling party 155 may use a PSTN phone via a Plain Old Telephone Service (POTS) line, a Primary Rate Interface (PRI) line, a SIP line, or a line using the International Telecommunications Union's H.323 standard for packet-based multimedia communications systems. Further, a calling party 155 may use an extension 115 on PBX 110, including local and/or tie line digital, analog, or IP telephone extensions 115.
A second model according to which proxy 134 may handle calls received in PBX 110 is referred to as the Call Forwarding Override (CFO) model, or the Redirect model. Under the CFO model, the proxy 134 redirects calls according to inputs received from a user 120 via a client 150. Once establishment of a call connection has been completed, i.e., forwarded to the destination selected by the user 120, the proxy 134 removes itself from the call flow, i.e., drops out of the call The CFO model thus advantageously alleviates the consumption of resources of such as SIP resources for the entire duration of a call, although those skilled in the art will recognize that it will be necessary, under the CFO model, for PBX 110 to send messages, e.g., SIP NOTIFY messages, to proxy 134 regarding call state changes.
Following step 210, control proceeds to step 215. In step 215, call management server 130, e.g., in some embodiments, application server 136, determines the rule or rules that apply for handling calls to the extension 115 for which a call was received in step 205. Specific call handling rules implemented in various embodiments are discussed in more detail below. In general, the call handling rule or rules determined in step 215 specify a location, e.g., a second telephone number, Uniform Resource Indicator (URI), etc, to which the call received in step 215 should be forwarded.
Following step 215, control proceeds to step 220. In step 220, call management server 130 selectively redirects the call received in step 205, i.e., call management server 130 takes action with respect to the call according to the call handling rule or rules identified in step 215. In some embodiments, not shown in FIG. 2, the process 200 ends following step 220. Further, in some embodiments, step 220 is skipped altogether, or occurs after one of steps 225 or 230, and in either case control proceeds directly from step 215 to step 225. However, in some embodiments, control proceeds to step 225 following step 220
In step 225, one or more users 120 is notified of the call received in step 205. This notification may take one or more different forms in various embodiments, some of which are described in more detail below For example, a pop-up window with information relating to the call may be displayed within an interface of a client 150. Such a pop-up widow may present the user 120 with various choices regarding a call, such as forward to voice-mail, forward to a specified extension 115, forward to another telephone number, do not disturb, etc. Further, call management server 130 may send, or may cause to be sent, a message such as an e-mail, page, SMS message, etc., to client 150. In some embodiments, not shown in FIG. 2, the process 200 ends following step 225. However, in some embodiments, following step 225, control proceeds to step 230.
In step 230, the call received in step 205 is selectively redirected according to one more inputs provided by a user 120 via a client 150. In many embodiments, the user 120 is presented with a list of one or more options that may be selected regarding a call in an interface such as a GUI on client 120, and selects one or more of the options through the interface. For example, as described in more detail below, a user 120 may choose to forward a call to voice mail, forward a call to another telephone number, etc. In some embodiments, the process waits for user 120 input for a predetermined period of time (e g., 18 seconds in one embodiment) and, if such input is not received within the predetermined period of time, redirects the call according to specified rules. Following step 230, the process 200 ends.
a Call Notification
FIG. 3 is a call flow diagram for a call handled under the 3PCC model, where call handling rules provide for user 120 to receive real time notification of a call via a client 150, according to an embodiment. As shown in FIG. 3, a call request from a calling party 155 directed to a called party (user 120) associated with a called extension 115 is received at PBX 110. PBX 110, upon receiving the call request, sends a SIP INVITE message to proxy 134 of call management server 130. As noted above, this INVITE message may include an indication of the called extension 115. PBX 110 may also provide a ring signal to the calling party 155 to indicate that the call request is proceeding. The ring signal may be delayed until the processing illustrated in FIG. 3 has been completed, but to avoid confusion for calling parties may be provided after a maximum delay period (“MAX_PDD” on FIG. 3), for example, 3 seconds
In the embodiment illustrated by FIG. 3, application server 136 concurrently sends a response message to proxy 134 indicating that the call should be routed as indicated. Proxy 134 in turn sends a SIP INVITE message to PBX 110, indicating that the PBX should attempt to connect the call as indicated. PBX 110 then attempts to connect the call to the called extension 115 of the called party, i.e., user 120, using a signaling method appropriate to the connection (e.g., Q.931, SIP, H.323, SS7, etc). Upon answer at called extension 115, the PBX 110 connects the call between the calling party and called party, and indicates to the proxy 134 (e.g., using a SIP OK message) that the call has been established.
FIG. 4 is a call flow diagram for a call handled under the 3PCC model, where call handling rules provide for user 120 to receive real time notification of a call via a client 150, and to make a real time selection to route the call to a predetermined (i.e., default) telephone number, according to an embodiment. The initial steps of the embodiment of FIG. 4 are similar to those of FIG. 3. PBX 110 receives a call request from calling party 155 to a called extension 115, PBX 110 sends a SIP INVITE message to proxy 134, proxy 134 sends a service request message to application server 136, and application server 136 causes a pop-up window to be displayed on a client 150 associated with the called party. In contrast to FIG. 3, in FIG. 4 it can be seen that, once a pop-up window is displayed on client 150, application server 136 and proxy 134 take no action until application server 136 receives a selection from user 120 via client 150 to route the call to the predetermined telephone number (which, in this example, is the called extension 115). The user 120 has a predetermined amount of time to make a selection in the pop-up window, and if a selection is not made within the predetermined period of time (e g., eighteen seconds in some embodiments), PBX 110 may be configured to take some default action, e.g., route to voice mail, forward the call, etc. During the period between receipt of the call request from the calling party 155 and the selection by the user 120, the PBX 110 may simply send a ring signal calling party 155.
FIG. 5 is a call flow diagram for a call handled under the 3PCC model, where call handling rules provide for user 120 to receive real time notification of a call via a client 150, and to make a real time selection as to an address (e.g, a telephone number) to which the call should be sent, according to an embodiment. The initial steps of the embodiment illustrated in are the same as those of FIGS. 3 and 4. Upon causing the pop-up window to be displayed on client 150, application server 136 waits for a response from user 120 via client 150 indicating an address to which the call should be sent. This may be achieved by providing the user 120 with various selectable objects in the pop-up window (e.g., links, pull-down menus, etc.) or by allowing the user to free-form enter an address. Identifiers for various addresses (e.g., “home,” “mobile,” “Mom,” etc) may be provided, which may be interpreted by application server 136 to identify the corresponding network address. The application server 136 then sends a response message to proxy 134 indicating the selected address for forwarding, and proxy 134 sends a message, e.g., a SIP INVITE message, to PBX 110 indicating the selected address. PBX 110 then attempts to connect the call to the selected address instead of the called extension 115 using an appropriate signaling method for the selected address, and the call is established in a manner similar to FIGS. 3 and 4.
FIG. 6 is a call flow diagram for a call handled under the 3PCC model, where call handling rules provide for a user 120 to receive real time notification of a call via a client 150, and to make a real time selection to forward the call to a voice mail account, according to an embodiment. In this embodiment, a call may be sent to voice mail either upon the selection of a user 120 via a client 150, or by default, Thus, in this embodiment, even if client 150 is turned off or for some reason is unable to receive messages from application server 136, a call may be sent to voicemail even if the user 120 is unable to answer or otherwise respond to the call.
FIG. 7 is a call flow diagram for a call handled under the 3PCC model, where call handling rules provide for user 120 to receive real time notification of a call via a client 150, and for a call to be forwarded according to find me follow me (FMFM) rules, according to an embodiment. FMFM, as is known to those skilled in the art, comprises a set of rules for forwarding a call so that a call may be answered by the particular user 120 at a variety of different telephone numbers, including different extensions 115. The initial steps of the embodiment of FIG. 7 are the same as those for FIGS. 3-6. Furthermore, similar to the embodiment of FIG. 6, after the application server 136 causes the pop-up window to be displayed on client 150, it sends a response message to proxy 134 indicating that the call should be connected to the called extension 115, which then sends a message to PBX 110 indicating that the call should be connected to called extension 115. PBX 110 attempts to connect the call to called extension 115 using an appropriate signaling method.
NOTIFY messages as shown in FIG. 8 and others of the drawing figures herein are described in R. Sparks, RFC 3515—The Session Initiation Protocol (SIP) Refer Method, April 2003, published by the Internet Society of Reston, Va., and available on the World Wide Web, fully incorporated herein by reference. RFC 3515 describes the REFER method of transferring calls. NOTIFY messages provide updates to the current state of the pending transfer request, (100 Trying) indicating the PBX is attempting to establish a connection and the 200 OK that it was successful. It is to be understood that all of the signaling examples provided herein are based on an abbreviated format and do not reflect all the messages that occur during call setup as defined in RFC 3261, incorporated herein by reference above and other corresponding RFCs such as RFC 3515. FIG. 8 is also a logical representation of a call state and does not reflect exact time-referenced messages. For example, the Ringing and Answer messages from PBX 110. to Calling Party 155 may actually occur after the 200 OK (1) from Proxy 134 to PBX 110
If there is no answer to the call, the PBX 110 applies normal call coverage routing options known to those skilled in the art, e.g., overflow to voicemail or any of the valid PBX 110 processing options for dealing with a no answer scenario. In the case of overflow to voicemail, the PBX 110 will still send a CANCEL message to proxy 134 to terminate the pending INVITE transaction with proxy 134 also sending a “<serviceUpdate> Result=NoAnswer” message.
FIG. 16 is a call flow diagram for a call handled under the SimRing model, where call handling rules provide for user 120 to receive real time notification of a call via a client 150, and for a call to be forwarded according to find me follow me (FMFM) rules, according to an embodiment, Unlike other actions taken under the SimRing model, call forwarding according to FMFM does not require call forwarding taking place simultaneous with attempting to connect to a called extension 115. If a user 120 is at or near the called extension 115, ringing other extensions 115 and/or other addresses will not be advantageous Instead, once a timeout period has elapsed, proxy 134 sends an INVITE message to PBX 110, which rings an extension or telephone number from a list of FMFM numbers associated with the user 120 of the extension 115.
The initial steps of the embodiment of FIG. 16 are the same as those for other described embodiments. Furthermore, the steps of the embodiment of FIG. 16 are similar to the embodiment of FIG. 7. In this embodiment, contemporaneously with sending the SIP INVITE message to proxy 134, PBX 110 attempts to connect the call to called extension 115 using an appropriate signaling method. Application server 136 sends a message to proxy 134 indicating that the proxy 134 should perform a find me/follow me operation. Proxy 134 sets a timeout period for the find me/follow me operation. If proxy 134 receives no indication from PBX 110 that the call attempt to called extension 115 has connected before the end of the timeout period, proxy 134 sends a message to application server 136 that no connection has occurred.
an application server configured to provide call management services to a plurality of users of a private branch exchange (PBX), the PBX receiving an incoming call request to an extension of at least one of the plurality of users; and
a protocol proxy in selective communication with the PBX and the application server, the protocol proxy configured to receive the incoming call request forwarded from the PBX and send the incoming call request to the application server, the incoming call request being received according to a protocol for establishing call sessions;
wherein the application server is further configured to receive the incoming call request from the protocol proxy and send at least one call routing instruction to the protocol proxy in response to receiving the incoming call request, said at least one call routing instruction configured to instruct the PBX with respect to disposition of the incoming call.
2. The system of claim 1, wherein the at least one call routing instruction is based on at least one input from at least one client device.
3. The system of claim 2, the at least one client device including a graphical user interface (GUI) configured to display information concerning the incoming call request.
4. The system of claim 3, wherein the GUI is further configured to present a plurality of options regarding the incoming call request, the plurality of options including at least one of: (i) forward the incoming call request to voice mail; (ii) forward the incoming call request to another extension of the PBX; (iii) forward the incoming call request to another telephone number; and (iv) do not disturb.
5. The system of claim 1, wherein the at least one call routing instruction is based on information retrieved from a database configured to store the at least one call routing instruction associated with at least one of the plurality of users.
6. The system of claim 1, wherein the at least one call routing instruction is an instruction for at least one of forwarding the incoming call request to voicemail and forwarding the incoming call request to a specified telephone number.
11. The system of claim 1, wherein the application server is external to the PBX.
12. The system of claim 1, wherein the protocol proxy is configured to manage an incoming call to the at least one user according to a model selected from one of the following:
(3) a simultaneous ring model, wherein the PBX sends information relating to the incoming call to the protocol proxy and at the same time attempts to connect the incoming call to an extension on the PBX.
receiving an incoming call request in a private branch exchange (PBX) and directed to an extension of the PBX;
sending, from the PBX, to a protocol proxy in selective communication with the PBX and an application server providing call management services to a plurality of users of the PBX, information relating to the incoming call request according to a protocol for establishing call sessions;
sending the information relating to the incoming call request from the protocol proxy to the application server configured to provide enhanced call management services to users receiving incoming calls; and
receiving, by the protocol proxy from the application server, at least one call routing instruction in response to receiving the information relating to the incoming call request, the at least one call routing instruction configured to instruct the PBX with respect to disposition of the incoming call.
14. The method of claim 13, wherein the at least one call routing instruction is based on input from at least one client device.
15. The method of claim 14, the at least one client device including a graphical user interface (GUI), and further comprising displaying information concerning the incoming call request in the GUI.
16. The method of claim 15, further comprising presenting a plurality of options regarding the incoming call request in the GUI, the plurality of options including at least one of: (i) forward the incoming call request to voice mail; (ii) forward the incoming call request to another extension of the PBX; (iii) forward the incoming call request to another telephone number; and (iv) do not disturb.
17. The method of claim 13, further comprising retrieving the at least one call routing instruction from a database storing the at least one call routing instruction associated with at least one user.
18. The method of claim 13, wherein the at least one call routing instruction is an instruction for at least one of forwarding the incoming call to voicemail and forwarding the incoming call to a specified telephone number.
19. The method of claim 13, wherein the protocol includes Session Initiation Protocol (SIP).
20. The method of claim 13, further comprising the application server receiving call information from at least one of a public switched telephone network (PSTN), a cellular phone network, and a Voice over Internet Protocol (VoIP) network.
21. The method of claim 13, further comprising managing the incoming call in the protocol proxy according to a model selected from one of the following:
an application server configured to provide call management services to a plurality of users of a private branch exchange (PBX), the PBX receiving an incoming call request to an extension of one of the plurality of users; and
a protocol proxy in selective communication with the PBX and the application server, the protocol proxy configured to receive a Session Interchange Protocol (SIP) INVITE message from the PBX and send the SIP INVITE message to the application server, the SIP INVITE message being forwarded by the PBX in response to the PBX receiving the incoming call request, the SIP INVITE message providing the application server with at least a substantially real-time notification of the incoming call request;
wherein the application server is further configured to receive the forwarded SIP INVITE message from the protocol proxy and send at least one call routing instruction to the protocol proxy in response to receiving the SIP INVITE message to provide at least one call management service, the at least one call routing instruction configured to instruct the PBX with respect to disposition of the incoming call.
23. The system of claim 22, wherein the application server is further configured to notify at least one of the one of the plurality of users and a designated surrogate for the one of the plurality of users of the incoming call in response to the forwarded SIP INVITE message.
24. The system of claim 23, wherein the application server is further configured to redirect or forward the incoming call request using at least one of: (i) SIP REDIRECT, REFER, or UPDATE messages; and (ii) SIP INVITE or REPLACE procedures to modify the media flow between call endpoints.
US13/045,199 2005-10-03 2011-03-10 PBX call management Active 2026-06-26 US8737385B2 (en)
US11/240,599 Continuation US7920692B2 (en) 2005-10-03 2005-10-03 PBX call management
US20110164744A1 US20110164744A1 (en) 2011-07-07
US8737385B2 true US8737385B2 (en) 2014-05-27
TWI381712B (en) * 2007-08-14 2013-01-01 Traditional switches expand systems that connect to Internet telephony
Jiang, et al., "Integrating Internet Telephony Services," IEEE Internet Computing, vol. 6, Issue 3, pp. 64-72, May-Jun. 2002.
Rosenberg, at al., "SIP: Session initiation Protocol-RFC 3261," Network Working Group, The Internet Society, 252 pages, Jun. 2002.
Rosenberg, at al., "SIP: Session initiation Protocol—RFC 3261," Network Working Group, The Internet Society, 252 pages, Jun. 2002.
US7920692B2 (en) 2011-04-05
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:OLSHANSKY, ROBERT;SPOREL, ERIC R;LIAO, ROBERT H;AND OTHERS;REEL/FRAME:033238/0452