When referring to VoIP and IP telephony the main focus is around voice services, such a consideration may mislead users making them thinking that these kind of solution are only related to voice. IP telephony standards (see Chapter 2) do have the capabilities of signalling and initiate multimedia communications. This scenario details how voice over IP technologies / standards and videoconferencing solutions may be seamless integrated. The goal is to provide the users with a global architecture derived from IP telephony standards giving videoconferencing systems the chance of being adopted on a broad area. Videoconferencing systems have the task of making people feeling like they are all sharing the same space and communicating as they were in the same room. Successful videoconferencing is when technology is no longer noticeable. Even if the perceived quality of video and audio plays a very important role in fulfilling such a requirement, there are a number of other factors influencing the overall quality of videoconferencing that only the integration with IP telephony may provide:
- 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 on how to find reachability information about the party to call;
- value added services, data/applications sharing and voice mail are only two example of value-added services not feasible with classic telephony systems which 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 start detailing 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 basic ones with enanched facilities, here we report 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 intercompany 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 into a classroom and private lessons group of students located in different locations are educational processes using videoconferencing tools.
- Customer Services - Videoconferencing-based customer services enable call centers to be more effective while interacting with customers.
- Justice services - Many legal systems introduces the use of videoconferencing to enable police officers to attend legal proceedings. This optimizes the time police need to spend in jails and courthouses.
- Virtual/Remote Laboratories - Remote laboratories allow researchers to share advanced appliancies using existing network infrastructure. As the Telemedicine application specialized devices may be required to enable high-quality video contents not available with the standard videoconferencing systems; moreover, special considerations applies when such interaction modes are considered.
A successful integration scenario would require, from the application side, application specific devices (for basic meetings maybe simple desktop conferencing equipments may be enough) to deliver the content to the end-user and, from the technical side, servers (to build a global architecture accessible by all group user), gateways (to provide interoperability with different access technologies and different IP telephony protocols), conference bridges and multipoint conferencing units (to provide multipoint capabilities for multipoint conferencing). The user advantages in deploying such advanced collaborative environments are clearly evinced if thinking at the returns in terms of time, travel costs, productivity and equipment acquisition.
At the SURFnet offices an integrated voice and video environment is setup based on H.323 technology (endpoints, MCU and gateway), cisco Callmanager (Skinny), and a PBX. This therefore also is an example of scenario 2b (Integration with legacy PBX systems). Figure 3.x gives an overview of the components and how they are connected.
The goal of the integration of voice and video over IP was to make it possible to abstract from the device the user wants to use to communicate. When someone contacts him/her at the SURFnet office by any means (PSTN or H.323 of H.320). The components necessary to establish such an integrated infrastructure are:
- a PBX, connected to the PSTN, in our case a Philips Sopho, to handle all incoming regular voice calls;
- a H.323 gateway, in our case a Radvision L2W (LAN to WAN H.323) gateway, on the one side connected to the PBX (by ISDN2 lines) and on the other side to the local IP network;
- a H.323 gatekeeper, in our case the build-in gatekeeper at 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 our case a Cisco Callmanager, being the gatekeeper performing PBX-like functions for the IP-phones;
- endstations, being the user's terminal(s).
The terminals used here are:
- IP phones, in our case Selsius and Cisco IP phones, registered to the Callmanager;
- H.323 videoconferencing stations, in our 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 our case Philips, registered at the PBX;
For allowing multipoint calls a MCU (Radvision MCU323) was added and the conference feature on the PBX was enabled. These are not necessary functionalities, but can enhance the communication experience.
The means by which integration was established was the unique Numbering and Dial Plan. We follow the Global Dialling System (GDS, see section on dialplans and http://www.wvn.ac.uk/support/h323address.htm fully and decided to use the full E.164 addressing and number our videoconferencing and IP tel endpoints like they were regular phones. Thereby we guaranteed that even if the terminals were called/dialed from the PSTN the number would be routed to the SURFnet PBX. Also the other way around, from the voice and video over IP terminals any regular PSTN number could be dialled without the need for rewriting. 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, Egon's phone number is 030-2305367, or international number 0031302305367. His IP phone number is 030-2305167. For demonstration purposes he also numbered his H.323 station 030-2305367. 00 is the international access code in the Netherlands, 030 is the area code of Utrecht (the city the SURFnet offices are located), 23053 and 23051 are the prefixes/numberblocks SURFnet bought and 67 is the local, office number assigned to Egon (Note: to Egon and not his devices, because there is more than 1 numberblock that holds 67 (367 and 167).
Egon 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 service at the office gatekeeper (with the prefix 5) and connected to the PBX. In the PBX 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 as webbased service so people can maintain their own records and preferences. At the PBX also the group number (for making all telephones in a group ring) 501 for the group Egon belongs to is defined. At the gatekeeper the 500 number is configured as backup number that will be called if the H.323 call doesn't get answered. The IPphones are registered with their 1xx number (in my case 167) at the Callmanager which itself is registered as a gateway serving all these numbers (so 167, 109, 1xx etc) at the gatekeeper.
We can distinguish the following situations (not complete list of possibilities, but a couple of descriptive ones):
a) a user on the PSTN calls Egon 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 in his tables for a terminal with number 67, finds it as Egon's H.323 station and forwards the call. The ISDN signalling is done between the PBX and the gateway and the call is setup. Egon answers the incoming call on his videoconferencing station, only getting audio since there is no video attached to the signal from the PSTN user. If Egon doesn't answer 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 make all phones in the group ring. Egon or one of his colleagues can than answer the call by picking up any of the phones in the group.
b) a user using an IP phone dials Egon's phone number. For this example Egon 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. This 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 Egon's IP phone. Someone using a H.323 videoconferencing station finds Egon'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 teh Callmanager and routes the call there. The callmanager acts as a H.323-Skinny gateway and forwards the call to the IPphone.
Note. If Egon had also used the number 030-2305367 for his IPphone he would have had to make the choice at the gatekeeper to route all calls to the H.323 VC terminal OR to the IPphone, since there cannot be two devices registered with the same alias (E.164 no.) at the same gatekeeper.
Local dialling between the systems is supported to, Egon can call 97 from his phone to reach his H.323 station, or 167 to reach his IPphone. The other way around (from IPphone 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 then people, either using a PSTN device or a H.323 IP phone or 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 Adressing.