When referring to VoIP and IP telephony the main focus is on voice services, which may be misleading regarding the support of video. IP telephony standards (see Chapter 2) do have the capabilities of signaling and are able to initiate multimedia communications. This scenario details how voice over IP technologies / standards and videoconferencing solutions may be seamlessly integrated. The goal is to provide the users with a global architecture derived from IP telephony standards, giving videoconferencing systems the chance of becoming widely used and adopted. Videoconferencing systems have the purpose of facilitating meetins of remote participants, and to support the illusion that they are all sharing the same space and communicating as if they were in the same room. Perfect videoconferencing sessions are achieved when the technology is no longer noticeable. Even though the perceived quality of video and audio plays the most important role, there are a number of other factors influencing the perception of successful videoconferencing:
- accessibility of the system, the system should be accessible on a broad area giving users the easiest way of communicating without worrying on how to join a conference or how to find reachability information on the party to call;
- value-added services, such as data/application sharing and voice mail, are only two examples of value-added services which are not feasible with classic telephony systems, yet may improve the quality experienced by the user;
- interoperability among different technologies: the system should be transparent to different technologies in order to give the users the chance of having seamless connectivity.
In order to describe the possible integration scenario of VoIP and Videoconferencing we need to examine which are the possible applications related to the Videoconferencing scenario. Basic use of videoconferencing systems relates to meetings (special cases of meetings are classroom and collaboration meetings); more specific applications may be developed on top of the basic functionality, with enanched options. Here we cite a set of the most significant applications:
- Telecommuting - Telecommuting is a broad term referring to corporate employees who interact electronically with corporate resources and people. Extensions of the term refer to the individual interaction and collaboration that takes place between home-based consultants and inter-company business partners.
- Telemedicine - Videoconferencing solutions delivering high-quality video images to remote medical specialists. Specialized videoconferencing devices may be required to enable high-quality video contents not available with the standard videoconferencing systems.
- Distance Learning - Video lectures, remote guest speakers invitation to a classroom and private lessons to groups of students located in different locations are some of the educational processes requiring the use of videoconferencing tools.
- Customer Services - Videoconferencing-based customer services enable call center operators to be more effective while interacting with customers.
- Justice services - Many legal systems introduce the use of videoconferencing to enable police officers to attend legal proceedings. This optimizes the time police need to spend in courthouses.
- Virtual/Remote Laboratories - Remote laboratories allow researchers to share advanced appliances using existing network infrastructure. In the Telemedicine, specialized devices may be required to enable high-quality video contents (not available with the standard videoconferencing systems) to be transmitted; moreover, special considerations apply when such interaction modes are considered.
A successful integration scenario would require, on the application side, application specific devices (for basic meetings, simple desktop conferencing equipment may be enough) to deliver the content to the end-user and, on the technical side, servers (to build a global architecture accessible by all group users), gateways (to provide interoperability with different access technologies and different IP telephony protocols), conference bridges and multipoint conferencing units (to provide capabilities for multipoint conferencing).
In order to give the reader an understanding of a complex scenario, such as the integration of voice and videoconferencing over IP, we describe here an example actually implemented at the SURFnet offices in The Netherlands. An integrated voice and video environment is a setup based on H.323 components (endpoints, MCU and gateway), a Cisco CallManager (using the Skinny protocol), and a PBX. Therefore this is also an example of scenario 2b (Integration with legacy PBX systems). Figure 3.8 gives an overview of the components and how they are connected.
The goal of the integration of voice and videoconferencing over IP was to make possible to refer directly to the user without knowing his location and what terminal is actually using. When someone contacts the user by any means (PSTN or H.323 of H.320), the call should be completed by reaching any device the user may have operational. The components necessary to establish such an integrated infrastructure are:
- a PBX, connected to the PSTN, in this case a Philips Sopho, to handle all incoming regular voice calls;
- a H.323 gateway, in this case a Radvision L2W (LAN to WAN H.323) gateway, on the one side connected to the PBX (by 2 ISDN lines) and on the other side to the local IP network;
- a H.323 gatekeeper, in this case the build-in gatekeeper of the Radvision gateway, to route all calls on the IP network, including making decisions when to route the call off-net (to the PSTN through the PBX);
- a Callmanager, in this case a Cisco Callmanager, being the gatekeeper to performing PBX-like functions for the IP-phones;
- endstations, being the user's terminal(s).
The terminals used here are:
- IP phones, in this case Selsius and Cisco IP phones, registered on the Callmanager;
- H.323 videoconferencing stations, in this case VCON EscortPro boards in PCs with Meetingpoint 4.6 and Polyspan Viewstations (128 and FX), registered at the H.323 gatekeeper;
- regular DECT phones, in this case Philips, registered at the PBX;
For allowing multipoint calls a MCU (Radvision MCU323) has to be added and the conference feature on the PBX to be enabled. These are not necessary functionalities, but can enhance the communication experience.
The means by which integration was established was the Dial Plan that guaranteed unique number addressing for all devices. The Global Dialing System (GDS, see section on dialplans and http://www.wvn.ac.uk/support/h323address.htm) was adopted, and the full E.164 addressing, number of videoconferencing and IP telephony endpoint numbering allow all terminals to be used like regular phones. Thereby it is guaranteed that for terminals called/dialed from the PSTN, the call would be routed to the PBX. Also the other way around, from the voice and video over IP terminals any regular PSTN number could be dialed, without the need for rewriting the dial string. GDS is supported by the ViDeNet H.323 gatekeeper hierarchy, which resembles the phone system in that it is a hierarchy of distributed gatekeepers that route IP calls based on prefix resolution.
In the examples below, "A"'s phone number is 030-2305367, and his international is 0031302305367. His IP phone number is 030-2305167. For demonstration purposes he has also registered his H.323 station as 030-2305367. 00 is the international access code in the Netherlands, 030 is the area code of Utrecht, 23053.. and 23051.. are the prefixes/numberblocks SURFnet has control of and 67 is the local office number assigned to "A" (Note: to "A" and not his devices, because there is more than 1 numberblock that holds 67 (367 and 167).
"A" registers his H.323 station with the number 67 at SURFnet's office gatekeeper, which itself is registered with prefixes 3023051 and 3023053 at the Dutch national gatekeeper, which itself is registered with prefix 31 at the ViDeNet root gatekeepers. The gateway is registered as a service at the office gatekeeper (with the prefix 5) and connected to the PBX. In the PBX, it is configured that all calls to 367 and 167 have to be forwarded to the gateway. In today's PBXs this is easily configurable and can often be made available even as a web-based service, so users can maintain their own preferences. At the PBX, the group number (for making all telephones in a group ring) 501 for the group "A" belongs to is also defined. At the gatekeeper the number 500 is configured as a backup number, that will be called if the H.323 call is not answered. The IP phones are registered with their 1xx number (in this case 167) at the CallManager which itself is registered as a gateway serving all these numbers (167, 109, 1xx etc) at the gatekeeper.
We can examine the following situations (not a complete list of possibilities, but a couple of descriptive ones):
a) a user on the PSTN calls "A" at SURFnet, which has decided to take all calls on his H.323 station. When the call for 030-2305367 comes in at the PBX of SURFnet, the PBX looks for the terminal (telephone) 67. It recognizes that the call has to be forwarded to the gateway. When the call is routed there the H.323 gatekeeper picks it up and looks for a terminal with number 67, finds it as "A"'s H.323 station and forwards the call. The ISDN signalling is done between the PBX and the gateway and the call is set up. "A" answers the incoming call on his videoconferencing station, only receiving audio, since there is no video attached to the signal from the PSTN user. If "A" does not answer on his H.323 station, then the gatekeeper sees this and dials the backup number 501. The gatekeeper recognizes this as a call for the voice service at the gateway (prefix 5) and routes the call there. The gatekeeper passes it off to the PBX which makes all phones in the group ring. "A" or one of his colleagues can then answer the call by picking up any of the phones in the group.
b) a user using an IP phone dials A's phone number. For this example "A" has his regular phone registered with 67 at the PBX and his H.323 station as 97 at the gatekeeper. The H.323 IP phones (or the Cisco IP phones through the Callmanager) when connected to the GDS/ViDeNet system can find each other through that hierarchy. If someone using an IP phone dials 0031302305367 then the Call manager recognizes this as an international call and forwards it to the local gatekeeper. The gatekeeper sees that it is an international call and forwards it to the ViDeNet root gatekeeper. Here the prefix 31 is recognized and the call is forwarded to the Dutch National gatekeeper. There the prefix 3023053 is recognized and the call is forwarded to the SURFnet office gatekeeper. Here the number 67 is recognized. Not having a station with 67 registered there it falls back to forwarding the call to the gateway which routes it to the PBX. Here the phone with 67 is found and the call is setup.
c) a videoconferencing station dials A's IP phone. Someone using a H.323 videoconferencing station finds "A"'s number on a card as 00312305167. He dials the number. Like in the example above, through the ViDeNet hierarchy the call gets to the SURFnet office gatekeeper who sees that the call is for 167. In its tables it finds that that number belongs to the CallManager and routes the call there. The CallManager acts as a H.323-Skinny gateway and forwards the call to the IPphone.
Note. If "A" had also used the number 030-2305367 for his IP phone he would have had to make the choice at the gatekeeper to route all calls to the H.323 VC terminal, or to the IP phone, since there cannot be two devices registered with the same alias (E.164 no.) at the same gatekeeper.
Local dialing between the systems is supported too: "A" can call 97 from his phone to reach his H.323 station, or 167 to reach his IP phone. The other way around (from IP phone or H.323 station) he needs to use a defined prefix (5 for voice calls, see above), so 5367 will ring his normal PSTN phone.
In case the MCU was involved, people using either a PSTN device, or a H.323 IP phone, or a videoconferencing station, would dial the routable E.164 number of the multipoint conference that is registered at the office gatekeeper, as if it was a H.323 terminal.
The next step towards full integration is the introduction of a SIP proxy and SIP-H.323 gateway making it possible to extend the range of used devices even further.
Note, the example above relies on a numeric dialing plan. Alphanumeric dialing and routing is implemented differently, see section 2.xx on Addressing.