Figure 4.11 Example of simple IP Telephony
P.82
[IP Telephony Cookbook] / Setting Up Basic Services
The solution described allows an easy integration of IP Telephony into a PBX world.The advantage of this solution compared to just more legacy phones is that IP Telephony allows more flexibility regarding the endpoints, allowing both hard and software phones that may even be connected by wireless LAN (depending on the authentication mechanisms used).
The disadvantage of this solution is that it relies heavily on the PBX, which remains the core element of the infrastructure. If there is demand for more IP Telephony accounts, more numberblocks must be available.To free such a block requires giving legacy phone users new numbers.The solution also does not make use of the Internet for long-distance calls or select an IP Telephony service provider.
~ 4.4.2 Example 2: An example of complex, full-featured IP Telephony Assumption: a university with multiple locations, a shared, unstructured dialling space has a need for both SIP and H.323. It should be possible to test new IP Telephony server firmware before installing it 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 standardised protocols, the research network runs either an 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 an 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 organised.There is an 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 back-end is provided by a RADIUS server that stores logins and passwords.
P.83
[IP Telephony Cookbook] / Setting Up Basic Services
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 of a PSTN Telco.
Production network
PSTN
Gateway
Billing
redundant
Gatekeeper
Gateway
RADIUS
Gatekeeper
Gatekeeper
Test network