Classifications

• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04M—TELEPHONIC COMMUNICATION
  • H04M7/00—Arrangements for interconnection between switching centres
  • H04M7/12—Arrangements for interconnection between switching centres for working between exchanges having different types of switching equipment, e.g. power-driven and step by step or decimal and non-decimal
  • H04M7/1205—Arrangements for interconnection between switching centres for working between exchanges having different types of switching equipment, e.g. power-driven and step by step or decimal and non-decimal where the types of switching equipement comprises PSTN/ISDN equipment and switching equipment of networks other than PSTN/ISDN, e.g. Internet Protocol networks
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04M—TELEPHONIC COMMUNICATION
  • H04M3/00—Automatic or semi-automatic exchanges
  • H04M3/42—Systems providing special services or facilities to subscribers
  • H04M3/54—Arrangements for diverting calls for one subscriber to another predetermined subscriber
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04Q—SELECTING
  • H04Q3/00—Selecting arrangements
  • H04Q3/0016—Arrangements providing connection between exchanges
  • H04Q3/0029—Provisions for intelligent networking
  • H04Q3/0045—Provisions for intelligent networking involving hybrid, i.e. a mixture of public and private, or multi-vendor systems

Definitions

• BACKGROUND This invention relates to communications capabilities available to businesses, specifically communications capabilities available to businesses during and immediately following disaster events.
• a disaster is characterized by any event that renders one or more sites of a business incapable of receiving and responding to telephone calls from the external world.
• Disasters are also characterized by a business site' s inability to place telephone calls to the outside world.
• the site' s communication infrastructure will be rendered inoperable viz. the Private Branch Exchange (PBX) suffers damage .
• PBX Private Branch Exchange
• the communications infrastructure may be inaccessible by business users (users) but left intact. In either case normal methods of communication by telephone are no longer available to the business.
• Hot sites are locations where the business had contracted with a third party to provide disaster recovery services and systems access to data for users. It is likely that telephone service was provided at these hot sites.
• Hot sites can be equipped to handle telephone communications in addition to providing on-line access to customer data.
• customers must provide their telephone company a switchover plan to be executed in the event of a disaster.
• the plan must be coordinated with the hot site vendor.
• the switchover can take from twenty-four to forty eight hours.
• the customer is left with no telephone communications during and immediately after the disaster event.
• PBXs since most medium to large customers have PBXs connected to the telephone company via T-I with DIDs they rely on the PBX to provide the intelligence required to direct individual calls to particular extensions. It is likely that this capability will also be lost as a result of the disaster.
• Ichikawa et al shows a method and system of ensuring that customers can place calls during emergency situations regardless of the number of regular outbound trunks in service.
• the prior art addresses telephone communications through and immediately after disaster events in U.S. Pat. No. 5,982,870 to Pershan et al .
• Pershan et al present a method for concurrently redirecting, or call forwarding, a multitude of phone numbers to alternative phone numbers and therefore locations.
• the method disclosed by Pershan et al does not allow for individual freedom of movement and does not provide an inherent capability to anticipate problems that may be a direct result of the disaster or for other reasons. For example, it is reasonable to assume that the alternate locations where lines are redirected may be inaccessible due to traffic problems caused by the disaster.
• Pershan et al There is yet another subtle but significant limitation on the Pershan et al patent for the communications continuity application. Pershan et al rely exclusively on the existing PSTN infrastructure. Indeed, this is one of the more elegant aspects of the present invention. At the same time, widespread availability of the service afforded by the Pershan et al patent has not materialized and is geographically limited.
• the invention comprises a system and method for enabling users to receive telephone calls, placed to telephone extensions at their job site, at any location they see fit so long as an Internet connection and a personal computer terminal are available.
• a system comprises a gateway device connected to the public switched telephone network (PSTN) and a geographically dispersed data network such as the Internet or a Virtual Private Network (VPN) .
• PSTN public switched telephone network
• VPN Virtual Private Network
• Said gateway is connected to a control segment comprised of a sufficient number of computers to permit controlling said gateway, storing user profiles, extensions, telephone numbers, voicemail messages, text messages, control algorithms, and other data, databases, and running the system software.
• Said users establish a connection ; with the control segment over said data network by using application software such as an Internet browser.
• Said control segment directs said gateway to establish a connection with said personal computer for the purpose of receiving phone calls normally destined for said users work extension or work phone number.
• said users will be able to receive and place phone calls through their work phone number or extension, as if they were at their normal job site, from any location where there is an Internet connection or access to a pre-established VPN.
• FIG. 1 is a schematic block diagram, according to the invention, depicting the network interconnections and associated devices to redirect telephone calls from a business' s location to data terminals connected to a VPN or the Internet.
• FIG. 2 is a block diagram depicting a generalized PBX connected to a central office switch.
• FIG. 3 is a schematic block diagram depicting a third method of connecting the system to the PSTN.
• FIG. 4 is a schematic block diagram depicting a third method of connecting the system to the PSTN through the PBX.
• FIG. 5 is a block diagram of a possible software architecture for the system depicting one embodiment of the invention.
• FIG. 6 is a flow chart showing a routine for system login and redirection of lines from central office A to the system and ultimately the user on the Internet.
• FIG. 7 is a flowchart of a sub-routine of the flowchart of FIG. 6 showing a process for updating the Telephone Extension Translation Table (STIM) of the system by users logging in using IP phones.
• STIM Telephone Extension Translation Table
• FIG. 8 is a flowchart of a sub-routine of the flowchart of FIG. 6 showing a process for updating the Telephone
• FIG. 9 is a flowchart of a sub-routine of the flowchart of FIG. 6 showing a process for registering a user's telephone applet or IP phone with the Session Initiation Protocol Server shown in FIG. 5.
• FIG. 10 is a flowchart of a sub-routine of the flowchart of FIG. 6 showing a process for creating a Session Identification number (SID) during login.
• SID Session Identification number
• FIG. 11 is a flowchart showing a sequence of steps and processes for receiving a telephone call from the PSTN by a user ' logged into the system shown in FIG. 5.
• FIG. 12 is a flowchart showing a sequence of steps and processes for making a telephone call to a number in the PSTN by users logged into the system of FIG. 5.
• FIG. 13 is a flowchart showing a sequence of steps and processes for forwarding (redirecting) telephone numbers to new numbers and locations by the system of FIG. 5.
• FIG. 14 is a simplified data model of the User Profile Database (UPD 74) of FIG. 5.
• a business site 15 houses a PBX 16 with telephone sets 17, 18, and 82 attached.
• the three telephone sets are representative of telephones for users at the business site (maybe up to several hundred or more) .
• Telephone set 82 is connected 45 to a DID line.
• Telephone sets 17 and 18 are connected to extension lines.
• the PBX 16 is connected 14, e.g. by voice T-I lines, to the Telephone Company's Central Office A (COA) 20 within the PSTN 19.
• COB Central Office B
• COB Central Office B
• COB Central Office B
• GW Voice over IP gateway
• Segment (CS) site 23 which is removed from the business site 15.
• GW 24 is further connected 50 to a local area network (LAN) 26 to which are also connected a plurality of computers of the system.
• Said computers include a WEB Server (WS) 70, the Auto Attendant Voice Mail Dialer
• the UPD contains all information necessary to administer and control the system of the invention.
• the UPD houses all of the user profiles including first name, last name, password, announcements, telephone numbers, IP addresses, etc.
• the SSD houses all transaction and performance related information viz. call start times, number of SIP registrations, failed connection attempts, connect times, online times, etc.
• the LAN 26 of FIG. 1 is connected 50 to a Router 46 which is further connected through a high speed data line 29 to a virtual private data network (VPN) 30.
• the VPN 30 is connected through a high-speed data line 31 to the Internet 32.
• Each personal computer 34 is equipped with a sound card, headphones 35, and a microphone 36.
• the connection 33 can be made through any Internet Service Provider (ISP) by dial-up, high-speed cable service, Digital Subscriber Line (DSL) , or through any other method available.
• ISP Internet Service Provider
• DSL Digital Subscriber Line
• the VPN 30 is also connected through a high-speed data line 37 to one of a possible plurality of hot sites or disaster recovery sites 38. Connection to the disaster recovery site 38 is accomplished through a router 39 that is connected to a local area network (LAN) 42 within the site 38. Personal computer terminals 34 are connected to the LAN 42 in the disaster recovery site 38.
• LAN local area network
• FIG. 2 is introduced to aid illustration of other methods of connecting the system of the invention to the PSTN.
• Connection 14 comprises direct inward dial (DID) lines implemented over digital T-I lines or analog lines. This is usually the case for medium to large businesses with many users (on the order of hundreds).
• Connection 14 may also comprise plain old telephone service (POTS) lines over T-Is or analog lines.
• FIG. 3 shows an another method of connecting the CS 23 to the PSTN.
• Connection 14 of FIG. 2 is replaced by a connection 47 from the switch 13 at the COA 20 to a GW 24.
• An Internet protocol (IP) connection 44 is made between the GW 24 and another VoIP gateway (GW) 49 at the business site 15.
• GW 49 is connected to the PBX 16 through analog or digital phone lines 47.
• An IP line 41 connects GW 24 to the router 46 of FIG. 1.
• FIG. 4 shows another method of connecting the system of the invention to the PBX 16 and the -COA 20 switch 13. Connection 14 of FIG. 1 between the central office and PBX 16 is left intact. In FIG. 4 a connection 48 is made between the PBX 16 and a GW 24. The GW 24 is connected 41 to the router 46 of FIG. 1 through a data line 41.
• FIG. 5 depicts a possible software architecture of the system of the invention for the current embodiment.
• the system controller (SC) 25 software hosts 4 software modules as follows :
• SCE System Control Executive
• SIP Session Initiation Protocol
• SS Session Initiation Protocol
• RGM Report Generator Module
• SC 25 comprises two databases in this architecture:
• SSD System Statistics Database
• the system controller is logically connected to WEB server (WS) 70 through which users log into the system from their WEB browser (WB) 60 running on their personal computer terminal 34.
• WS 70 hosts WEB pages and applets (such as the telephone applet (TA) 61 that enable users to navigate and use a plurality of user interface screens comprising administrative and other system functions (such as recording messages, playing back voice mail, entering extension numbers, etc.).
• the Auto Attendant-Voice Mail-Dialer Server (AVDS) 79 is hosted on another computer server platform and hosts three software modules and a database as follows: 1. Auto Attendant Module (AAM) 66,
• the AVDS 79 is logically connected to the SC 25 and can also establish SIP sessions with callers located in the PSTN or connected to the system.
• the Telephone Applet 61 runs in a WB 60 on the user' s personal computer terminal 34 of FIG 1.
• a calling party 63 is connected to the PSTN, and establishes a virtual connection 77 to the Telephone Applet 61 through the Gateway 24 of FIG. 1, the VPN 30 and the Internet 32.
• the original business site 15 is also shown.
• PSTN Public Switched Telephone Network
• COA Central Office A
• TDM Telephone voice trunk lines
• VoIP Voice over IP
• GW Gateway
• SC System Controller
• LAN Local Area Network
• IP Router 41 Digital data line or lines e.g. T-I or multiple T- l's
• LAN connection e.g. twisted pair, thin coaxial cable, etc
• IP LAN e.g. lOBaseT, 100BaseT, Ethernet, etc
• LAN connection e.g. twisted pair, thin coaxial cable, etc
• AAM Auto Attendant Module
• SSD System Statistics database
• MS Media Server
• SS SIP Server
• UPD User Profile Database
• VAD Voicemail & Announcements Database
• RGM Report Generator module
• FIG. 1 calls placed over the PSTN 19 to the telephone numbers assigned to telephone sets 17 and 18 reach the PBX 16 causing telephone sets 17 or 18 to ring once the calling party has entered the proper extension numbers when prompted by the PBX auto attendant.
• a preferred embodiment, shown in FIG. 1, assumes that the Telephone Company serving the business site 15 offers a service for concurrently redirecting multiple lines in the PSTN. In lieu of this, a method of redirecting the telephone lines 14 to the alternate lines 22 should be available. Such a method is made part of the system of the invention and its operation is described later. In accordance with the present invention, however, the redirection should take place on demand through manual intervention or automatically through other features available in the PSTN 19.
• a feature could be invoked at the central office 20 that redirects the lines 14 on failure of the PBX (as in "transfer on no answer") .
• Using a line forwarding method based within the PSTN obviates the need to introduce equipment at either the COA 20 or the business site 15 as shown in FIG. 3 and 4 thereby making the system of the invention more robust, less intrusive, easier to implement, more flexible, and easier to manage than the prior art including Pershan, et al.
• the user login process which is central to the establishment of calls between the user and the PSTN, will be presented prior to examining call processing by the system of the invention.
• the login process is presented by way of example and, using FIG. 1, assumes that the user has a terminal 34 which is connected 33 to the Internet 32.
• FIG. 6 is a flowchart of the login process.
• the login process resides partly in the SCE 72 software module of the SC 25 and partly in the UPD 74 (perhaps through the use of stored procedures) both shown in FIG. 5.
• the user proceeds to execute their WB 60 and enter the System Website URL, step 141.
• WB 60 brings up the system home page initiating the system user login process, step 142, and the user is prompted for a user name or account number and password, steps 143 and 145.
• step 144 in the UPD 74 or the password does not correspond to the account number
• step 145 the user is directed to re-enter the information. This is a simple procedure to authenticate the user base and can be enhanced as needed for specific applications requiring varying levels of security. It is also possible to implement X.500 or LDAP directory service authentication or other similar administrative security methodologies.
• the SCE 72 issues a query to the UPD 74 that returns a list of voice mail messages, step 146, (if any) that the user may have received while offline.
• Concurrently SCE 72 determines that the user is using a terminal 34 by querying WB 60, step 147, and generates a session ID (SID) (see FIG. 10 for process: create SID), step 148.
• SID session ID
• the session ID is bundled, or packaged, along with TA 61 by the SCE 72 which then instructs the WS 70 to download TA 61 to the users WB 60, step 149.
• Packaging the SID with TA 61 can be a accomplished in a variety of ways including:
• the SID can be transferred as part of a CAB file containing the executable code for TA 61; or (4) Combining the SID in a self-extracting file along with the TA as is done with software installation programs .
• step 150 the Session-Telephone-IP address Map (STIM) is updated. It is useful to go into some detail about the purpose and construction of the STIM.
• STIM Session-Telephone-IP address Map
• the Session-Telephone-IP address Map (STIM)
• FIG. 14 shows an example of what a STIM would look like within the current embodiment.
• the basic function of the STIM is to provide a dynamic, session dependent, logical mapping of user telephone numbers and extensions to their IP address. Since the current invention directly addresses communications continuity within a disaster context in accordance with one embodiment, it is expected that IP addresses of users of the system will change from session to session. In this context a session is defined to be the period of time a user is in the online state. Factors that create this dynamic are:
• DNS Domain Name Service
• ISPs normally implement DHCP or WINS services to enable IP address re-use. Thus each time a user connects to the Internet through their ISP the IP address assigned to their terminal 34 will be different. 3. During and post-disaster users may have to stay home or be forced to log in from a hotel, library, a friend's house, or other location making sessions temporary in most cases. When they log in again, say from another location, their IP address will be different all the way to the top-level domain.
• Point 1 above bears closer scrutiny as it represents a subtle but significant limitation overcome by creation and use of the STIM.
• IP telephony standards rely on DNS to locate users within and across domains. This approach assumes prior knowledge of the user's whereabouts within the domaion structure of the enterprise. Further, it assumes ready access to IP address maps contained in hosts and routers. None of this data exists in the diaster scenario for which the system of the invention has been designed.
• the STIM must be a self-contained, dynamically adaptive, logical entity, driven by user interaction with the system, that maps each new IP address to the corresponding user's telephone number on a session by session basis.
• FIG. 14 shows an example of a STIM in table format, for the current invention, that is a logical entity formed as a result of a query issued by the SCE 72 to the UPD 74.
• letters across the top of the table correspond to columns and numbers down the left side of the table correspond to rows .
• Row 1 contains column labels that are actually field names (or columns) from various tables in the sample data model for the UPD 74 shown in FIG. 13.
• Columns A, B, and C are formed from table User
• columns D, E, and F are formed from table Tel_Line
• columns G and H are formed from table Session in FIG. 14.
• a session ID is generated using a random number generator (or a unique sequence number generator present in most RDBMS engines), step 156.
• UPD 74 is updated by inserting the newly- created SID in table Session (in the session_id field) , step 157.
• This step is key in forming a new row in the STIM since row creation is driven by session creation or user logins. That is, in one embodiment, there will be a new row created for each session for each user.
• the SID is inserted into or packaged with TA 61 in preparation for downloading, step 158.
• Step 150 in FIG. 6 is the updating of the STIM with the IP address of the terminal 34. This process is shown in more detail in FIG. 8.
• TA 61 executes in the WB 60, step 159, and during execution it logs itself into UPD 74 as a client using the SID as a password, step 160.
• TA 61 then updates the STIM by inserting the IP address of the terminal 34 into table Session of UPD 74, step 161. This last step completes one row of the STIM thereby satisfying all conditions for the user to receive and make telephone calls over the terminal 34 through the system.
• step 151 the user is . prompted to select to accept calls or remain in auto attendant mode, step 151. If the user responds with a "no" in step 151 the account remains in auto attendant mode, TA 61 is updated with the chosen account status and the message indication received from executing step 146. Both of these data are displayed on the user interface (UI) for TA 61, step 155. On the other hand, if the user responds with a "yes" in step 151 TA 61 is registered with SS 73, step 153.
• SS 73 is the SIP server module of the SC 25. SIP was chosen for the current embodiment due to its ease of implementation, simplicity of design, and ease of troubleshooting.
• SIP call processing is much simpler than that offered by other IP telephony standards.
• SIP is a text-based protocol that "rides" on top of IP and as such makes system design and debugging relatively straightforward. Also there are significant performance gains to be had by using SIP over, say H.323 for constructing the system's call processing function. However, in other embodiments the same functionality can be achieved by using H.323, S/MGCP, or other call control and processing models and protocols. All three protocols are well understood, albeit still in the formative stages, and systems, such as the current system, can be readily by those skilled in the art. Indeed, there are numerous sources of open source code available for users agents (in the current embodiment using SIP these would be the TA 61), SIP servers, and Media Servers.
• FIG. 9 shows the "Process: Register with SS 73" which is a detail of step 153 in FIG. 6.
• the SCE 72 uses the newly created SID to issue a query to UPD 74 to obtain the IP address of the terminal 34, step 165.
• the account number (acct_num) of the present user is used to enter table Tel_Line and return the user' s telephone number
• tel_num or extension (tel_ex) .
• Acct_num is also used to enter table Session, find the most recent SID (session_id) , and return the corresponding IP address (ip_address) .
• the SCE 72 issues a third party SIP REGISTER request to the SS 73 on behalf of the users TA 61, step 166.
• SIP REGISTER request to the SS 73 on behalf of the users TA 61
• step 166 To direct call requests to the TA 61 of terminal 34 SS 73 uses the IP address.
• Both the GW 24 and SS 73 use the phone number to make call requests and proxy calls as specified in IETF RFC 2543. Thus the GW 24 forwards all incoming calls to the SS 73 as call requests. This process will be examined later in the call processing section.
• the program flow returns to FIG. 6 where the TA 61 is updated with the registration status, step 152.
• AAM 66 of the AVDS 79 is de-activated in step 154. This allows calls to be directed to the TA 61 of terminal 34 instead of to the auto attendant.
• the status of the auto attendant is reflected in the TA 61, step 152, by indication on the UI, step 155.
• the user is now ready to receive and place calls using their TA 61 through the system to the PSTN. Calls can also be placed to other users of the system without going through the PSTN so long as said users are online.
• Prouse' s number is dialed from a telephone 63 (shown in FIG. 1) on the PSTN 19. Numbers normally routed to the PBX of FIG. 1 have been redirected to COB 21.
• GW 24 receives SS7 signaling from the PSTN that a call has arrived for 301-555-5000. GW 24 forms a SIP INVITE request 5000@SS_IP_address and sends it to SS 73, step 168 in FIG. 11.
• SS__IP_address is the IP address of the SIP server SS 73 in SC 25.
• GW 24 is configured to view SS 73 as a call peer therefore all calls arriving from the PSTN are sent to SS 73 for processing and signaling by SIP proxy.
• SS 73 parses the request and strips the "5000" to form a query to UPD 74 in order to determine the most recent SID for telephone number 5000 in table Session, steps 169 and 170.
• UPD 74 returns the current IP address of user Prouse from the STIM, step 171.
• SS 73 forms and sends INVITE request to TA 61 at 172.48.96.20, step 172. This initiates the proxy call processing and, using FIG. 1, the first event at TA 61 is a ringing indication ! on its UI or through headphones 35 attached to terminal 34.
• Prouse wants to place a call through her terminal 34 to 301-333-9999, a number on the PSTN that is not in UPD 74. Conditions are as in the previous scenario. After logging in Prouse sets up her preferences for call processing (records announcements, greetings, etc.) then dials 301-333-9999 all through TA 61, step 176. TA 61 converts the dialed number to a SIP URL: 3013339999 ⁇ SS IP address and forwards an INVITE request to SS 73, step 177.
• SS 73 determines whether the dialed number is a user on the system by querying UPD 74 for the following: Prouse registration, finding 301-333- 9999 in the STIM, and user Prouse has rights to make calls to the PSTN, step 178.
• UPD 74 returns to SS 73 that Prouse is registered with rights to dial the PSTN and that 301-333-9999 is not in the STIM, step 179.
• SS 73 initiates a proxy call to GW 24 by issuing an INVITE request to 301-333-9999, step 180.
• GW 24 receives and processes the INVITE by selecting an available trunk line and initiating signaling with the PSTN to dial 301-333- 9999, step 181.
• the rest of the call processing is identical to that used for receiving calls from the PSTN ( as specified in the previous example, steps 173 through 175.
• FIG. 12 shows a flowchart of a process for achieving multiple line redirection using the capabilities of the system of the invention as described herein.
• the software to implement the flowchart could be made an integral part of the SCE 72 and its features made available to a system administrator through an appropriately crafted UI.
• the process of FIG. 12 assumes that the Telephone Company servicing the business undergoing the disaster offers remote call forwarding and that lines can be forwarded by issuing DTMF tones to a Voice Response unit (VRU) at the appropriate redirection service number.
• VRU Voice Response unit
• the program flow in FIG. 12 also assumes that certain data were entered into UPD 74 with respect to forwarding the telephone numbers for users in the database. Some of these data include:
• VRU responses may be in the form of human speech, in which case the AVDS would require a speech recognition module. Program logic would also be needed to interpret the output from the speech recognition module and direct the AVDS to respond accordingly.
• Line fowarding using the system of the invention, is accomplished by a user with administrative privileges (SYSAD) logging into the system using the site URL, step 182 in FIG. 12.
• SYSAD administrative privileges
• the redirection option from a menu provided by the system over a WEB page the SYSAD selects from all or number of telephone numbers to be redirected and selects the redirect command, steps 183 and 184.
• the redirection command is received by the SCE 72, which then:
• step 186 Issues another query to UPD 74 that returns the location of the DTMF tone sequence and responses from the redirect service for each redirection service number to be used, step 186. With the returned data the SCE 72 creates a Master Line Forwarding Plan (MLFP), step 187.
• MLFP Master Line Forwarding Plan
• the whole process for a single number may be very simple. For example, dialing the fowarding service number, detecting a simple response like a tone, and issuing #-7-3 then entering the destination number. It may be that a password is required by the redirection service in which case this too will be entered by DTMF tones .
• the SCE 25 executes a programmed loop that starts by issuing third party proxy call requests for the DM 71 to SS 73 for each number to be redirected (forwarded) , step 188. Concurrently, the MLFP loaded into fields in UPD 74 corresponding to the DM 71, step 189. This action prepares the DM 71 for issuing the proper DTMF sequences once proxy calls are connected to the AVDS 79. Proxy calls are made and media flows between GW 24 and MS 69 as required to execute the MLFP, steps 190 through 192.
• the number of simultaneous calls placed to redirection service numbers will depend on availability of outbound trunks (connected to GW 24) and the number of discrete redirection service numbers. For example, it may be that a single redirection service number could be called and the DM 71 can redirect any quantity of telephone numbers in turn during a single call.
• Certain system implementations may require verification of redirection for each number.
• a program sequence may be created that places a call to each user telephone number and detects the arrival of the call at GW 24 in the form of a proxy call request for that number. Once the proxy request with the dialed number in it is detected the SCE 72 can issue a go on-hook and proceed to the next number to be verified.
• the VPN 30 may be removed and the Router 46 directly connected to the Internet.
• the Internet 32 may be removed and terminal 34 connected to the VPN 30.
• call processing functions may be implemented with any existing or future Internet telephony protocol standard as created and produced by the Internet Engineering Task Force.
• Session Initiation protocol and call processing model another embodiment can employ the H.323 protocol and call processing model. It is intended, therefore, changes and modifications of the like described above to create other embodiments of the invention be covered by the following claims.

Landscapes

• Engineering & Computer Science (AREA)
• Computer Networks & Wireless Communication (AREA)
• Signal Processing (AREA)
• Telephonic Communication Services (AREA)
• Data Exchanges In Wide-Area Networks (AREA)

Applications Claiming Priority (1)

Publications (2)

Family

ID=38923711

Family Applications (1)

Country Status (2)

Families Citing this family (2)

Citations (1)

Family Cites Families (4)

• 2006
  • 2006-07-11 WO PCT/US2006/026757 patent/WO2008008055A2/en active Application Filing
  • 2006-07-11 EP EP06786794A patent/EP2044728A4/de not_active Withdrawn

Patent Citations (1)

Non-Patent Citations (1)

Also Published As

Similar Documents

Legal Events