Table of Contents
- 4.1. General concepts
- 4.1.1. Architecture
- 4.1.2. Robustness
- 4.1.3. Management issues
- 4.2. Dialplans
- 4.3. Authentication
- 4.3.1. Authentication in H.323
- 4.3.2. Authentication in SIP
- 4.4. Examples
- 4.5. Setting up H.323 services
- 4.6. Setting up SIP services
- 4.6.1. Operation of SIP Servers
- 4.6.2. SIP Express Router
- 4.6.3. Asterisk
- 4.6.4. VOCAL
- 4.7. Firewalls and NAT
- 4.7.1. Firewalls and IP telephony
- 4.7.2. NAT and IP telephony
- 4.7.3. SIP and NAT
In Chapter 2 we saw how the H.323 and SIP protocols work. This chapter explains how to set up an infrastructure including H.323 and/or SIP components while given real world configuration examples for popular equipment. The focus will be on setting up basic services, meaning the equipment that are necessary to provide basic call services authentication and billing.
Before giving examples on how to set up SIP or H.323 zones using equipment from specific vendors this section introduces the general concepts. With these concepts in mind it will be easier to understand the vendor specific parts that follow.
Chapter 2 introduced us to the architectures of pure H.323 and SIP environments. Basically, there is one central server and multiple telephony endpoints registering with that server. The server's task - next to others - is to resolve a dialed address to an IP target. However, when we talk about real world set-ups this server infrastructure tends to be more complicated. Reasons for this are:
- Usage of redundant servers to increase availability or provide load balancing (see Section 4.1.2)
- Usage of multiple servers - e.g. for branch offices
- More than one signaling protocol
There are two possibilities to support multiple signaling protocols within one zone: have servers with built-in support for every protocol or have dedicated servers for each protocol and signaling gateways between them.
A server that supports more than one signaling protocol (see Figure 4.1) is the best solution. It is easier to manage since there is just one configuration to take care of and there will not be any problems with server-to-server interaction.
Unfortunately there seems to be no equipment that provides fully featured SIP and H.323 support on the same machine.[1]
If a zone includes both a SIP-proxy as well as a H.323 gatekeeper then call routing inside the domain becomes an issue. A signaling gateway is required to enable a H.323 endpoint to call a SIP endpoint and vice versa (see Figure 4.2).
The gateway is used to translate signaling between the two worlds. The media stream may still be exchanged directly between the endpoints, but eventually (see Section 5.1.4.4) the gateway needs to transcode different codecs, even if both endpoints support the same codec. This problem might occur, if either the gateway or the entity calling the gateway (endpoint or gatekeeper) does not support FastConnect (Section 2.2.1.5.1).
A architectural problem similar to the last one is the usage of servers that feature a proprietary IP telephony protocol and provide a SIP or H.323 interface that is limited to basic call functionality without any supplementary services or security features. An example for this is the popular Cisco CallManager™.
The most common scenario for introducing IP telephony systems is to integrate them with an existing PBX. On the technical side this usually involves a gateway that translates between H.323 or SIP and QSIG or other protocols over an S2M interface. The services that can be provided between the legacy PBX and the IP world will depend on the QSIG implementation of the PBX and the Gateway vendor. There is no general advice here but to test before buying.
Beside technical aspects, organizational aspects of PBX-VoIP integration call for careful planning and analysis. The question here is how to integrate legacy and IP telephony equipment into the dialplan of an organization. Is it necessary the phone number to reflect whether the participant is a VoIP user or a PBX user?
Generally, there are three possibilities to explore as explained below. You may find more details on setting up an IP telephony gateway in section Section 5.1.
This option requires that in the dialplan there is a numberblock available for IP telephony use. It is easy to implement on legacy PBXes and IP telephony servers but results in new phone numbers for every user that switches from legacy to IP telephony.
In this example the PBX is configured to forward every call starting with the prefix 8 or 9 to the gateway. The gateway passes the call to one of the IP telephony servers depending on the prefix 8 or 9. Unknown target prefixes are routed to the legacy PBX. An IP telephony server just needs to route all internal calls with unknown prefixes to the gateway.
Per number routing on the PBX. When migrating from an legacy PBX towards IP telephony it is often required to provide seamless migration for users switching over from the PBX to the IP world, e.g. when a user decides to switch to IP telephony but wants to keep his telephone number.
This is quite easy to achieve by setting up a database that stores the information for telephone numbers that belong to the PBX or the IP world. (See Figure 4.4). The IP telephony server and the PBX access the same data to decide where to route a call. Calls to external targets are routed to the PBX and out into the PSTN.
There are variations to this scenario. Indeed, it is quite unusual that an IP telephony server uses the same database as the PBX, unless they are from the same manufacturer. Then there are two possibilities: setting up a second database suitable for the IP telephony server (and risk inconsistencies) or let the IP telephony server route calls to unregistered targets to the PBX. The latter is easier to implement but prevents the discarding of the PBX and the use of IP telephony providers in the future.
A similar but more complex scheme is the variant where there is more than one IP telephony server in the IP world - e.g. a server for each signaling protocol used. In this case there needs to be a database that not only contains the information about which number shall be reached on the PBX and which in the IP world, but also the information which IP server (and signaling protocol) to use.
The first scenario uses two gateways and thus allows the PBX to decide where to route a call to. The IP telephony servers route calls they cannot resolve locally through a dedicated gateway to the PBX and let it make the routing decision. If both IP telephony servers support the same signaling protocol they may contact each other directly (see Section 4.1.1.2).
The second scenario uses only one gateway so the PBX does not need to know which IP telephony server to contact anymore but merely the fact that the call has an IP target.The components in the IP world share a common configuration database that locates a specific number on server A (e.g. a SIP proxy) or B (e.g. a H.323 gatekeeper). This allows any server or gateway component to make routing decisions.
The described scenario may vary in many ways. The assumption that all IP components use the same routing database is often difficult to achieve, especially if products from different manufacturers are used because there is no common format for such entries. In this case it might well be that a separate database is maintained for each component - leading to administrative overhead for their synchronization with a high risk of inconsistency.
The bigger an institution is the more complex its organizational infrastructure is. This may be due to the need to support multiple locations (sites) or because certain organizational units need to administrate their own communication solutions (and eventually do not adhere the institution's standard procedures). Either way, the IP telephony system probably consists of more than one server, all with the need to share the same dialing space.
One possibility of connecting two or more networks is to give each network a different prefix and make routing decisions based upon those prefixes. This works best if the current PSTN dialplan already provides these prefixes, e.g. in the form of area codes plus subscriber prefix.
This is the classic Branch office scenario that is based upon the assumption that both networks have different locations and dialing prefixes already exist in the PSTN. This is the same problem as the one already addressed in Section 4.1.1.1.1.
Prefix based routing fails to work if you have more than one IP telephony server and a PBX - all of them within the same dialing address space - and want to allow users to change their legacy PBX phone for an IP phone without switching to a new phone number.
An example of such a scenario is a university that has no structure in its PBX dialplan and that now introduces IP telephony, but has a computer science faculty that runs its own IP telephony server. How does the system know where to route a dialed number?
Obviously a central database storing routing information for each phone number would be a good idea (see Figure 4.7). This usually works only if all routing entities support the same kind of database - meaning that the legacy PBX and the new IP telephony server must share the same database. Such a solution is most probably only possible if the PBX and the IP telephony server come from the same vendor.
More likely is a solution where a PBX "knows" which numbers are located in the IP world and the IP telephony servers use a shared database that defines which number belongs to which server. If there are different types of IP telephony servers it may be that they are unable to share a common routing database in which case each server has its own database - resulting in administration overhead and risk of inconsistency.
The previously introduced possibilities required some kind of static configuration to bind a number to a specific server. These scenarios usually end up in using at least one routing database - but often more. The requirement for such a burden has its roots presumably in the classic PBX mentality of static configuration. In the IP world the network offers the possibility to carry information from one server to another so that IP telephony protocols provide the means to dynamically exchange routing information. The mechanisms can generally be divided into Push and Pull techniques. When using a Push mechanism a server informs its peers of every endpoint that registers or unregisters from the server, thus allowing its peer servers to immediately make routing decisions immediately if necessary. On the other hand, care must be taken of the fact that servers that are integrated later will be sync-ed.
Pull mechanisms are used when a server asks its peer servers for an target address when it needs to resolve an external target address. The peer giving a positive reply receives the routed call (see Figure 4.8)
In H.323 trunking is achieved by LRQ messages (see Section 7.1.1. SIP has no extra mechanism for address resolution but is able to fan out a call to multiple servers at once. Both signaling protocols may use TRIP (see Section 7.1.3) to distribute numeric addresses - but not names.
A highly available telephony infrastructure must deal with the fact that an IP telephony server might crash or be down for administrative reasons. Telephony services can be affected adversely in various ways, when a server goes down and another server takes over. The following are some approaches for implementing robustness in the server infrastructure.
The first approach is to set up more than one server for a zone and treat them as separate routers (see Section 4.1.1.2.3) that share the same configuration. In this case, there is no replication of registration or call data across multiple servers.
If the primary server fails, a calling phone eventually will not even notice at first because the UDP media stream usually is transmitted directly between the two endpoints. But the TCP signaling connections do not survive such a crash and so the first TCP message sent afterwards leads to an error and very likely to a call clearing.
A phone that is not currently in a call has no way of detecting a server crash in time. After its registration period expires it will try to refresh its registration with the primary server and fail. It then needs to find a new IP telephony server. H.323 provides a mechanism called “Alternate Gatekeeper” which basically defines that a gatekeeper registering an endpoint informs it of possible secondary gatekeepers that can be used alternatively. The telephone stores this information and in case of a server failure tries to contact the other listed gatekeepers.
Another possibility that works for SIP and H.323 is to configure a prioritized list of H.323 gatekeepers or SIP proxies in a DNS SRV record for the zone. This requires that the telephone is aware of its DNS domain and is able to query DNS servers - a concept that is common in the SIP world, but seldom found in H.323 devices.
In general, without synchronization between the replicated servers the failure of one server normally results in the loss of all calls. The server loss is discovered at least after the defined registration timeout, which usually is measured in minutes - but theoretically can also be set to days. After that time the phones should be able to find an alternate IP telephony server to register with.
- Another approach is to use servers that maintain replicated registration data while only one of them is the active server, and the other is the standby server. If the active server fails the standby server detects this instantly and can use the replicated information about which devices are registered to inform all endpoints (phones) that it is now the new active server. As a result, the outage will be noticeable only for a few seconds - of course, active calls will still cleared, and definitely not resumed.
If the previous approach is pushed a bit further both servers could replicate every kind of state they keep internally, down to the connection layer. In case the active server crashes, the other system takes over and can announce (via ARP) the same MAC address as the crashed server. This kind of "Hot Standby Server" would take over instantly and seamlessly, allowing even ongoing calls to continue without noticeable interruption.
In terms of server infrastructure, this is the most advanced and complicated solution a manufacturer could implement. It does not require the phones to be intelligent or support any kind of robustness mechanisms. The downside of this approach is that the ARP rewriting mechanism might not work in switched networks - which would force both servers to be in the same shared network segment.
A general advice on which kind of robustness mechanism to use is hard to give. The third solution allows the use of "dumb" endpoints because operation of the backup server is completely transparent to them, reducing the cost of endpoint equipment. The other two solutions offer the possibility to put the redundant server into different buildings - allowing the telephone system to operate even if one building burns down. A general observation is that telephones having the capability to switch servers immediately are not very common, and servers supporting Hot Standby as described above are equally hard to get.
Every manufacturer that offers IP telephony solutions implements some robustness mechanism or another. One should just be aware of the endpoint requirements that must be met to take advantage of the mechanism offered.
When setting up an IP telephony infrastructure certain issues concerning administration tasks should be considered ahead of time.
Having to migrate legacy and IP telephony gives rise to the problem of maintaining multiple account databases. The legacy PBX already has a configuration that defines valid numbers. The same usually applies to an IP telephony server (see Figure 4.4). A shared configuration database for both the PBX and the IP telephony server is very uncommon, unless they are of the same manufacturer and have similar configuration interfaces. Of course, keeping two separate databases consistent is difficult on the long run.
To make this problem even worse it is possible that the gateway between the IP and the PSTN world needs access to the valid numbers as well. Potentially, this implies a third database with valid numbers - making the administration of telephony accounts (e.g. creating a new account or moving one account from legacy telephony to IP telephony) a tough job.
Another issue occurs regarding the question who is allowed to administrate what in the telephone system. In classic environments there is a small group of PBX administrators that sits in a special location while the network world - at least on campuses - often consists of locally administrated networks.
When introducing IP telephony there is the chance - or pitfall, depending on your point of view - to apply the structures from the network world to the telephony world. For instance consider an IP telephony infrastructure of a university that gives every student a telephony account. At the start of the semester several hundred new accounts must be created. To reduce the workload this could be delegated to administrators of the different departments. Or consider a research staff member that moves from one office to another which might require a configuration change when using port based authentication. It would be fine if this changes might be done decentralized.
Decentralized administration does not necessarily mean that all administrators have the same permissions. An IP telephony server might for example separate the permission to change account data from the permissions to view the call detail records.
Many available products allow remote administration through a web interface which generally allows decentralized administration. If different administration permissions can be granted highly depends on the products used.
[1] Actually there is a product that claims support for both SIP and H.323 protocols: the Asterisk™ PBX http://www.asterisk.org/. How well it supports SIP and H.323 is not yet known.