This section lists some examples on how a zone setup could look like depending on the requirements.
Assumption: An institution currently using a PBX with internal numbers of four digits length. There telephone numbers from 6000 to 6999 are available for IP telephony. There are no requirements regarding authentication. Because only calls into the PSTN shall be billed the PBX is the only place where billing shall take place. There are no special requirements regarding availability and there is no demand for IP telephony research.
Components: Any kind of IP telephony server (H.323 gatekeeper or SIP proxy)- even productions using proprietary protocols are usable. The gateway must be able to translate signaling between the protocol that the server uses and the PBX. The protocol to the PBX usually uses one of the protocols described in Section 5.1.1.
Structure: See Figure 4.11.
Call Routing: The PBX is configured to route every call to a number starting with 6 to the gateway. The IP telephony server either has the gateway as a default route for unknown/unregistered targets or is configured to route every call to a number that does not start with 6 to the gateway too. The gateway can either be configured to always route a call from one side to the other or needs to be get a configuration similar to the IP telephony server.
Authentication: Authentication on the IP side is either done using the H.323 or SIP authentication mechanisms or can be done on the link layer. In the latter case a telephone number is bound to a specific port or MAC address.
Billing: The billing mechanisms that were already in use for PBX calls can be used for IP telephony as well as all outgoing calls pass the PBX.
The described solution allows an easy integration of IP telephony into a PBX world. The gain of this solution compared to just more legacy phones is that IP telephony allows more flexibility regarding the endpoints - allowing hard- and software phones that may even be connected by wireless LAN (depending on the authentication mechanisms used).
The problems of this solution are that it heavily relies on the PBX that remains the core element of the infrastructure. If once there is demand for more IP telephony accounts more number blocks must be available - to free such a block requires giving legacy phone users to numbers. The solution also is not prepared to make use of the Internet for long distance calls or select an IP telephony service provider.
Assumption: A university with multiple locations, a shared unstructured dialing space and need for borth SIP and H.323. It should be possible to test new IP telephony server firmwares before installing them in the production network. To stretch this idea further an additional requirement is that the IP telephony system has to be divided into three logical networks: a production network (the telephone system for 90% of all employees), a testing network to run new firmware versions before deploying them in the production network, and a research network for IP telephony related research work. Obviously the networks differ in reliability - having high reliability requirements in the production network and nearly none in the research network. A daring user might decide to participate in the testing network - without changing his phone number or using a second phone.
Components: To be able to do IP telephony research on standardized protocols the research network runs either a H.323 gatekeeper or a SIP proxy. The production network runs a redundant server that supports H.323 as well as SIP. The testing network uses the same server model - without redundancy. The gateway is either a H.323/PSTN or SIP/PSTN gateway. A RADIUS server stores all valid users (names and numbers) along with their password. The billing records can be written by the PBX and the IP telephony server - e.g. using a SQL server.
Structure: Figure 4.12 describes how the servers are organized. There is a H.323 gatekeeper or SIP proxy for each logical network. Which logical network an endpoint belongs to is simply defined by which server it is registered with and is independent from the physical network structure. To participate in testing of new features, the endpoint of the user need only be configured to register on the server using the new firmware version.
Call Routing: Routing decisions are either made using a shared database (see Section 4.1.1.1.3) or by routing calls to external targets via the server in the production network to the PBX gateway. A server whose user dials an internal number tries other locally registered endpoints first, before asking the peer server using the LRQ mechanism of H.323.
Authentication: To achieve authentication the mechanisms described in Section 4.3 are used. The authentication backend is provided by a RADIUS server that stores logins and passwords.
Billing: Because external calls are routed through the PBX the existing billing solution may be used. If the production network gatekeeper is able to write billing records as well, it will become the production billing server when sometime in the future the university selects an IP telephony provider instead a PSTN Telco.
This scenario is quite complex, but it is the most flexible. It allows individual users to move from the legacy telephony world to IP telephony, eventually reducing the PBX to a minimal state. It is made robust by using redundant servers where necessary. Because routing decisions are made on the IP side, this solution qualifies for communication with external targets via the Internet or through use of an IP telephony provider. The decision for open standards (SIP, H.323) allows soace for research initiatives and prevents dependencies on specific vendors.
All these possibilities come at a price. Several servers must be bought and the complex structure makes it harder to trace errors.