Source: http://www.google.com/patents/US20060067300?dq=assignee:+google
Timestamp: 2016-04-30 13:34:42
Document Index: 57233324

Matched Legal Cases: ['Application No. 60', 'Application No. 60', 'Application No. 60', 'Application No. 60', 'Application No. 60', 'Application No. 60', 'Application No. 60']

Patent US20060067300 - System and method for bridge call appearance in distributed peer-to-peer network - Google PatentsSearch Images Maps Play YouTube News Gmail Drive More »Sign inPatentsA Bridge Call Appearance (BCA) Group including a plurality of peer-to-peer packet-based devices and methods for operating the BCA Group are provided by embodiments of the present invention. In the BCA Group at least one peer-to-peer packet-based device is designated as a primary device and remaining...http://www.google.com/patents/US20060067300?utm_source=gb-gplus-sharePatent US20060067300 - System and method for bridge call appearance in distributed peer-to-peer networkAdvanced Patent SearchPublication numberUS20060067300 A1Publication typeApplicationApplication numberUS 10/953,039Publication dateMar 30, 2006Filing dateSep 30, 2004Priority dateSep 30, 2004Also published asCA2581203A1, CA2581203C, CN101049003A, CN101049003B, EP1794994A1, EP1794994A4, WO2006034589A1Publication number10953039, 953039, US 2006/0067300 A1, US 2006/067300 A1, US 20060067300 A1, US 20060067300A1, US 2006067300 A1, US 2006067300A1, US-A1-20060067300, US-A1-2006067300, US2006/0067300A1, US2006/067300A1, US20060067300 A1, US20060067300A1, US2006067300 A1, US2006067300A1InventorsBehrouz Poustchi, Tu DoOriginal AssigneeBehrouz Poustchi, Tu DoExport CitationBiBTeX, EndNote, RefManPatent Citations (37), Referenced by (36), Classifications (23), Legal Events (2) External Links: USPTO, USPTO Assignment, EspacenetSystem and method for bridge call appearance in distributed peer-to-peer network
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS [0056] Embodiments of the invention provide a distributed peer-to-peer network Bridge Call Appearance (BCA) functionality for performing call processing features which are implemented locally on network devices. [0057] Referring to FIG. 1, shown is an example implementation of a BCA Group generally indicated by 10 which makes use of distributed peer-to-peer call processing provided by an embodiment of the invention. [0058] A BCA Group is considered to be a group of peer-to-peer packet-based network devices in which one or more of the network devices is designated to be an intermediary for protocol signaling of calls occurring within the BCA Group. For example, calls originating outside the BCA Group which are directed to a network device within the BCA Group have protocol signaling for establishing the call, maintaining the call, and disconnecting the call handled via the intermediary network device. In a similar fashion calls originating within the BCA Group which are directed to a network device outside the BCA Group have protocol signaling for establishing the call, maintaining the call, and disconnecting the call handled via the intermediary network device as well. Calls originating within the BCA Group for a network device within the BCA Group also require similar protocol signaling for establishing the call. A practical example of a use for such a BCA Group that would support BCA call processing features provided by embodiments of this invention is an office environment having a boss with several administrative assistants. The boss has a terminal set and the administrative assistants each have terminal sets. This group of terminal sets would be considered a BCA Group wherein the boss's terminal set is designated as a primary terminal set, to act as the intermediary as described above, and the terminal sets of the administrative assistants provide support for the boss's terminal set. When a call comes in for the primary terminal set all phones in the BCA ring simultaneously. If so desired, one of the administrative assistant terminal sets can accept responsibility for the call and the administrative assistant will then handle the call accordingly by conversing with the caller, placing the call on hold, transferring the call, or initiating other call processing features. Protocol signaling steps taken to deal with the call by the administrative assistant terminal set are handled via the boss's terminal set, as will be described in more detail below. [0059] BCA Group 10 shows five network devices in the form of terminal sets 101,102,103,104,105 coupled to a network 30. The network 30 may be for example a LAN (Local Area Network). In the example of FIG. 1 there are five terminal sets 101,102,103,104,105; however, more generally there are a total of N terminal sets where N≧2. In BCA Group 10 one or more terminal sets is designated as a primary terminal. A designation as a primary terminal identifies that a terminal set acts as an intermediary for signaling protocol in establishing, maintaining and disconnecting calls conducted between a terminal set in BCA Group 10 and another terminal set in BCA Group 10 or a terminal set external to BCA Group 10, either internal or external a local peer-to-peer network. Remaining terminal sets in BCA Group 10 are designated as secondary terminals. A designation as a secondary terminal identifies that a terminal set provides support to the primary terminal when the primary terminal is busy or otherwise unavailable. However, the secondary terminals also act independently having many of the same call processing features as the primary terminal. [0060] In some embodiments, where more than one terminal set is designated as a primary terminal within a BCA group, a primary terminal may be designated as a secondary terminal for other primary terminals. [0061] The terminal sets in the BCA Group do not physically need to be in close proximity. However, in some embodiments, it may be advantageous from a user's point of view that the terminal sets in the BCA Group are in close proximity. For example, in the office environment described above the administrative assistants are typically close to the boss and are often aware of the boss's activities. This familiarity allows the administrative assistants to provide knowledgeable support for the boss while using the administrative assistant terminal set. [0062] Embodiments of the invention provide that the terminal sets in the BCA group maintain a listing of connectivity of the BCA terminal sets. For example, the primary terminal maintains a listing of the secondary terminals that are registered to the primary terminal. The primary terminal may also maintain a listing of other primary terminals for which it is acting as a secondary terminal. Each secondary terminal may maintain a listing of which primary terminals it is registered with and which other secondary terminals are registered with those primary terminals. [0063] A terminal set has a user interface used to facilitate normal operation of the terminal set. The terminal set may include some or all of the following: keypads for dialing a number, keypads capable of being assigned to particular call features such as call forwarding, voice mail, transferring a call, etc, and a display for providing text or graphics information to a user of the terminal. [0064] The user interface provides a user of the terminal set to display status of another terminal set. In particular, the user interface displays information regarding status of the designated primary terminal to a user of a designated secondary terminal that is supplied by messages sent from the primary terminal. For example, in some embodiments the user interface includes illuminated keypads. An illuminated keypad is used to answer a call and a manner of the keypad being illuminated indicates the status of the call. In some embodiments, the user interface includes a liquid crystal display (LCD) for displaying graphics or text information regarding the status of the call such as words indicating if a call is active, ringing, on hold, or being transferred as well as numbers indicating directory numbers or extensions related to the status of the call. [0065] In some embodiments provided by the invention the BCA Group is set up by an administrator. For example, the administrator establishes a BCA Group by selecting a particular terminal set to be the primary terminal and selects other terminal sets to act as secondary terminals for the BCA Group. The information identifying the primary and secondary terminals included in the established BCA Group is then propagated to other terminal sets in the overall network using peer-to-peer information propagation techniques. In some embodiments the information is only propagated to those terminal sets that need the information, such as the primary and secondary terminals of the established BCA Group. In some embodiments, the information is propagated using techniques described in co-pending U.S. Patent Application entitled “INFORMATION DISTRIBUTION SYSTEM, METHOD AND NETWORK DEVICE, filed Sep. 30, 2004 <attorney docket number 50447-21>. [0066] In some embodiments, the administrator uses the terminal set user interface to designate which terminals are primary terminals and which terminals are secondary terminals. In some embodiments, the administrator uses a web tool for accessing the terminals via the network 30 to designate which terminals are primary terminals and which terminals are secondary terminals. [0067] Preferably, network devices used in the BCA Group are packet-based telephones such as IP (Internet Protocol) telephone terminal sets. Other examples are a video phone, a PDA (Personal Digital Assistants), a wireless device, a computer supporting peer-to-peer voice over packet-based communication or a wireless telephone that can be suitably programmed and configured to provide the BCA call processing features described below. In some cases, the terminal sets are for example IP phones such as that manufactured by Mitel, Nortel, Avaya, Siemens, NEC, Pingtel or 3COM. [0068] BCA Group 10 comprises a plurality of interconnected peer-to-peer network devices 101,102,103,104,105 for collectively implementing BCA call processing features in a distributed manner. [0069] Referring now to FIG. 2, a peer-to-peer network 20 including at least one BCA Group 10 as described in FIG. 1 will now be described. [0070] The peer-to-peer network 20 is shown to have three BCA Groups. A first BCA Group BCA1 220 is shown to include terminal sets 201,202,203,204, a second BCA Group BCA2 221 is shown to include terminal sets 204,206,207,208,209, and a third BCA Group BCA3 222 is shown to include terminal sets 211,212,213. In BCA1 220, terminal set 201 is designated as a primary terminal and terminal sets 202,203,204 are designated as secondary terminals. In BCA2 221, terminal set 206 is designated as a primary terminal and terminal sets 204,207,208,209 are designated as secondary terminals. In BCA3 222, terminal set 211 is designated as a primary terminal and terminal sets 212,213 are designated as secondary terminals. The peer-to-peer network 20 also is shown to include two individual terminal sets 205,210. In some embodiments, the network 30 is the same network that all the terminal sets in the peer-to-peer network 20 are coupled to, i.e. the terminal sets in the respective BCA Groups BCA1 220 and BCA2 221 are coupled to network 30. In some embodiments the terminal sets of the BCA Group, such as terminal sets 211,212,213 of BCA3 222 may be coupled to a local network 230 and that local network is coupled to network 30. In the example of FIG. 2 there are only three BCA Groups BCA1 220, BCA2 221, BCA3 222 and two terminal sets 205, 210. However, more generally in a peer-to-peer network there are a total of N BCA Groups containing M terminal sets where N≧1 and M≧2 as well as any number of individual terminal sets not assigned to any BCA Group. Furthermore, BCA Groups may not necessarily be distinct. A member of one BCA Group may also be a member of another BCA Group as shown by terminal set 204 which is in both BCA1 220 and BCA2 221. [0071] Connected to the network 30 as shown in FIG. 2 is a Thin Trunk Interface (TTI) 40. The TTI 40 is, for example, a basic Analog or digital T1/E1 interface or any other suitable PSTN interface and provides a local central office or PSTN (Public Switched Telephone Network) interface. The TTI 40 is coupled to a number of telephone “lines”. The lines are wire pairs coupled to PSTN 45. In some implementations, there are many lines requiring multiple thin trunk interfaces. For example, in one implementation, if 8 lines are required for connection to the PSTN 45 and each TTI 40 has four lines then a second TTI 40 is added to the peer-to-peer network 20. [0072] In some embodiments the peer-to-peer network 20 has a plurality of connections to an Internet Protocol (IP) network 60, possibly having as many connections as there are terminal sets coupled to the peer-to-peer network 20. In some embodiments, the IP network 60 includes a centralized server (not shown) which is used to route calls between nodes coupled to the IP network 60 and terminal sets coupled to the peer-to-peer network 20. In some embodiments the IP network 60 is a conventional network in which packetized data is transferred between network nodes. In some embodiments the IP network 60 is a Voice over IP (VoIP) network. [0073] In some embodiments, an interface coupled to the network 30 is an Internet Protocol Interface (IPI) 50. The IPI 50 is coupled to IP Network 55. The IPI 50 acts as a device to limit the number of connections to the network 30. As opposed to having a permanent packetized protocol connection for every extension or terminal set of the peer-to-peer network 20, the IPI 50 functions to make a temporary connection between a terminal set external to the peer-to-peer network 20 (coupled to the peer-to-peer network 20 through IP network 55) and a terminal set within the peer-to-peer network 20. [0074] In some embodiments the peer-to-peer network 20 has only IPI 50 and no TTI 40. In other embodiments the peer-to-peer network 20 has both IPI 50 and TTI 40. In some embodiments multiple IPIs 50 may be used. In some embodiments IP network 55 and IP network 60 are the same IP network. [0075] Embodiments of the invention provide that the TTI 40 and/or the IPI 50 maintain a listing of connectivity of terminal sets in the peer-to-peer network 20. For example, in some embodiments, the interfaces 40,50 maintain listings of the primary and secondary terminals included in respective BCA Groups. The interfaces 40,50 may also maintain listings of primary terminals that act as a secondary terminals for other primary terminals. The information identifying the primary and secondary terminals included in BCA Groups is propagated to the interfaces 40,50 in the peer-to-peer network 20 using peer-to-peer information propagation techniques in the same manner as information is propagated between peer-to-peer terminals. [0076] It is to be understood that the peer-to-peer network 20 of FIG. 2 is only a specific example of the incorporated subject matter. For example, in some implementations the network 30 forms part of a larger network that is a collection of smaller networks interconnected by way of VPN (Virtual Private Network) connections. Also, in some embodiments provided by the invention not all of the features in FIG. 2 are included, for example the IPI 50 is not necessary in all embodiments. [0077] In the following descriptions of BCA call processing features a device being called by a BCA terminal set or a device calling a BCA terminal set is referred to as “Terminal Device X”. In the following signaling call flows describing embodiments of the invention “Terminal Device X” is a terminal set exterior to the peer-to-peer network 20, TTI 40 or IPI 50 that is routing a call from exterior to the peer-to-peer network 20, a terminal set within the peer-to-peer network 20, or a terminal set within the same BCA group. [0078] A first BCA Group call processing feature provided by embodiments of the invention is receiving an incoming call. In a general case of receiving an incoming call a user of Terminal Device X is calling a user of a primary terminal of the BCA Group. The primary and all secondary terminals will ring simultaneously. If the user of the primary terminal is unavailable to take the call, one of the secondary terminals can accept the call. For example, a first secondary terminal accepts the invitation from the primary terminal and the primary terminal then cancels any outstanding invitations to other secondary terminals in the BCA Group. The primary terminal serves as a signaling bridge to connect Terminal Device X with the first secondary terminal. The first secondary terminal notifies the other secondary terminals that it is connected with Terminal Device X. After a dialog between the users of Terminal Device X and a user of the secondary terminal has been completed the primary terminal arranges the disconnection of the secondary terminal and Terminal Device X. [0079] Referring to FIG. 3, an example of a signaling flow 300 for an incoming call to a terminal in a BCA Group will now be described. The particular signaling flow diagram 300 includes signal flow information pertaining to four terminals. A first terminal is Terminal Device X 301, which is placing a call to the primary terminal 302 in the BCA Group. The three terminals in the BCA Group are BCA primary terminal 302, a first BCA secondary terminal 303 and a second BCA secondary terminal 304. [0080] The following signal flow example uses Session Initiation Protocol (SIP) messaging. SIP is a request/response type of protocol. A first device sends a request to a second device. The second device responds to the request and further action results depending in the response of the second device. The SIP core standard (currently RFC 3261), which is incorporated herein by reference defines SIP requests and responses such as INVITE, BYE, OK, and ACK and the manner in which they are used. [0081] As shown in FIG. 3, a first step involves Terminal Device X 301 issuing an “INVITE (cid=1)” request 310 to BCA primary terminal 302. BCA primary terminal 302 issues a local alert 311 within the BCA primary terminal 302 in response to “INVITE (cid=1)” 310. BCA primary terminal 302 knows about (is provisioned with the identification of) all the other BCA terminals in the group as described above based on the establishment of the BCA Group by the administrator. In addition to alerting the BCA primary terminal 302 locally, the BCA primary terminal 302 also simultaneously issues invitations to BCA secondary terminals 303,304 in the form “INVITE (cid=2)” 312 to BCA secondary terminal 303 and “INVITE (cid=3)” 313 to BCA secondary terminal 304 to alert BCA secondary terminals 303,304 of an incoming call to the BCA Group. BCA primary terminal 302 sends a “180 Ringing (cid=1)” 315 signal to Terminal Device X 301. BCA secondary terminal 303 sends a “180 Ringing (cid=2)” 316 signal response to BCA primary terminal 302 and BCA secondary terminal 304 sends a “180 Ringing (cid=3)” 317 response to BCA primary terminal 302. In this example we assume that BCA secondary terminal 303 picks up the call and sends a “200 OK (cid=2)” response 319 to BCA primary terminal 302, for example if the user of BCA primary terminal 302 is away from the terminal at the time of the call. In response, BCA primary terminal 302 cancels local ringing 320 that is occurring on BCA primary terminal 302. BCA primary terminal 302 also sends a “200 OK (cid=1)” message 322 to Terminal Device X 301 to announce the call will be received by a terminal in the BCA Group. BCA primary terminal 302 sends out “CANCEL/487/ACK (cid=3)” 323 to BCA secondary terminal 304 to cancel the original “Invite” request 310. Terminal Device X 301 sends an acknowledgement 324 in the form “ACK (cid=l)” to BCA primary terminal 302 and BCA primary terminal 302 sends an acknowledgement 325 in the form “ACK (cid=2)” to BCA secondary terminal 303. At this point in time a connection is established between Terminal Device X 301 and the BCA secondary terminal 303, wherein information is transmitted 330 between the two terminals 301,303 using Real-time Transfer Protocol (RTP). BCA secondary terminal 303 sends a “NOTIFY/200 OK-Confirmed” message 331 and “NOTIFY/200 OK-Confirmed” message 332 to BCA secondary terminals 302 and 304 respectively to notify BCA terminals 302 and 304 that BCA secondary terminal 303 is occupied with the call from Terminal Device X 301. Upon completion of a dialog between a user of Terminal Device X 301 and a user of BCA secondary terminal 303, Terminal Device X 301 sends a “BYE (cid=1)” message 335 to BCA primary terminal 302 and BCA primary terminal 302 sends a “BYE (cid=2)” message 336 to BCA secondary terminal 303. BCA secondary terminal 303 responds with “200 OK (cid=2)” 337 to BCA primary terminal 302 and BCA primary terminal 302 sends “200 OK (cid=1)” 338 to Terminal Device X 301. After message 338, BCA secondary terminal 303 sends a signal “NOTIFY/200 OK-Terminate” 339,340 to both BCA terminals 302 and 304 to notify the BCA terminals 302,304 that the BCA secondary terminal 303 is finished with its part in the call processing feature 300. [0082] FIG. 3 is one example of how an incoming call could be handled by the BCA Group. In the example, BCA secondary terminal 303 accepts the invitation and picks up the call. In other situations BCA secondary terminal 304 picks up the call resulting in a similar flow but different call identifiers (cid) in the signaling protocol between terminals. In a situation where more than two BCA secondary terminals are involved, the call is picked up by any available secondary terminal. [0083] A second BCA Group call processing feature provided by embodiments of the invention is placing an outgoing call. In a general case of placing an outgoing call, a user of a BCA Group primary terminal is calling a user of Terminal Device X. The primary terminal sends a notification to all secondary terminals registered with the primary terminal that the primary terminal is trying to contact Terminal Device X. After a connection between Terminal Device X and the primary terminal is established the primary terminal sends confirmation to all the secondary terminals that connection has been made with Terminal Device X and the primary terminal is now busy. After a dialog between Terminal Device X and the primary terminal has been completed the primary terminal notifies all the secondary terminals that the primary terminal has completed the call with Terminal Device X and that the primary terminal is available. [0084] Referring to FIG. 4, an example of a signaling flow 400 for an outgoing call from a terminal in the BCA Group will now be described. The particular signaling flow diagram 400 includes signal flow information pertaining to four terminals, Terminal Device X 401, BCA primary terminal 402, first BCA secondary terminal 403 and second BCA secondary terminal 404. [0085] As shown in FIG. 4, a first step involves the BCA primary terminal 402 sending a “NOTIFY/200 OK-Trying” message 410, 411 to BCA secondary terminal 403 and BCA secondary terminal 404 before sending an “INVITE” to Terminal Device X 401. BCA primary terminal 402 then issues an “INVITE (cid=1)” 413 request to Terminal Device Xoutside terminal 401. Terminal Device X 401 sends a “180 Ringing (cid=1)” 414 signal response to BCA primary terminal 402. Terminal Device X 401 further sends a “200 OK (cid=1)” 415 message to BCA primary terminal 402. In response to the “200 OK (cid=1)” 415 sent by Terminal Device X 401, BCA primary terminal 402 sends an acknowledgement 416 in the form “ACK (cid=1)”. At this point in time a connection is established between BCA primary terminal 402 and Terminal Device X 401, wherein information is transmitted 420 between the two terminals 401,402 using RTP. BCA primary terminal 402 sends a “NOTIFY/200 OK-Confirmed” message 422 to BCA secondary terminal 403 and a “NOTIFY/200 OK-Confirmed” message 423 to BCA secondary terminal 404 to notify those terminals that BCA primary terminal 402 is occupied with a call to Terminal Device X 401. Upon completion of a dialog between a user of Terminal Device X 401 and a user of BCA primary terminal 402, Terminal Device X 401 sends a “BYE (cid=1)” message 425 to BCA primary terminal 402 and BCA primary terminal 402 sends a “200 OK (cid=1)” message 426 to Terminal Device X 401. BCA primary terminal 402 sends a “NOTIFY/200 OK-Terminate” message 430 to BCA secondary terminal 403 and a “NOTIFY/200 OK-Terminate message” 431 to BCA secondary terminal 404 to notify those terminals that BCA primary terminal 402 has completed the call with Terminal Device X 401. [0086] A third BCA Group call processing feature provided by embodiments of the invention is placing a call on hold. In a general case of placing a call on hold a user of a BCA Group terminal places a call on hold from another terminal, internal or external to the peer-to-peer network. For example, it is assumed that a user of a first secondary terminal is connected to Terminal Device X and wishes to place the user of Terminal Device X on hold. In initiating placing the call on hold the first secondary terminal sends an invitation to the primary terminal it is registered with to accept control of the call on hold. The primary terminal sends an invitation to Terminal Device X to be placed on hold. After Terminal Device X accepts being placed on hold the primary terminal takes over control of the hold and establishes a one way connection with Terminal Device X. [0087] Some embodiments of the hold call processing function are done this way to relieve a secondary terminal from streaming media, for example music-on-hold, while the call is placed on hold. The primary terminal will assume this responsibility. In a case where the secondary terminal has to monitor several primary terminals, this may help to reduce the load on the secondary terminal, hence improving the overall network scalability. [0088] The one way RTP connection between the primary terminal and Terminal Device X allows the primary terminal to supply media such as music or voice messages to Terminal Device X while it is on hold. While the primary terminal plays music-on-hold to Terminal Device X, there is no media flowing between the primary terminal and the first secondary terminal. The first secondary terminal also notifies the rest of the BCA group that the call is being held at primary terminal. [0089] Referring to FIG. 5, an example of a signaling flow 500 for a terminal in the BCA Group placing a call on hold will now be described. The particular signaling flow diagram 500 includes signal flow information pertaining to four terminals, Terminal Device X 501, BCA primary terminal 502, first BCA secondary terminal 503 and second BCA secondary terminal 504. [0090] As shown in FIG. 5, a connection is currently established between Terminal Device X 501 and BCA secondary terminal 503, wherein information is transmitted 510 between the two terminals 501, 503 using RTP. A first step of the process involves BCA secondary terminal 503 initiating placing the call on hold. BCA secondary terminal 503 sends an “INVITE (cid=2)(BCA-hold)” request 511 that includes a special header to tell BCA primary terminal 502 to change media source, for example, supplying music-on-hold or some other signal that indicates to a caller on hold that the call is still active. Alternatively, the special header (BCA-hold) can be excluded in request 511. In this case, BCA primary terminal 502 determines that the request 511 is for a “bca hold” when the request 511 contains one of the following in a Session Description Protocol (SDP): connection IP address c=0.0.0.0, or an attribute field set to send-only (a=send-only) or to inactive (a=inactive). After determining that the request 511 is for a “bca hold”, BCA primary terminal 502 can play the appropriate hold media, such as “music on hold” (MOH), toward Terminal Device X. BCA primary terminal 502 sends an “INVITE (cid=l)(send-only MOH)” request 512 to Terminal Device X 501. Terminal Device X 501 responds with “200 OK (cid=1)” 515 and then BCA primary terminal 502 further sends a “200 OK (cid=2)” response 516 to BCA secondary terminal 503. BCA secondary terminal 503 responds to “200 OK (cid=2)” 516 from BCA primary terminal 502 with an acknowledgement in the form “ACK (cid=2)” 517. BCA primary terminal 502 sends an “ACK (cid=1)” 518 to Terminal Device X 501. At this point a connection is made between Terminal Device X 501 and BCA primary terminal 502. The connection is a one way connection for transmitting 520 media such as music or voice messages using RTP from BCA primary terminal 502 to Terminal Device X 501 while Terminal Device X the outside terminal 501 is on hold. BCA terminal 503 then notifies all BCA terminals 502,504 of the location and status of the hold by sending a “NOTIFY/200 OK-HOLD” message 525, 526 to all BCA terminals 502, 504. [0091] In FIG. 5 there are only two BCA secondary terminals to notify about a status of hold, more generally the BCA primary terminal notifies all terminals in the BCA Group of the hold status. [0092] A fourth BCA Group call processing feature is retrieving a call from hold. In a general case of retrieving a call from hold a user of a BCA Group terminal retrieves a call that is placed on hold by a first secondary terminal and currently on hold by the primary terminal. For example, a second secondary terminal sends an invitation to the primary terminal it is registered with to retrieve the call on hold. The primary terminal sends an invitation to Terminal Device X to take the call off-hold and to attempt to connect Terminal Device X with the second secondary terminal which is trying to pick up the call. At the same time, the primary terminal also sends a message to the first secondary terminal that originally put the call on hold to terminate that call, which has been replaced by the call from a second secondary terminal that is trying to pick up the held call. After Terminal Device X accepts the invitation, the primary terminal establishes a connection between Terminal Device X and the second secondary terminal that is picking up the call. After connection between Terminal Device X and the secondary terminal has been established, the second secondary terminal notifies all the secondary terminals and the primary terminal that it has retrieved the call from hold. After a dialog between a user of Terminal Device X and a user of the second secondary terminal has been completed the primary terminal still acting as the intermediary for signaling protocol between Terminal Device X and the second secondary terminal notifies the second secondary terminal that the user of Terminal Device X has terminated the call. The second secondary terminal then notifies all other BCA Group terminals that the call has been terminated and the first secondary terminal is available. [0093] Referring to FIG. 6, an example of a signaling flow 600 for a terminal in the BCA Group retrieving a call from hold will now be described. The particular signaling flow diagram 600 includes signal flow information pertaining to four terminals, Terminal Device X 601, BCA primary terminal 602, first BCA secondary terminal 603 and second BCA secondary terminal 604. [0094] As shown in FIG. 6, a one way RTP connection is currently established between Terminal Device X 601 and BCA primary terminal 602, wherein information is transmitted 610 from BCA primary terminal 602 to Terminal Device X 601. A first step of the process involves BCA secondary terminal 604 initiating retrieving the call which was placed on hold by BCA secondary terminal 603. BCA secondary terminal 604 sends an “INVITE (cid=99)(Replaces:cid 2) (SDP=BCA secondary terminal 604)” request 611 to BCA primary terminal 602. Call cid=99 represents a new call initiated from BCA secondary terminal 604 to replace call cid=2 that is being held at BCA primary terminal 602. BCA primary terminal 602 sends an “INVITE (cid=1)(SDP=BCA secondary terminal 604)” request 612 to Terminal Device X 601. BCA primary terminal 602 realizes that this is a call to replace call cid=2 that was previously put on hold by BCA secondary terminal 603. BCA primary terminal 602 sends a “BYE (cid=2)” signal 613 to BCA secondary terminal 603 to terminate that call and in response BCA secondary terminal 603 sends a “200 OK (cid=2)” message 614 back to BCA primary terminal 602. Terminal Device X 601 responds to the “INVITE” 612 with “200 OK (cid=1)” 615 and then BCA primary terminal 602 further sends a “200 OK (cid=99)” message 616 to BCA secondary terminal 604. BCA secondary terminal 604 responds to “200 OK (cid=99)” 616 from BCA primary terminal 602 with an acknowledgement in the form “ACK (cid=99)” 617. BCA primary terminal 602 sends an “ACK (cid=1)” 618 to Terminal Device X 601. At this point in time a connection is established between Terminal Device X 601 and BCA secondary terminal 604, wherein information is transmitted 620 between the two terminals 601, 604 using RTP. BCA secondary terminal 604 sends a “NOTIFY/200 OK-Confirmed” message 621, 622 to BCA secondary terminal 603 and BCA primary terminal 602, respectively to notify these terminals that BCA secondary terminal 604 is busy with the call involving Terminal Device X 601. Upon completion of a dialog between the user of Terminal Device X 601 and the user of BCA secondary terminal 604, Terminal Device X 601 terminates the call with BCA secondary terminal 604 by sending “BYE (cid=1)” 625 to BCA primary terminal 602. BCA primary terminal 602 sends “BYE (cid=99)” 626 to BCA secondary terminal 604 and in response BCA secondary terminal 604 sends a “200 OK (cid=99)” 627 message back to BCA primary terminal 602. BCA primary terminal 602 sends a “200 OK (cid=1)” message 628 to Terminal Device X 601. BCA secondary terminal 604 sends a “NOTIFY/200 OK-Terminate” signal 629, 630 to BCA terminals 602, 603 notifying the BCA terminals 602, 603 that BCA secondary terminal 604 has terminated connection with Terminal Device X 601. [0095] In another embodiment, in which BCA primary terminal 602 is picking up the held call, BCA primary terminal 602 simply sends a “BYE” message to BCA secondary terminal 603 that put the call on hold originally, to tear down that call (cid=2). It would then re-invite Terminal Device X 601, which essentially would take Terminal Device X 601 off of music-on-hold and resume 2-way media directly with BCA primary terminal 602. After this, BCA primary terminal 602 would notify (“NOTIFY/200 OK-Confirmed”) the secondary BCA terminals 602, 603 that it is taking the call. [0096] Additional BCA Group call processing features include blind and attended transfers from one terminal in the BCA Group to another terminal. In a general case of transferring a call from a user of a BCA Group terminal to another terminal, a first step involves utilizing aspects of the hold call processing feature as described above. For example, a first secondary terminal uses the hold feature to place the call on hold while it performs the steps necessary to complete the transfer. In one embodiment of a blind transfer call processing feature the first secondary terminal sends an invitation to the terminal of a desired destination to accept the call. If the invitation is accepted the first secondary terminal transfers control of the call back to the primary terminal. The primary terminal sends an invitation to the terminal of the desired destination to connect the terminal of the desired destination with the call and upon acceptance of the invitation connects Terminal Device X and the terminal of the desired destination. Upon successfully establishing the connection the primary terminal sends notification of the successful connection to the first secondary terminal and then the first secondary terminal sends notification to the other BCA Group terminals that it has completed its function in the blind transfer and is again available. [0097] In an attended transfer call processing feature the signal flow is similar to a blind transfer call processing feature, however provision is made for the user of the first secondary terminal to introduce the user of the outside terminal. [0098] Referring to FIG. 7A, an example of a signaling flow 700 for a blind transfer from one terminal in the BCA Group to another terminal in the peer-to-peer network will now be described. The particular signaling flow diagram 700 includes signal flow information pertaining to four terminals, Terminal Device X 701, BCA primary terminal 702, first BCA secondary terminal 703 and second BCA secondary terminal 704 plus an additional internal terminal 705. [0099] As shown in FIG. 7A, a connection is currently established between Terminal Device X 701 and BCA secondary terminal 703, wherein information is transmitted 710 between the two terminals 701,703 using RTP. A first step of the process involves BCA secondary terminal 703 initiating transferring a call. Steps 711, 712, 715, 716, 717, 718 and 720 are the same as steps 511, 512, 515, 516, 517, 518 and 520 of the hold call processing feature 500 described above. Following BCA secondary terminal 703 sending BCA primary terminal 702 an “ACK (cid=2)” message 717, BCA secondary terminal 703 also sends an “INVITE (cid=99)” request 721 to internal terminal 705 causing internal terminal 705 to ring and notify a user of internal terminal 705 of an incoming call. Internal terminal 705 sends a “180 Ringing (cid=99)” response back to BCA secondary terminal 703. At this point in time the user of BCA secondary terminal 703 hangs up 723. BCA secondary terminal 703 sends a “REFER (cid=2)” message 725 to BCA primary terminal 702 including the information “Refer-to: Internal Terminal 705”, “Refer-by: BCA secondary terminal 703” and “Replaces: cid=99”. In response to “REFER (cid=2)” 725 BCA primary terminal 702 sends a “202 Accepted (cid=2)” response to BCA secondary terminal 703. Then BCA primary terminal 702 sends an “INVITE (cid=202;replaces cid=99)-no media” request 727 to internal terminal 705. The “INVITE (cid=202;replaces cid=99)-no media” request 727 replaces the existing call cid=99 with cid=202, which is now in a ringing state. This “INVITE” request 727 carries no media description of the calling party because at this point, BCA primary terminal 702 is still playing music to Terminal Device X 701. Since call cid=99 is being replaced, internal terminal 705 sends a “BYE (cid=99) 728 signal to BCA secondary terminal 703 to tear down the pending call cid=99. BCA secondary terminal 703 responds to internal terminal 705 with a “200 OK (cid=99) message 729. Internal terminal 705 responds to “INVITE” 727 by sending a “180 Ringing (cid=202)” message 730 to BCA primary terminal 702. Internal terminal 705 also sends a “200 OK (cid=202)” message 734 to the BCA primary terminal 702. The media description of internal terminal 705 is carried in a session description protocol (SDP) within this response. This results in BCA primary terminal 702 sending an “INVITE (cid=1)” request 735 to Terminal Device X 701 with the SDP of terminal 705 learned from the “200 OK” response 734. Terminal Device X 701 responds with a “200 OK (cid=1)” response 736. BCA primary terminal 702 sends an “ACK (cid=202)-media X” 737 to internal terminal 705 followed the receipt of message “200 OK (cid=1)” 736 from Terminal Device X 701. The acknowledgement message 737 to internal terminal 705 carries the media description of Terminal Device X 701 in the associated SDP. BCA primary terminal 702 also sends an “ACK (cid=1)” 740 to Terminal Device X 701 to acknowledge the previous “200 OK (cid=1)” 736 from terminal 701. Hence, at the end of the above-described process in which BCA primary terminal 702 is the signalling intermediary, Terminal Device X 701 and internal terminal 705 have each other's SDP information. A connection is then established between Terminal Device X 701 and internal terminal 705, wherein information is transmitted 742 between the two terminals 701, 705 using RTP. BCA primary terminal 702 further sends a “Notify/200 OK-Success(cid=2)” message 744 to BCA secondary terminal 703 notifying BCA secondary terminal 703 that the transfer has been successfully completed and BCA secondary terminal 703 responds by sending a “BYE (cid=2)” 745 message to BCA primary terminal 702. BCA primary terminal 702 sends “200 OK (cid=2)” 746 to BCA secondary terminal 703 in response to “BYE (cid=2)” 745. The BCA secondary terminal 703 also sends a “Notify/200 OK-Terminate” 747, 748 message to BCA secondary terminal 704 and BCA primary terminal 701 notifying BCA secondary terminal 704 and BCA primary terminal 702 that BCA secondary terminal 703 has completed its involvement in the call transfer feature process 700. [0100] A second embodiment of a blind transfer call processing feature 707 from one terminal in the BCA Group to another terminal in the peer-to-peer network is shown in FIG. 7B. The difference between the embodiments of FIG. 7A and FIG. 7B is that in FIG. 7B BCA secondary terminal 703 does not send a request inviting internal terminal 705 to accept the transfer, receive a “180 Ringing” response or send a “CANCEL/487/ACK” message to internal terminal 705 as in steps 721, 722 and 724 of blind transfer call processing feature 700. In addition, the “REFER” command of step 750 in FIG. 7B contains slightly different instructions. Therefore, BCA secondary terminal 703 does not contact internal terminal 705 with the “INVITE (cid=99)” request 721, but directly sends a “REFER (cid=2)” 750 message to BCA primary terminal 702 including the information “Refer-to: Internal Terminal 705” and “Refer-by: BCA secondary terminal 703”. Also, the “INVITE” step 751 in call processing feature 707 differs from the “INVITE” step 727 in call processing feature 700 in that cid=202 is not replacing cid=99. As a result, steps 728 and 729 of call processing feature 700 are not required in call processing feature 707. The remaining steps of the second embodiment of the blind transfer feature 707 are the same as the first embodiment of FIG. 7A. [0101] Referring to FIG. 8, an example of a signaling flow for an attended transfer call processing feature 800 from one terminal in the BCA Group to another terminal in the peer-to-peer network will now be described. The particular call processing feature 800 includes signal flow information pertaining to five terminals, Terminal Device X 801, BCA primary terminal 802, first BCA secondary terminal 803, second BCA secondary terminal 804 and internal terminal 805. In the example being described BCA secondary terminal 803 transfers a call to internal terminal 805. [0102] Initial steps of an attended transfer call processing feature process 800 of FIG. 8, namely placing the call on hold, steps 810,811,812,815,816,817,818,820 and 821 are the same as steps 710,711,712,715,716,717,718,720 and 721 of the blind transfer call processing feature process 700 described above with respect to FIG. 7A. Following BCA secondary terminal 803 sending the “INVITE (cid=99)” request 821 to internal terminal 805, the internal terminal 805 sends a “180 Ringing/200 OK (cid=99)” response. 850 back to BCA secondary terminal 803. BCA secondary terminal 803 sends an acknowledgement 851 to internal terminal 805 in the form “ACK (cid=99)”. At this point in time a connection is established between BCA secondary terminal 803 and internal terminal 805, wherein information is transmitted 852 between the two terminals 803,805 using RTP. This connection allows the user of BCA secondary terminal 803 to introduce the user of the Terminal Device X 801 to the user of internal terminal 805. BCA secondary terminal 803 sends an “INVITE (cid=99)-hold” request 853 to internal terminal 805 and by way of response internal terminal 805 sends “200 OK (cid=99)” 854 to BCA secondary terminal 803. BCA secondary terminal 803 acknowledges the response with “ACK (cid=99)” 855. The remaining steps in FIG. 8 are the same as those in the embodiment of the blind transfer feature of FIG. 7A. [0103] Referring to FIG. 9, an example of a signaling flow for an attended transfer call processing feature 900 from one terminal in the BCA Group to the BCA primary terminal will now be described. The particular call processing feature 900 includes signal flow information pertaining to five terminals, Terminal Device X 901, BCA primary terminal 902, first BCA secondary terminal 903, second BCA secondary terminal 904 and internal terminal 905. In the example being described BCA secondary terminal 903 transfers a call to BCA primary terminal 902. [0104] Initial steps of an attended transfer feature process 900 of FIG. 9, namely placing the call on hold, steps 910,911,912,915,916,917,918,and 920 are the same as steps 810,811,812,815,816,817,818 and 820 of the attended transfer call processing feature 800 described above with respect to FIG. 8. Following BCA secondary terminal 903 sending an “ACK (cid=99)” 917 signal to primary terminal 902, BCA secondary terminal 903 also sends an “INVITE (cid=99)” request 921 to the BCA primary terminal 902. BCA primary terminal 902 sends BCA secondary terminal 903 a “180 Ringing/200 OK (cid=99)” response 950. BCA secondary terminal 903 sends an acknowledgement 951 to BCA primary terminal 902 in the form “ACK (cid=99)”. At this point in time a connection is established between BCA secondary terminal 903 and BCA primary terminal 902, wherein information is transmitted 952 between the two terminals 902,903 using RTP. This connection allows the user of BCA secondary terminal 903 to introduce the user of Terminal Device X 901 to the user of BCA primary terminal 902. BCA secondary terminal 903 sends an “INVITE (cid=99)-hold” request 953 to BCA primary terminal 902 and by way of response BCA primary terminal 902 sends “200 OK (cid=99)” 960 to BCA secondary terminal 903. BCA secondary terminal 903 acknowledges the response with “ACK (cid=99)” 955. BCA secondary terminal 903 sends a “REFER (cid=2)” message 962 to BCA primary terminal 902 including the information “Refer-to: BCA primary terminal 902”, “Refer-by: BCA secondary terminal 903” and “Replaces: cid=99”. In response to “REFER (cid=2)” 962 BCA primary terminal 902 sends a “202 Accepted (cid=2)” response 928. Based on the “REFER” message 962, BCA primary terminal 902 realizes it is being referred to a call that is local to itself. This means that call cid=1 should now terminate at BCA primary terminal 902. This results in BCA primary terminal 902 sending an “INVITE (cid=1)” request 935 to Terminal Device X 901 to which Terminal Device X 901 responds with a “200 OK (cid=1)” 936. BCA primary terminal 902 acknowledges the “200 OK (cid=1)” 936 with an “ACK (cid=1)” 940 sent to Terminal Device X 901. A connection is then established between Terminal Device X 901 and BCA primary terminal 902, wherein information is transmitted 942 between the two terminals 901,902 using RTP. The BCA primary terminal 902 also sends “Notify/200OK—Confirmed” 943,944 to the secondary terminals 903 and 904 notifying these terminals that BCA primary terminal 902 is now in a conversation. BCA primary terminal 902 sends “BYE (cid=99)” 970 to BCA primary terminal 903 terminating cal cid=99 and BCA primary terminal 903 responds to BCA secondary terminal 902 by sending “200 OK (cid=99)” 971. BCA primary terminal 902 further sends a “Notify/200 OK-Success” message 972 to BCA secondary terminal 903 notifying BCA secondary terminal 903 that the transfer of cid=99 has been successfully completed. Then BCA secondary terminal 903 responds by sending “BYE (cid=2)” 973 to BCA primary terminal 902 terminating call cid=2, whereby BCA primary terminal 902 sends back a “200 OK (cid=2) response 974. [0105] The particular examples described above with respect to FIGS. 3-9 are shown being implemented with SIP. However, it is understood that other types of protocol signaling can be used to perform the signaling steps described above in the general examples of the BCA Group call processing features. [0106] The use of RTP for communication between terminals in the various BCA Group call processing features is also noted to be one particular example of a protocol for such communication and it is to be understood that other protocols could be used for such communication in place of RTP. [0107] The use of SDP for carrying media description between terminals in the various BCA Group call processing features is also noted to be one particular example of a protocol for such communication and it is to be understood that other protocols could be used for such communication in place of SDP. [0108] An advantage of this type of BCA Group architecture is that Terminal Device X does not have to interact with multiple terminals within the peer-to-peer network. The use of the primary terminal as an intermediary allows Terminal Device X to interact with a single terminal for the sake of protocol signaling for initiating, maintaining and disconnecting from calls. As a result, terminals external to the peer-to-peer network can operate with any desired protocol and the BCA Group and/or peer-to-peer network can operate on the same protocol or a different and independent protocol for signaling between terminals of the peer-to-peer network. In some embodiments provided by the invention a protocol translator resides in any one of or all of the TTI, IPI, and/or the primary terminal of the BCA Group. [0109] The signal flow charts described above are intended as examples of how call processing features may be implemented, in particular using SIP messaging. In some embodiments it may not be necessary to include all of the SIP commands or signals as described herein and in some embodiments there may be additional steps which are included to improve the BCA Group call processing features or add additional functionality to the features. It should also be understood that the ordering of steps as described herein are but examples of how the process may be implemented. Ordering of steps may have some deviation from those described above and still fall within the subject matter of the invention. [0110] FIG. 10 shows a functional block diagram of software 1050 operating on terminal set 101 of FIG. 1. The software 1050 includes modules for performing particular functions, for example Bridge Call Appearance call processing features, as well a module for distributing information between the modules. The software 1050 will be described as operating on terminal set 101; however, it is to be understood that similar software is implemented in terminal sets 102, 103, 104, 105 and the terminal sets of FIG. 2. Furthermore, in some cases, at least some of the features of the software 1050 described below are implemented in any network device in the peer-to-peer network 20 including TTI 40 or IPI 50, for example. The software 1050 is stored in RAM and runs on a CPU, both also included in a terminal set such as terminal set 101 or other network devices such as TTI 40 or IPI 50. More generally, the software 1050 can be implemented as any suitable combination of instructions stored in memory for execution by general or special purpose processors, firmware, ASICs (Application Specific Integrated Circuits), FPGAs (Field-Programmable Gate Arrays), and general or special purpose logic. A system dispatcher 1000 provides communication and scheduling between various functional elements which include a call processing module 1005, a Bridge Call Appearance module 1010, a dialing rules module 1015, a peer discovery module 1020, a display handler 1025, an audio handler 1030, an input handler 1035, and a peer back-up module 1040. The call processing module 1005 also interfaces with a protocol stack 1045. [0111] FIG. 10 shows a detailed example of functions that may be included in a network device such as terminal set 101, TTI 40 or IPI 50; however, it is to be understood that a network device need not have all of the functions shown in FIG. 10 and that in some implementations a network device will have only some of the functionality shown in FIG. 10. The display handler 1025 formats information and displays the information to a user. The input handler 1035 monitors inputs from for example key presses, hook switch, volume keys, and hands free and mute buttons and informs the system dispatcher 1000. The system dispatcher 1000 then distributes messages to other modules for further appropriate action to be taken. The audio handler 1030 plays audio tones such as ringing, busy, and call waiting tones and/or connects to a handset speaker or speaker phone through a media call upon receipt of an audio message from the system dispatcher 1000. [0112] When terminal set 101 is initially connected to the network 30 it performs a peer discovery by executing the peer discovery module 1020. At this point terminal set 101 undergoes a discovery of peer network devices such as terminal sets 102, 103, 104, 105 and other network devices such as TTI 40 and IPI 50, by way of messages between terminal set 101 and terminal sets 102, 103, 104, 105, TTI 40 and IPI 50. Once the other terminal sets and network devices are discovered, information is exchanged between the terminal set 101 and the other terminal sets and network devices. In some embodiments, at least part of the information exchanged in the messages is included in a routing table. [0113] In some implementations, a BCA primary network device such as a terminal set has one or more network device designated to serve as a backup BCA primary network device in the event that the BCA primary network device is unavailable to process a call. In particular, if a BCA primary network device is unavailable to process a call, the call is re-directed to one of its designated backup network devices and the designated backup network device receiving the re-directed call provides BCA and/or other types of call functionality for the BCA primary network device that is unavailable. In some embodiments, if the primary network device is unavailable and the secondary network devices registered with the primary network device are not available then the designated backup network device will not take over for the primary device. In some embodiments, the secondary network devices also have backup network devices. [0114] On a more simplified level, each network device maintains an identification of designated backup network devices for itself and every other network device. In particular, when a new network device is added to the peer-to-peer network 20, the network device makes use of its peer discovery module 1020 to obtain routing information pertaining to other network devices in the peer-to-peer network 20 and makes use of the peer backup module 1040 to designate two other network devices as backup network devices. [0115] Referring back to FIG. 10, the dialing rules module 1015 contains and/or applies a set of dialing rules for the call-processing module 1005, which control how calls are directed. [0116] The call-processing module 1005 interacts with the protocol stack 1045 to set up and tear down calls, and to set up media calls. [0117] The call processing modules of a number of network devices collectively serve to deliver PBX-like (Private Branch Exchange-like) call processing capabilities in a distributed fashion without the need for a PBX (Private Branch Exchange). For example, the call processing module 1005 of terminal set 101 handles calls not only intended for terminal set 101 but also handles calls for other network devices for which it has been designated as a backup terminal set. This allows the BCA module 1010 to perform the functions of a backup primary terminal when terminal set 101 has been so designated. [0118] The BCA module 1010 is responsible for handling the BCA call processing features described above such as receiving an incoming call, placing an outgoing call, placing a call on hold, retrieving a call from hold, and blind or attended transfers. The BCA module contains computer readable program code for performing steps described above in the signaling flow diagrams for enabling the BCA call processing features in a distributed manner for a BCA Group comprised of a plurality of interconnected peer-to-peer packet-based network devices. [0119] FIG. 11 shows a flow chart for a method of initiating a call from one network device to another network device, which might for example be employed in the peer-to-peer network 20 of FIG. 2. In particular, a caller at an originator network device wishes to call a person at a destination network device. At step 1100, the originator network device attempts to establish a connection for a call with the destination network device. At step 1105, if the connection is established (yes path) the call is processed normally (step 1150). At step 1105 if the attempt is unsuccessful, then the originator network device looks up its routing information to determine which network device is to serve as a first backup network device for the destination network device and to determine an address for the first backup network device. The attempt may be unsuccessful due to for example one or more of a network failure, a failure at the destination network device, the destination network device being unplugged or a lack of resources at the destination network device to process a call. In some cases, the lack of resources might be due to for example all call threads at the destination network device being used simultaneously. The originator network device then initiates a call to the first backup network device by attempting to establish a connection using the address of the first backup network device (step 1110). At step 1115, if the attempt is successful (yes path) and a connection is established with the first backup network device, the call is processed (step 1150). Again, the attempt at the connection with the first backup network device may be unsuccessful (no path) at step 1115 and if the attempt of step 1110 fails, then the originator network device looks up its routing information to determine which network device is to serve as a second backup network device for the destination network device and to determine an address for the second backup network device. The originator network device then initiates a call to the second backup network device by attempting to establish a connection using the address of the second backup network device (step 1120). At step 1125, if the attempt is successful (yes path) and a connection is established with the second backup network device, the call is processed (step 1150). If the attempt is unsuccessful (no path) then a busy indication is received by the originator network device to announce that no connection is possible at that time (step 1130). [0120] Regarding processing at the destination network device, in one implementation at step 1150 the call is processed with a ringing signal being generated for answering of the call by a user of the BCA primary terminal or backup BCA primary terminals. [0121] In a situation where the call is placed from a location outside the peer-to-peer network, TTI 40 or IPI 50 performs the actions of the originator network device described above. TTI 40 and IPI 50 maintain information in the same manner as the peer-to-peer terminals regarding which terminals are designated as primary terminal, secondary terminals, and back-up terminals for primary terminals. Therefore, when a call is originated outside the peer-to-peer network 20 the call enters the peer-to-peer network 20 through either TTI 40 or IPI 50. TTI 40 or IPI 50 then contacts the BCA primary terminal and if the BCA primary terminal is not connected to the network, then TTI 40 or IPI 50 looks up its routing information to determine which network device is to serve as a backup BCA primary terminal. [0122] In the method of FIG. 11, each network device is assigned two other network devices as backup network devices and as such there are up to two attempts at establishing connections with network devices designated as backup network devices (steps 1110, 1120). More generally, a network device has M other network devices designated as backup network devices with M≧1 and successive attempts at establishing connections with the M backup network devices are performed until one of the attempts is successful. If none of the attempts are successful then a busy indication is sent back to the caller as described with reference to step 1130. [0123] FIG. 12 illustrates the signal flow for an incoming call when it has been already determined that the BCA primary terminal 302 is inactive and a BCA primary back-up terminal 305 has been identified to perform the tasks of inactive BCA primary terminal 302. The steps of the call processing feature 1200 are the same as those for the call processing feature 300 in which the BCA primary terminal 302 was active, except that all protocol signaling is handled through BCA primary back-up terminal 305 instead of BCA primary terminal 302. [0124] FIG. 12 illustrates an example of an incoming call to a back-up primary terminal. This is not to indicate that this is the only BCA call processing feature in which a backup primary terminal is used or needed. The principle of using a pre-designated backup primary terminal can apply to any of the BCA call processing features described above where appropriate. [0125] In addition to BCA call processing features, other call processing functionality such as call forwarding, call park and pickup, call transfer, and paging, and other features such as time synchronization, backup features, and peer discovery, may be provided locally at network devices within a network. Such features and functionality are described in U.S. Provisional Patent Application No. 60/441,481 entitled “DISTRIBUTED PEER-TO-PEER CALL TRANSFER SYSTEM, METHOD AND TELEPHONE TERMINALS” and filed Jan. 22, 2003; U.S. Provisional Patent Application No. 60/441,121 entitled “DISTRIBUTED PEER-TO-PEER CALL FORWARDING SYSTEM, METHOD AND TELEPHONE TERMINAL” and filed Jan. 21, 2003; U.S. Provisional Patent Application No. 60/473,877 entitled “DISTRIBUTED PEER-TO-PEER CALL PARK AND CALL PARK PICKUP SYSTEM, METHOD AND TELEPHONE TERMINALS” filed May 29, 2003; U.S. Provisional Patent Application No. 60/518,646 entitled “PEER-TO-PEER DISCOVERY SYSTEM, METHOD AND NETWORK DEVICES” filed Nov. 12, 2003; U.S. Provisional Patent Application No. 60/523,703 entitled “PEER BACK-UP IN A DISTRIBUTED PEER-TO-PEER NETWORK: SYSTEM, METHOD AND NETWORK DEVICES” filed Nov. 21, 2003; U.S. Provisional Patent Application No. 60/523,140 entitled “TIME SYNCHRONIZATION OF NETWORK DEVICES IN A NETWORK: SYSTEM, METHOD AND NETWORK DEVICE” filed Nov. 19, 2003; and U.S. Provisional Patent Application No. 60/524,041 entitled “SYSTEM, METHOD AND NETWORK DEVICES FOR PAGING IN A NETWORK” filed Nov. 24, 2003, all of which are incorporated herein by reference. It is to be clearly understood that embodiments of the invention are also provided which only provide BCA call processing features. [0126] Numerous modifications and variations of the present invention are possible in light of the above teachings. It is therefore to be understood that within the scope of the appended claims, the invention may be practised otherwise than as specifically described herein. Patent CitationsCited PatentFiling datePublication dateApplicantTitleUS4866758 *Oct 31, 1988Sep 12, 1989American Telephone And Telegraph CompanyPhone management server for use with a personal computer LANUS4873716 *Dec 27, 1988Oct 10, 1989American Telephone And Telegraph Company, At&T Bell LaboratoriesPath allocation arrangement for multi-terminal groupsUS5309028 *Jul 14, 1992May 3, 1994At&T Bell LaboratoriesCall coverage arrangement in an ISDN switching systemUS5724418 *Nov 27, 1996Mar 3, 1998Teledata Solutions, Inc.Call distributorUS5946386 *Mar 11, 1996Aug 31, 1999Xantel CorporationCall management system with call control from user workstation computersUS5963620 *May 30, 1997Oct 5, 1999Jetstream Communications, Inc.Integrated communications control device for a small office configured for coupling within a scalable network including multiple simultaneous call capabilityUS5999965 *Aug 19, 1997Dec 7, 1999Netspeak CorporationAutomatic call distribution server for computer telephony communicationsUS6363065 *Nov 10, 1999Mar 26, 2002Quintum Technologies, Inc.okApparatus for a voice over IP (voIP) telephony gateway and methods for use thereinUS6366661 *Oct 25, 1999Apr 2, 2002Quest Communications Int'l., Inc.Online call routing apparatus and methodUS6424700 *Dec 9, 1999Jul 23, 2002Nortel Networks CorporationNetwork based distributed PBX with connection loss survival featuresUS6560222 *Oct 15, 1999May 6, 2003Vertical Networks, Inc.Systems and methods for multiple voice and data communications using intelligently bridged TDM and packet buses and methods for performing telephony and data functions using the sameUS6584108 *Sep 30, 1998Jun 24, 2003Cisco Technology, Inc.Method and apparatus for dynamic allocation of multiple signal processing resources among multiple channels in voice over packet-data-network systems (VOPS)US6604140 *Sep 23, 1999Aug 5, 2003International Business Machines CorporationService framework for computing devicesUS6665293 *Sep 21, 2001Dec 16, 2003Quintum Technologies, Inc.Application for a voice over IP (VoIP) telephony gateway and methods for use thereinUS6665395 *Dec 11, 1998Dec 16, 2003Avaya Technology Corp.Automatic call distribution system using computer network-based communicationUS6693897 *Nov 10, 2000Feb 17, 2004Sbc Technology Resources, Inc.Method and system of screening and control of telephone calls while using a packet-switched data networkUS6704396 *Feb 27, 2002Mar 9, 2004Sbc Technology Resources, Inc.Multi-modal communications methodUS6721412 *May 8, 2000Apr 13, 2004Qwest Communications International Inc.Method of coordinating a call among multiple devicesUS6728267 *Dec 23, 1998Apr 27, 2004Nortel Networks LimitedService capable networkUS6744758 *May 10, 2002Jun 1, 2004Vertical Networks, Inc.Systems and methods for multiple mode voice and data communications using intelligently bridged TDM and packet busesUS6768731 *Oct 21, 1999Jul 27, 2004Lg Electronics Inc.Internet phone system and control method thereforUS6970698 *Jul 23, 2002Nov 29, 2005Sbc Technology Resources, Inc.System and method for updating data in remote devicesUS20020047942 *Dec 15, 2000Apr 25, 2002Pieter VorenkampDigital IF demodulator for video applicationsUS20020080757 *Dec 13, 2001Jun 27, 2002Kai NarvanenArranging packet data connections in office systemUS20020082006 *Dec 13, 2001Jun 27, 2002Kai NarvanenArranging internal data connections of office systemUS20020083428 *Dec 18, 2001Jun 27, 2002Lg Electronics Inc.Method for downloading information data in wireless local loop systemUS20020112058 *Jun 1, 2001Aug 15, 2002Microsoft CorporationPeer networking host framework and hosting APIUS20020113908 *Feb 19, 2002Aug 22, 2002Pace Micro Technology Plc.Remote control handsetUS20020188657 *Jan 22, 2002Dec 12, 2002Traversat Bernard A.Resource identifiers for a peer-to-peer environmentUS20030185232 *Apr 2, 2003Oct 2, 2003Worldcom, Inc.Communications gateway with messaging communications interfaceUS20030187641 *Apr 2, 2003Oct 2, 2003Worldcom, Inc.Media translatorUS20030235182 *Jun 21, 2002Dec 25, 2003Mcmullin RickVirtual key systemUS20040003041 *Apr 2, 2003Jan 1, 2004Worldcom, Inc.Messaging response systemUS20040008665 *Sep 5, 2001Jan 15, 2004Johnson Harold W.Providing end-user communication services over peer-to-peer internet protocol connections between service providersUS20040128144 *Oct 10, 2003Jul 1, 2004Johnson Christopher SeanPrompt management method supporting multiple languages in a system having a multi-bus structure and controlled by remotely generated commandsUS20050036482 *Aug 15, 2003Feb 17, 2005Dmitry GoroshevskyServerless and switchless internet protocol telephony system and methodUS20050129214 *Dec 11, 2003Jun 16, 2005Tyagarajan NvMethod and apparatus for selecting an agent to handle a call* Cited by examinerReferenced byCiting PatentFiling datePublication dateApplicantTitleUS7551725Sep 1, 2005Jun 23, 2009At&T Intellectual Property I, L.P.Systems and methods for providing call monitoring service for multiple telecommunications unitsUS7630481 *Dec 8, 2009At&T Intellectual Property I, L.P.Systems and methods for providing a telecommunications extension service for multiple telecommunications unitsUS7743024May 1, 2007Jun 22, 2010Skype LimitedSynchronising contactsUS8018899 *Feb 16, 2006Sep 13, 2011Samsung Electronics Co., Ltd.Handoff system and method between different kinds of devices, SIP server and operational method of SIP serverUS8081737May 20, 2009Dec 20, 2011At&T Intellectual Property I, L.P.Systems and methods for providing call monitoring service for multiple telecommunications unitsUS8116302Sep 22, 2006Feb 14, 2012Verizon Patent And Licensing Inc.Method and system for providing call screening in a packet-switched networkUS8130639Sep 22, 2006Mar 6, 2012Verizon Patent And Licensing Inc.Method and system for providing distinctive announcements in a SIP-based networkUS8144693Mar 27, 2012Verizon Services Organization Inc.Method and system for providing telemetry, verification and/or other access in a SIP-based networkUS8165280Sep 22, 2006Apr 24, 2012Verizon Services Organization Inc.Method and system for providing busy override service in a SIP-based networkUS8194645 *Jul 13, 2007Jun 5, 2012Samsung Electronics Co., Ltd.System for blind/attended transfer in session initiation protocol (SIP)-based network and method of controlling the transferUS8320532Sep 22, 2006Nov 27, 2012Verizon Patent And Licensing Inc.Method and system for providing voice dialing service in a SIP-based networkUS8363812Jan 29, 2013Verizon Patent And Licensing Inc.Method and system for providing call parking in a SIP-based networkUS8374166Sep 22, 2006Feb 12, 2013Verizon Patent And Licensing Inc.Method and system for providing call waiting features in a SIP-based networkUS8447019May 21, 2013Verizon Patent And Licensing Inc.Method and system for providing call screening in a packet-switched networkUS8462772Sep 22, 2006Jun 11, 2013Verizon Patent And Licensing Inc.Method and system for providing party line emulation in a SIP-based networkUS8855290 *Jun 11, 2010Oct 7, 2014Shoretel, Inc.Shared call stack in a communications systemUS8873548Sep 22, 2006Oct 28, 2014Verizon Patent And Licensing Inc.Method and system for providing call-forwarding status indications in a packet-switched networkUS8885639Sep 22, 2006Nov 11, 2014Verizon Patent And Licensing Inc.Method and system for providing talking call waiting in a SIP-based networkUS8908835Sep 22, 2006Dec 9, 2014Verizon Patent And Licensing Inc.Method and system for providing forced hold behavior in a SIP-based networkUS9041957 *Dec 17, 2012May 26, 2015Kabushiki Kaisha ToshibaFacsimile apparatus, facsimile system, and home gatewayUS9191521Jan 28, 2013Nov 17, 2015Verizon Patent And Licensing Inc.Method and system for providing call waiting features in a SIP-based networkUS9241074Sep 22, 2006Jan 19, 2016Verizon Patent And Licensing Inc.Method and system for providing variable dial pattern provisioning in a SIP-based networkUS9319530Apr 4, 2011Apr 19, 2016Verizon Patent And Licensing Inc.Method and system for providing telemetry, verification and/or other access in a SIP-based networkUS20060187943 *Feb 16, 2006Aug 24, 2006Samsung Electronics Co., Ltd.Handoff system and method between different kinds of devices, SIP server and operational method of SIP serverUS20070047698 *Sep 1, 2005Mar 1, 2007Henry KafkaSystems and methods for providing call monitoring service for multiple telecommunications unitsUS20070047704 *Sep 1, 2005Mar 1, 2007Henry KafkaSystems and methods for providing a telecommunications extension service for multiple telecommunications unitsUS20080046478 *May 1, 2007Feb 21, 2008Indrek MandreSynchronising contactsUS20080175229 *Jul 13, 2007Jul 24, 2008Joo-Hong LeeSystem for blind/attended transfer in session initiation protocol (SIP)-based network and method of controlling the transferUS20090225974 *May 20, 2009Sep 10, 2009Henry KafkaSystems and Methods for Providing Call Monitoring Service for Multiple Telecommunications UnitsUS20100027531 *Jul 27, 2009Feb 4, 2010Akihisa KurashimaCommunication control apparatus, system, method and programUS20100067681 *Nov 20, 2009Mar 18, 2010At&T Intellectual Property I, L.P.Systems and methods for providing a telecommunications extension service for multiple telecommunications unitsUS20110158132 *Jun 30, 2011Verizon Services Organization, Inc.Method and system for providing call screening in a packet-switched networkUS20130163042 *Dec 17, 2012Jun 27, 2013Toshiba Tec Kabushiki KaishaFacsimile apparatus, facsimile system, and home gatewayWO2007125427A2 *Apr 27, 2007Nov 8, 2007Skype LimitedSynchronising contactsWO2007125427A3 *Apr 27, 2007Jan 24, 2008Teet KonnussaarSynchronising contactsWO2008073993A1 *Dec 12, 2007Jun 19, 2008Qualcomm IncorporatedSession establishment in a group communication system* Cited by examinerClassifications U.S. Classification370/352International ClassificationH04L12/66Cooperative ClassificationH04L65/4007, H04M7/0063, H04L29/06027, H04M3/42212, H04M3/54, H04M3/42187, H04M3/58, H04M3/42314, H04M3/428, H04M3/42374, H04M3/42127, H04M3/46, H04M2203/2044, H04M3/546, H04M3/5108European ClassificationH04M3/46, H04M7/00M6, H04L29/06C2, H04M3/42P, H04M3/42F, H04L29/06M4ALegal EventsDateCodeEventDescriptionSep 30, 2004ASAssignmentOwner name: NIMCAT NETWORKS INC., CANADAFree format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:POUSTCHI, BEHROUZ;DO, TU;REEL/FRAME:015852/0589Effective date: 20040928Mar 17, 2006ASAssignmentOwner name: AVAYA CANADA CORP., CANADAFree format text: MERGER;ASSIGNOR:NIMCAT NETWORKS INCORPORATED;REEL/FRAME:017322/0265Effective date: 20060101Owner name: AVAYA CANADA CORP.,CANADAFree format text: MERGER;ASSIGNOR:NIMCAT NETWORKS INCORPORATED;REEL/FRAME:017322/0265Effective date: 20060101RotateOriginal ImageGoogle Home - Sitemap - USPTO Bulk Downloads - Privacy Policy - Terms of Service - About Google Patents - Send FeedbackData provided by IFI CLAIMS Patent Services