Ip Telephony Cookbook
Ip Telephony Cookbook
The IP Telephony Cookbook was created through the IP Telephony project as a reference document for setting up IP Telephony solutions at university campuses and NRENs. The project started in April 2003 and ran until February 2004. The Cookbook provides an overview of available and future IP Telephony technologies, scenarios for IP Telephony deployment and infrastructures, guidelines on protocols, service set-ups and connection to a global dialling plan. Furthermore, the Cookbook reports on the interoperability of equipment, existing IP Telephony projects and regulatory aspects. The project was carried out by the University of Pisa, Italy, TZI-University of Bremen and FhG FOKUS, Germany, with contributions from CESNET, GRNET, SURFnet and the University of Graz. Funding to the project was provided by TERENA, ARNES, CARNet, CYNET, SUNET and UKERNA. Representatives of the funding organisations were members of the Project Review Committee.
ISBN 90-7759-08-6
TERENA 2004 All rights reserved. Parts of this report may be freely copied, unaltered, provided that the original source is acknowledged and the copyright preserved.
Production: TERENA Secretariat Design: Eva de Lange Printing: GraphicResult
P.2
AUTHORS: Margit Brandl - Karl Franzens - UNI Graz, Dimitris Daskopoulos - GRNET, Erik Dobbelsteijn - SURFnet, Rosario Giuseppe Garroppo - University of Pisa, Jan Janak - FhG Fokus, Jiri Kuthan - FhG Fokus, Saverio Niccolini - University of Pisa, Jrg Ott - Universitt Bremen TZI, Stefan Prelle - Universitt Bremen TZI, Sven Ubik - CESNET Uni Graz, Egon Verharen - SURFnet
P . 3
CONTENTS //
1. INTRODUCTION
1.1 1.2 1.3 1.4 1.5 Goal Reasons for writing this document Contents How to read this document Techno-economic aspects of moving from classic telephony to VoIP
2. TECHNOLOGICAL BACKGROUND
2.1 Components 2.1.1 Terminal 2.1.2 Server 2.1.3 Gateway 2.1.4 Conference bridge 2.1.5 Addressing 2.2 Protocols 2.2.1 H.323 2.2.2 SIP 2.2.3 Media gateway control protocols 2.2.4 Proprietary signalling protocols 2.2.5 Real Time Protocol (RTP) and Real Time Control Protocol (RTCP)
11
3. IP TELEPHONY SCENARIOS
3.1 Introduction 3.2 Scenario 1: Long-distance least cost routing 3.2.1 Least cost routing - an example of an implementation 3.3 Scenario 2: Alternatives to legacy PBX systems 3.3.1 Scenario 2a: IP Phones without a PBX system 3.3.2 Scenario 2b: Integration of VoIP with legacy PBX systems 3.3.3 Scenario 2c: Full replacement of legacy PBX systems 3.4 Scenario 3: Integration of VoIP and videoconferencing 3.4.1 Integrating voice and videoconferencing over IP - an example
52
64
P.4
4.3.2 Authentication in SIP 4.4 Examples 4.4.1 Example 1: simple, use IP Telephony like legacy telephony 4.4.2 Example 2: complex, full-featured 4.5 Setting up H.323 services 4.5.1 Using a Cisco Multimedia Conference Manager (MCM Gatekeeper) 4.5.2 Using a RADVI SION-Enhanced Communication Server (ECS Gatekeeper) 4.5.3 Using an OpenH.323 Gatekeeper - GNU Gatekeeper 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
135
173
184
P . 5
7.1.2 H.225.0 Annex G 7.1.3 Telephony routing over IP (TRIP) 7.1.4 SRV-records 7.1.5 ENUM 7.2 Call routing today 7.2.1 SIP 7.2.2 Using H.323 7.3 Utopia: setting up global IP Telephony 7.4 Towards Utopia 7.4.1 Call routing assistant
200
210
214
// GLOSSARY
226
P.6
Introduction //>
P.7
integration of global telephony, describing the technological solutions available for the integration of global IP Telephony and the successful replacement of classic telephony. Chapter 7 reports on today's situation, as well as migration and future trends.The last chapter contains the regulatory/legal considerations users have to be aware of when moving from classic telephony to IP Telephony.The topics here relate to the regulation of IP Telephony in Europe and in other countries outside the European Union. A large number of legal issues for classic telephony are detailed, from licensing to unbundling, and their mapping to the IP world. Finally, the IP Telephony Cookbook contains two annexes. Annex A lists and describes current and future IP Telephony Projects in Europe. Annex B gives the reader useful information about IP Telephony hardware and software, reporting hands on experience (i.e., how the devices performed, how good tech-support was, what were the workarounds for some of the problems faced, etc).
P.8
communication between scientists that might not use traditional, still relatively expensive, long-distance calls as extensively as they could use IP Telephony. Even where financial constraints are not the driving force, the potential for enhancing IP Telephony with additional services that support scientific co-operation makes IP Telephony an attractive solution. IP Telephony can provide a number of benefits beyond replacing existing PBX/PSTN telephony: Enhanced speech quality The PSTN (and most PBXs) are limited to 3.1 kHz, 8-bit/sample audio. It is likely that future IP phones can provide CD quality and possibly even stereo audio. Even where the additional bandwidth required for this extreme level of quality cannot be provided; modest codecs such as G.722 (7 kHz speech bandwidth) can be used to provide better quality than conventional telephony; Improved availability There are many aspects of availability. Lowering the cost can make telephony more available to low-budget activities. Redundancy can provide as good as (or even better) reliability than traditional telephony. Integrating telephony with location-based computing and groupawareness systems can make the communication partners much more available, or provide the means to transfer communication to a point in time where it is more appropriate than the usual interrupt-driven telephone call; Improved coverage In a similar argument, IP Telephony can be made available in places where traditional phones are often not available in a university, e.g., lab settings (in particular, student labs). Also, many universities still consider the cost of phone installations high enough to force their employees to share phones in a common office, again, not necessary when workstation-based IP Telephony is used; Improved mobility It is very easy to move an IP phone to another room.There is no need to deal with ports on the PBX and change dial numbers. Simply plugging it into an ethernet socket in a new room makes it available; Improved media integration IP phones can be enabled to add media to an ongoing call as required, e.g., viewing a picture or drawing on a whiteboard. Using workstations themselves as IP phones can facilitate providing this function, whereas the standards are not yet there for coupling traditional phones and workstations; New services As IP Telephony evolves, it can be used to provide new services (like user-defined call processing) or to integrate existing concepts, e.g., Presence, Location Awareness or Instant Messaging. Because of the open standards available for these services, they need not to be limited to vendor-specific solutions. In other words, it can be much easier to deal with issues such as CTI (Computer Telephony Integration) and so pave the way to a completely new way of understanding telephony; Research As mentioned before, the protocols and standards used for IP Telephony are open and publicly available.This allows research institutions to work on their own services and solutions.
P.9
It is important to point out that before introducing IP Telephony into the network of an organisation; several issues unknown to the old telephone system have to be taken into account. A rough, non-exhaustive list may include addressing (special subnet/VLAN for phones), Quality of Service (QoS), security, positioning of gateways, interfacing of firewalls and, last but not least, maintenance of the system (backups, spares, etc., - something not very common in the legacy PBX world). With regard to the economic aspects, the packetisation of voice using Voice over IP has given rise to new international telecommunications carriers.These carriers have distributed network architectures using the Internet as a platform.VoIP networks have an architecture offering the most efficient way to implement multilateral telecommunications agreements, thus eliminating the need for carriers to engage in hundreds of bilateral traffic agreements as are required between traditional circuit-switched PSTN carriers. Moreover, since packet networks are software driven, they can be configured more dynamically than traditional PSTN networks. For example, with a global voice over packet network, new destinations are available to all users on the network, without the need for constant additional investment. IP Telephony telecommunications companies may expand the availability of services to a wider audience. IP Telephony technologies can be used to build voice networks more rapidly and at a lower cost than legacy PSTN systems. Easier deployment of Voice over IP networks can bring the benefits of telecommunications to more people in a much shorter timeframe than would be possible with conventional PSTN networks. At the same time, not having to build extensive infrastructure provides the motivation for many companies to migrate to IP Telephony architectures.
P.10
Technological Background }
This chapter provides technical background information about the protocols and components used in IP Telephony. It introduces the relevant component types, gives detailed information about H.323, SIP and RTP as well as information about media gateway control and vendor -specific protocols.
} 2.1 Components
An IP Telephony infrastructure usually consists of different types of components.This section gives an overview of typical components without describing them in a protocol-specific context.
} 2.1.1 Terminal
A terminal is a communication endpoint that terminates calls and their media streams. Most commonly, this is either a hardware or a software telephone or videophone, possibly enhanced with data capabilities.There are terminals that are intended for user interaction and others that are automated, e.g., answering machines. An IP Telephony terminal is located on at least one IP address.There may well be multiple terminals on the same IP address but they are treated independently. Most of the time, a terminal has been assigned one or more addresses (see Section 2.1.5), which others will use to dial to it. If IP Telephony servers are used, a terminal registers the addresses with its server.
} 2.1.2 Server
Placing an IP Telephony call requires at least two terminals, and the knowledge of the IP address and port number of the terminal to call. Obviously, forcing the user to remember and use IP addresses for placing calls is not ideal and dynamic IP addressing schemes (DHCP) make this requirement even more intolerable. As mentioned before, terminals usually register their addresses with a server.The server stores these telephone addresses along with the IP addresses of the respective terminals, and is thus able to map a telephone address to a host. When a telephone user dials an address, the server tries to resolve the given address into a network address.To do so, the server may interact with other telephony servers or services. It may also provide further call routing mechanisms like CPL (Call Processing Language) scripts
P.11
or skill-based routing (e.g., route calls to WWW-Support to a list of persons who are tagged to be responsible for this subject). Finally, a telephony server is responsible for authenticating registrations, authorising calling parties and performing the accounting
{ 2.1.3 Gateway
Gateways are telephony endpoints that facilitate calls between endpoints that usually would not interoperate. Usually this means that a gateway translates one signalling protocol into another (e.g. SIP/ISDN signalling gateways), but translating between different network addresses (IPv4/IPv6) or codecs (media gateways) can be considered gatewaying as well. Of course, it is possible that multiple functionalities exist in a single gateway. Finding gateways between VoIP and a traditional PBX is usually quite simple. Gateways that translate different VoIP protocols are harder to find. Most of them are limited to basic call functionality.
{ 2.1.5 Addressing
A user willing to use a communication service needs an identifier to describe himself and the called party. Ideally, such an identifier should be independent of the user's physical location.The network should be then responsible for finding the current location of the called party. A specific user may define to be reached by multiple contact address identifiers. Regular telephony systems use E.164 numbers (the international public telecommunication numbering plan). An identifier is composed of up to fifteen digits with a leading plus sign, for example, +1234565789123.When dialling, the leading plus is normally replaced by the international access code, usually double zero (00).This is followed by a country code and a subscriber number. The first IP Telephony systems used the IP addresses of end-point devices as user identifiers. Sometimes they are still used now. However, IP addresses are not location-independent (even if IPv6 is used) and they are hard to remember (especially if IPv6 is used) so they are not suitable as user identifiers. Current IP Telephony systems use two kinds of identifiers: - URIs (RFC2396); - Numbers (E.164).
P.12
Some systems tried to use names (alpha-numeric strings), but this led to a flat naming space and thus limited zones of applicability. A Universal Resource Identifier (URI) uses a registered naming space to describe a resource in a location-independent way. Resources are available under a variety of naming schemes and access methods including e-mail addresses (mailto), SIP identifiers (sip), H.323 identifiers (h.323, RFC3508) or telephone numbers (draft-ietf-iptel-rfc2806bis-02). E-mail-like identifiers have several advantages.They are easy to remember, nearly every Internet user already has an e-mail address and a new service can be added using the same identifier.The user location can be found with a Domain Name System (DNS).The disadvantage of URIs is that they are difficult or impossible to dial on some user devices (phones). If we want to integrate a regular telephony system with IP Telephony, we must deal with phone number identifiers even on the IP Telephony-side.The numbers are not well suited for an Internet world relying on domain names.Therefore, the ENUM system was invented, using adapted phone numbers as domain names. ENUM is described in Chapter 7.
{ 2.2. Protocols
{ 2.2.1 H.323
The H.323 Series of Recommendations evolved out of the ITU-T's work on video telephony and multimedia conferencing. After completing standardisation on video telephony and videoconferencing for ISDN at up to 2 Mbit/s in the H.320 series, the ITU-T took on work on similar multimedia communication over ATM networks (H.310, H.321), over the analogue Public Switched Telephone Network (PSTN) using modem technology (H.324), and over the stillborn Isochronous Ethernet (H.322).The most widely-adopted and hence most promising network infrastructure - and the one bearing the largest difficulties to achieve well-defined Quality of Service - was addressed in the beginning of 1995 in H.323: Local Area Networks, with the focus on IP as the network layer protocol.The primary goal was to interface multimedia communication equipment on LANs to the reasonably well-established base on circuit-switched networks. The initial version of H.323 was approved by the ITU-T about one year later, in June 1996, thereby providing a base on which the industry could converge.The initial focus was clearly on local network environments, because QoS mechanisms for IP-based wide area networks, such as the Internet, were not well established at this point. In early 1996, Internet-wide deployment of H.323 was already explicitly included in the scope, as was the aim to support voice-only applications and, thus, the foundations to use H.323 for IP Telephony were laid. H.323 has continuously evolved towards becoming a technically sound and functionally rich protocol platform for IP Telephony applications.The first major additions to this end were included in H.323 version 2, approved by the ITU-T in January 1998. In September 1999, H.323v3 was approved by the ITU-T, incorporating numerous further functional and conceptual extensions to enable H.323 to serve as a basis for IP Telephony on a global scale and as well as making it meet requirements in enterprise environments. Moreover, many new enhancements were introduced into the H.323 protocol.Version 4 was approved on November 17, 2000 and contains enhancements in a number of important areas, including reliability, scalability, and flexibility.
P.13
New features help facilitate more scalable Gateway and MCU solutions to meet the growing market requirements. H.323 has been the undisputed leader in voice, video, and data conferencing on packet networks, and Version 4 endeavours to keep H.323 ahead of the competition.
{ 2.2.1.1 Scope
As stated before, the scope of H.323 encompasses multimedia communication in IP-based networks, with significant consideration given to gatewaying to circuit-switched networks (in particular to ISDN-based video telephony and to PSTN/ISDN/GSM for voice communication).
Internet / Intranet H.323 Terminal H.323 Gatekeeper H.323 MCU H.323 Gateway H.323 Terminal ISDN H.320
PSTN H.324
Internet/Intranet SIP
Figure 2.1 Scope and components defined in H.323 H.323 defines a number of functional / logical components as shown in Figure 2.1: - Terminal Terminals are H.323-capable endpoints, which may be implemented in software on workstations or as stand-alone devices (such as telephones).They are assigned to one or more aliases (e.g. a user's name/URI) and/or telephone number(s); - Gateway Gateways interconnect H.323 entities (such as endpoints, MCUs, or other gateways) to other network/protocol environments (such as the telephone network).They are also assigned one or more aliases and/or telephone number(s).The H.323 Series of Recommendations provides detailed specifications for interfacing H.323 to H.320, ISDN/PSTN, and ATM-based networks. Recent work also addresses control and media gateway specifications for telephony trunking networks such as SS7/ISUP; - Gatekeeper The gatekeeper is the core management entity in an H.323 environment. It is, among other things, responsible for access control, address resolution and H.323 network (load) management and provides the central hook to implement any kind of utilisation / access policies. An H.323 environment is subdivided into zones (which may, but need not be congruent with the underlying network topology); each zone is controlled by one primary gatekeeper (with optional backup gatekeepers). Gatekeepers may also provide added value, e.g., act as a
P.14
conferencing bridge or offer supplementary call services. An H.323 Gatekeeper can also be equipped with the proxy feature. Such a feature enables the routing through the gatekeeper of the RTP traffic (audio and video) and the T.120 traffic (data), so no traffic is directly exchanged between endpoints. (It could be considered a kind of IP-to-IP gateway that can be used for security and QoS purposes); - Multipoint Controller (MC) A Multipoint Controller is a logical entity that interconnects the call signalling and conference control channels of two or more H.323 entities in a star topology. MCs coordinate the (control aspects of) media exchange between all entities involved in a conference.They also provide the endpoints with participant lists, exercise floor control, etc. MCs may be embedded in any H.323 entity (terminals, gateways gatekeepers) or implemented as stand-alone entities.They can be cascaded to allow conferences spanning multiple MCs; - Multipoint Processor (MP) For multipoint conferences with H.323, an optional Multipoint Processor may be used that receives media streams from the individual endpoints, combines them through some mixing/switching technique, and transmits the resulting media streams back to the endpoints; - Multipoint Control Unit (MCU) In the H.323 world, an MCU is simply a combination of an MC and an MP in a single device. The term originates in the ISDN videoconferencing world where MCUs were needed to create multipoint conferences out of a set of point-to-point connections.
Audio Video
Conference Control
Gatekeeper
Data Applications
RSVP
RTP/RTCP
RAS
H.225.0
H.245
Relaiable MC
T.120
UDP IP / IP Multicast
P.15
- H.225.0 Registration, Admission, and Status (RAS) The RAS channel is used for communication between H.323 endpoints and their gatekeeper and for some inter-gatekeeper communication. Endpoints use RAS to register with their gatekeeper, to request permission to utilise system resources, to have addresses of remote endpoints resolved, etc. Gatekeepers use RAS to keep track of the status of their associated endpoints and to collect information about actual resource utilisation after call termination. RAS provides mechanisms for user/endpoint authentication and call authorisation; - H.225.0 Call Signalling The call signalling channel is used to signal call setup intention, success, failures, etc, as well as to carry operations for supplementary services (see below). Call signalling messages are derived from Q.931 (ISDN call signalling); however, simplified procedures and only a subset of the messages are used in H.323.The call signalling channel is used end-to-end between calling party and called party and may optionally run through one or more gatekeepers (the call signalling models are later described in the Signalling models Section). Optimisations: Since version 3, H.225.0 supports the following enhancements: Multiple Calls - To prevent using a dedicated TCP connection for each call, gateways can be built to handle multiple calls on each connection. Maintain Connection - Similar to Multiple Calls, this enhancement will reduce the need to open new TCP connections. After the last call has ended, the endpoint may decide to maintain the TCP connection to provide a better call setup time for the next call.
The primary use of both enhancements is at the communication between servers (gatekeeper, MCU) or gateways.While, in theory, both mechanisms were possible before, beginning with H.323v3, the messages contained fields to indicate support for the mechanisms; - H.245 Conference Control The conference control channel is used to establish and control two-party calls (as well as multiparty conferences). Its functionality includes determining possible modes for media exchange (e.g., select media encoding formats that both parties understand) and configuring actual media streams (including exchanging transport addresses to send media streams to and receive them from). H.245 can be used to carry user input (such as DTMF) and enables confidential media exchange and defines syntax and semantics for multipoint conference operation (see below). Finally, it provides a number of maintenance messages. Also, this logical channel may (optionally) run through one or more gatekeepers, or directly between calling party and called party (please refer to the Signalling models Section for details). It should be noted that H.245 is a legacy protocol inherited from the collective work on multimedia conferencing over ATM, PSTN and other networks. Hence it carries a lot of fields and procedures that do not apply to H.323 but make the protocol specification quite heavyweight. Optimisations: The conference control channel is also subject to optimisations. Per default, it is transported over an exclusive TCP connection but it may also be tunnelled within the signalling connection
P.16
(H.245 tunnelling). Other optimisations deal with the call setup time.The last chance to start an H.245 channel is on receipt of the CONNECT message which implies that the first seconds after the user accepted the call, no media is transmitted. H.245 may also start parallel to the setup of the H.225 call signalling, which is not really a new feature but another way of dealing with H.245.Vendors often call this Early Connect or Early Media. Since H.323v2, it is possible to start a call using a less powerful but sufficient capability exchange by simply offering possible media channels that just have to be accepted.This procedure, called FastConnect or FastStart, requires less round-trips and is transported over the H.225 channel. After the FastConnect procedure is finished or when it fails, the normal H.245 procedures start. A number of extensions to H.323 include mechanisms for more efficient call setup (H.323 Annex E) and reduction of protocol overhead e.g., for simple telephones (SETs, simple endpoint types and H.323.Annex F).
Gatekeeper id1
P.17
After the endpoint discovers the location of the gatekeeper, it tries to register itself (RRQ). Such a registration includes (among other information): - The addresses of the endpoint - for a terminal, this may be the user ids or telephone numbers. An endpoint may have more than one address. In theory it is possible that addresses belong to different users to enable multiple users to share a single phone - in practice, this depends on the phones and the gatekeeper implementation; - Prefixes - if the registering endpoint is a gateway it may register number prefixes instead of addresses; - Time to live - an endpoint may request how long the registration will last.This value can be overwritten by gatekeeper policies. The gatekeeper checks the requested registration information and confirms the (possibly modified) values (RCF). It may also reject a registration request because of, for example, invalid addresses. In the case of a confirmation, the gatekeeper assigns a unique identifier to the endpoint, which will be used in subsequent requests to indicate that the endpoint is still registered.
P.18
P.19
- ALERTING message This message may be sent by the called user to indicate that called user alerting has been initiated (in everyday terms, the phone is ringing); - CALL PROCEEDING message This message may be sent by the called user to indicate that requested call establishment has been initiated and no more call-establishment information will be accepted.
Figure 2.4 Direct signalling model The CONNECT message closes the H.225.0 call signalling part of the call and makes the terminals starting the H.245 conference control one. In such call mode, the H.245 Conference Control messages are exchanged directly between the two endpoints (the correct h245Address was retrieved from the CONNECT message itself).The procedures started with the H.245 Conference Control channel are used to: - allow the exchange of audiovisual and data capabilities, with the TERMINAL CAPABILITY messages; - request the transmission of a particular audiovisual and data mode, with the LOGICAL CHANNEL SIGNALLING messages; - manage the logical channels used to transport the audiovisual and data information; - establish which terminal is the master terminal and which is the slave terminal for the purposes of managing logical channels, with the MASTER SLAVE DETERMINATION messages; - carry various control and indication signals; - control the bit rate of individual logical channels and the whole multiplex, with the MULTIPLEX TABLE SIGNALLING messages; - measure the round trip delay, from one terminal to the other and back, with the ROUND TRIP DELAY messages. Once the H.245 conference control messages are exchanged, the two endpoints have all the necessary information to open the media streams.
P.20
packet-based network from the gatekeeper, which either grants the request with an ACF (Admission ConFirm) or denies it with an ARJ (Admission ReJect). After this first step, the call signalling part of the call begins with the transmission of the SET UP message from the calling party to its gatekeeper.The transport address of the SET UP message (and of all the H.225.0 call signalling messages) is retrieved by the calling party from the destCallSignalAddress field, carried inside the ACF received. In the case of the gatekeeper-routed call signalling model, it is the address of the gatekeeper itself.The SET UP message is then forwarded by the gatekeeper (or by the gatekeeper network) to the called endpoint. Upon receiving the SET UP message, the called party starts its H.225.0 RAS procedure with its gatekeeper. If successful, a CONNECT message is sent to indicate acceptance of the call. Because of the call model, this message is also sent to the called endpoint's gatekeeper which is in charge of forwarding it to the calling party endpoint (either directly or using the gatekeeper network). Before sending the CONNECT message, two other messages may be sent from the called party to its gatekeeper (those two messages are not depicted in the figure since only mandatory messages are reported): - ALERTING message This message may be sent by the called user to indicate that called user alerting has been initiated (in everyday terms, the phone is ringing); - CALL PROCEEDING message This message may be sent by the called user to indicate that requested call establishment has been initiated and no more call establishment information will be accepted.
Figure 2.5 Gatekeeper-routed call signalling model The two optional messages listed above are then forwarded by the gatekeeper (or by the gatekeeper network) to the calling party. After receiving the CONNECT message, the calling party starts the H.245 Conference Control channel procedures directly with the called party (the correct h245Address was retrieved from the CONNECT message itself).The scope of the H.245 Conference Control channel procedure is the same as is detailed above. Please refer to the Direct signalling model Section for details.
P.21
network by the gatekeeper, which either grants the request with an ACF (Admission ConFirm) or denies it with an ARJ (Admission ReJect). After this first step, the call signalling part of the call begins with the transmission of the SET UP message from the calling party to its gatekeeper. The transport address of the SET UP message (and of all the H.225.0 call signalling messages) is retrieved by the calling party from the destCallSignalAddress field carried inside the ACF received. In the case of gatekeeper-routed H.245 control model, it is the address of the gatekeeper itself.The SET UP message is then forwarded by the gatekeeper (or by the gatekeeper network) to the called endpoint. Upon receiving the SET UP message, the called party starts its H.225.0 RAS procedure with its gatekeeper. If successful, a CONNECT message is sent to indicate acceptance of the call. Because of the call model, this message is also sent to the called endpoint's gatekeeper, which is in charge of forwarding it to the calling party endpoint (either directly or using the gatekeeper network). Before sending the CONNECT message, two other messages may be sent from the called party to its gatekeeper (those two messages are not depicted in the figure since only mandatory messages are reported): - ALERTING message This message may be sent by the called user to indicate that called user alerting has been initiated (in everyday terms, the phone is ringing); - CALL PROCEEDING message This message may be sent by the called user to indicate that requested call establishment has been initiated and no more call establishment information will be accepted.
Figure 2.6 Gatekeeper-routed H.245 control model The two optional messages listed above are then forwarded by the gatekeeper (or by the gatekeeper network) to the calling party. After receiving the CONNECT message, the calling party starts the H.245 Conference Control channel procedures with its gatekeeper (the correct h245Address was retrieved from the CONNECT message itself). All of the H.245 channel messages are then exchanged by the endpoints with their gatekeeper (or gatekeepers). It is the gatekeeper (or gatekeeper network) which takes care of forwarding them up to the remote endpoint as foreseen by the gatekeeper-routed H.245 control model.The scope of the H.245 Conference Control channel procedure is the same as is detailed above. Please refer to the Direct signalling model Section for details.
P.22
P.23
- both endpoints registered to different gatekeepers Each of the two endpoints communicate with their gatekeeper depending on the signalling model configured, additional H.225.0 RAS messages may be exchanged between gatekeeper in order to retrieve location information (see Locating zone external targets Section for more details) - call setup with Fast Connect procedure In this call set up, the media channels are established using the Fast Connect procedure.The Fast Connect procedure speeds up the establishment of a basic point-to-point call (only one round-trip message exchange is needed) enabling immediate media stream delivery upon call connection.The Fast Connect procedure is started if the calling endpoint initiates it by sending a SETUP message containing the FastStart element (to advise it is going to use the Fast Connect procedure). This kind of element contains, among the other things, a sequence of all of the parameters necessary to immediately open and begin transferring media on the channels.The Fast Connect procedure may be refused by the called endpoint (motivations may be either because it wants to use features requiring use of H.245 or because it does not implement it).The Fast Connect procedure may be refused with any H.225.0 call signalling message, up to and including the CONNECT one. Refusing the Fast Connect procedure (or not initiating it) requires that H.245 procedures be used for the exchange of capabilities and the opening of media channels. Moreover, the Fast Connect procedure allows more information for the scope of H.323/SIP gatewaying (further details to be found in Chapter 4); - call setup via gateways When a gateway is involved, the call setup between it and the network endpoint is the same as the endpoint-to-endpoint call setup; - call setup with an MCU When an MCU is involved, all endpoints exchange call signalling with the MCU (and with the interested gatekeepers, if any). No changes are foreseen between an endpoint and the MCU call setup since it proceeds the same as the endpoint-to-endpoint; - broadcast call setup This kind of call setup follows the procedures defined in Recommendation H.332.
P.24
After Terminal Capability Exchange has been initiated, a master-slave determination procedure (consisting of either MASTERSLAVEDETERMINATION or MASTERSLAVEDETERMINATIONACK) has to be started as the first H.245 Conference Control procedure. Upon failure of initial capability exchange or master-slave determination procedures, a maximum of two retries are performed before the endpoint passes to the Call Termination phase. Normally, after successful completion of the requirements of this phase, the endpoints proceed directly to establishment of the audiovisual communication phase.
P.25
request an increase or decrease in the call bandwidth. If the aggregate bit rate of all transmitted and received channels does not exceed the current call bandwidth, then an endpoint may change the bit rate of a logical channel without requesting a bandwidth change. After requesting a bandwidth change, the endpoint waits for confirmation prior to actually changing the bit rate (confirmation usually comes from the gatekeeper). Asking for call bandwidth changes is performed using a BANDWIDTH CHANGE REQUEST(BRQ) message. If the request is not accepted, a BANDWIDTH CHANGE REJECT (BRJ) message is returned to the endpoint. If the request is accepted, a BANDWIDTH CHANGE CONFIRM (BCF) is sent back to the endpoint.With Supplementary Services, support is optional.The H.450 Series of Recommendations describes a method of providing Supplementary Services in the H.323 environment. Figure 2.8 reports some of the supplementary services defined so far and their number in the series.
Recommendation number Recommendation Title H.450.1 Supplementary Service Framework H.450.2 Call Transfer Supplementary Service H.450.3 Call Diversion Supplementary Service H.450.4 Call Hold Supplementary Service H.450.5 Call Park and Pickup Supplementary Service H.450.6 Call Waiting Supplementary Service H.450.7 Message Waiting Supplementary Service H.450.8 Name Identification Supplementary Service H.450.9 Call Completion Supplementary Service H.450.10 Call Offer Supplementary Service H.450.11 Call Intrusion Supplementary Service
P.26
A call may be terminated differently depending on the gatekeeper presence and on the party issuing the call termination: - call clearing without a gatekeeper No further action is required; - call clearing with a gatekeeper The gatekeeper needs to be informed about the call termination. After RELEASE COMPLETE is sent, an H.225.0 DISENGAGE REQUEST (DRQ) message should be sent by each endpoint to its gatekeeper. A Disengage Confirm (DCF) message is sent back to the endpoints to acknowledge the reception; - call clearing issued by the gatekeeper A call may be terminated by the gatekeeper by sending a DRQ to an endpoint.The procedure described above for call termination should be followed immediately by the endpoint up to the RELEASE COMPLETE message.Then a reply to the gatekeeper should be sent using a DCF message.The other endpoint should follow the same call termination procedures upon receiving the ENDSESSIONCOMMAND message. Moreover, if a multipoint conference is taking place, in order to close the entire conference, the gatekeeper should send a DRQ to each endpoint in the conference.
P.27
A location request can be sent via unicast or multicast. If sent via multicast, only the gatekeeper that can resolve the address replies. If a gatekeeper receives a unicast LRQ, it either confirms or rejects the request. This mechanism can have a list of peer gatekeepers to ask, in parallel or sequentially. It is also possible to assign a domain suffix or number prefix to each peer so that an address with a matching number prefix of a neighbouring institution will result in a request to the gatekeeper of that institution. By defining default peers, one could also build a hierarchy of gatekeepers (see Chapter 7 for further details).
Zone B
(6)
(4) (5)
Caller
(9)
Callee
Figure 2.10 A sample H.323 call setup scenario The called party explicitly confirms with its gatekeeper that it is allowed to accept the call (5, 6) and, if so, alerts the recipient of the call, returns an alerting indication and (once the receiving user picks up the call) eventually an indication of successful connection setup back to the calling party (7, 8). In (parallel to) this exchange, capability negotiation and media stream configuration take place.When the setup has completed, both parties start sending media streams directly to each other.
P.28
P.29
These mechanisms are grouped into the Security Profiles, where the Baseline Security Profile provides authentication and message integrity, making it suitable for subscription-based environments and the Voice Encryption Profile that provides confidential end-to-end media channels.
{ 2.2.2 SIP
{ 2.2.2.1 The purpose of SIP
SIP stands for Session Initiation Protocol. It is an application-layer control protocol that has been developed and designed within the IETF.The protocol has been designed with easy implementation, good scalability, and flexibility in mind. The specification is available in form of several RFCs.The most important one is RFC3261, which contains the core protocol specification.The protocol is used for creating, modifying and terminating sessions with one or more participants. By sessions, we understand a set of senders and receivers that communicate and the state kept in those senders and receivers during the communication. Examples of a session can include Internet telephone calls, distribution of multimedia, multimedia conferences, distributed computer games, etc. SIP is not the only protocol that the communicating devices will need. It is not meant to be a general purpose protocol.The purpose of SIP is just to make the communication possible.The communication itself must be achieved by other means (and possibly another protocol).Two protocols that are most often used along with SIP are RTP and SDP.The RTP protocol is used to carry the real-time multimedia data (including audio, video and text).The protocol makes it possible to encode and split the data into packets and transport these packets over the Internet. Another important protocol is SDP, Session Description Protocol, which is used to describe and
P.30
encode capabilities of session participants. Such a description is then used to negotiate the characteristics of the session so that all of the devices can participate, including, for example, negotiation of codecs used to encode media so all the participants will be able to decode it, negotiation of transport protocol used and so on. SIP has been designed in conformance with the Internet model. It is an end-to-end -oriented signalling protocol which means that all the logic is stored in end-devices (except routing of SIP messages). State is also stored only in end-devices.There is no single point of failure and networks designed this way scale well.The price we have to pay for the distributiveness and scalability is higher message overhead, caused by the messages being sent end-to-end. It is worth mentioning that the end-to-end concept of SIP is a significant divergence from a regular PSTN (Public Switched Telephone Network) where all the state and logic is stored in the network and the end-devices (telephones) are very primitive.The aim of SIP is to provide the same functionality that the traditional PSTNs have, but the end-to-end design makes SIP networks much more powerful and open to the implementation of new services that can hardly be implemented in the traditional PSTNs. SIP is based on HTTP protocol.The HTTP protocol inherited format of message headers from RFC822. HTTP and is probably the most successful and widely used protocol in the Internet. SIP tries to combine the best of both. In fact, HTTP can be classified as a signalling protocol too, because user-agents use the protocol to tell an HTTP server which documents they are interested in. SIP is used to carry the description of session parameters.The description is encoded into a document using SDP. Both protocols (HTTP and SIP) have inherited the encoding of message headers from RFC822.The encoding has proven to be robust and flexible over the years.
P.31
UAC Calling Party Stateful Forking Proxy INVITE UAC INVITE UAS UAS UAC INVITE UAS UAC Called Party UAS
BYE
UAC
Figure 2.11 UAC and UAS Figure 2.11 shows three user agents and one stateful forking proxy. Each user agent contains UAC and UAS.The part of the proxy that receives the INVITE from the calling party, in fact, acts as a UAS.When forwarding the request statefully, the proxy creates two UACs, each of them responsible for one branch. In the example, called party B picked up and later, when he wants to tear down the call, he sends a BYE. At this time, the user agent that was previously UAS becomes a UAC and vice versa.
P.32
P.33
2.2.2.2.2.3 Proxy server usage In a typical configuration, each centrally-administered entity (a company, for instance) has its own SIP Proxy Server, which is used by all user agents in the entity. Suppose that there are two companies, A and B, and each of them has its own proxy server. Figure 2.12 shows how a session invitation from employee Joe in company A will reach employee Bob in company B.
DNS Server
Company A
proxy.a.com Joe 1. INVITE
3. proxy.b.com
Company B
Figure 2.12 Session invitation User Joe uses address sip:[email protected] to call Bob. Joe's user agent does not know how to route the invitation itself but it is configured to send all outbound traffic to the company SIP Proxy Server proxy.a.com.The proxy server figures out that user sip:[email protected] is in a different company so it will look up B's SIP Proxy Server and send the invitation there. B's proxy server can be either pre-configured at proxy.a.com or the proxy will use DNS SRV records to find B's proxy server.The invitation reaches proxy.bo.com.The proxy knows that Bob is currently sitting in his office and is reachable through phone on his desk, which has IP address 1.2.3.4, so the proxy will send the invitation there.
2.2.2.2.3 Registrar
Its has been mentioned that the SIP Proxy at proxy.b.com knows current Bob's location but have not mentioned yet how a proxy can learn current location of a user. Bob's user agent (SIP phone) must register with a registrar.The registrar is a special SIP entity that receives registrations from users, extracts information about their current location (IP address, port and username in this case) and stores the information into a location database.The purpose of the location database is to map sip:[email protected] to something like sip:[email protected]:5060.The location database is then used by B's proxy server.When the proxy receives an invitation for sip:[email protected] it will search the location database. It finds sip:[email protected]:5060 and will send the invitation there. A registrar is very often a logical entity only. Because of their tight coupling with proxies, registrars are usually co-located with proxy servers.
P.34
Figure 2.13 shows a typical SIP registration. A REGISTER message containing Address of Record sip:[email protected] and contact address sip:[email protected]:5060 where 1.2.3.4 is IP address of the phone is sent to the registrar.The registrar extracts this information and stores it into the location database. If everything went well then the registrar sends a 200 OK response to the phone and the process of registration is finished.
Location Database Record in Location Database User sip:[email protected] is reachable at sip:[email protected]:5060 User Agent REGISTER Store Location 200 OK sip:[email protected] 1. REGISTER Registrar Location Database
2. STORE
1.2.3.4:5060
3. 200 OK Registrar
Figure 2.13 Overview of Registrar Each registration has a limited life span.The expires header field or the expires parameter of the contact header field determines for how long the registration is valid.The user agent must refresh the registration within the life span. Otherwise it will expire and the user will become unavailable.
P.35
Redirect Server
INVITE #1
User Agent A
INVITE #2
User Agent B
P.36
c=IN IP4 213.20.128.35 b=CT:1000 t=0 0 m=audio 54742 RTP/AVP 97 111 112 6 0 8 4 5 3 101 a=rtpmap:97 red/8000 a=rtpmap:111 SIREN/16000 a=fmtp:111 bitrate=16000 a=rtpmap:112 G7221/16000 a=fmtp:112 bitrate=24000 a=rtpmap:6 DVI4/16000 a=rtpmap:0 PCMU/8000 a=rtpmap:4 G723/8000 a=rtpmap: 3 GSM/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16
The first line tells us that this is an INVITE message which is used to establish a session.The URI on the first line, sip:[email protected] is called Request URI and contains the URI of the next hop of the message. In this case, it will be host iptel.org. A SIP request can contain one or more Via header fields which are used to record path of the request.They are later used to route SIP responses exactly the same way.The INVITE message contains just one Via header field which was created by the user agent that sent the request. From the Via field we can tell that the user agent is running on host 195.37.77.100 and port 5060. The From and To header fields identify initiator (calling party) and recipient (called party) of the invitation (just like in SMTP where they identify sender and recipient of a message). The From header field contains a tag parameter which serves as a dialogue identifier and will be described in Section 2.2.2.5. The Call-ID header field is a dialogue identifier and its purpose is to identify messages belonging to the same call. Such messages have the same Call-ID identifier. CSeq is used to maintain order of requests. Because requests can be sent over an unreliable transport that can re-order messages, sequence numbers must be present in the messages so that recipient can identify re-transmissions and out-of-order requests. The Contact header field contains the IP address and port on which the sender is awaiting further requests sent by called party. Other header fields are not important and will be not described here. The Message header is delimited from message body by an empty line.The Message body of the INVITE request contains a description of the media type accepted by the sender and encoded in SDP.
P.37
- ACK This message acknowledges receipt of a final response to INVITE. Establishing of a session utilises 3-way hand-shaking due to asymmetric nature of the invitation. It may take a while before the called party accepts or declines the call so the called party's user agent periodically re-transmits a positive final response until it receives an ACK (which indicates that the calling party is still there and ready to communicate); - BYE BYE messages are used to tear down multimedia sessions. A party wishing to tear down a session sends a BYE to the other party; - CANCEL CANCEL is used to cancel a not yet fully-established session. It is used when the called party has not replied with a final response yet but the calling party wants to abort the call (typically when a called party does not respond for some time); - REGISTER The purpose of REGISTER is to let the registrar know of current user's location. Information about the current IP address and port on which a user can be reached is carried in REGISTER messages. Registrar extracts this information and puts it into a location database.The database can be later used by SIP Proxy Servers to route calls to the user. Registrations are time-limited and need to be periodically refreshed. The listed requests usually have no message body because it is not needed in most situations (but can have one). In addition, many other request-types have been defined but their descriptions are out of the scope of this document.
Responses are very similar to the requests, except for the first line.The first line of response contains a protocol version (SIP/2.0) reply code and reason phrase.The reply code is an integer number from 100 to 699 and indicates type of the response.There are 6 classes of responses:
P.38
1xx are provisional responses. A provisional response is a response that tells to its recipient that the associated request was received but the result of the processing is not known yet. Provisional responses are sent only when the processing does not finish immediately.The sender must stop re-transmitting the request upon reception of a provisional response. Typically, proxy servers send responses with code 100 when they start processing an INVITE and user agents send responses with code 180 (Ringing) which means that the called party's phone is ringing. 2xx responses are positive final responses. A final response is the ultimate response that the originator of the request will ever receive.Therefore, final responses express the result of the processing of the associated request. Final responses also terminate transactions. Responses with code from 200 to 299 are positive responses.That means that the request was processed successfully and accepted. For instance, a 200 OK response is sent when a user accepts the invitation to a session (INVITE request). A UAC may receive several 200 messages to a single INVITE request.This is because a forking proxy (described later) can fork the request so it will reach several UAS and each of them will accept the invitation. In this case, each response is distinguished by the tag parameter in the To header field. Each response represents a distinct dialogue with an unambiguous dialogue identifier: - 3xx responses are used to redirect a calling party. A redirection response gives information about the user's new location or an alternative service that the calling party might use to satisfy the call. Redirection responses are usually sent by proxy servers.When a proxy receives a request and does not want or can't process it for any reason, it will send a redirection response to the calling party and put another location into the response which the calling party might want to try. It can be the location of another proxy or the current location of the called party (from the location database created by a registrar).The calling party is then supposed to re-send the request to the new location. 3xx responses are final; - 4xx are negative final responses. A 4xx response means that the problem is on the sender's side. The request could not be processed because it contains bad syntax or cannot be fulfilled at that server. - 5xx means that the problem is on server's side.The request is apparently valid but the server failed to fulfil it. Clients should usually retry the request later; - 6xx reply code means that the request cannot be fulfilled at any server.This response is usually sent by a server that has definitive information about a particular user. User agents usually send a 603 Decline response when the user does not want to participate in the session. In addition to the response class, the first line also contains the reason phrase.The code number is intended to be processed by machines. It is not very human-friendly but it is very easy to parse and understand by machines.The reason phrase usually contains a human-readable message describing the result of the processing. A user agent should render the reason phrase to the user. The request to which a particular response belongs is identified using the CSeq header field. In addition to the sequence number, this header field also contains the method of corresponding request. In our example it was a REGISTER request.
P.39
P.40
Called party
180 Ringing
200 OK
ACK
BYE
200 OK
Transaction #2
P.41
Called party
180 Ringing
200 OK
ACK
Dialog
BYE
200 OK
Transaction #2
Figure 2.16 SIP dialogue Some messages establish a dialogue and some do not.This is used to explicitly express the relationship of messages and also to send messages that are not related to other messages outside a dialogue. That is easier to implement because user agents do not have to maintain the dialogue state. For instance, an INVITE message establishes a dialogue, because it will later be followed by a BYE request, which will tear down the session established by the INVITE.This BYE is sent within the dialogue established by the INVITE. But, if a user agent sends a MESSAGE request, such a request does not establish any dialogue. Any subsequent messages (even MESSAGE) will be sent independently of the previous one.
P.42
Because the user agents know the location of each other, it is not necessary to send further requests to any proxy.They can be sent directly from user agent to user agent.That is exactly how dialogues facilitate routing. Further messages within a dialogue are sent directly from user agent to user agent.This is a significant performance improvement because proxies do not see all the messages within a dialogue.They are used to route just the first request that establishes the dialogue.The direct messages are also delivered with much smaller latency because a typical proxy usually implements complex routing logic. Figure 2.17 contains an example of a message within a dialogue (BYE) that bypasses the proxies.
Proxy 1 INVITE Proxy 2
INVITE
INVITE
BYE
Calling party
Called party
P.43
2.2.2.6.1 Registration
Users must register themselves with a registrar to be reachable by other users. A registration comprises a REGISTER message followed by a 200 OK sent by the registrar if the registration was successful. Registrations are usually authorised so a 407 reply which can appear if the user did not provide valid credentials. Figure 2.18 shows an example of a registration.
User Agent REGISTER w/o credentials 407 Registrar
REGISTER w/ credentials
200 OK
P.44
SIP Proxy
Called party
100 Trying
200 OK
200 OK
ACK
RTP Streams
P.45
BYE
200 OK
BYE 200 OK
200 OK
Figure 2.20 BYE message flow (with and without record routing) The lefthand message flow of Figure 2.20 shows how a BYE (request within dialogue established by INVITE) is sent directly to the other user agent when there is no Record-Route header field in the message.The righthand message flow shows how the situation changes when the proxy puts a Record-Route header field into the message.
P.46
A user agent interested in an event notification sends a SUBSCRIBE message to a SIP server.The SUBSCRIBE message establishes a dialogue and is immediately replied to by the server using a 200 OK response. At this point, the dialogue is established.The server sends a NOTIFY request to the user every time the event to which the user subscribed changes. NOTIFY messages are sent within the dialogue established by the SUBSCRIBE. Note that the first NOTIFY message in Figure 2.21 is sent regardless of any event that triggers notifications. Subscriptions, as well as registrations, have a limited life span and therefore must be periodically refreshed.
MESSAGE MESSAGE
200 OK 200 OK
P.47
variants of it are used as the call signalling protocol between switches; this protocol is used to route voice/data channels across the backbone network by instructing each switch on the way which incoming line is to be forwarded to which outgoing line and which other processing (such as simple voice compression, in-band signalling detection to customer premise equipment, etc.) is to be applied.Voice/data channels themselves are plain bit pipes identified by roughly a trunk and line identifier at each switch.
Figure 2.23 Application scenario for Media Gateway Control Protocols A similar construction is now considered by a number of telecom companies for IP-based backbone networks that may successively replace parts of their overall switched-network infrastructure, as depicted in Figure 3.7. Instead of voice switches, IP routers are used to build up a backbone network which employs IP routing, possibly MPLS, and, most likely, some explicit form of QoS support to carry voice and data packets from any point in the network to any other. In contrast to voice switches, this does not require explicit configuration of the individual routers per voice connection. Instead, only the entry and exit points need to be configured with each others' addresses, so that they know where to send their voice/data packets.Two types of gateways are used at the edges of the IP network to connect to the conventional telephone network: signalling gateways to convert SS7 signalling into IP-based call control (which may make use of H.323 or SIP or simply provide a transport to carry SS7 signalling in IP packets [SIGTRAN]) and media gateways that perform voice transcoding. Some central entity (or more probably, a number of co-operating entities) forms the intelligent core of the backbone, the Media Gateway Controller(s).They interpret call signalling and decide how to route calls and they provide supplementary services, etc. Having decided on how a call is to be established, they inform the (largely passive and dumb) media gateways at the edges (ingress and egress gateways) how and where to transmit the voice packets.The Media Gateway Controllers also re-configure the gateways in case of any changes in the call, invocation of supplementary services, etc.The media gateways may be capable of detecting invocation of control features in the media channel (e.g., through DTMF tones) and notify the Media Gateway Controller(s), which then initiate the appropriate actions. A number of protocols have been defined for communication between Media Gateway Controllers and media gateways. Initial versions were developed by multiple camps, some of which merged to create the Media Gateway Control Protocol (MGCP), the only one of the proprietary protocols that is documented as an Informational RFC (RFC 2705). An effort was launched to make the two remaining camps cooperate and develop a single protocol to be standardised, which resulted in work groups in the ITU-T (rooted in Study Group 16, Q.14) and
P.48
in the IETF (Media Gateway Control, MEGACO WG).The protocol being jointly developed is referred to as H.248 in the ITU-T and as MEGACO in the IETF. One particular protocol extension currently discussed in the IETF is the definition of a protocol for communication with an IP telephone at the customer premises that fits seamlessly with the Media Gateway Control architecture. Such a telephone would be a rather simple entity, essentially capable of transmitting and receiving events and reacting to them, while the call services are provided directly by the network infrastructure.
{ 2.2.5. Real Time Protocol (RTP) and Real Time Control Protocol (RTCP)
RTP and RTCP are the transport protocols used for IP Telephony media streams. Both of them were defined in RFC1889: the former as a protocol to carry data that has real-time properties, the latter to monitor the quality of service and to convey information about the participants in ongoing session.The services provided by the RTP protocol are: - identification of the carried information (audio and video codecs); - checking packet in-order delivery and, if necessary, re-ordering the out-of-sequence blocks; - transport of the coder/decoder synchronisation information; - monitoring of the information delivery. The RTP protocol uses the underlying User Datagram Protocol (UDP) to manage multiple connections between two entities and to check for data integrity (checksum). An important point to stress is that RTP neither provides any means to have a guaranteed QoS nor assumes the underlying network delivers ordered packets. The RTCP protocol uses the same protocols as RTP to periodically send control packets to all session participants. Every RTP channel using port number N has its own RTCP protocol channel with port number equal to N+1.The services provided by the RTCP are: - giving a feedback on the data quality distribution, feedback used to keep control of the active codecs; - transporting a constant identifier for the RTP source (CNAME), used by the video data; - advertising the number of session participants which is used to adjust the RTP data transmission rate; - carrying session control information used to identify the session participants.
P.49
The next two subsections describe the RTP and RTCP header and the different types of packets that the two protocols use.
Figure 2.24 RTP header The header fields are here detailed: - version (V - 2 bits) contains the RTP protocol version; - padding (P - 1 bit), if set to 1, then the packet contains one or more additional bytes after the data field; - extension (X - 1 bit), if set to 1, then the header is followed by an extension; - CSRC count (CC - 4 bits) contains the CSRC identifier number which follows the header; - marker (M - 1 bit) is the application available field; - payload type (PT - 7 bits) identifies the data field format of the RTP packet and determines its interpretation by the application; - sequence number (16 bits) value incremented by one for each RTP packet sent, is used by the receiver to detect losses and to determine the right sequence; - RTP timestamp (32 bits) is the sampling time of the first RTP byte, used for synchronisation and jitter calculation; - SSRC ID (32 bits) identifies the synchronisation source, chosen randomly within a RTP session; - CSRC ID list (from 0 to 15*32 bits) is an optional field identifying the sources which contribute to the data in the packet.The number of the CSRC IDs is written in the CSRC count field.
P.50
- RR, Receiver Report, to carry the statistics of the session participants which are not active transmitters; - SDES, Source DESscription, to carry the session description (including the CNAME identifier); - BYE, to notify the intention of leaving the session; - AAP, to carry application specific functions, used by experimental use of new applications. Every RTCP packet begins with a fixed part similar to the one of the RTP ones, and this part is then followed by structural elements of variable length. More than one RTCP packet may be linked together to build a COMPOUND PACKET. Moreover, in order to maximise the statistics resolution, the SR and the RR packet-types are to be sent more often than the other packet-types.
P.51
P.52
Figure 3.2 Integration of data and telephony between locations A hybrid solution, including both traditional processing of calls over PSTN/ISDN and additional IP Telephony parts, results in this detailed architecture.
Figure3.3 Least-cost routing architecture The features that a least-cost routing architecture may provide can be summarised as: - call routing by time of day and day of the week, allowing selection of the best rates for specific time periods; - call routing by destination, allowing selection of the best rates depending on the destination of the call; - number modification, allowing dial-string manipulation of the original number dialled, to facilitate prefix-based routing; - class of service management, allowing management of individual extensions with differentiated class of service, to give that higher level of service to users who need it.
P.53
extra digits for each appropriate prefix, both because it is time-consuming and, as a result of negligence. Therefore, an engineering process is needed to keep the costs low. Least-cost routing is the solution to these kinds of problems, because it allows the telephone system to automatically route the long-distance call to the most economical telephony carrier/network, saving money on the long-distance bill and reducing the employee's effort in making calls. In order to put such solution in place, the company needs to deploy a set of gateways in the locations where branch offices are located, to take advantage of the integration of data and telephony links between locations as depicted in Figure 3.2.This can result in savings from both calls located in the area of the branch offices, as well as office-to-office calls, taking advantage of the data network connecting the company's sites. Note that in this case, a distributed routing table has to be implemented, in order to facilitate control by the system administrator, who may wish to update it anytime changes in long-distance rates occur.
Figure 3.4 Legacy PBX which trunks to the PSTN One of the most economically feasible deployments of IP Telephony is currently is in the area of installing voice over IP as a replacement for inter-building PSTN connections within one company, or even, the complete replacement of the PBX phone system itself, along with its terminals. This chapter first describes the scenarios in which IP phones can be deployed in a peer-to-peer fashion without additional control entities in the network.This case is only covered briefly because its practical use is limited. Then, a more common scenario will be described, where IP Telephony is introduced into the existing telephony infrastructure.The legacy PBX is still functional in this scenario and voice calls can be carried not only over regular PSTN trunks, but also over IP backbones.
P.54
The last scenario describes the total replacement of a PBX infrastructure by IP Telephony equipment.
Figure 3.5 IP Phone to IP Phone without PBX For mission-critical cases, such as a commercial company or an institutional phone system, this is an awkward method. Moreover, it is not possible to make a call to a regular telephone within the institution or to the PSTN, because no VoIP-to-PSTN gateway is available. Also, common features like central address books, call forwarding services, etc. are harder to integrate with the phone terminal. If the destination is unreachable, nothing useful can be done with the call, like redirecting it to a voicemail service, etc.This setup is therefore only recommended for testing purposes. Call setup is very simple, when using either H.323, or SIP, or any variations of these protocols. Since the calling party directly enters the IP address of the destination, call initiation signalling is sent directly to that IP address. If the terminal is functional, it will process the signalling and the called party will be prompted to pick up the phone.When that happens, the call is setup, a codec is negotiated and the voice stream will start, until signalling that terminates the call is exchanged.
> 3.3.2. Scenario 2b: Integration of VoIP with legacy PBX systems
This scenario allows the co-existence and intercommunication of the institutional conventional telephony network (conventional phones connected to PBX) and the local IP Telephony network.The scenario is suitable when the local IP Telephony network is constructed gradually in an institution that already has a conventional telephony network. In a later stage, the conventional telephony network and the PBX can be totally replaced by the IP Telephony network, thus converging to Scenario 2c. For example, in order to provide for smooth transition, it might be worthwhile to buy a gateway with two ISDN PRI interfaces (or just with one interface and borrow the second interface for
P.55
the transition period). One interface is connected to the PSTN and the second one to the PBX. During the transition period, a gateway also performs call routing between the PSTN and the old PBX and vice versa, providing a smooth transition. This chapter gives an overview of options for interconnecting a PBX to a Voice Gateway (VoGW).These options also apply to Scenario 1. More technical details for individual interfaces are given in Chapter 4.
Figure 3.6 Integration of IP Telephony with a legacy PBX system The choice of a particular interface between a PBX and a VoGW depends on the required functionality, availability of interconnection ports on both sides and also on cost constraints. Interfaces can be divided into analogue and digital.The former include a 2-wire U-interface with a subscriber loop and various types of E&M interfaces.The latter include an E1/CAS trunk with MFC-R2 signalling and ISDN with DSS1 or QSIG signalling. Giving technical details about the trunks and interfaces mentioned above is outside the scope of this chapter Please refer to Chapter 4 for further details. On the other hand, technical people who want to understand this kind of scenario may benefit from a discussion of the advantages and shortcomings of individual interfaces, which are summarised in the following list: - Subscriber loop - suitable when conventional phones should be connected directly to VoGW (Voice GateWay) via an FXS interface - an FXS interface connects directly to a standard telephone and supplies ring, voltage, and dial tone, but can also be used for PBX interconnection. A disadvantage is that when calling inward towards the PBX, an extension number can be dialled only as DTMF (Dual-Tone Multi-Frequency) suffix, after a call is established and is already accounted for.This type of interface is usually a low-cost solution; - E&M interfaces - E&M commonly stands for both Ear and Mouth or recEive and transMit. It allows extension dialling before the conversation begins. It requires a special interface card for the PBX, but if the PBX is already equipped with this card, this can also be a low-cost solution; - E1/CAS trunk with MFC-R2 signalling - CAS (Channel Associated Signalling) exists in many variants that operate over analogue and digital interfaces.The advantage of a digital interface is its ability to transfer the identification of the calling party, which is important for detailed accounting.This is the first digital solution that was used, which was later largely
P.56
replaced by ISDN interfaces. It requires special interface cards on both sides of the interconnection, and it is a rather expensive solution; - ISDN with DSS1 signalling - In addition to calling party identification, supplementary services are available such as Call Waiting, Do Not Disturb, etc. It can be used with a BRI interface (Basic Rate Interface, up to 2 simultaneous calls) or a PRI interface (Primary Rate Interface, up to 30 simultaneous calls).The interface card is usually already in place on modern PBXs.The PRI interface is economically preferable when more than 8 channels (4xBRI) are required; - ISDN with QSIG signalling - QSIG signalling supports more supplementary services, such as completion, Path replacements, etc. However, QSIG uses proprietary features of the PBX from particular manufacturers and is therefore suitable only for corporate networks, where IP Telephony is used to interconnect PBXs in company branches.
Figure 3.7 IP Telephony fully-replacing PBX The design of an IPBX system involves a couple of choices.
P.57
P.58
public mobile telephony networks to the campus wireless environment, potentially reducing costs when calling locally on campus.
P.59
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 deliver high-quality video images to remote medical specialists. Specialised videoconferencing devices may be required to enable highquality video contents not available with the standard videoconferencing systems; - Distance Learning - Video lectures, remote guest speakers invited 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 centre operators to be more effective when interacting with customers. - Justice services - Many legal systems have introduced the use of videoconferencing to enable police officers to attend legal proceedings.This optimises the time police need to spend in courthouses; - Virtual/Remote Laboratories - Remote laboratories allow researchers to share advanced appliances using existing network infrastructure. In telemedicine, specialised devices not available with the standard videoconferencing systems may be required to enable high-quality video contents to be transmitted. Moreover, special considerations apply when such interaction modes are considered. While simple desktop conferencing equipment may be enough for basic meetings, a successful integration scenario would require, on the application side, application-specific devices to deliver the content to the end-user.The technical side would require 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.
P.60
- an 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; - an 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 call manager, in this case a Cisco CallManager, being the gatekeeper to perform 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 Escort Pro 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.
Figure 3.8. Integrated voice and video over IP architecture at the SURFnet offices. To allow multipoint calls, an MCU (RADVISION MCU323) has to be added and the conference feature on the PBX has 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 Dialling System (GDS) 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 (see the Section on Dial Plans and also http://www.wvn.ac.uk/support/h323address.htm). Therefore, it is guaranteed that for terminals called/dialled 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 dialled without the need for rewriting the dial string. GDS is supported by the ViDeNet H.323
P.61
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 phone number 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 that the assignment is 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 501 for group that A belongs to is also defined (the group number for making all telephones in a group ring). 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. The following situations are not a complete list of possibilities, but a several representative ones: - A user on the PSTN calls A at SURFnet, who 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 recognises 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 As 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 recognises 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. - A user, using an IP phone, dials As 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 CallManager recognises 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 recognised and the call is forwarded to the Dutch national gatekeeper.There the prefix 3023053 is recognised and the call
P.62
is forwarded to the SURFnet office gatekeeper. Here the number 67 is recognised. 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. - A videoconferencing station dials As IP phone. Someone using an H.323 videoconferencing station finds As 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 an H.323-Skinny gateway and forwards the call to the IP phone. 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 dialling between the systems is also supported: 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. If MCU was involved, people using either a PSTN device, or an 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 an 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 the devices used even further. Note that the example above relies on a numeric dialling plan. Alphanumeric dialling and routing is implemented differently (see Section 2.1.5 on Addressing).
P.63
In Chapter 2, the working of H.323 and SIP protocols was explained.This chapter explains how to set up an infrastructure including H.323 and/or SIP components and gives real-world examples of configuration for popular equipment.The focus will be on setting up basic services, meaning the equipment that is necessary to provide basic call services, authentication and billing.
~ 4.1.1 Architecture
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, among others, is to resolve a dialled address to an IP target. However, when we talk about real-world set-ups, this server infrastructure tends to be more complicated.The 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 signalling protocol. There are two possibilities to support multiple signalling protocols within one zone: have servers with built-in support for every protocol or have dedicated servers for each protocol and signalling gateways between them. A server that supports more than one signalling 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 an H.323 Gatekeeper, then call routing inside the domain becomes an issue. A signalling gateway is required to enable an H.323 endpoint to call a SIP endpoint and vice versa (see Figure 4.2).
1. Actually there is a product that claims support for both SIP and H.323 protocols: the Asterisk PBX. See: http://www.asterisk.org/. How well it supports SIP and H.323 is not yet known. P.64
H.323 Gatekeeper
Signalling
SIP-Proxy
Registration
Registration
Media
Figure 4.2 SIP/H.323 zone using a signalling gateway The gateway is used to translate signalling 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 (see Section 2.2.1.5.1). An architectural problem similar to the last one is the use of servers that feature a proprietary IP Telephony protocol and provide a SIP or an H.323 interface that is limited to basic call functionality without any supplementary services or security features. An example of this is the popular Cisco CallManager.
P.65
Besides technical aspects, organisational aspects of PBX-VoIP integration call for careful planning and analysis.The question is how to integrate legacy and IP Telephony equipment into the dial plan of an organisation. Is it necessary that the phone number reflects whether the participant is a VoIP user or a PBX user. Generally, there are three possibilities to explore, as explained below.There are more details on setting up an IP Telephony gateway in Section 5.1.
Figure 4.3 Routing based on number prefix 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 only needs to route all internal calls with unknown prefixes to the gateway.
Database
2972 -> PSTN 2973 -> IP 2974 -> IP 2975 -> PSTN
Database
PSTN
2973
2972
P.66
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.
2974
B
IP telephony server Gateway
Legacy PBX
PSTN A
2973
2972
(b)
2972 -> PSTN 2973 -> IP A 2974 -> IP B 2975 -> PSTN 2974 2972 -> PSTN 2973 -> IP A 2974 -> IP B 2975 -> PSTN Database
B PSTN
2973 2972
P.67
The first scenario uses two gateways and thus allows the PBX to decide where to route a call to. 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 signalling 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, but merely needs to know the fact that the call has an IP target. 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., an 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 synchronisation with a high risk of inconsistency.
~ 4.1.1.2 Trunking
The bigger an institution is, the more complex its organisational infrastructure.This may be due to the need to support multiple locations (sites) or because certain organisational units need to administer 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 dialling space.
PSTN
1000-4999 5000-6999
7000-7999
8000-9999
IP
P.68
This is the classic branch office scenario that is based upon the assumption that both networks have different locations, and that dialling prefixes already exist in the PSTN.This is the same problem as the one already addressed in Section 4.1.1.1.1.
2975
2972
2974
IP C B
2973
Figure 4.7 Static individual trunking A more likely solution is a model 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.
P.69
2975
2972
2974
IP C B
2973
~ 4.1.2. Robustness
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.
P.70
1.The first approach is to set up more than one server for a zone and treat each of them as a separate router (see Section 4.1.1.2.3) that shares 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 will not even notice, at first, because the UDP media stream is usually transmitted directly between the two endpoints. But, the TCP signalling 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 prioritised 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 synchronisation between the replicated servers the failure of one server normally results in the loss of all calls.The server loss is discovered 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. 2. 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 for only a few seconds. Of course, active calls will still be cleared, and definitely not resumed. 3. 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. If 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 rewriting-mechanisms ARP might not work in switched networks, which would force both servers to be in the same shared network segment. It is hard to give general advice on which kind of robustness-mechanism to use.The third solution allows the use of dumb endpoints because operation of the backup server is completely
P.71
transparent to them, reducing the cost of endpoint equipment.The other two solutions offer the possibility of putting 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 obtain. Every manufacturer that offers IP Telephony solutions implements some robustness-mechanism. One should be aware of the endpoint requirements that must be met to take advantage of the mechanism offered.
~ 4.1.3.2 Decentralisation
Another issue occurs regarding the question of who is allowed to administer what in the telephone system. In classic environments, there is a small group of PBX administrators that sits in a special location, but in 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 these changes could be decentralised.
P.72
Decentralised 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 decentralised administration.Whether different administration permissions can be granted heavily depends heavely on the products used.
P.73
3.Per-number routing The cleanest way to handle call routing is to perform routing decisions on the individual number (see Section 4.1.1.1.2).Whether a number belongs to an IP phone or PBX phone is fully transparent to the user and no error-prone default routes are required. It is also the solution that has the highest configuration and administration effort because there are, most probably, at least two databases that must be kept consistent. 4.Protocol- and number-based routing The call routing problem gets worse as soon as multiple call-signalling protocols are deployed in the IP world and there is no single server supporting all of them at once (see Figure 4.5). Every IP Telephony server must be aware that a number that belongs to another server must be routed to the gateway, or otherwise the gateway must be the default route for unknown targets. In any case, calls for unknown targets land on a gateway.The gateway needs to decide where to route a call. Because it is desirable that gateways are dumb (to prevent having yet another place to configure routing details), the gateway will hand the call to the PBX which makes the final routing decision, which eventually means to hand the call to another gateway (or back to the originating server if there is only one multi-protocol gateway). All of the problems and solutions mentioned above are very dependent on specific products and the features they support, so, unfortunately, there can be no general advice on how to implement dial plan migration.
~ 4.3 Authentication
To charge individuals for used services, it is necessary to have means of authentication for registration and call signalling.This section gives an overview of the mechanisms used for this purpose in H.323 and SIP.
P.74
~ 4.3.1.3 Integrity
Integrity refers to message integrity and ensures that a received message is identical to that which was transmitted by the sender and has not been modified. H.235 supports two mechanisms to achieve integrity: the use of CryptoTokens and the IntegrityCheckValue. 1.CryptoTokens are already described in Section 4.3.1.2.To allow an integrity check, the whole message is used to compute a MAC/digital signature, instead of just a small subset required for authentication. This mechanism can be used for any signalling channel (RAS/H.225.0/H.245). 2.IntegrityCheckValue refers to an element that occurs in RAS messages. Again, the hash-value of the message (without the hash-value) is transmitted. This second mechanism was introduced before the adoption of H.235, because it was deemed critical that there was not a data-integrity mechanism for the unreliable RAS channel. Since the adoption of H.235, the CryptoToken method is the preferred way to check integrity.
~ 4.3.1.4 Confidentiality
Confidentiality ranges from secured H.225.0 signalling channels to secured media streams.The H.323/H.235 suite of protocols does not specify a way to secure the signalling channels, because they are used first in every call but have to be secured from the very beginning. Instead,Transport Layer Security (TLS) or IPSEC is be used to secure the H.225.0 channel. An endpoint supporting such a mechanism must listen on a well-known port (e.g., 1300 for TLS) to receive secured connections. Within H.225.0, the security capabilities for the H.245 media control channel can be exchanged. The H.245 channel itself can be used to negotiate media encryption.
P.76
It consists of a set of parameters that are sent to the user.The user then uses the parameters to generate the proper digest reply and send it back to the server.The meaning of the parameters in the digest challenge is as follows: - realm:The realm parameter is mandatory and must be present in all challenges. Its purpose is to identify credentials within a SIP message. In the case of SIP, it is usually set to the domain that the proxy server is responsible for. SIP user agents are supposed to display the contents of the parameter to the user when they prompt him for username and password so that he uses the appropriate username and password (for this server); - nonce: this is a server-specified data string which is uniquely generated each time a server generates a digest challenge. Nonce is usually constructed as the MD5 hash of some data.The data usually includes time-stamp and a secret phrase of the generating server.That ensures that each nonce has a limited lifetime (i.e., expires after some time and can not be used later) and also is unique (i.e., no other server will be able to generate the same nonce). Clients use the nonce to generate a digest response and thus the server will receive the contents of the nonce back in a digest response. It usually checks the validity of the nonce before it checks the rest of the digest response. So, basically, nonce is a sort of an identifier that ensures that received digest credentials have really been generated for a particular digest challenge, and also limits the lifetime of the digest response, preventing replay attacks in the future; - opaque: this is an opaque data string passed to the user in a challenge.The user will pass the data string back to the server in a digest response.That allows servers to be stateless. If there is any state they need to maintain between challenge and response, they can pass it to the client using this parameter and read it again later when a digest response comes. - algorithm: the algorithm used to calculate hashes. Currently only MD5 is supported; - qop: the quality of protection.The parameter specifies what protection schemes the server supports. A client will pick one from the list.The value auth indicates just authentication.
P.77
The value auth-int indicates authentication with some integrity protection. For a more detailed description, see RFC2617. After receiving the digest challenge, a user agent will prompt the user for username and password (if not preconfigured), generate a digest response and send the response to the server. A digest response might look like this:
Digest username="jan", realm="iptel.org", nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", uri="sip:iptel.org", qop=auth, nc=00000001, cnonce="0a4f113b", response="6629fae49393a05397450978507c4ef1", opaque=""
The digest response is similar to the digest challenge.Those parameters that are the same have the same meaning as in the digest challenge. Below is a brief description of only the new parameters: - uri: the parameter contains URI the clients wants to access; - qop: the level of protection chosen by the client; - nc: (nonce count) the value is the hexadecimal count of the number of requests (including the current request) that the client has sent with the nonce value in this request. For example, in the first request, sent in response to a given nonce value, the client sends nc=00000001.The purpose of this directive is to allow the server to detect request replays by maintaining its own copy of this count. If the same value is seen twice, then the request is a replay; - cnonce: the value is an opaque quoted string value provided by the client and used by both client and server to avoid chosen plain-text attacks, to provide mutual authentication and to provide some message integrity protection; - response: a string computed by the user agent which proves that the user knows a password. Upon reception of a digest response, the server recalculates the value of the response parameter for comparison purposes, using attributes provided by the client and the password stored on the server. If the result is identical to the response received from the client, then the client has proven knowledge of the password and he is authenticated.
P.78
The server then verifies the digest response and processes the request if the verification was successful. Proxy servers use the Proxy Authentication Required response and include the digest challenge into the Proxy-Authenticate header field. An example of such a challenge might look like:
SIP/2.0 407 Proxy Authentication Required. Via: SIP/2.0/UDP 195.37.78.121:5060. From: sip:[email protected];tag=3944790419. To:<sip:[email protected];user=phone>;tag=794fe65c16edfdf45da4fc39a5d2867 Call-ID: [email protected]. CSeq: 1 INVITE. Proxy-Authenticate: Digest realm="iptel.org", \ nonce="3f9fc19cf91f65958f664122c1310d4c28cc61a2". Content-Length: 0.
SIP user agents (including registrars and back-to-back user agents) use the 401 Unauthorised response for the digest challenge. An example of such a challenge might be:
SIP/2.0 401 Unauthorised. Via: SIP/2.0/UDP 218.79.100.193:65030;branch=z9hG4bK1ce21dab. To: "IPTel844978" <sip:[email protected]>;tag=794fe65c16edfdf45da4fc39 From: "IPTel844978" <sip:[email protected]>;tag=1fd6218e. Call-ID: [email protected]. CSeq: 88608141 REGISTER. WWW-Authenticate: Digest realm="iptel.org", \ nonce="3f9fc19cf91f65958f664122c1310d4c28cc61a2". Content-Length: 0.
407 responses are used by SIP elements (mostly SIP Proxy Servers) that are not the final destination for the request, and after authentication, will forward the requests further. 401 responses are used by SIP elements that are the final destination for the request and after authentication will generate a final reply. When including the digest response clients add an Authorisation or a Proxy-Authorisation header field that contains the digest response.The following example shows a REGISTER message containing digest credentials.
REGISTER sip:iptel.org SIP/2.0. Via: SIP/2.0/UDP 195.37.78.121:5060. From: sip:[email protected]. To: sip:[email protected]. Call-ID: [email protected]. CSeq: 102 REGISTER. User-Agent: CSCO/4. Contact: <sip:[email protected]:5060>. Authorisation: Digest username="jan",realm="iptel.org",
P.79
P.80
Registrar
REGISTER w/ credentials
200 OK
P.81
~ 4.4. Examples
This section lists some examples of how a zone setup could look like, depending on the requirements.
PSTN
P.82
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.
P.83
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.
Gatekeeper Gatekeeper
Test network
Research network
Figure 4.12 Example of a multi-server IP Telephony zone 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 space for research initiatives and prevents dependency 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.
P.84
Figure 4.13 Examples of gatekeeper features Guides for basic operation of the above three gatekeepers follow, but official documentation for these products should be consulted when advanced functionality and features are required.
~ 4.5.1.1. Installation
Since the Cisco MCM Gatekeeper is only an IOS feature (IOS being the Cisco router operating system), basic IOS installation procedures are sufficient, assuming a correct IOS image with MCM functionality has been chosen from the Cisco support site.Two tools can help you choose an appropriate IOS for your available router, but they are only available to registered users on the Cisco Website: - Cisco IOS Upgrade Planner - Cisco Software Advisor. Look for High-Performance Gatekeeper under features and for IP/H.323 under feature sets. IOS versioning is a subject difficult to follow. Add to this the fact, that the MCM has been
3. http://sourceforge.net/projects/openh323proxy/ P.85
undergoing changes during IOS development and gatekeeper features available on different IOS versions vary significantly. Finding the right IOS-MCM combination to use for a specific hardware configuration can become time consuming. Always prefer the latest available IOS release for your hardware, assuming enough RAM is available to accommodate it.
~ 4.5.1.2 Configuration
Working with the Cisco IOS command line interface requires some experience with basic commands, modes of operation, loading software images and configuration files, none of which will be described here in detail. If you are not familiar with Cisco IOS basic commands, make sure you read an introductory guide by Cisco.To configure the Cisco MCM, you must establish command line access (telnet) to the router that runs the IP/H.323 feature set and enter privileged (enable command) mode, indicated by the # at the prompt, before you can enter configuration commands. Enter configuration mode (config command) and then specify the gatekeeper section. In this section, you will need to enter the MCM configuration commands, as in the sample below, which merely initialises the gatekeeper operation:
gkp#config Configuring from terminal, memory, or network [terminal]? Enter configuration commands, one per line. End with CNTL/Z. gkp(config)#gatekeeper gkp(config-gk)#zone local gkp.mydomain.org mydomain.org gkp(config-gk)#no shutdown gkp(config-gk)#^Z
The above sample is sufficient to start gatekeeper services on the router, but a more detailed configuration with comments for a basic gatekeeper set-up follows.We have dropped the command line prompt for simplicity.The following commands can be typed at the configuration interface, as shown above. Note that all user-specified fields are indicated as enclosed in brackets and you must customise/replace them appropriately for your site. This section goes outside the gatekeeper configuration section as it relates to general AAA settings and RADIUS server communication. H.323 endpoint RAS registration will be checked against local IOS usernames first and then RADIUS-defined usernames. Accounting records will be sent to the RADIUS server.
! aaa new-model aaa authentication login h323 local group radius aaa accounting connection h323 start-stop group radius ! radius-server host [radius.mydomain.org] auth-port [1812] acct-port [1813] radius-server key [radius-server-key-as-defined-in-radius-host] radius-server authorisation permit missing Service-Type !
P.86
! Gatekeeper section ! gatekeeper ! ! Local zone info, as controlled by this gatekeeper ! The zone name "myzone" is for config purposes only and plays no role, ! while the domain is important for endpoints registering by e-mail alias, ! as endpoints that request to be registered by e-mail address must match ! the specified "mydomain.org" part. ! The zone prefix is important for recognising ! in-zone calls and endpoints, e.g anything beginning with 0030234 ! zone local [myzone] [mydomain.org] zone prefix [myzone] [0030234*] !
To set up connectivity with other zones and gatekeepers, specify the IP of the neighbouring gatekeeper with a zone remote and the prefix it services with a zone prefix for that zone. For example, if you know a neighbour gatekeeper handles all calls with prefix 0030248, include the following two lines.
! zone remote [neighb1] [neighb1-domain.com] [neighb1-gkp-ip] 1719 zone prefix [neighb1] [0030248*] !
The VideNet Gatekeeper, for example, is the largest global network of H.323 zones, to which you can connect as shown below. Any calls beginning with 00, are routed to the VideNet Gatekeeper. In order to accept calls from VideNet as well, you have to make your gatekeeper well known to the VideNet hierarchy of gatekeepers (see https://videnet.unc.edu/)
! zone remote videnet3 videnet 137.44.172.248 1719 zone prefix videnet3 00* lrq forward-queries add-hop-count !
To force endpoints to register with a specific h323-id and password you can use H.235 (few endpoints support it) or the h323-id/password mechanism that the MCM provides.
! accounting security h323-id security password separator / !
Make sure no H.323 proxy services are unintentionally used, unless proxy functionality is needed for security or QoS reasons.
! no use-proxy [myzone] default inbound-to terminal no use-proxy [myzone] default outbound-from terminal
P.87
~ 4.5.1.3 Operation
Immediately after configuration, the MCM may service endpoints, and you can verify this by making a couple of endpoints point to the gatekeeper for registration. As soon as the endpoints register, they can be listed with the following command: - show gatekeeper endpoints You may proceed with calling between the two endpoints by dialling from the one the registered aliases (name or number) of the other.The ongoing call can be listed with the following command: - show h323 gatekeeper calls As an administrator of the gatekeeper, you may disconnect the call, or even unregister an endpoint. - clear gatekeeper call call-id . . . - unregister . . . A view of the operational status of the gatekeeper, such as zones defined, endpoints registered, neighbour gatekeepers defined etc. may be displayed by the following command: - show gatekeeper status Debug logs of the gatekeeper operations may be monitored with the following sequence of commands:
terminal monitor debug gatekeeper main 10 debug h225 asn1 debug h245 asn1
The first command makes your terminal capable of displaying console-style logs and debugging output.The second command produces debugging output regarding basic gatekeeper actions. Obviously, the last two commands display information on H.225 and H.245 protocols and the output can be overwhelming, but it may be the only debugging option when faced with an otherwise intractable problem. Each debugging option can be stopped by its equivalent no debug and all debugging output can be stopped with the no debug all command.
P.88
shortcomings to this method that stem mostly from the fact that it is a proprietary solution, which, in some cases, exposes clear text passwords to neighbouring devices (MCUs, gateways, gatekeepers). Of course, the MCM includes RADIUS support, which might allow for an IP address + alias identification method to be implemented on the RADIUS server side, but such a solution imposes restrictions to endpoint mobility.
P.89
~ 4.5.2.1 Installation
Installing the ECS Gatekeeper is a very simple task, since it involves merely the execution a GUI setup wizard, which requires no configuration options.The only potential source of installation problems lies with the fact that the Windows SNMP service must already be installed, before any service packs and the ECS installer are applied. If this advice, which is listed in the ECS documentation, is ignored, the ECS installer refuses to proceed and the only option is to reinstall the operating system itself. Also, the administrator of the host must make sure that port 80 is free, since the ECS installs an HTTP service on this default port for configuration management over a Web interface.The documentation also calls for an FTP server to be running at the same host, but it only serves for downloading ECS log files, which is not a required functionality.
~ 4.5.2.2 Configuration
Once installed, the ECS is ready to run with default configuration options.The administrator can access the management interface (see Figure4.14) by launching a browser and requesting the local Web server (http://localhost).The interface presents a login page, where the default username and password can be entered (admin/null-no-password). After successful login, the administrator is made aware of the fact that the management tool can supervise the operation of a whole hierarchy of ECS Gatekeepers (Global picture), as well as the single ECS installation residing on this host (Local picture). Proceed with the Local administrator interface.
Figure 4.14 ECS local administration entry Immediately afterwards, the menus for the administration of the locally-installed gatekeeper are shown, as below. There are four commands to allow configuration management.The Refresh button fills in the Web interface forms with configuration data from the currently-running ECS Gatekeeper configuration.The Upload button takes all the changes made on the Web interface and applies them to the currently-running ECS configuration.The Import and Export buttons are used to store and retrieve snapshots of the configuration at different points in time.
P.90
Figure 4.15 ECS administration menus The rest of the interface is fairly straightforward, with an array of configuration tabs (sections), the most important of which are listed below: - Status tab: allows view of the current status of the gatekeeper by indicating the number of ongoing calls and registered endpoints, as well as bandwidth usage statistics for in-zone and outof-zone calls; - Settings tab: this is where most of the configuration options are specified, logically separated into a series of thematic categories (Basics, Calls, Dial Plan, Supplementary Services, Logs, LDAP, DNS, Security, Alternate Gatekeeper, Advanced); - Endpoints tab: allows view and control of the currently-registered endpoints with details on their aliases (name and number), IP addresses and online time.This tab can be used to predefine endpoints, i.e. assign specific aliases to endpoints that may later be used for endpoint identification during authentication; - Services tab: allows view and configuration of the currently declared services. By default, four services exist at installation time and they are not activated, since their prefix setting is null. Therefore they merely exist as templates for defining basic services functionality; - Call Control tab: allows view and control of the calls in progress and the setting up of gatekeeper-initiated calls between arbitrary endpoints, with the Make call option, assuming the gatekeeper runs in fully-routed mode (see the Signalling Models Section and the Settings tab, category Calls in the ECS interface); - Forwarding tab: allows set-up of forwarding rules based on source and destination, for three cases: forward on busy, forward on no answer, unconditional forward; - Hierarchy tab: allows set-up of a parent gatekeeper in order to forward Location Requests for cases of unresolved destinations. User-assigned filters may also be applied to specify and control the extent of the cases referred upstream to the parent gatekeeper.
P.91
Even though the ECS Gatekeeper runs out-of-the-box, you may want to inspect some of its basic settings and decide whether they fit the needs of your application.There are three tabs that should be, at least browsed, through before proceeding with operation. Under Settings tab, in the category Basic, make a note of the name of the gatekeeper (gatekeeper ID). Also, be aware of the setting who can register, where the choices are everyone for no authentication control, predefined endpoints only for some authentication control and no endpoints to turn down all endpoints for maintenance reasons only.The choice between dial plan v.1 and dial plan v.2 may not be obvious, but keep in mind that the second option allows more flexibility in hierarchically connected gatekeeper environments. Once chosen, it dynamically enables extra configuration sections.The option for DHCP environment may be used for authentication control, as it instructs the gatekeeper to identify endpoints by previously seen IP addresses and H.323 aliases (names) and authenticate them, based on this information.The last choice, merge predefined and on-line aliases upon registration is an interesting feature, because it allows the gatekeeper to apply extra aliases to well-known and identified endpoints, e.g., an endpoint may register with a name alias only, but the gatekeeper will attach an E.164 number to this endpoint as well. Under the Settings tab, in the category Calls, be aware of the routing mode selection, as it alter the operation of the gatekeeper dramatically. Direct mode employs minimal communication between endpoints and gatekeeper (RAS messages only), while Call set-up routing mode forces call set-up messages to be routed through the gatekeeper as well (Q.931).The third mode forces all previous messages, as well as call control messages, to be routed through the gatekeeper and not directly between the endpoints.The setting of accept calls can be used for maintenance reasons to turn off all calling between endpoints. Under the Settings tab, in the category Dialplan, assuming you have chosen dial plan version 2, you will be able to specify the stripping of zone prefixes from destination information of incoming calls.This feature may allow a more user-friendly dial plan, where in-zone endpoints use shorter dial numbers for dialling and out-of-zone endpoints use full-length dial numbers. In passing, check the category Logs if you would like to enable logging for debugging purposes, and the category Billing to enable usage statistics and accounting. Category DNS will allow discovery of neighbouring gatekeepers through specially crafted DNS TXT records, but it seems to be compatible only with other RADVISION gatekeepers. Category LDAP will allow endpoint alias data and neighbour data to be retrieved from LDAP directory services, as well as LDAP-enabled endpoint authentication.
~ 4.5.2.3 Operation
Immediately after installation, the ECS may service endpoints, and you can verify this by making a couple of endpoints point to the gatekeeper for registration. As soon as the endpoints register, they appear at the Endpoints tab.You may proceed with calling between the two endpoints by dialling from one of the registered aliases (name or number) to the other.The ongoing call will appear in the Call Control tab. As an administrator of the gatekeeper, you may disconnect the call, or even un-register an endpoint from the respective tab sections. Logs of gatekeeper
P.92
operations may be started through the Settings tab, Logs subsection and can be inspected as text files from the C:\Program Files\Radvision\ECS\Gatekeeper\Logs directory where they are maintained and rotated after they reach a certain size.
P.93
~ 4.5.3.1 Installation
Installing the GNU GK Gatekeeper is not a simple task, if you decide to compile the source of the gatekeeper and the two libraries it requires. However, this may be your only option, if support of MySQL and LDAP is required, since the provided precompiled binaries are lacking it.To avoid compilation of the code, please refer to the Pre-Built binaries downloads at the end of this section. In order to compile and build the GNU GK you will need both the PWLib libraries (version 1.2 or later) and the OpenH323 libraries (version 1.8 or later). If you are not familiar with those libraries, please refer to their Web site on how to build them. Recommended versions of the libraries are PWLib 1.4.11 or later and Openh323 1.11.7 or later. The order of compiling the packages is the following: - PWLib (release + debug version); - OpenH323; - OpenH323 test application (not needed, just to make sure everything works so far); - The GNU Gatekeeper itself; To compile the GNU Gatekeeper on UNIX, do a make debug or make opt in the gatekeeper source directory to build debug or release versions, respectively. Use make both to build both versions. Note that you have to use GCC 2.95.2 or later. Good practice is to do a make debugdepend or make optdepend in the gatekeeper source directory before starting actual compilation (make debug or make opt). On Windows, just open and compile the provided project (gk.dsw) for Microsoft Visual C++ 6.0 or 7.0 (Visual C++ 5.0 is too old). The gatekeeper supports MySQL and LDAP back-end interfaces (support for LDAP is still under development).The make scripts will look for the MySQL and OpenLDAP libraries in standard places, but if they are not found, you will have to explicitly point to their source directories by config options. If you do not want MySQL support, you may set the NO_MYSQL environment before making:
P.94
$ NO_MYSQL=1 make both To leave out LDAP support: $ NO_LDAP=1 make both Or disable both with $ NO_MYSQL=1 NO_LDAP=1 make both
For gatekeepers with a large numbers of concurrent calls, the GNU GK has implemented an extended fd_set structure that enables the gatekeeper to support thousands of concurrent calls in routed mode.To enable this feature, export the LARGE_FDSET environment variable to the maximum number of file descriptors. For example:
$ LARGE_FDSET=16384 make opt The GNU GK includes implementation of a Radius protocol client that enables registration/admission authentication and authorisation using Radius servers. This featured is enabled by default. To disable compilation of these Radius modules, set the NO_RADIUS environment variable before making: $ NO_RADIUS=1 make both The GNU GK is able to do accounting. Currently, only RADIUS and plain text file accounting modules are available. The accounting is still considered an experimental feature, so it is not compiled in by default. To enable accounting, set the HAS_ACCT environment variable before making: $ HAS_ACCT=1 make both
Moreover, there is no special installation procedure needed. After compilation, copy the executable to a directory of your choice and create a configuration file for it.There are several configuration examples in the etc/ subdirectory of the source tree. See the next section on Configuration for further explanations. For example, to start the gatekeeper, a command like this should work if the configuration file (gnugk.ini) is correct.
$ /usr/sbin/gnugk -c /etc/gnugk.ini -o /var/log/gnugk.log -ttt
If you do not wish to compile the gatekeeper from source, there are several pre-built binaries packages available. Not all versions will be made available as binaries.Therefore the reader will have to check what is available. Regarding Red Hat packages, you will have to download the RPMs and enter the following command as root, substituting in the name of the file you wish downloaded.
$ rpm -Uvh gnugk-x.x.x.rpm
P.95
Regarding the Debian packages, you can install the gatekeeper by using the following command as root:
$ apt-get install openh323gk
~ 4.5.3.2 Configuration
The behaviour of the gatekeeper is completely determined by the command line options at run time and the specified configuration file. Some command line options may override settings in the configuration file. In order to avoid confusion, it is common practice to keep all the configuration options in the configuration file and start the GNU GK with the following command:
$ [/usr/sbin/]gnugk -c /etc/gnugk.ini -o /var/log/gnugk.log -ttt
Here we provide a sample configuration file with the most important options for setting up basic services and their relative explanation. Note that all user-specified fields are indicated as beginning with my and you must customise/replace them appropriately for your site.
#Two lines in order to be able to telnet your GK on a specific port #(the default is port 7000) #(the authorisation rules are detailed in the [GkStatus::Auth] section) [Gatekeeper::Main] Fourtytwo=42 #name of your GK Name=my-GnuGK #Network information #Specify the network interfaces of the gatekeeper #By default the gatekeeper will detect the interfaces #of your host automatically Home=my-ip-address #information about the parent GK in order to forward LRQ #for out-of-zone calls [RasSrv::Neighbors] [neighbour-name]=my-ip-address:my-port;my-prefix-of-the-neighbour #define some features on LRQ and LCF [RasSrv::LRQFeatures] #The gatekeeper replies with LCFs containing #the destinationInfo and destinationType fields, #the registered aliases and the terminal type of the destination endpoint #The neighbor gatekeeper can then save the information #to suppress later LRQs #However, some vendors' gatekeepers misuse the information, #thus resulting in interoperability problems #set it to 0 if you encounter problems with a third-party GK
P.96
IncludeDestinationInfoInLCF=0 #Include a NonStandardParameter in LRQs #to be compatible with Cisco gatekeepers CiscoGKCompatible=1 #If hopCount has reached 0, the gatekeeper shall not forward the message ForwardHopCount=10 #route mode section [RoutedMode] #Enable the gatekeeper routed mode, as opposed to the direct mode GKRouted=1 #Route the H.245 control channel, only takes effect if GKRouted=1 H245Routed=1 #Some endpoints send h245Address in the UUIE of Q.931 #even when h245Tunnelling is set to TRUE #This may cause interoperability problems, avoid setting this option to 1 RemoveH245AddressOnTunnelling=1 #The gatekeeper could tear down a call by sending #RAS DisengageRequest to endpoints #Some bad endpoints just ignore this command, with this option turned on, #the gatekeeper will send #Q.931 Release Complete instead of RAS DRQ to both endpoints #to force them to drop the call DropCallsByReleaseComplete=1 #Setting this parameter to 1 makes the gatekeeper #to always send Release Complete to both endpoints #before closing the call when it receives DRQ from one of the parties SendReleaseCompleteOnDRQ=1 #Authorisation rules for telnet access to port #(the default is port 7000) [GkStatus::Auth] #allow only specific addresses rule=regex # - we are allowing the IP addresses 192.168.1.* regex=^(192\.168\.1\.[0-9]+) default=forbid #if you want to allow everybody, comment the previous lines and ... #rule=allow
~ 4.5.3.3 Operation
There are a number of ways to monitor the operation of the GNU GK. A command-line (telnet) interface is provided, which is installed by default and allows monitoring of endpoints registrations and call requests. It also accepts unregistration commands for specific endpoints, call clearing and even reloading of the configuration file, having inserted the following lines in the configuration file:
P.97
[Gatekeeper::Main] Fourtytwo=42 [GkStatus::Auth] rule=allow we can telnet to the GNU GK machine on the port specified in the configuration file (the default is port 7000): me@mypc> telnet gnugk-ip-address 7000
There are a number of commands that can be issued in this telnet session: type help to see a list of them. Most commands are easy and intuitive and there is no need to explain them further.To end the telnet session with the gatekeeper, type quit and hit Enter. Moreover, there are two Graphical User Interface (GUI) front-ends for the gatekeeper in order to monitor and visualise the operations: - Java GUI:This allows you to monitor the registrations and calls that go through the gatekeeper. A right-click on a button gives you a popup menu for each endpoint.This GUI works with Java 1.0 built into most Web browsers; - GkGUI: A new standalone Java program. It requires Java 1.4.The GkGUI is released under GNU General Public License.
P.98
be prepared to spend many hours over out-dated documentation and recompilations of new code-fixing releases.
P.99
Content-Length: 0. . # U +0.000406 195.37.77.101:5060 -> 153.96.14.162:5060 SIP/2.0 401 Unauthorised. Via: SIP/2.0/UDP 153.96.14.162:5060. From: sip:[email protected]. To: sip:[email protected]. Call-ID: [email protected]. CSeq: 101 REGISTER. WWW-Authenticate: Digest realm="iptel.org", \ nonce="3d9385170000000043acbf6ba...", algorithm=MD5. Server: Sip EXpress router(0.8.8 (i386/linux)). Content-Length: 0. Warning: 392 127.0.0.1:5060 "Noisy feedback tells: pid=31604 ".
Note that in this example, the second-hop server does not issue any warning header fields in replies and it is thus impossible to display its IP address in sipsak's output.
P.100
4.6.2.2.2 Requirements
* gcc or icc : gcc >= 2.9x; >= (3.1 recommended. It will work with older version but it might require some options tweaking for best performance.)
P.101
* bison or yacc (Berkeley yacc) * flex * GNU make (on Linux this is the standard make, on FreeBSD and Solaris is called gmake) * sed and tr (used in the make files) * GNU tar (gtar on Solaris) and gzip if you want make tar to work. * GNU install or BSD install (on Solaris ginstall) if you want make install, make bin, and make sunpkg to work. * mysql if you need MySQL support. * apache (httpd) if you want serweb support * PHP, MySQL-PHPfor serweb support * libmysqlclient and libz (zlib) if you want MySQL support (the MySQL module) * libexpat if you want the Jabber gateway support (the Jabber module)
Packages for other popular distributions are available, and can be installed using the appropriate package manager for that distribution. On many platforms you can start the ser service using:
/etc/init.d/ser start
That will start the server with the default configuration.You can try to register your SIP user agent (for example, MS Messenger) with the server, place first calls as well as send instant messages to other users registered with this server. The default configuration is very limited. Its purpose is to allow the starting to start the server easily and to test the basic functionality.The default configuration does not include authentication, the persistence of the user location database and many other important features.
P.102
Once you have the MySQL server installed and running, execute
/usr/sbin/ser_mysql.sh create
That will create database ser and all the tables that are required by SER. You can verify that the database has been created and correct permissions assigned by using the MySQL management tool and these steps: Mysql> select * from user; | Host | User |% | ser | localhost | ser |% | serro | localhost | serro
| Select_priv |N |Y |N |Y
The above results show that the two users, ser and serro, have been created and granted the permissions needed to access the database. Note that, in the above example, the permissions have been modified to deny access to these accounts from any system (%) other than the local host.
mysql> connect ser; Connection id: 294 Current database: ser mysql> show tables; +-----------------+ | Tables_in_ser | +-----------------+ | acc | | active_sessions | | aliases | | config | | event | | grp | | location | | missed_calls | | pending | | phonebook | | reserved | | silo | | subscriber | | version | +-----------------+ 14 rows in set (0.00 sec) mysql> select * from subscriber; | phplib_id | USERNAME | PASSWORD | FIRST_NAME | ... | 4cefa7a4d3c8c2dbf6328520bd873a19 | admin | heslo | first | ...
P.103
The previous query shows that you have one user account defined and it has administrator privileges. Users with administrator privileges will be allowed to user the admin interface of Serweb. Another account needs to be the administrator for your realm.That will be done later.
P.104
Note that the default configuration settings, as set by this simple script, have several limitations. By default, authentication is turned off to avoid dependency on MySQL. Unless it is turned on, anyone can register using any name and hijack someone else's calls. Even if authentication is turned on, there is no relationship between, authentication username and the address of record (see Section 2.2.2.2.3).That means, for example, that a user authenticating himself correctly with a john.doe id, may register contacts for gw.bush. Site policy may wish to mandate that the authentication ID must be identical to the username claimed in the To header field.The auth module contains action called check_to that can be used to enforce such a policy. No dial plan is implemented. All users are supposed to be reachable via the user-location database. The script assumes users will be using the server's hostname as the domain part of the address of record. If users wish to use another name (domain name for example), this must be set using the alias options. If authentication is turned on by un-commenting-related configuration options, the server will assume that the back-end authentication database contains the password in clear-text form (another option is storing HA1 strings for the digest authentication, but the strings must be generated for every administrative domain of the server separately). Example 4.3 Example of a default configuration script
# # simple quick-start config script # # ----------- global configuration parameters -----------------------debug=3 # debug level (cmd line: -dddddddddd) fork=yes log_stderror=no # (cmd line: -E) /* Uncomment these lines to enter debugging mode fork=no log_stderror=yes */ check_via=no # (cmd. line: -v) dns=no # (cmd. line: -r) rev_dns=no # (cmd. line: -R) port=5060 children=4 fifo="/tmp/ser_fifo" # ------------------ module loading ----------------------------------
P.105
# Uncomment this if you want to use SQL database #loadmodule "/usr/local/lib/ser/modules/mysql.so" loadmodule loadmodule loadmodule loadmodule loadmodule loadmodule loadmodule "/usr/local/lib/ser/modules/sl.so" "/usr/local/lib/ser/modules/tm.so" "/usr/local/lib/ser/modules/rr.so" "/usr/local/lib/ser/modules/maxfwd.so" "/usr/local/lib/ser/modules/usrloc.so" "/usr/local/lib/ser/modules/registrar.so" "/usr/local/lib/ser/modules/textops.so"
# Uncomment this if you want digest authentication # mysql.so must be loaded ! #loadmodule "/usr/local/lib/ser/modules/auth.so" #loadmodule "/usr/local/lib/ser/modules/auth_db.so" # ----------------- setting module-specific parameters --------------# -- usrloc params -modparam("usrloc", "db_mode", 0)
# Uncomment this if you want to use SQL database # for persistent storage and comment the previous line #modparam("usrloc", "db_mode", 2) # -- auth params -# Uncomment if you are using auth module # #modparam("auth_db", "calculate_ha1", yes) # # If you set "calculate_ha1" parameter to yes (which true in this config), # uncomment also the following parameter) # #modparam("auth_db", "password_column", "password") # -- rr params -# add value to ;lr param to make some broken UAs happy modparam("rr", "enable_full_lr", 1) # ------------------------# main routing logic route{ # initial sanity checks -- messages with request routing logic -------------------
P.106
# max_forwards==0, or excessively long requests if (!mf_process_maxfwd_header("10")) { sl_send_reply("483","Too Many Hops"); break; }; if (msg:len >= max_len ) { sl_send_reply("513", "Message too big"); break; }; # we record-route all messages -- to make sure that # subsequent messages will go through our proxy; that's # particularly good if upstream and downstream entities # use different transport protocol if (!method=="REGISTER") record_route(); # subsequent messages withing a dialog should take the # path determined by record-routing if (loose_route()) { # mark routing logic in request append_hf("P-hint: rr-enforced\r\n"); route(1); break; }; if (!uri==myself) { # mark routing logic in request append_hf("P-hint: outbound\r\n"); route(1); break; }; # if the request is for other domain use UsrLoc # (in case, it does not work, use the following command # with proper names and addresses in it) if (uri==myself) { if (method=="REGISTER") { # Uncomment this if you want to use digest authentication # if (!_authorize("iptel.org", "subscriber")) { # www_challenge("iptel.org", "0"); # break; # }; save("location"); break;
P.107
}; lookup("aliases"); if (!uri==myself) { append_hf("P-hint: outbound alias\r\n"); route(1); break; }; # native SIP destinations are handled using our USRLOC DB if (!lookup("location")) { sl_send_reply("404", "Not Found"); break; }; }; append_hf("P-hint: usrloc applied\r\n"); route(1); } route[1] { # send it out now; use stateful forwarding as it works reliably # even for UDP2TCP if (!t_relay()) { sl_reply_error(); }; }
P.108
route{ # for testing purposes, simply okay all REGISTERs if (method=="REGISTER") { log("REGISTER"); sl_send_reply("200", "ok"); break; }; # rewrite current URI, which is always part of destination ser rewriteuri("sip:[email protected]:9"); # append one more URI to the destination ser append_branch("sip:[email protected]:9"); # redirect now sl_send_reply("300", "Redirect"); }
P.109
# ------------------ module loading ---------------------------------loadmodule "modules/sl/sl.so" loadmodule "modules/tm/tm.so" # ----------------- setting module-specific parameters --------------# -- tm params -# set time for which ser will be waiting for a final response; # fr_inv_timer sets value for INVITE transactions, fr_timer # for all others modparam("tm", "fr_inv_timer", 15 ) modparam("tm", "fr_timer", 10 ) # ------------------------# main routing logic route{ # for testing purposes, simply okay all REGISTERs if (method=="REGISTER") { log("REGISTER"); sl_send_reply("200", "ok"); break; }; # try these two destinations first in parallel; the second # destination is targeted to sink port -- that will make ser # wait until timer hits seturi("sip:[email protected]"); append_branch("sip:[email protected]:9"); # if we do not get a positive reply, continue at reply_route[1] t_on_failure("1"); # forward the request to all destinations in destination set now t_relay(); } failure_route[1] { # forwarding failed -- try again at another destination append_branch("sip:[email protected]"); request routing logic -------------------
P.110
log(1,"first redirection\n"); # if this alternative destination fails too, proceed to ... t_on_failure("2"); t_relay(); } failure_route[2] { # try out the last resort destination append_branch("sip:[email protected]"); log(1, "second redirection\n"); # we no more call t_on_negative here; if this destination # fails too, transaction will complete t_relay();
4.6.2.4.5 Accounting
In some scenarios, like termination of calls in the PSTN, SIP administrators may wish to keep track of placed calls. SER can be configured to report on completed transactions. Reports are sent by default to the syslog facility. Support for RADIUS and MySQL accounting exists as well. Note that SER is by no means call-stateful. It reports on completed transactions, i.e., after a successful call set up is reported, it drops any call-related state.When a call is terminated, a transactional state for the BYE request is created and forgotten again after the transaction completes.This is a feature and not a bug. Keeping the state information during transactions only allows the achievement of significantly higher scalability. It is then up to the accounting application to correlate call initiation and termination events. To enable call accounting, tm and acc modules need to be loaded and requests need to be processed statefully and labelled for accounting.This means that if you want a transaction to be reported, the initial request must have taken the path setflag(X), t_relay in the SER script. X must have the value configured in the acc_flag configuration option. Also note, that, by default, only transactions that initiate a SIP dialogue (typically INVITE) visit a proxy server. Subsequent transactions are exchanged directly between end-devices, do not visit proxy server and cannot be reported.To be able to report on subsequent transactions, you need to force them to visit the proxy server by turning on record routing. Example 4.6 Configuration with enabled accounting
# # example: accounting calls to numerical destinations # # ------------------ module loading ---------------------------------loadmodule "modules/tm/tm.so" loadmodule "modules/acc/acc.so" loadmodule "modules/sl/sl.so"
P.111
loadmodule "modules/maxfwd/maxfwd.so" loadmodule "modules/rr/rr.so" # ----------------- setting module-specific parameters --------------# -- acc params -# set the reporting log level modparam("acc", "log_level", 1) # number of flag, which will be used for accounting; if a message is # labeled with this flag, its completion status will be reported modparam("acc", "log_flag", 1 ) # ------------------------# main routing logic route{ /* ********* ROUTINE CHECKS ********************************** */ request routing logic -------------------
# filter too old messages if (!mf_process_maxfwd_header("10")) { log("LOG: Too many hops\n"); sl_send_reply("483","Too Many Hops"); break; }; if (len_gt( max_len )) { sl_send_reply("513", "Wow -- Message too large"); break; }; # Process record-routing if (loose_route()) { t_relay(); break; };
# labeled all transaction for accounting setflag(1); # record-route INVITES to make sure BYEs will visit our server too if (method=="INVITE") record_route();
P.112
# forward the request statefuly now; (we need *stateful* forwarding, # because the stateful mode correlates requests with replies and # drops retransmissions; otherwise, we would have to report on # every single message received) if (!t_relay()) { sl_reply_error(); break; }; }
P.113
}; # all other requests to off-line users are simply replied # statelessly and no reports are issued sl_send_reply("404", "Not Found"); break; } else { # user on-line; report on failed transactions; mark the # transaction for reporting using the same number as # configured above; if the call is really missed, a report # will be issued setflag(3); # forward to user's current destination t_relay(); break; };
P.114
The table with aliases is updated using the serctl tool.The command serctl alias add <alias> <uri> adds a new alias, the command serctl alias show <user> prints an existing alias, and the command serctl alias rm <user> removes it.
[jiri@cat sip_router]$ serctl alias add 1234 sip:[email protected] sip:[email protected] 200 Added to table ('1234','sip:[email protected]') to 'aliases' [jiri@cat sip_router]$ serctl alias add john sip:[email protected] sip:[email protected] 200 Added to table ('john','sip:[email protected]') to 'aliases' [jiri@cat sip_router]$ serctl alias show john <sip:[email protected]>;q=1.00;expires=1073741811 [jiri@cat sip_router]$ serctl alias rm john 200 user (aliases, john) deleted
Note that the persistence of records needs to be turned on in the usrloc module. All changes to aliases would otherwise be lost on server reboot.To enable the persistence, set the db_mode usrloc parameter to a non-zero value.
# ....load module ... loadmodule "modules/usrloc/usrloc.so" # ... turn on persistence -- all changes to user tables are immediately # flushed to mysql modparam("usrloc", "db_mode", 1) # the SQL address: modparam("usrloc", "db_url","mysql://ser:secret@dbhost/ser")
P.115
serctl can also change the user's password or remove existing accounts from the system permanently.
[jiri@cat gen_ha1]$ serctl passwd newuser newpassword MySql Password: password change succeeded [jiri@cat gen_ha1]$ serctl rm newuser MySql Password: user removed
Typically, user contacts are automatically uploaded by SIP phones to the server during the registration process and administrators do not need to worry about them. However, users may wish to append permanent contacts to PSTN gateways or to locations in other administrative domains.To manipulate the contacts in such cases, use the serctl ul tool. Note that this is the only correct way to update contacts -- direct changes of the back-end MySQL database do not affect a server's memory. Also note, that if persistence is turned off (usrloc db_mode parameter set to 0), all contacts will be lost on server reboot. Make sure that the persistence is enabled if you add permanent contacts. To add a new permanent contact for a user, call serctl ul add <username> <contact>.To delete all users contacts, call serctl ul rm <username>.The command serctl ul show <username> prints all current contacts of this user.
[jiri@cat gen_ha1]$ serctl ul add newuser sip:[email protected] sip:[email protected] 200 Added to table ('newuser','sip:[email protected]') to 'location' [jiri@cat gen_ha1]$ serctl ul show newuser <sip:[email protected]>;q=1.00;expires=1073741812 [jiri@cat gen_ha1]$ serctl ul rm newuser 200 user (location, newuser) deleted [jiri@cat gen_ha1]$ serctl ul show newuser 404 Username newuser in table location not found
P.116
Authorisation (i.e., the process of determining who may call where) is facilitated in SER using the group membership concept. Scripts make decisions on whether a calling party is authorised to make a call to a specific destination, based on the user's membership in a group. For example, a policy may be set up to allow calls to international destinations, only to users who are members of int group. Before a user's group membership is checked, his identity must be verified.Without cryptographic verification of the user's identity, it would be impossible to confirm that a calling party really is who he claims to be. The following script demonstrates how to configure SER as an access control server for a PSTN gateway.The script verifies user identity using digest authentication, checks user's privileges, and forces all requests to visit the server. Example 4.8 Script for gateway access control
loadmodule loadmodule loadmodule loadmodule loadmodule loadmodule loadmodule loadmodule loadmodule loadmodule "modules/sl/sl.so" "modules/tm/tm.so" "modules/acc/acc.so" "modules/rr/rr.so" "modules/maxfwd/maxfwd.so" "modules/mysql/mysql.so" "modules/auth/auth.so" "modules/auth_db/auth_db.so" "modules/group/group.so" "modules/uri/uri.so"
# ----------------- setting module-specific parameters --------------modparam("auth_db", "db_url","mysql:ser:heslo@localhost/ser") modparam("auth_db", "calculate_ha1", yes) modparam("auth_db", "password_column", "password") # -- acc params -modparam("acc", "log_level", 1) # that is the flag for which we will account -- don't forget to # set the same one :-) modparam("acc", "log_flag", 1 ) # ------------------------# main routing logic route{ /* ********* ROUTINE CHECKS ********************************** */ request routing logic -------------------
# filter too old messages if (!mf_process_maxfwd_header("10")) { log("LOG: Too many hops\n"); sl_send_reply("483","Too Many Hops"); break;
P.117
}; if (len_gt( max_len )) { sl_send_reply("513", "Wow -- Message too large"); break; }; /* ********* RR ********************************** */ /* grant Route routing if route headers present */ if (loose_route()) { t_relay(); break; }; /* record-route INVITEs -- all subsequent requests must visit us */ if (method=="INVITE") { record_route(); }; # # # # now check if it really is a PSTN destination which should be handled by our gateway; if not, and the request is an invitation, drop it -we cannot terminate it in PSTN; relay non-INVITE requests -- it may be for example BYEs sent by gateway to call originator if (!uri=~"sip:\+?[0-9]+@.*") { if (method=="INVITE") { sl_send_reply("403", "Call cannot be served here"); } else { forward(uri:host, uri:port); }; break; }; # account completed transactions via syslog setflag(1); # free call destinations ... no authentication needed if ( is_user_in("Request-URI", "free-pstn") /* free destinations */ | uri=~"sip:[79][0-9][0-9][0-9]@.*" /* local PBX */ | uri=~"sip:98[0-9][0-9][0-9][0-9]") { log("free call"); } else if (src_ip==192.168.0.10) { # our gateway does not support digest authentication; # verify that a request is coming from it by source # address log("gateway-originated request"); } else { # in all other cases, we need to check the request against # access control lists; first of all, verify request # originator's identity if (!proxy_authorize( "gateway" /* realm */, "subscriber" /* table name */)) { proxy_challenge( "gateway" /* realm */, "0" /* no qop */ );
P.118
break; }; # authorise only for INVITEs -- RR/Contact may result in weird # things showing up in d-uri that would break our logic; our # major concern is INVITE which causes PSTN costs if (method=="INVITE") { # does the authenticated user have a permission for local # calls (destinations beginning with a single zero)? # (i.e., is he in the "local" group?) if (uri=~"sip:0[1-9][0-9]+@.*") { if (!is_user_in("credentials", "local")) { sl_send_reply("403", "No permission for local calls"); break; }; # the same for long-distance (destinations begin with two zeros") } else if (uri=~"sip:00[1-9][0-9]+@.*") { if (!is_user_in("credentials", "ld")) { sl_send_reply("403", " no permission for LD "); break; }; # the same for international calls (three zeros) } else if (uri=~"sip:000[1-9][0-9]+@.*") { if (!is_user_in("credentials", "int")) { sl_send_reply("403", "International permissions needed"); break; }; # everything else (e.g., interplanetary calls) is denied } else { sl_send_reply("403", "Forbidden"); break; }; }; # INVITE to authorised PSTN }; # authorised PSTN # if you have passed through all the checks, let your call go to GW! rewritehostport("192.168.0.10:5060"); # forward the request now if (!t_relay()) { sl_reply_error(); break; }; }
P.119
Use the serctl tool to maintain group membership.The command serctl acl grant <username> <group> makes a user member of a group, the command serctl acl show <username> shows groups of which a user is member, and the command serctl acl revoke <username> [<group>] revokes a user's membership in one or all groups.
[jiri@cat sip_router]$ serctl acl grant john int MySql Password: +------+-----+---------------------+ | user | grp | last_modified | +------+-----+---------------------+ | john | int | 2002-12-08 02:09:20 | +------+-----+---------------------+
~ 4.6.3 Asterisk
In this section we will describe an example configuration of the Asterisk PBX.We will focus mainly on the configuration of the SIP part.
~ 4.6.3.2 Installation
Download the tarball and untar it using:
tar xvfz asterisk-0.5.0.tar.gz
~ 4.6.3.3 Configuration
The configuration files can be found in the /etc/asterisk directory.The most important files are: sip.conf which contains configuration of SIP user agent and extensions.conf which defines the dialling plan. In this simple example, Asterisk is configured to act as a simple back-to-back user agent. It will allow SIP user agents to register to it and make calls which will be routed to an outbound proxy.
P.120
Section general contains some generic settings. Configure Asterisk to listen on port 5060 and to listen on all available interfaces. Specify context to be from-sip.The same context must be later configured in extensions.conf ! The line beginning with register instructs Asterisk to act as a user agent and register with the iptel.org server as user asterisk with password, password.The /jan part indicates that all incoming calls to user asterisk will be forwarded to user jan, registered at the Asterisk server. Section iptel contains configuration of a peer. In this case, it is the iptel.org proxy server, because we will be using this server as an outbound proxy. In this section, the parameter fromdomain is specified, because we want all outgoing messages to have this domain in the From header field. The last section, jan, contains credentials and data for a user that will be able to register with the Asterisk server. In this case, one SIP phone is configured with username jan and with an empty password and with a phone that will be registered with the Asterisk server to receive calls for username jan.
P.121
The first line describes the context which we have already configured in sip.conf .The following lines describe the dialling plan.The exten directive means that the extension of the call will be processed.The first parameter after the => is the extension. If the extension starts with an underscore then it will be treated as an expression. Otherwise only an exact match will be accepted. In the example, the first two lines match the extension jan.The rest of the lines will match any extension starting with digit 3. The second parameter is the preference of the line in the dialling plan.The last parameter is the action to be executed when the extension matches.The first line says that calls with extension jan will be routed to SIP and peer jan. Any extensions beginning with 3 will be routed to the iptel.org server using SIP and username jan will be set as the calling party ID. If a call fails then Asterisk will reply with an error message.
~ 4.6.4 VOCAL
~ 4.6.4.1 Overview
The Vovida Open Communication Application Library (VOCAL) is an open source project targeted at facilitating the adoption of Voice over IP in the marketplace.VOCAL provides the development community with software and tools needed to build Voice over IP features, applications and services.The VOCAL system is a distributed network of servers that provides Voice Over Internet Protocol (Voice over IP) telephony services.VOCAL supports devices that communicate using the Session Initiation Protocol (SIP, RFC3261).VOCAL also supports analogue telephones via residential gateways.VOCAL supports on-network and off-network calling. Off-network calling enables subscribers to connect to parties through either the Internet or the Public Switched Telephone Network (PSTN). The basic software in VOCAL includes a set of SIP-based servers (Redirect Server, Feature Server, Provisioning Server and Marshal Proxy Server).This is the stable development branch of the VOCAL server. Moreover, even if the following applications are not included in the current release (1.5.0), their source code remains available in the CVS archive
http://www.vovida.org/cgi-bin/fom?file=556:
P.122
SIP to MGCP translator Policy server Conference proxy server SIP to H.323 translator JTAPI feature server SIP User Agent (replaced by SIPset) SNMP/NetMgnt
For a more detailed overview of the VOCAL system please refer to: http://www.vovida.org
~ 4.6.4.2 Installation
If you have a previous installation of VOCAL that uses the vocalstart executable to run, you must stop all servers with vocalstart stop. Note that vocalstart is no longer used, as of version 1.4.0. In order to perform this action and to install VOCAL, you must be logged in as root in your Linux system. There are two options for downloading and installing VOCAL: - Installing from RPM: - Download vocalbin-version-x.i386.rpm from http:/www.vovida.org Install the RPM as root, typing rpm -U vocalbin-version-x.i386.rpm. Installing from source: Type the following sequence of commands:
./configure make make install
You must become root before executing make install. If you want to have more information about compiling and installing VOCAL please refer to the file BUILD.txt.
~ 4.6.4.3 Configuration
To set up a basic configuration, you have to use the configuration script indicated here:
/usr/local/vocal/bin/allinoneconfigure/allinoneconfigure
Running the allinoneconfigure script, you will be asked a number of questions. For basic services setup, answer all questions with the default answers. After such a default configuration, an Apache Web Server has been reconfigured on your Linux machine to provide basic Web-based configuration (provisioning in VOCAL terms) and must be restarted for this to take effect.
P.123
When the Apache Web Server is restarted you will be able to use the Web-based provisioning of the VOCAL system. In order to start provisioning your system you will have to point a browser to.
http://your.server.name/vocal/
You will be prompted for a password.The username is vocal. During configuration, you were asked to enter a password or choose to have one generated for you. If you have forgotten the password from that step, you can regenerate one by running the command:
allinoneconfigure -r
After you have run the allinoneconfigure script, make sure that your VOCAL system is running typing the following command:
/usr/local/vocal/bin/vocalctl status
You have to make sure that you are able to see all of the necessary processes, as follows:
fs 5080 fs 5085 ms 5060 ... 14957 14955 15002
If, instead of such a list of actively running servers with the details of the ports they are listening to, you see vocald is not running, then your VOCAL system is not running because something went wrong in the configuration. If your VOCAL system is running, you can verify your installation by running the verifysip command. Passing it the -a option causes verifysip to create two test users, test1000 and test1001, and make a call from test1000 to test1001. After testing, verifysip will remove the two users.You should be able to run it with a command like this:
/usr/local/vocal/bin/verifysip -a
P.124
~ 4.6.4.4 Operation
VOCAL 1.5.0 comes with two provisioning systems. Both work on the same configuration data. The first, uses a Java application to configure the system.The second uses Web-based CGI scripts, which run on the Web server to configure and control VOCAL. It can be accessed through your Web browser.The Web-based provisioning system provides simple access to the most commonly used provisioning options for an all-in-one system.The Java-based application provides complete view to the server's features, and dial plan provisioning. Both provisioning systems can be used on the same system, but they should not be run at the same time.The Web-based provisioning system is more limited than the Java-based one, thus some tasks require using the latter. For tasks other than those requiring the Java provisioning system, we recommend using the Web-based provisioning system.The provisioning systems allow the system administrators to work with user and server data. Administrators can choose to Add, View, Edit and Delete Users, as well as insert details of the clients/users allowed access to the VOCAL services. Server data can be used to configure services, as well as install more advanced features.
P.125
Dial plans are easily managed by configuring entries in the provisioning system GUI. Redirection services and backup servers, as well as more features like call forwarding and call blocking are carried out using specialised servers. Last, but not least, a voice mail server is used to deliver mail with attached voice files containing messages registered to the users.
P.126
2.Call signalling: Some call signalling messages contain IP addresses that are necessary for subsequent communication, e.g., the IP address (and port) to which media data will be sent. Usually, an endpoint transmits its local (private) IP address, causing the communication partner to fail when trying to connect to that IP address. One possible solution is the STUN protocol, defined in RFC 3489. An endpoint implementing this protocol connects to a public STUN server to be informed of his public IP address.The result of this query is used as the IP address to register with at a remote server.While STUN seems to be more popular in the SIP world, there is no H.323 endpoint that we are aware of that supports this feature. Another possibility is to use a router that is aware of IP Telephony protocols and rewrites the IP addresses within the application layer messages, as they are routed. But this requires full decoding and encoding support for SIP and/or H.323, which is simple for the text-based SIP protocol but quite complex for the ASN.1-based H.323 protocol. In addition, it is always possible that such a router might remove all message content it does not understand, so that trying to transport new protocol features through such a router may inexplicably fail. Such an IP Telephony router may come in the form of an application running on the NAT router itself - like the OpenH323Proxy4.
4. <http://sourceforge.net/projects/openh323proxy/> P.127
The price for the simplifications will be the use of an RTP relay in cases where it is not absolutely necessary, but such cases seem to be quite rare.The simpler solution will also impose higher requirements on SIP devices. Fortunately, most manufacturers seem to have implemented all necessary features already. The scenario, as presented in following subsections, assumes that the SIP Proxy is in the public Internet and SIP user agents are behind NAT.
P.128
Similarly, a user agent behind NAT must send a media packet with a source port that is same as the port on which the user agent expects media from remote party and which was advertised in the SDP.This is the only that way media will be able to pass the NAT in both directions. In addition, the remote party (which is in the public Internet) must ignore the contents of SDP and send the media, not to the IP and port which it received SDP, but to the IP and port from which are media from the remote party is coming.That will be the public IP of the NAT box. This approach is called Connection-Oriented Media and is also known as Symmetric Media. It will work when one party is behind a NAT and the other party is in the public Internet. In that case, the party behind NAT will send the first packet and the party in the public Internet will use the first packet to determine the IP and port to which it should send. When both parties are behind two different NATs, this approach will not work.The reason is very simple. Since both SIP user agents are behind NAT, both of them need to send the first media packet to open pinholes in NAT. Both of them will use the data received in SDP, but that will not work because the NATs might have changed the port number. To solve the situation, an intermediary in the public Internet will be necessary, an RTP proxy.The RTP proxy will receive all the media traffic from both parties and send it to the other side. Because it will be located in the public Internet, it can wait for the first media packet from both sides and send subsequent media packets to IPs and ports from which it received the first packets.
All the necessary NAT traversal features are implemented in the SIP Express Router available from iptel.org. Below is a brief description how the NAT traversal support works in the server.
P.129
4.7.3.3.1 Registration
When the server receives a registration, it tries to find out if the sender is behind a NAT. It does so by comparing the IP address from which the request came with IP address in Via of the sender. If they differ, then the user is behind a NAT and the information is saved into a userlocation database along with his contacts. If the previous test fails, then the proxy checks if Contacts contain private IP addresses. If so, then the user agent is also behind a NAT and the information is saved into a user-location database. For user agents behind NAT, registrar rewrites IP addresses and ports in the Contact header fields with the IP and port from which the REGISTER came and saves the value into the user location database. Later, when the proxy retrieves the information from the location database, it will get the rewritten values and it will send requests correctly to the IP of the NAT box which will, in turn, forward the request to the host in the private network.
P.130
It has been mentioned that the use of an RTP proxy is not forced when the called party is in the public Internet and does support symmetric media, but how do we know that? Indeed, there is currently no way of finding out whether a SIP user agent supports symmetric media or not.That means that an RTP proxy is not forced, except for destinations that are known to be symmetric, like voicemail or a PSTN gateway.
4.7.3.4.2 Drawbacks
Use of the RTP proxy has some drawbacks that are worth mentioning. First of all, it introduces another hop on the path from one user agent to another and this results in increased delay. How much the delay is increased depends on the underlying network and the location of the user agents. Secondly, the use of an RTP proxy imposes more burden on the server, because all of the media traffic has to go through the server. For example, for G.711, it is 64 kbit/s in each direction, per call. Care should be taken when building a server for RTP proxy that will receive a lot of media traffic.
First of all, it is necessary to load the nathelper module and configure its parameters. Put the following into the configuration file to load the module:
loadmodule "/usr/local/lib/ser/modules/nathelper.so"
P.131
The first parameter tells the registrar module which flag should be used to mark contacts behind NAT.The second parameter is the interval (in seconds) for keeping messages alive (to keep the NAT bindings open), and the last parameter specifies that only contacts that are behind the NAT should be pinged. To check if the sender of a message is behind a NAT, put the following test at the beginning of the main routing section of the configuration file (right after the test for messages that are too large):
# special handling for NATed clients; first, nat test is # executed: it looks for via!=received and RFC1918 addresses # in Contact (may fail if line-folding used); also, # the received test should, if complete, should check all # vias for presence of received if (nat_uac_test("3")) { # allow RR-ed requests, as these may indicate that # a NAT-enabled proxy takes care of it; unless it is # a REGISTER if (method == "REGISTER" || ! search("^Record-Route:")) { log("LOG: Someone trying to register from private IP, rewriting\n"); # # # # # # # This will work only for user agents that support symmetric communication. We tested quite many of them and majority is smart smart enough to be symmetric. In some phones, like it takes a configuration option. With Cisco 7960, it is called NAT_Enable=Yes, with kphone it is called "symmetric media" and "symmetric signalling". (The latter not part of public released yet.)
fix_nated_contact(); # Rewrite contact with source IP of signalling if (method == "INVITE") { fix_nated_sdp("1"); # Add direction=active to SDP };
P.132
force_rport(); setflag(6); }; };
The test does exactly what was described in previous sections. At the end of the processing, perform a similar test for the called party and force the use of an RTP proxy, if necessary. Because, potentially, there can be many places in an average configuration script from which to send out messages (all occurrences of the t_relay() or forward() actions). Put the whole test into a separate route section and call the section t_relay().
# # Forcing media relay if necessary # route[1] { if (uri=~"[@:](192\.168\.|10\.|172\.16)" && !search("^Route:")){ sl_send_reply("479", "We don't forward to private IP addresses"); break; }; if (isflagset(6)) { force_rtp_proxy(); t_on_reply("1"); append_hf("P-Behind-NAT: Yes\r\n"); }; if (!t_relay()) { sl_reply_error(); break; }; }
The route section checks if flag 6 (marks NAT) is set and if it is set, then it will force the use of the RTP proxy. Also setup an onreply_route section which will process 200 OK messages (it is necessary rewrite the Contact header field and SDP body in the reply).
P.133
This will generate a binary called rtpproxy. Start the proxy using ./rtpproxy and restart SER. SER and the RTP proxy use the socket /var/run/rtpproxy.sock to communicate.
P.134
This chapter introduces the user to the concept of setting up advanced services.There are sections for configuration and basic operations of gatewaying functions (Section 5.1) (gateways configuration, SIP to H.323 and vice-versa, H.323 to PSTN and SIP to PSTN), supplementary services (Section 5.2) and multipoint conferencing (Section 5.3).
-/ 5.1 Gatewaying
Please refer to Section 4.1 for a general architecture of SIP-H.323 and PSTN gatewaying.This section deals with an analysis of the characteristics of gateways and the configuration principles for the gatewaying functions to be set up in an advanced environment.The topics detailed in this section range from VoIP - PSTN gateways to SIP - H.323 Gateways configuration, ending with short considerations on accounting.
P.135
analogue module in a PBX. A corresponding module in a voice gateway is called a Foreign Exchange Station (FXS).
Figure 5.1 Voice gateway interfaces - PBX role FXS and SLMA modules can also be interconnected to trunk modules.Trunk Module Analogue (TMA) is the name of the trunk module on the PBX side, and Foreign Exchange Office (FXO) is the common name of the corresponding module in a voice gateway. A subscriber loop can be used in any of the following configurations: - Telephone to SLMA or FXS; - FXS to TMA; - FXO to SLMA. There are two operating modes: - FXO/TMA - telephone emulation (as common terminal equipment).This is a very simple mode. It only detects a ringing signal and provides digit dialling and switching between offhook (to close the loop) an on-hook (to open the loop); - FXS/SLMA - subscriber line circuit emulation. In this mode, the SLMA or FXS waits for a closed loop that will generate a current flow and a signalling tone of 425 Hz (with 10% tolerance).The Subscriber Line Interface Circuit Emulation (SLIC) provides the functions of BORSHT (Battery, Overvoltage, Ringing, Supervision, Hybrid 2/4 wires and Testing). The two most common methods for end-loop signalling are loop-start and ground-start signalling. DTMF (Dual Tone Multi-Frequency) is commonly used to transmit telephone number digits. DTMF tones identify numbers 0 through 9 and the * and # symbols. Digits are represented by a particular combination of two frequencies from the high group and the low group. Each group includes only four frequencies. Out of sixteen possible combinations, twelve are used on the keypad. DDI (Direct Dialling In) is possible only through a DTMF suffix, that is, during the connection time when the calling party normally is already paying for the connection.
P.136
M
signalling wires
Figure 5.2 E&M signalling, type V Signalling is carried out with direct current via the E & M control wires for call setup and tear down, pulse dialling and remote blocking. DTMF signals can alternatively be used for dialling. The E&M signalling can operate in several modes: - continuous signal; - wink start signal; - delay dial; - immediate dial.
P.137
17-31) to support for several features: - malicious call tracing (used to transfer calling party numbers); - override authorisation; - free calls; - called party hold.
S
TE1 NT2
T
NT1
U
Transmission line Customer premises ISDN local exchange
R
TE2 TA
Figure 5.3 ISDN configuration U interface is a two-wire interface from the telephone exchange; it supports full-duplex data transfer over a single pair of wires: only a single device can be connected to a U interface. T interface is between network terminations NT1 and NT2: NT1 converts two-wire U interface into four-wire T interface.
P.138
S interface and T interface are electrically equivalent. ISDN devices include an NT-2 in their design.The NT2 communicates with terminal equipment TE1 (ISDN terminal) or TE2 (nonISDN, connected to NT2 via terminal adapter), and handles the layer 2 and layer 3 ISDN protocols. Network Termination NT is divided into NT1 and NT2; NT1 works in Layer 1 and NT2 in Layers 2 and 3. NT1 and NT2 are connected by a four-wire T interface. Terminal Equipment TE1 is an ISDN compatible device (TE1 is connected to NT2 via a fourwire S interface). Terminal Equipment TE2 is a non-ISDN-compatible device that requires terminal adapter interconnection. Terminal Adapter provides an ISDN-compliant interface to NT and a standard interface to TE2 (such as RS-232, USB, X.21, etc.). Because a PBX can provide NT2 functions, the T interface is commonly used for interconnection of a PBX and a Voice Gateway.The PBX works in the user-side operation mode and the Voice Gateway in the network-side operation mode.
5.1.1.4.1 Q.931
The L2 and L3 interface of ISDN is also referred to as the Digital Subscriber Signalling System No.1 (DSS1).The L2 protocol of ISDN is ITU Q.920/Q. 921 and the L3 protocol is ITU Q.930/Q.931. Q.932 enables general procedures for accessing and controlling supplementary services. Q.931 provides call control capabilities. Some of the most important Q.931 messages are: - Setup; - Setup acknowledge; - Call proceeding; - Progress; - Alerting; - Connect; - Connect acknowledge; - Disconnect; - Release complete; - Information. The destination digits can be sent in two forms during call-setup: - complete called party number in the SETUP message, also known as the en-bloc signal; - one by one in separate messages, also known as the overlap signal An example of Q.931 Call control messages in call-setup with the en-bloc signal is shown in Figure 5.4.This example corresponds to the following setup: - Cisco AS5300 was used as a Voice Gateway and debugging was enabled with debug isdn q931 command;
P.139
- The call was initiated from the Technical University in Ostrava to the Czech Technical University in Prague,.The PBX was connected through ISDN/PRI and the called number was sent as the en-bloc in the SETUP message; - The Calling Party Number was 596991699 - The Called Party Number was 224352979
Figure 5.4 Q.931 call control messages in call-setup with the en-bloc signal
Jun 24 18:30:12.817: ISDN Se0:15: RX <- SETUP pd = 8 callref = 0x0002 Sending Complete Bearer Capability i = 0x8090A3 Channel ID i = 0xA9838E Calling Party Number i = 0x00, 0x83, '596991699', Plan:Unknown, ... Called Party Number i = 0x80, '224352979', Plan:Unknown, Type:U... High Layer Compat i = 0x9181 Jun 24 18:30:12.837: ISDN Se0:15: TX -> CALL_PROC pd = 8 callref = 0x8002 Channel ID i = 0xA9838E Jun 24 18:30:13.129: ISDN Se0:15: TX -> ALERTING pd = 8 callref = 0x8002 Progress Ind i = 0x8188 - In-band info or appropriate now available Progress Ind i = 0x8182 - Destination address is non-ISDN
An example of Q.931 call control messages in call-setup with the overlap signal is shown in Figure 5.5.
P.140
This example corresponds to the following setup: - Cisco AS5300 was used as a Voice Gateway; debugging was enabled with a debug isdn q931 command; - The call was initiated from the Czech Technical University in Prague to PSTN (Public Switched Telephone Network); the PBX in Prague was connected through ISDN/PRI and the called number was sent as the digit by digit (overlap) in the SETUP and INFOMATION messages; - The Calling Party Number is 224355406; - The Called Party Number is 224324997.
Jun 24 18:31:43.092: ISDN Se1:15: RX <- SETUP pd = 8 callref = 0x540A Bearer Capability i = 0x8090A3 Channel ID i = 0xA1838E Progress Ind i = 0x8183 - Origination address is non-ISDN Calling Party Number i = 0x31, 0x81, '224355406', Plan:ISDN, Type:. Called Party Number i = 0x81, '2', Plan:ISDN, Type:Unknown Jun 24 18:31:43.104: ISDN Se1:15: TX -> SETUP_ACK pd = 8 callref = 0xD40A Channel ID i = 0xA9838E Jun 24 18:31:43.808: ISDN Se1:15: RX <- INFORMATION pd = 8 callref = 0x540A Called Party Number i = 0x81, '2', Plan:ISDN, Type:Unknown Jun 24 18:31:45.152: ISDN Se1:15: RX <- INFORMATION pd = 8 callref = 0x540A Called Party Number i = 0x81, '4', Plan:ISDN, Type:Unknown Jun 24 18:31:46.536: ISDN Se1:15: RX <- INFORMATION pd = 8 callref = 0x540A Called Party Number i = 0x81, '3', Plan:ISDN, Type:Unknown Jun 24 18:31:47.564: ISDN Se1:15: RX <- INFORMATION pd = 8 callref = 0x540A Called Party Number i = 0x81, '2', Plan:ISDN, Type:Unknown Jun 24 18:31:48.896: ISDN Se1:15: RX <- INFORMATION pd = 8 callref = 0x540A Called Party Number i = 0x81, '4', Plan:ISDN, Type:Unknown Jun 24 18:31:51.012: ISDN Se1:15: RX <- INFORMATION pd = 8 callref = 0x540A Called Party Number i = 0x81, '9', Plan:ISDN, Type:Unknown Jun 24 18:31:52.696: ISDN Se1:15: RX <- INFORMATION pd = 8 callref = 0x540A Called Party Number i = 0x81, '9', Plan:ISDN, Type:Unknown Jun 24 18:31:54.480: ISDN Se1:15: RX <- INFORMATION pd = 8 callref = 0x540A Called Party Number i = 0x81, '7', Plan:ISDN, Type:Unknown Jun 24 18:31:54.604: ISDN Se1:15: TX -> CALL_PROC pd = 8 callref = 0xD40A Jun 24 18:31:55.684: ISDN Se1:15: TX -> ALERTING pd = 8 callref = 0xD40A Progress Ind i = 0x8288 - In-band info or appropriate now available
P.141
This section introduces the basic principles on how to perform gatewaying using H.323. Basic configuration guidelines and operational principles of commercial and open source gatekeepers are described here in order to detail how to set up gatekeepers for interconnection with PSTN. Moreover, details on the configuration of gateways are given in order to provide guidelines on how to configure gateways to be part of an H.323 network.
5.1.2.1.1 Installation
Its installation is straight-forward, requiring merely power, a network interface, BRI ISDN interfaces and a PC on the same LAN for setting-up initial configuration parameters through a windows-based application.To manage the device, install the RADVISION OnLAN Tools from the installation disks, by running the setup.exe program on the PC. Since the gateway has no network configuration to begin with, the PC running the software will have to be on the same LAN in order to perform initial network setup of the unit. After specifying an IP address for the Ethernet interface of the unit, the configuration application can then be run remotely.
5.1.2.1.2 Configuration
When running the configuration application, you will need to specify the IP address of the target device, or choose one from the list of detected devices on the same LAN. After entering the administrative password, you are presented with a window where you specify which configuration to edit.The options are to edit the currently-loaded configuration of the device, or a previously saved-to-file configuration.The next step is to select which functionality to configure: the gatekeeper (select Gatekeeper Setup) or the gateway (select Unit Setup). Only the second option is of interest, since the gateway can register with any of the gatekeepers detailed above, and the built-in gatekeeper can be turned off since it provides only basic functionality. Select Unit Setup and proceed with Unit Identification and Date/Time options, which are informational only, by pressing the Next button. The next screen, Miscellaneous Parameters, presents a number of configuration options.The critical settings are the ones for Default Gatekeeper and for Default Router IP, which you must set to the IP address of the gatekeeper controlling your zone, and the IP address of the router (network gateway in the IP protocol sense).The rest of the settings can be left at their default state.
P.142
Figure 5.7 OnLAN unit identification The next screen, LAN Port Settings, is responsible for configuring the Ethernet interfaces.There are four screens, one for each of the four Ethernet ports. Configuring just one interface with an IP Address and IP Mask is sufficient.A summary screen with settings for all four ports follows.
P.143
Figure 5.8 OnLAN miscellaneous parameters and gateway registration on gatekeeper The next screen, Services Definition Table, is the most important one, since it defines the services that the gateway will make available to calling parties, by registering them with its controlling gatekeeper.
P.144
Each service definition includes information about the Prefix. It is called with the Call Type, which can be voice-only or H.320 (voice and video), and the Maximum Bit Rate which a call of this type and will be required. By defining different services, the calling parties are given the option to choose the type of call they can make, based on the service prefix they dial, assuming the prefixes are well known to the users, or at least that the gatekeepers have pre-selected default gateway services. For example, if the gateway defines a voice-only service with a prefix of e.g., 9, the administrator of the gatekeeper will likely make this the default service to route all calls to the gateway. Any user requiring a voice and video call will have to know the service prefix, e.g., 8, for that special type of call.The L2W gateway will already have template services defined, but you can add, edit or delete services as needed.There is certainly one thing you will need to customise and that is the service prefixes, in order to make them match your local dialling scheme.
Figure 5.10 OnLAN editing of a service definition The next screens refer to WAN Port Settings which, for an ISDN interface, present relative settings.The country-specific ISDN protocol must be selected, and the Phone Number connected to the ISDN port can be indicated. Also, specific services can be enabled or disabled for this WAN port, assuming more than one type of WAN port is available, each with distinct capabilities. A summary screen with settings for all WAN ports follows. At the end of the configuration wizard, you are given the option to save the new configuration settings in a file before downloading them to the gateway itself. At this point, the gateway is reloaded and the new settings are applied.
5.1.2.1.3 Operation
Immediately after configuration and reload, the gateway attempts to register its services with the gatekeeper.This must be verified on the gatekeeper-side before attempting to use the gateway's services. Specifically, there are two things that must be checked: a) the registration of the gateway on the gatekeeper and b) the registration of its service prefixes on the gatekeeper. For example, on the Cisco MCM Gatekeeper, the appropriate commands would be:
> show gatekeeper endpoints GATEKEEPER ENDPOINT REGISTRATION ================================ CallSignalAddr Port RASSignalAddr Port Zone Name
Type
Flags
P.145
1024
gk.mydomain.org
CH320-GW
At least one entry should refer to the registration of the gateway, indicating its IP address, the type of registration (H320-GW) and the H.323 alias of the unit (GW4134522623).
> show gatekeeper gw-type-prefixes GATEWAY TYPE PREFIX TABLE ========================= Prefix: 92* Zone gk.mydomain.org master gateway list: 194.257.8.150:1820 GW4134522623 Prefix: 93* Zone gk.mydomain.org master gateway list: 194.257.8.150:1820 GW4134522623
A listing of all registered services at the gatekeeper should include an entry for each of the services defined on the gateway, indicating the prefix, and the IP address and the H.323 alias of the gateway to forward calls to. If registration of services with the gatekeeper is confirmed, the gateway is ready to service calls, which can be traced through the gatekeeper tools. The gateway can be monitored by a command-line interface only:
> telnet 194.257.8.150 Trying 194.257.8.150... Connected to 194.257.8.150. Escape character is '^]'. VxWorks login: admin Password: ->
At this prompt, no command can be entered to explicit logs, but passive monitoring of events is provided. Logs on this interface can be overwhelming, but the L2W gateway does not provide any other means of debugging, or monitoring. Please note that in the current release a bug makes the L2W gateway unregister from the gatekeeper after some time, making its services unavailable to the zone. Check often for registration of gateway services and in case they are lost, reboot the gateway to force gatekeeper registration again.The most flexible way to reboot the gateway is to use the telnet interface, login, and apply a Control-X command.
5.1.2.1.4 Authentication
In environments where gatekeeper registration is authenticated, the gateway has to provide authentication credentials in order for the gatekeeper to allow its registration. If H.235 authentication is required by the gatekeeper, the L2W gateway does not support it and administrative measures must be taken at the gatekeeper-side to exempt it from authentication. If authentication by H.323 alias and password is required, e.g., for the Cisco MCM piggy-back mechanism, the L2W gateway has a fixed H.323 alias that it tries to register with the gatekeeper
P.146
(of the format GWnnnnnnnnnn, where n is a number generated by the gateway itself and is not configurable).The administrator must make sure that this specific H.323 alias is allowed to register on the gatekeeper with no password. Similar measures must be taken in case an IP-address plus H.323 alias-authentication method is applied on the gatekeeper-side.
Figure 5.11 Cisco voice gateway interconnection Gateway configuration can be divided into three main parts: - Protocol configuration; - Interface configuration; - Dial-peer configuration. The example corresponds to the following setup. As a Voice Gateway is used, Cisco 2651XM with appropriate IOS is connected through PRI/ISDN to the PBX and is registered to a gatekeeper. Examples of the configuration were cut off from the Cisco CLI command and show runningconfig output and comments.
P.147
accounting messages helps to manage the system easily if the gateway has more than one interface used for VoIP.
h323-gateway h323-gateway h323-gateway h323-gateway h323-gateway voip voip voip voip voip interface id GK1-CESNET2 ipaddr 195.113.113.131 1718 priority 100 id GK2-CESNET2 ipaddr 195.113.144.85 1718 h323-id VoGW-ZCU tech-prefix 1#
Voice gateway is registered to gatekeeper GK1-CESNET2 A second gatekeeper GK2-CESNET2 is used as backup The h323-id of the Voice Gateway is VoGW-ZCU. It is checked on the gatekeeper and is needed for successful registration
primary-net5 is the setting of the DSS1 (EuroISDN) signalling protocol on the primary interface PRI (basic-net3 is used on the BRI). timer T302 is the interval in milliseconds for overlap mode (the interface waits 5 seconds for possible additional call-control information). isdn protocol-emulate network is the configuration of the Layer2 and Layer3 of the ISDN protocol, the Voice Gateway is working as NT and the PBX is in the slave mode. isdn send-alerting causes the Alerting message to be is sent out before the Connect message. isdn sending-complete is an optional enhancement, where the sending complete information element is required in the outgoing call setup message.The last command specifies the transfer capability for voice calls.
P.148
dial-peer voice 1 pots destination-pattern 42037763.... progress_ind alert enable 8 direct-inward-dial port 0/0:15
These commands specify rules for calls to the PSTN(PBX) from the VoIP-side. The called number prefix is 42037763 and must be followed with four digits of extension (four dots substitution pattern).The best match to destination pattern chooses the right dial peer. progress_ind alert enable 8 is the transcription of the Progress element in the Alerting message.This transcription causes B-channels to interconnect and allows the resolving of a possible problem with the ring-back tone. The rules are written into the port interface 0/0:15 with DDI (Direct Dialling In).
dial-peer voice 112 voip destination-pattern 420......... session target ras no vad
These commands specify rules for calls leading to the VoIP-side from the PSTN(PBX): - The called number prefix is 420 and it must be followed with nine digits; - The target of this session is the gatekeeper, accessible through RAS signalling; - The last command specifies that the Voice Activity Detection is not possible (higher voice quality); - The default configuration is VAD with CNG function (Comfort Noise Generation). The user is reminded here that the listed configuration may not be sufficient to run a voice gateway on Cisco routers. Commands may depend on the type of the router and the IOS version used.
These entries tell the gatekeeper to route all calls to E.164 numbers, starting with 0, to the gateway that has registered with the H.323 alias gw-PSTN, and all calls to the E.164 numbers,
P.149
starting with 3, to the gateway that has registered with the H.323 alias gw-MOBILE. If there is no registered gateway with these alias, the call will fail. Note that you must use the gateway alias. You cannot just tell the gatekeeper the IP number of the gateway. Static configuration of gateway-ip-address/prefix is, in principle, possible using the [RasSrv::PermanentEndpoints] configuration section, but such a solution is not advised, because it leads to errors when a network reconfiguration is done. When using a gateway, you often have to use different numbers internally and rewrite them before sending them over a gateway into the telephone network.You can use the RasSrv::RewriteE164 section to configure this. [RasSrv::RewriteE164] 12345=08765 In this example, the gatekeeper is configured to replace the numbers 12345 at the beginning of the E.164 number dialled to 08765 (for example, 12345-99 is rewritten to 08765-99). Please refer to rewrite for the section syntax. A gateway can register its prefixes with the gatekeeper by containing supportedPrefixes in the terminalType field of RRQ.The following option defines whether to accept the specified prefixes of a gateway. AcceptGatewayPrefixes=1 #Default: 1 5.1.3. Gatewaying from SIP to PSTN/ISDN
P.150
The first parameters configure the gateway to be passive.That is good for the Connection Oriented Media.Value. Passive means that if there is a direction=active parameter in SDP, then the gateway will wait with the sending of media until it receives the first media packet from the remote party.This feature can be very useful for NAT traversal. It can be enabled only when the gateway is in the public Internet. The second line configures the gateway to check for the source of incoming media and send its media there if it is in a symmetric mode.This option is related to the previous one. Retry. Parameters specify how many times various SIP messages should be retried. The last parameter specifies how to reach the SIP Proxy. In this case, the gateway will send all the SIP traffic to iptel.org and it will use DNS to resolve it to IP.
P.151
- a call from H.323 to SIP; - media-switching and capabilities-negotiation; - a call termination. There are different modes in which a SIP/H.323 Gateway can operate. In this section, basic operation modes are described. For more detailed operations, please refer to Interworking Between SIP/SDP and H.323 for examples of basic functionalities as well as configuration guidelines. Actual configurations are relative to specific hardware/software and are out of the scope of this document. A SIP/H.323 Gateway may have a built-in H.323 Gatekeeper or a built-in SIP registrar (optional presence or activation of such entities are dependent on software implementation choices). Different operations are performed by the SIP/H.323 Gatekeeper depending on whether the internal gatekeeper/internal SIP register is activated or not. If a SIP/H.323 Gateway is configured appropriately, it should try to register both with an H.323 Gatekeeper using RAS procedures and with a SIP registrar, in order to perform the gateway's address resolution from either side. A SIP entity can query the registrar, whereas an H.323 entity can query the H.323 Gatekeeper to locate the SIP/H.323 Gateway. If the internal gatekeeper is activated, then no registration to an external gatekeeper should be performed. If the internal SIP registrar is activated, then no registration to an external SIP registrar should be performed. At least one H.323 Gatekeeper and at least one SIP registrar should be always specified/activated for operations to be successful. If an H.323 Gatekeeper is not specified, then a broadcast GRQ, Gatekeeper ReQuest, message should be sent to discover it. Once the H.323 Gatekeeper address is known, an RRQ, Registration ReQuest, message is used to register to it.The SIP/H.323 Gateway alias should be inserted in such a message. If no built-in SIP registrar is used, then an external SIP registrar address should always be specified (a SIP REGISTER message should always contain the destination address).The contact address inserted in the REGISTER message should be that of the SIP/H.323 Gateway itself.
P.152
SIP/H.323 Gateway SIP User Agent TE1 REGISTER SIP proxy /registar RRQ
Figure 5.12 A SIP/H.323 Gateway containing a SIP Proxy and registrar 2. The SIP/H.323 Gateway contains an H.323 Gatekeeper (Figure 5.13).The user registration information from both networks is maintained by the SIP Proxy Server.The SIP registrar receives the forwarding of any H.323 registration request received by the H.323 Gatekeeper.The SIP server stores the user registration information of both the SIP and H.323 entities;
SIP/H.323 Gateway SIP User Agent TE1 REGISTER SIP proxy /registar REGISTAR RRQ Sip messages H.323 messages
Figure 5.13 A SIP/H.323 Gateway containing an H.323 Gatekeeper 3. The SIP/H.323 Gateway is independent of a proxy or a gatekeeper (Figure 5.14). User registration is done independently in the SIP and H.323 networks.
H.323 Gatekeeper
H.323 Terminal
SIP/H.323 Gateway
LPQ
H.323 Terminal
P.153
P.154
capabilities-negotiation.While SIP offers media with the INVITE message, the normal H.323 mode is to open a separate H.245 channel. In this case, the SIP/H.323 Gateway has to start a muted SIP call, and re-negotiate the capabilities later, unless the H.323 client supports the use of the FastStart procedure. If both of these conditions can not be ensured, the gateway must use the default codecs for both sides and, eventually, perform media transcoding.
P.155
replicate all the wide range of services we are already used to in the PSTN networks. Section 5.2.1 will deal with the supplementary services using the H.323 protocol, while Section 5.2.2 will deal with supplementary services using the SIP protocol.
P.156
Supplementary services in H.323 are specified in a multi-tier approach. Basic services consist of building blocks or primitives from which more complex services can be developed. Compound services are developed from two or more basic services. For example, in a consultation transfer service, the user needs to put a multimedia call on hold and retrieve it later, to call another person and possibly alternate between the two calls, and to transfer the two calls together. Hence, this service is simply obtained combining basic supplementary services.The basic supplementary services defined in the H.450 series are described in the following; - H.450.2 - Call Transfer. It enables a user A to transform an existing call (user A - user B) into a new call between user B and a user C selected by user A; - H.450.3 - Call Diversion. It is also known as call forwarding and comprises the services: call forwarding unconditional, call forwarding busy, call forwarding no reply and call deflection. It applies during call establishment by providing a diversion of an incoming call to another destination alias address. Any of the above variants of call forwarding may operate on all calls, or selectively on calls fulfilling specific conditions programmed or manually selected by the user; - H.450.4 - Call Hold. It allows the served user (holding user), which may be the originally calling or the called user, to interrupt communications on an existing call and then subsequently, if desired, re-establish (i.e., retrieve) communications with the held user. During the call interruption, the holding user provides some form of media for the held user, and may perform other actions while the held user is being held, e.g., consulting another user; - H.450.5 - Call Park and Pickup.This is a service that enables the parking user A to place an existing call with user B to a parking position and to later pick up the call from the same or other terminal; - H.450.6 - Call Waiting. It permits a served user while being busy with one or more calls to be informed of an incoming call from a new user by an indication.The served user then has the choice of accepting, rejecting or ignoring the waiting call.The user calling the busy party is informed that the call is a waiting call at the called destination; - H.450.7 - Message Waiting Indication. It provides general-purpose notifications of waiting messages, including the number, type and subject of the messages; - H.450.8 - Name Indication.This service permits to a user A to be informed of an incoming or existing call or of the alerting state by a user B.The notification can be provided from a server or directly from user B; - H.450.9 - Call Completion. It enables a calling user A to have the call toward a user B completed without having to make a new call attempt, when the first call procedure has been not completed since user B was busy or, though alerted, did not answer; - H.450.10 - Call Offer. It permits to a calling user A, encountering a busy destination user B, to camp-on to the busy user.This means that the call is indicated to user B and kept in a waiting state until user B reacts to the indication, rather than being released due to the busy condition; - H.450.11 - Call Intrusion. It enables a calling user A, encountering a busy destination user B, to establish communication with user B by breaking into an established call between user B and a third user C;. - H.450.12 - Common Information Additional Network Feature (ANF-CMN).This is an additional network feature that enables the exchange of Common Information between ANFCMN endpoints.This Common Information is a collection of miscellaneous information that relates to the endpoint or equipment at one end of a connection and includes one or more of the following: Feature Identifiers, Feature Values, or Feature Controls.This information, when received by an ANF-CMN endpoint, can be used for any purpose, e.g., as the basis for indications to the local user or to another network or in order to filter feature requests.
P.157
The following examples can be useful to understand how the supplementary services can be implemented. In the example, attention will be focused mainly on the signalling procedure, considering that the peer-to-peer approach adopted by the H.323 supplementary services concentrates the problems related to the service implementation to the endpoint or gatekeeper used as service server.
Figure 5.15 Messages exchanged to implement the CT-SS without gatekeeper The example refers to the case where the gatekeeper is absent or the direct signalling model is adopted. In this case, only the software able to process and to generate the APDUs is necessary to implement the service. An example is given in Figure 5.16 where we report an Ohphone (an openh323 application) interface modified with, the addition, of a Call Transfer Supplementary
P.158
services button. In this case, simply pressing the Transfer button makes the application of an open dialogue screen, allowing the insertion of the H.323 ID of the called party and generating the necessary APDUs.
Figure 5.16 An example of Call Transfer Supplementary Service without gatekeeper - Ohphonemodified interface
P.159
To better understand the signalling procedure used, Figure 5.17 illustrates the messages exchanged for the CT-SS when the gatekeeper manages the signalling on behalf of the transferred user, i.e., B user.
Figure 5.17 Messages exchange for gatekeeper-managed CT-SS After the reception and the processing of the FACILITY message, indicating that user A wants to transfer the current call, the gatekeeper sends a SETUP message with a callTransferSetup.invoke APDU to the transferred-to endpoint C.Then, the reception of the ALERTING or CONNECT message with the appropriate APDU transmitted by the user C enables the gatekeeper to send a FACILITY message with the APDU informing the endpoint B that it has been transferred (joining). To instruct the endpoint for the new set of media channels, the gatekeeper sends an empty terminal capability set (it is defined as a terminalCapabilitySet message that contains only a sequence number and a protocol identifier) to endpoints A and B, causing A and B to close their logical channels, and to endpoint C, causing this endpoint to enter in the transmitter side paused state. While in this state, an endpoint does not initiate the opening of any logical channels, but accepts the opening and closing of logical channels from the remote end, based on the usual rules, and continues to receive media on open logical channels opened by the remote endpoint.This procedure allows gatekeepers to re-route connections from endpoints that do not support supplementary services, and endpoints to receive announcements (e.g., pre-connect call progress) where the announcing entity does not wish to receive media from the endpoint. The transmitter side paused state is left by the endpoint on reception of any terminalCapabilitySet message, other than an empty capability set. On leaving this state, an endpoint resets its H.245 state to that which it was in just after the H.245 transport connection was made at call establishment time (i.e., the beginning of phase B), but it preserves state information relating to any logical channels that are open.
P.160
This puts the endpoint in a known H.245 state after the pause, allowing an endpoint to be connected to a different endpoint when it is released from the paused state. After leaving the transmitter side paused state, an endpoint proceeds with normal H.245 procedures: it takes part in master/slave determination signalling and proceeds with normal open logical channel signalling procedures. After these procedures, necessary to set the new call between B and C, the gatekeeper sends a RELEASE COMPLETE message containing callTransferInitiate return result APDU to release the call signalling channel of the primary calls, i.e., between A and B.
P.161
On acceptance of the CD request, the served endpoint performs the diversion towards the indicated diverted-to number.The original call at the served user remains in the alerting state and the served user is still able to accept the call until the diverted-to endpoint enters an alerting state. When the diverted-to endpoint enters the alerting state, the call to the served user is cleared.
P.162
When the SS-CW is invoked, user B is given an appropriate indication of the waiting call and the calling user C may be informed about SS-CW being invoked at the destination by being provided with an appropriate indication. After receiving the call waiting indication, user B has the choice of accepting, rejecting or ignoring the waiting call. During the call waiting condition, the calling user C has the option to release the call or to invoke other supplementary services, e.g., message waiting callback. In the case of endpoints able to simultaneously manage different calls, the SS-CW is invoked only when an attempt for a new call (i.e. the H.225.0 SETUP message from user C arrives to endpoint B) is made to exceed the maximum number of calls the endpoint B can simultaneously hold.This condition leads the served endpoint B to return an ALERTING message towards the calling user C containing the appropriate APDU. Meanwhile, the endpoint B locally provides a call waiting indication to the user B.The busy User B can free resources to accept a waiting call by: - releasing an existing call according to the procedures of recommendation H.225.0; - using the Call Hold Supplementary Service on an existing call according to the procedures of Recommendation H.450.4; - using the Call Park Supplementary Service on the existing call according to the procedures of Recommendation H.450.5. If the served user B accepts the waiting call, the served endpoint sends the CONNECT message to the calling user and proceeds with normal call establishment procedures. After the reception of the ALERTING message containing the APDU indicating the invocation of the SS-CW by the endpoint B, the calling endpoint provides a call waiting indication to the calling user, which has the following options: - wait until the waiting call gets accepted (connected) by the served user B; - release the call; - invoke other supplementary services, e.g. message waiting callback; - perform other actions (e.g. sending e-mail).
P.163
The RADVISION ECS Gatekeeper, being based on a H.323 v.4 protocol stack, implements a number of the H.450 features. On the ECS configuration interface, check the Settings tab, under the category Supplementary Services, where you can enable the following: - Unconditional forward (H.450.3): endpoints may select to redirect calls to other endpoints in all cases; - Forward on busy (H.450.3): endpoints may select to redirect calls to other endpoints when they are themselves busy; - Forward on no response (H.450.3): endpoints may select to redirect calls to other endpoints when they could not respond to a call after x minutes. After enabling the above services, the gatekeeper administrator can define forwarding rules by utilising the Forwarding tab. Rules for specific endpoints (Standard), as well as mass-application (Wildcard) rules for whole prefixes can be applied for all three forwarding conditions: unconditional, on busy, on no answer. For all supplementary services to function, the administrator must enable full routing mode (Settings tab, category Calls). Make note that the ECS administrator can also initiate calls between endpoints, by using the Call Control tab, and the Make Call button. The GNU Gatekeeper does not support any H.450 features either. However, some dynamic routing functionality can be implemented by utilising the virtual queues or CTI agents feature of the GNU Gatekeeper, which allows the operation of a simple model of aliasing a name and the forwarding of calls to a dynamic queue of agent endpoints.
P.164
The rest of this section demonstrates the most frequently used SIP services, gives a brief overview on provisioning of such services and also describes what the signalling looks like.
-/ 5.2.2.1 On-hold
With SIP, on-hold is implemented as a peer-to-peer feature. A phone putting the other telephone on hold does so by sending a specially-formed re-INVITE request. In response to such a request, the other phone stops sending media to save bandwidth and it indicates to the user that he is on hold. (It may be silent, display the status using user interface, play local music, etc.) There are subtle differences in how on-hold is signalled in earlier and current SIP versions. RFC 2543 used a dummy IP address 0.0.0.0 to indicate an on-hold condition whereas RFC 3261 uses SDP send only attribute. Call-flow on Figure 5.18 presents on-hold signalling implemented according to RFC 2543.The key message is re-INVITE, number 3, which puts the other party on hold.The SDP payload of numbered SIP messages is shown in detail (SIP headers have been removed because they are not important in this case).
Figure 5.18 On-hold call flow The following message is regular INVITE establishing a call 1. INVITE [SIP headers not shown]
v=0 o=Cisco-SIPUA 997 27044 IN IP4 192.168.2.32 s=SIP Call c=IN IP4 192.168.2.32
P.165
t=0 0 m=audio 21112 RTP/AVP 0 8 18 101 a=rtpmap:0 PCMU/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15
The previous INVITE is replied using the following 200 OK 2. 200 OK [SIP header not shown]
v=0 o=CiscoSystemsSIP-GW-UserAgent 2451 1894 IN IP4 195.37.77.110 s=SIP Call c=IN IP4 195.37.77.110 t=0 0 m=audio 18202 RTP/AVP 0 c=IN IP4 195.37.77.110 a=rtpmap:0 PCMU/8000 a=direction:passive
The following message puts the remote party on hold. Note the 0.0.0.0 on the line beginning with c=. 3. re-INVITE [SIP headers not shown]
v=0 o=Cisco-SIPUA 4919 16082 IN IP4 192.168.2.32 s=SIP Call c=IN IP4 0.0.0.0 t=0 0 m=audio 21112 RTP/AVP 0 8 18 101 a=rtpmap:0 PCMU/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15
The following message confirms the on hold state.There is nothing special in the SDP 4. 200 OK [SIP headers not shown]
v=0 o=CiscoSystemsSIP-GW-UserAgent 2451 1895 IN IP4 195.37.77.110 s=SIP Call c=IN IP4 195.37.77.110 t=0 0
P.166
P.167
Proxy
Called party
Transfer Agent
REFER REFER 202 Accepted 202 Accepted NOTIFY NOTIFY INVITE 100 Trying INVITE 100 Trying
200 OK 200 OK BYE BYE 200 OK 200 OK 200 OK 200 OK ACK ACK
Figure 5.19 Call transfer call flow The following INVITE message establishes a call from the calling party to the transfer agent. Note that the value from the Refer-To header field of the REFER message has been put into the Request-URI and To header field.
INVITE sip:[email protected] SIP/2.0 Via: SIP/2.0/UDP 192.168.0.130 From: <sip:[email protected]>;tag=32e189db-ec7e
P.168
To: <sip:[email protected]> Contact: <sip:[email protected]> Call-ID: [email protected] CSeq: 20142 INVITE Max-Forwards: 70 Content-Type: application/sdp Content-Length: 258 v=0 o=caller 0 0 IN IP4 192.168.0.130 s=c=IN IP4 192.168.0.130 t=0 0 m=audio 5004 RTP/AVP 0 8 4 18 2 15 a=ptime:20 a=rtpmap:0 PCMU/8000
The following BYE message (green in the call flow) terminates the call between calling party and called party.
BYE sip:195.37.77.101:5060;lr SIP/2.0 Via: SIP/2.0/UDP 192.168.2.32:5060 From: <sip:[email protected]>;tag=00036bb90fd3000 To: <sip:[email protected]>;tag=992d8f53-ca7e-c73f Call-ID: [email protected] CSeq: 104 BYE Content-Length: 0 Route: <sip:[email protected]:40012>
P.169
First, the current status of registered contacts is inspected.The command reveals that a SIP phone registered a contact from IP address 212.202.42.68.
jiri@fox:~$ serctl ul show jiri <sip:212.202.42.68:55723<;q=0.00;expires=272
To enable forwarding of incoming calls also to cell phone, introduce contact to the PSTN gateway. If a call arrives, the proxy server will ring both the previously-registered SIP phone and the manually-provisioned cell phone contact.
jiri@fox:~$ serctl ul add jiri sip:[email protected] sip:[email protected] 200 Added to table ('jiri','sip:[email protected]') to 'location' jiri@fox:~$ serctl ul show jiri <sip:[email protected]>;q=1.00;expires=1073741820 <sip:212.202.42.68:55723>;q=0.00;expires=21
....
# alas, the call was not established successfully; well, # let's retry with voicemail then failure_route[1] { revert_uri(); # resend to voicemail with original request URI
P.170
Whereas this example demonstrates a global site policy which is applied to each user, some subscribers may wish to formulate their specific call processing preferences. How the preferences are formulated and provisioned in the SIP server is not necessarily governed by standards. SIP servers may have their own proprietary user-provisioning interfaces, typically with a Web frontend. On the other hand, a standardised way of call handling allows easier service portability.The IETF standard for describing called partys preferences is called Call Processing Language, CPL. In short, it is a simple XML-based language that allows subscribers to determine how the server handles calls for them. It is a special-purpose language that supports the specification of most common types of call processing. CPL does not allow script writers to affect the behaviour of the server in a way which could compromise the security of the server. Whereas it is simple enough, most users will not be willing to write SER scripts. It is envisioned that CPL scripts will be generated and edited by applications with a convenient user interface. The following picture shows a screen snapshot of iptel.org's CPL editor.
P.171
The main function of the MCU starts at this point in the conference: it receives the audio signals of every party in the session, mixes the sources and copies the result to everyone except for the source party.This happens in real time, so everyone will hear everyone.This way of conversing has its specific ways of interaction between the parties. If a party wants to speak, it should be clear that the previous party has ended his part of the conversation.When collisions occur, it is useful if the session leader gives the word to one of those who wish to speak.These aspects have been investigated in the social-cultural area, but are not part of this cookbook. Now that the functionality is known in general, more details on the case of IP Telephony MCUs can be given. An MCU can be obtained either in hardware or in software. Many gatekeepers are equipped with built-in MCU software functionality. In case of a hardware MCU, the main interface is, of course, an Ethernet connection. From a functional point of view, users cannot approach the MCU directly over IP. No matter whether H.323 or SIP are used for setting up regular two-party calls, a user can only dial in to the MCU through a gatekeeper or SIP Proxy. Parties that use a PSTN phone can also join a conference by means of the IP-to-PSTN gateway.
Figure 5.21. MCU function in gatekeepers Modern MCUs can support both audio and video.The calling parties must support the audio and video codec that the MCU has on board. Some MCUs have the possibility to transcode between codecs, enabling users with different codecs to join the same conference. If video is also distributed by an MCU, the video streams cannot be mixed. One way this distribution mechanism is implemented is that only the video signal of the source with the loudest audio signal is transmitted to all users at that point of time (this in audio switching mode).There are other options, such as chair-controlled, in which the chair can lock the video (and possibly audio too) on one participant, or presentation mode. One participant is chosen and both audio and video are locked on the presenter; the rest of the audience can only listen. Some MCUs offer a Continuous Presence mode, in which the video signals is displayed in a matrix that shows all users to every user. Modern MCUs support other layouts as well. An alternative to using an MCU in the IP world is to use IP Multicast. In this case, all parties transmit their audio (and video) over a Multicast channel. All users must tune in to the channels of everyone else.This means that the total amount data traffic increases with every user that joins the conference. Unfortunately, few networks support Multicast.
P.172
This chapter introduces the concept of added-value services and their implementation in IP Telephony products.Value-added services are services that integrate VoIP with other protocols and services. Seamless integration with Web, E-mail and potential other Internet services provides convenience which, is a key feature of Internet telephony.
P.173
FreeRADIUS server can be configured to execute an external script each time an authentication is made.This method can be used to keep a list of currently registered endpoints on the gatekeeper and make it available over the Web as a primitive means of advertising availability. A slightly better method would be to configure FreeRADIUS with MySQL back-end and maintain a database table with currently registered endpoints, by updating the table for each RADIUS event (authentication and accounting).
P.174
- Sample ACD application: this interface allows the definition and management of groups of endpoints (agents) who will handle a large volume of calls for a single alias.The ACD will check which of the agents is qualified and available (not in another call and not logged off from ACD work) and informs the gatekeeper which agent will receive the call. If no agent is available, the ACD will tell the gatekeeper to reject the call. All call routing logic is kept out of the gatekeeper to ensure stable operation, while routing logic can be changed frequently; - PHP GNUgk Status Monitor - v0.4: this application allows monitoring of registered endpoints and calls in progress through a PHP Web interface. Call disconnection is possible and further functionality is being developed. Source code is available.
|- 6.2.1 Click-to-dial
Click-to-dial is a method of establishing a call between participants using a Web interface. It greatly simplifies dialling, in that calling parties do not have to dial lengthy addresses and they keep their phonebooks separately from SIP phones. In its simplest form, a user has a Webpage where he can enter the SIP addresses of two users, and the SIP user agents of those two users get connected.We will focus on REFER-based click-to-dial. A REFER-based click-to-dial scenario is based on the paradigm of intelligent end-devices and dumb network. One of the involved SIP user agents is asked to connect to the other and report to the server when it is done. The drawback of this approach is that one of the involved SIP user agents must support the REFER SIP method which has been standardised recently (see RFC3515).The big advantage that balances the previous drawback is that it is extremely easy to implement REFER- based click-to-dial in the server. Call-flow for REFER-based click-to-dial is depicted in Figure 6.1. First, the SIP server sends an INVITE to one of the phones because phones usually do not accept REFER without prior invitation.The INVITE contains 0.0.0.0 as the IP address in SDP, because there is no remote phone (the message is sent by user agent within the SIP server which does not deal with media). After that, the server sends a REFER method which will ask the phone to send INVITE somewhere else.The URI of the called party is passed to the phone in a Refer-To header field of the REFER method.
P.175
The phone sends a NOTIFY method back to the server once the connection is established. The click-to-dial feature allows the creation of many advanced features, like phone-book, in which you can click on an entry and your phone and phone of the person represented by the entry are connected.You can implement a list of missed call in exactly the same way and clicking on an entry in the list will connect your phone with that person. There are many others possible scenarios.
SIP Server INVITE UA1 UA2
200 OK ACK
|- 6.2.2 Presence
It is also possible to display the presence of SIP users in a Webpage (for example, in a phonebook). Displaying the on-line status of subscribers allows calling parties to determine availability and willingness to have a conversation conveniently.The status may be shown, for example, in the calling partys phonebook or on the called partys homepage. Linking on-line users to click-todial applications greatly integrates telephony with the Web and introduces convenience to users. When a SIP phone registers, the SIP server records this information into a database.The Web server can then access the database to see if a user is online or offline. Go to iptel.org, create a new account, and insert some entries into your phone-book to see how it works.
P.176
|- 6.2.4 Serweb
Serweb is a Web front-end for a SIP Express Router (see Section 4.6.2 for more details). Serweb creates a user interface for users of the proxy server, where they can manage their account, change their configuration and do many advanced things.
|- 6.2.4.1 Installation
Serweb is a set of php scripts.To run it, you will need Apache Web server with php and mysql support. Because a SIP Express Router and serweb talk together using a FIFO interface, the SIP Proxy and the Web server must be running on the same machine. Get serweb from http://developer.berlios.de/projects/serweb and untar the archive. It is recommended not to untar it to the document root of your Web server. Alternatively you can get serweb using CVS:
lexport CVSROOT=:pserver:anonymous:@cvs.berlios.de:/cvsroot/serweb cvs login cvs co iptel
|- 6.2.4.2 Configuration
The entire configuration of serweb is in config.php file in html subdirectory.You will need to configure the following:
- Host on which MySQL server is running: $this->db_host="localhost"; - Path of the user interface on the Web server: $this->root_path="/"; - Root URI of the Web server: $this->root_uri="http://www.foobar..." - Path of serweb images on the Web server: $this->img_src_path = $this>root_path."iptel_img/"; - Path of java script files of serweb: $this->js_src_path = $this>root_path."iptel_js/"; - Path of ccs files of serweb: $this->style_src_path = $this>root_path."iptel_styles/";
P.177
It is necessary to create some aliases in the configuration file of Apache Web server:
Alias Alias Alias Alias /iptel_img "/var/www/iptel/html/img" /iptel_styles "/var/www/iptel/html/styles" /user "/var/www/iptel/html/user_interface" /admin "/var/www/iptel/html/admin"
Do not forget to update the directory path according to your real settings and make sure that you have register_globals and short_open_tag set to On in your php.ini file.
|- 6.2.4.3 Operation
To login into serweb open: http://<your_server>/user in your Web browser. You will be prompted for username and password.The username and password is same as the one you are using in your SIP user agent to register at the server.
P.178
The My Account tab (see Figure 6.2) allows users to change their preferences and modified registered contacts.They can also see aliases they created and permissions for calling to the PSTN. Users can also create their own phone book (see Figure 6.3). In the phonebook, you can see the presence status of each user. If the user is currently registered, then you will see online in the status column. If he is not registered then you will see offline and if the user does not belong to administrative domain of the server, then you will see non-local.
Figure 6.3 Serweb - Phonebook Clicking on the address of a user will establish a phone call between your and his phone, provided that your phone supports REFER, as described in Section 6.2.1. The missed calls plane (see Figure 6.4), allows users' to see their missed calls. Again, clicking on an entry will connect you with that user and status describes presence of the user as described in the previous section.
P.179
Figure 6.4 Serweb - Missed calls When anyone sends a SIMPLE message to a user that is currently not online, the server will store the message and send it later when the recipient comes online. In the plane message store (see Figure 6.5), you can see all messages that are stored for you.
P.180
Figure 6.5 Serweb - Message store Then, when the server receives a MESSAGE request and it cannot deliver it because the recipient is offline, it will save the message:
if (!lookup("location")) { if (method == "MESSAGE") { if (!t_newtran()) { sl_reply_error(); break; }; if (m_store("0")) { t_reply("202", "Accepted for Later Delivery"); break; }; t_reply("503", "Service Unavailable"); break; }; };
When the lookup of recipient's location fails (the recipient is not registered), a new transaction is created (needed for msilo module). Save the message using the m_store command, and reply with 202 accepted .
P.181
Each time we call save (location), we have to check if the previously available user is registered again and if so, then send the stored messages.The following example shows how to do that:
if (!save("location")) { sl_reply_error(); }; m_dump();
Command m_dump checks if the registering user has any stored messages and if so, sends them.
|-6.3 Voicemail
Another Internet application which lends itself for integration with telephony is e-mail. A traditional PSTN application, which can be replaced with VoIP and e-mail, is voicemail. Traditional PSTN voicemail systems feature fairly inconvenient user interface for message retrieval: IVR (Interactive Voice Responder). Calling parties have to navigate through an automated voice menu, listen to lengthy announcements, type digits as prompted and be very patient to achieve very simple tasks. It is undoubtedly more convenient to deliver recorded messages to the called to party by e-mail.The called party can then listen, store and process the received messages at his convenience.The following picture shows the data flow in a voicemailto-e-mail scenario. An open-source voicemail-to-e-mail application, SEMS, is available from iptel.org. SEMS stands for SIP Express Media Server. It is an application framework that offers easily-built applications dealing with media streams.The framework itself provides only minimal functionality for accessing and manipulation of media streams and signalling. High-level logic is stored in additional modules that can be dynamically loaded. Examples of such modules are voicemail, announcement server and ISDN gateway. Some other voicemail systems exist including OpenAM, which is available from the OpenH323 Website and a voicemail system built-in inside the VOCAL system. Unfortunately, they are not easy to set up and they are not yet ready to be used in a production environment if you need a completely integrated product.They do not work without bugsand they can easily be customised for small environment scenarios.
P.182
P.183
The previous chapters described how to set up an IP Telephony site and how to use PSTN gateways to call external targets.With growing support and usage of IP Telephony, it becomes more and more interesting to interconnect IP Telephony sites and use the IP network to transport calls. Since dialling IP addresses is obviously not an option, inter-domain communication introduces the problem of call routing which can be dealt with in various ways.This chapter lists techniques and solutions for inter-domain call routing.
-}7.1 Technology
This section starts with listing possible mechanisms and protocols to provide inter-domain address resolution.
P.184
Figure 7.1 Location request mechanism In the case that a gatekeeper reached by the LRQ message does not know the answer to such a location request, there are different possible behaviours depending on the channel which is being used by the LRQ message. If the LRQ message was sent on the RAS channel, then the gatekeeper replies with a Location ReJect (LRJ), whereas no action is taken if it was sent on the multicast channel.This simple mechanism is depicted in Figure 7.1, where the channel being used by the LRQ messages is the RAS one. When handling calls directed to terminals on the traditional PSTN, the zone gatekeeper is in charge of registering the zone gateways. In such a case, the gatekeeper will take care of replying to the LRQ messages with a LCF message containing the call signal address of the gateway that is supposed to be the one routing the call to the PSTN network.
P.185
Annex G uses the AliasAddress structure to refer to addresses. Such usage is particularly useful when storing specific or wildcard addresses; thus it is able to carry any kind of address information used by H.323 (see Section 2.2.1.3.1). Along with the patterns, H.225.0 Annex G stores some routing information containing additional data about pricing, necessary access requests, contact information (which IP/Port to contact and what kind of QoS is provided) and other protocol-relevant data. Patterns and routing information are grouped in a so-called address template, along with the time to live to indicate how long the template is valid.The address template also contains information regarding the signalling protocols that may be used. Currently, signalling protocols include only the H.3xx protocol family.Templates are grouped together by an identifier, known as a descriptor. An administrative domain advertises templates by advertising descriptors to indicate the type of calls it can resolve.
T1
GK1
BE1
DescriptorIDRequest DescriptorIDConfirmation(IDs=d1,d2) DescriptorRequest(d1) DescriptorConfirmation DescriptorRequest(d2) DescriptorConfirmation
BE2
T2
Figure 7.2 Use of H.225.0 Annex G On the protocol side, H.225.0 Annex G defines unidirectional relationships between border elements. Such a relationship is established by sending a ServiceRequest to a well-known port (2099) of a configured peer. Upon receipt of a positive reply (ServiceConfirmation) the initiating peer sends a DescriptorIDRequest to the other border element, which replies by returning the IDs of all known descriptors (see Figure 7.2).The first border element now requests each descriptor by sending a DescriptorRequest. After all descriptors are sent, the initiating border element knows which addresses can be reached via the other border element.
P.186
When an endpoint,T1, tries to call another endpoint,T2, outside of T1's administrative domain, it sends the ARQ message to the gatekeeper GK1 as usual (see Figure 7.2). GK1 recognises the destination address in another administrative domain and asks its border element, BE1, by sending an LRQ.The border element knows by previous descriptor exchange with BE2 how to contact the given address. If BE2 requested that its authorisation is mandatory for all calls to that address template, BE1 sends an AccessRequest to BE2 before replying with a LCF (or LRJ) message. When GK1 receives a LCF message, the normal H.323 protocol flows apply. The access requests from BE1 to BE2 might be enforced.The gatekeeper of the called endpoint in BE2's administrative domain might send a ValidationRequest to BE2, to check if the incoming call has been accepted by the border element.
-} 7.1.3.1 Structure
TRIP defines communication between and within IP Telephony Administrative Domains (ITAD). Inter-ITAD communication uses peer relationships, which are considered to be setup between two sites upon a trust relationship. ITADs are identified by a globally unique number.The Internet Assigned Numbers Authority (IANA) registers ITAD numbers to ensure that a number is globally unique.Taking the amount of registered ITADs as an indicator of the interest in this protocol, and since exactly one registered ITAD is listed on the IANA Website,TRIP does not seem to be widespread. An ITAD consists of one or more location servers, of which at least one has a peer relationship to a location server of another ITAD.While inter-ITAD communication is routed on a hop-by-hop basis, the intra-ITAD communication is done by flooding all internal peers.
-} 7.1.3.2 Addressing
TRIP can be used for SIP and H.323 and allows disclosure of which signalling protocol can be used to reach an address. For instance, you can advertise the reachability of a phone number +49.421.2182972 via H.323 on host A, while the same address is reachable via SIP on another, host B. Since TRIP was intended to provide a mechanism that allows selection of egress gateways, the protocol is limited to phone numbers. It is not possible to advertise URIs and names (see Section 2.1.5) which makes TRIP unsuitable for all kinds of inter-domain call routing.
P.187
-} 7.1.3.3 Protocol
Initially, a TRIP Location Server (LS) knows just its local addresses.
A
B: sip:14,15 B: h323:19
A: sip:11,12,13,21
C: sip:10,18,19
D: sip:16,17
E: h323:10..18
Figure 7.3 TRIP: Location Servers and their initial data. After establishing connections with its peer LSs, each TRIP node advertises all the routes it already has knowledge of.
A
B: sip:14,15 B: h323:19 C: sip:10,18,19
A: sip:11,12,13,21 C: sip:10,18,19
C: B: B: A: D:
E: h323:10..18 D: sip:16,17
Figure 7.4 TRIP: LS tells peers their initial data When an LS receives data from a peer LS, it stores it internally.This data is distributed the next time the LS sends an UPDATE message to its peers, but not before a minimum delay has elapsed (see Figure 7.5). Each node can decide whether to advertise itself (or better: the associated VoIP server) as the next-hop server of the new learned numbers (Node D) or to pass the information of the original contact (Node C).
P.188
A
B: B: C: A: D: sip:14,15 h323:19 sip:10,18,19 sip:10..13,21 sip:16,17
A: C: B: B: D: C: B: B: A: D: D:
sip:11,12,13,21 sip:10,18,19 sip:14,15 h323:19 sip:16,17 sip:10,18,19 sip:14,15 h323:19 sip:10..13,21 sip:16,17 h323:10...18 E: h323:10..18 D: sip:16,17 D: sip:10,18,19
D: E: C: A: B: B:
Figure 7.5 TRIP: Advertising gathered knowledge When a LS collects a continuous range of telephone numbers (e.g., from 770 to 779), it can aggregate this information to a common prefix. In the example given in Figure 7.6, Node D knows how to reach the numbers from sip:10 to sip:19. Since E is not on the path to one of these numbers, it withdraws the routes sent previously and adds a new route containing the prefix 1. Node C could have done the same for h323:10 to h323:19 when talking to A, but since C was configured not to put itself in the chain of next-hop servers (or simply because the feature is not supported), it does not aggregate that information.
A: B: B: C: D: D: C: B: B: A: D: D: sip:11,12,13,21 sip:14,15 h323:19 sip:10,18,19 sip:16,17 h323:10..18 sip:10,18,19 sip:14,15 h323:19 sip:10..13,21 sip:16,17 h323:10..18 E: h323:10..18
B: B: A: C: D: D:
D: E: C: A: B: B:
D: sip:1 D: h323:19
P.189
-} 7.1.4 SRV-Records
In February 2000, RFC 2782 was approved, describing a DNS RR for specifying the location of services (DNS SRV).Before then, there was a need (and sometimes there still is) for users to know the exact address of a server providing a specific service for a specific domain (i.e., GK or SIP Proxy).The first attempt at point-to-service-specific servers was MX record, used for mail servers. But, unfortunately, there was no feasible means of expressing a common service. The SRV records allow administrators to easily manage the address propagation of servers providing specific services and could provide significant service-based routing advice. Several servers could be used for a single domain, with defined preference- and load-balancing. Users can easily ask for a desired service in a specific domain and obtain a name or list of server names that provide the service they requested. The SRV RR is a structured collection of fields, each one with a name and a specific meaning: - Service - Describes the service by its symbolic name (i.e., LDAP or SIP) registered by IANA Assigned numbers or locally defined. An underscore is prepended to avoid conflicts with common names that may occur in DNS. Service name is case insensitive; - Proto - Describes the used protocol by its symbolic name. An underscore is prepended to avoid conflicts with common names that may occur in DNS. Service name is case insensitive.The most common values for this filed are _tcp and _udp at present; - Name - Describes the domain name for which the service is specified; - TTL - It is the time to live of the record. It specifies how many seconds the record will be valid in the cache of a questioner; - Class - IN class is right for SRV records.The meanings of TTL and Class are described in detail in RFC 1035; - Priority - Describes priority of the target host in range between 0 and 65535.The records with lowest number should be tried first; - Weight - Describes a server selection mechanism for records with the same priority. Zero should be used if no server selection should be done. Otherwise, the higher number gives the record proportionally higher probability of being selected; - Port - Describes the service port on the target host (i.e., 5060 for SIP).These numbers are often the same as registered IANA assigned numbers, if the service is running in a standard port; - Target - Describes the name of the target host.The address for the name could be provided by one or more address records (even A or AAAA). Use of an alias as the name is prohibited. If the client wants to find a server for a desired service, it first tries SRV lookup. If the result contains one record, the address of the server is resolved and used. In a case where there is more than one record, they are ordered by preference and weight and tried out. If no record is returned, A or AAAA lookup should be performed.
$ORIGIN domain.org. _ldap._tcp SRV 0 1 389 ldap1.domain.org SRV 0 3 389 ldap2.domain.org SRV 1 0 389 ldap-old.domain.org *._tcp SRV 0 0 0 . *._ucp SRV 0 0 0 .
P.190
This example shows an SRV LDAP service for the domain domain.org. A user asking for LDAP service, using the TCP protocol, obtains three records. During the first round of attempts the user should try to connect to ldap1.domain.org or ldap2.domain.org.Three quarters of attempts should go to ldap1 and one quarter to ldap2. If neither of those two is available, the user should then try to connect to ldap-old.The last two records determine that no other service, using either TCP or UDP, is provided in the domain domain.org. More detailed information about DNS RR can be found in RFC 2782. The two most-used VoIP protocols are SIP and H.323.The SIP protocol usually uses service names such as _sip and _sips and protocol names such as _tcp and _udp. H.323, in its Annex O, describes the use of SRV RR to locate specific services. Service names and protocols are more distinguishable in H.323 than it is the case in SIP: - h323ls - Location Service, entity supporting H.225.0 LRQ; - h323rs - Registration Service, entity supporting H.225.0 RRQ; - h323cs - Call Signalling, entity that performs H.225.0 call signalling; - h323be - Border Element, entity that supports communication as defined in Annex G. Along with protocol symbolic names such as TCP and UDP, sctp and h323mux are also used.The contents of the Annex O will hopefully be implemented in new versions of H.323 products together with Protocol Specification,Version 5. As can be seen, SRV record helps to find service-specific servers for desired domains. In the case of VoIP, that means lowering the need to maintain the address of distant servers information at gatekeepers and proxies and to ease the configuration of the clients.
-} 7.1.5 ENUM
One of the main issues with IP Telephony today is seamless integration with the PSTN. As more than one signalling protocol is used, integration should include them all. In general, it could be useful to have one identifier (business card contact) for all available services. By service, we could understand phone call (PSTN, SIP, and H.323), e-mail,Web and many others. Such a unifying identifier was chosen to be the E.164 number defined by ITU-T standards. It is represented as a number up to fifteen digits with a leading +.These numbers are used in the PSTN and very often by H.323 systems.The next issue was to find a reasonable worldwide, deployed database that would hold and provide such translation information.The DNS seems to be the right way at the moment, as it is used in probably all server and client machines in the Internet. The mechanism of the E.164 to URI DDDS (Dynamic Delegation Discovery System RFC 3401) translation and its applications (ENUM) is described by RFC 2916 bis draft (currently 07) and by the RFCs listed as a reference in that draft.
P.191
The NAPTR RR is a structured collection of fields used to store translation information.The most important fields are the following: - Name Represents an E.164 number encoded as a domain name.The conversion is done by the following algorithm:
o All non-digit characters are removed. +420-123456789 is transformed to 42123456789 o Dots are inserted between each digit 42123456789 is transformed to 4.2.0.1.2.3.4.5.6.7.8.9 o Order of digits is reversed 4.2.0.1.2.3.4.5.6.7.8.9 is transformed to 9.8.7.6.5.4.3.2.1.0.2.4 o To the end is appended string e164.arpa 4.2.0.1.2.3.4.5.6.7.8.9 is transformed to 4.2.0.1.2.3.4.5.6.7.8.9.e164.arpa
The e164.arpa domain is used worldwide as the domain designed for the ENUM purpose only; - Order - Specifies the order of NAPTR rules processing.The ordering is from lowest to highest, i.e., records with the same order value are processed according to a combination of Preference and Service; - Preference - Equivalent to the Priority field in the SRV RR.The main difference between Order and Preference is that once a match is found, the client has to work with records within only one Order, but it can use records with different Preference values within the selected Order.The use of SRV records or a multiple address record is important for load balancing; - Flags - These are strings consisting of characters (A-Z, 0-9) that control the way of rewriting and interpreting a record. Flags are defined by RFC 3404. S, A and U flags are used as terminal flags terminating the DDDS loop (RFC 3402) and determining what should be the next action.The U flag is used to define that the output of the rule is an URI.The A flag means that the output is the domain name and that it should be resolved by using address records (A,AAAA, A6). It is expected that the output of the rule with the S flag is the domain name for which one or more SRV records exists.The most-used flag seems to be the U flag.The use of the U flag does not deny SRV lookup at questioner for the domains returned in URI.These two mechanisms can cooperate at a very large scale; - Service - Service parameters have the following form:E2U+service-type:subtype, where E2U is the mandatory and non-optional value determining E.164 to URI translation.The service-type and subtype (ENUM-service) define what the record can be used for. URI schemes, service-types and subtypes are not implicitly mapped one to another.This mapping could be done by specification of the ENUM-service. Most important for VoIP use, are SIP (draft-ietf-sipping-e164-04.txt) and H.323 (draft-ietf-enum-h323-01.txt) scheme specifications. The application decides what record to use, comparing its own capabilities and the user request with offered ENUM service types; - Regexp - This is a string containing a regular expression that the questioner applies to the original string. Note that regular expression is a very powerful tool and therefore should be
P.192
well-constructed and tested to avoid errors leading to partial unreachability of the user.The easiest regular expression is !^.*$!, which covers the whole original string; - Replacement - This field is used when the regular expression is a simple replacement and its value is the domain name that will be queried next. A NAPTR record for number +420123456798 could look like this:
$ORIGIN 9.8.7.6.5.4.3.2.1.0.2.4.e164.arpa IN NAPTR 10 100 "u" "E2U+sip" "!^.*$!sip:[email protected]!" . IN NAPTR 10 101 "u" "E2U+h323" "!^.*$!sip:[email protected]!" . IN NAPTR 10 102 "u" "E2U+msg:mailto" "!^.*$!mailto:[email protected]!" .
Domain 9.8.7.6.5.4.3.2.1.0.2.4.e164.arpa (user with E.164 number +420123456789) is contacted first by SIP, second by H.323 and third by e-mail. A wildcard could be used to express prefixes. Use of wildcards is under discussion.The example could then look like this.
$ORIGIN 7.6.5.4.3.2.1.0.2.4.e164.arpa * IN NAPTR 10 100 "u" "E2U+sip" "!^\+420(.*)$!sip:$\[email protected]!" .
All numbers with prefix +4201234567 will be translated into sip:1234567[suffix]@domain.org and contacted by SIP. How will the whole process work? In the example the user dials +420123456789 in his SIP client; a NAPTR query is performed and, according to the service provided by the SIP client, the URI sip:[email protected] is formed.Then the client tries to find the SIP server for the domain, domain.org via an SRV or A (AAAA, A6) query and connects to the obtained address. Using ENUM along with SRV helps to provide flexible management of available services and provides a single contact point that could be used even from the PSTN.This is the major task of ENUM. Even ENUM has some problems.The main problem could be security. Especially if DNS is used as record storage, information could be easily retrieved from the database and used, for example, for spamming.
P.193
Figure 7.7 Using peers to route external calls. This structure does not scale to a large number of connected sites. Manually configuring each server and its prefixes is error-prone and exhausting at best.The solution to this problem could be the usage of SRV-Records (see Section 7.1.4) or even TXT-Records that where defined for H.323 since version 2, but since most IP Telephony solutions where used for intra-domain
P.194
communication and as a PBX replacement, dynamic address resolution was not implemented for a long time. For this reason and because of legacy VoIP equipment, the idea of a gatekeeper hierarchy was born. A gatekeeper that cannot resolve an address itself sends a location request to a higher level gatekeeper that acts as a clearing house for this request.This gatekeeper may also need to ask a higher-level gatekeeper. The gatekeeper hierarchy is oriented at political or organisational structures. On top, there is a world gatekeeper that can route calls to the top level gatekeepers of all nations.The sub-structuring within a nation may vary. A dialling scheme must be applied to address the gatekeepers.To provide a testbed,ViDeNet came up with the Global Dialling Scheme (GDS) that is explained in more detail in Section 7.2.2.1.The problem with the GDS is that, in its original form, it differs from the E.164 numbering space except in country codes.
P.195
International Access Code (IAC) This is also called the world gatekeeper prefix. It is defined as 00; Country Code (CC) This follows the ITU international access code system. For instance, the country code for the Netherlands is 31. See the following PDF document for country codes:
http://www.itu.int/itudoc/itu-t/ob-lists/icc/e164_717.pdf
Organisational Prefix (OP) Many national research organisations follow the telephone number system in their country and use their area code and organisational telephone exchange prefix. For instance, SURFnet's OP is 302305. However, there are other possibilities. Some organisations use their administration number or make one up. National research organisations or videoconferencing service providers could instead supply you with an OP, as was the case with the old ViDeNet system. In any case, your OP must be unique within a country. If you do not know your OP, please contact your videoconferencing service provider, your national gatekeeper or the NASM working group (see below); Endpoint Number (EN) Your EN can be any number and it is decided by each organisation. However, we recommend that it is no longer than seven digits. Each endpoint number MUST be unique within the organisation. Both 305 and 1234567 are fine examples as long as they are unique.
7.2.2.1.2 Examples
The Megaconference informal test MCU: 00(IAC) 1(CC) 189(OP) 7201234(EN) Typed into your videoconferencing endpoint, the number would simply look like: 0011897201234
P.196
-} 7.2.2.2 Problems
The use of H.323 LRQs and of a gatekeeper hierarchy is an easy way to enable all kinds of H.323 equipment to reach other sites. On the other hand, there are some problems that make this solution less desirable: - Latency - The address resolution process may include multiple hops (e.g., from an organisational gatekeeper to another gatekeeper in another country, there are at least four hops). Each hop increases the time needed to process the request and eventually forward it. So it may take several seconds to resolve an address even before the call setup can begin. Speaking of call setup, one should consider that it is possible for a gatekeeper to put itself into the call signalling path. By changing the destination address of a LCF message to its own address, the higher level gatekeeper forces the requesting gatekeeper to pass the call to him.This may be useful for security reasons, e.g., when a gatekeepers policy only accepts incoming external calls that originate from a trusted higher-level gatekeeper to avoid being spammed from an uncontrollable source. But again this adds some latency to the call setup. - Bottlenecks and single point of failure - Every higher-level gatekeeper resolves addresses or routes of calls for its subordinate gatekeepers. It is critical that a gatekeeper is operational and can handle all incoming requests.To avoid bottlenecks or complete loss of higher-level gatekeepers, these must have a redundant layout, should have different locations and should use load-sharing mechanisms. - Cost - Running a higher-level gatekeeper is expensive, because one must provide hardware that guarantees continuous availability.. - Feature limit - The usage of a hierarchy limits the availability of protocol features to the feature set of the dumbest gatekeeper in the chain. Current versions of H.323 do, for example, carry more attributes than just AliasName and IPAddress, as it is the case in the Location Request (LRQ); such additional information specifies desired protocols or a hop count. A gatekeeper that uses a lower-protocol version will ignore those attributes and will not add that information in its reply.While this is annoying, it is still tolerable since advanced address resolution is not that important. But it is even worse when the call signalling is routed through the gatekeepers as well. In this case, it might happen that two communication partners using new equipment that supports a special feature (e.g., transmitting an image of the calling party on call setup) can not use this feature because of a gatekeeper in the call path that is not aware of the feature. So, hierarchical address resolution and call routing hinder research on IP Telephony. - Protocol limitation - By nature, the gatekeeper hierarchy is limited to H.323 and is difficult to merge with the SIP world. It is, of course, possible to provide gateways to SIP proxies but the infrastructure and the configuration will get complex and more error-prone.
P.197
P.198
The Call Routing Assistant is not a special product. In theory, every IP Telephony server that can be configured to route or resolve calls, without registering the other server, can be used in this place. Efforts are being made by the Center for Computing Technology in Bremen, Germany to provide an easy-to-use, open source CRA implementation.
P.199
-(.8.1. Overall
For a legal classification of Voice over IP, several aspects have to be taken into consideration. Where regulation focuses on technology - and there on the regulation of voice telephony - the definition of voice telephony is the starting point for all further legal and practical considerations. But when it comes to Voice over IP, terminology is used quite inconsistently.The lack of a clear definition often leads to misunderstandings and also problems in the exact legal classification. Internet telephony (or Voice over IP, VoIP) can be defined as a collection of Internet applications for real-time voice traffic over data networks using the Internet protocol (IP) whereby the quality of the transmitted voice depends on various factors such as available network capacity, gateways, audio codecs used, etc. For Oftel,Voice over Internet Protocol (VoIP) is the generic name for the transport of voice traffic using Internet Protocol (IP) technology.The VoIP traffic can be carried on a private managed network or the public Internet or a combination of both. A wide range of applications and services could use VoIP technology, from traditional telephone services to interactive games. Internet telephony (also referred to as Voice over the Internet) - according to Oftel - is a specific type of VoIP service that uses the public Internet to carry the IP traffic.4 The ITU 5 uses different definitions depending on the nature of the principle underlying the means of transmission.Therefore, Internet Protocol (IP) telephony is the transmission of voice, fax and related services over packet-switched IP-based networks. Internet telephony and VoIP are according to the ITU - specific sub-sets of IP Telephony. Internet telephony is therefore IP Telephony in which the principal transmission network is the public Internet. Internet telephony is also commonly referred to as Voice-on-the-Net (VON),Internet Phone, and Net telephony - with appropriate modifications to refer to fax as well, such as Internet Fax.Voice-over-IP (VoIP) IP Telephony is then telephony in which the principal transmission network or networks are private, managed IP-based networks (of any type).
Furthermore, regulation is based on public (provision of basic services to everybody) and state interest (license fees). Where Voice over IP services are exempted from regulation,Voice over IP faces some benefits in comparison to classical voice services. In Asia and America, classical voice telephony is substituted more and more by Voice over IP whereby positive cost factors of Voice over IP are partly supported by regulation of classical voice telephony.To balance this - and to further uphold public and state interests - a trend can be recognised that tends to also impose regulatory measurements on Voice over IP services, the more mature and the more common those services become.
services and a lack of a distinct market for VoIP services (given the fact that VoIP services are not offered as such, but - according to the Commission - always in combination with e.g., data transmission). Between 2000 and 2003 (when the New Regulatory Framework was published), the European Commission did not publish any document on VoIP. A Communication is, as such,soft law, meaning that it does not have the same legal consequences than a Directive or a Regulation (e.g., there is no need for the Member States to transfer it into national law), even though it is a means that it is often used to clarify things. Regarding Voice over IP there was legal uncertainty whether VoIP could be considered as voice telephony and therefore being held as voice service with all legal and practical consequences such as licensing and interconnection.With its Communication the European Commission clarified that point for the time being and stated that VoIP was not seen as voice service and therefore did not face voice telephony regulation. In the New Regulatory Framework - which aims to be technologically neutral - the chance that the European Commission will work on another Communication to clarify the legal status of VoIP has been decreased. Electronic communications networks and electronic communications services are facing the same regulation no matter which technology they are using.Therefore, the basic answer to the question whether VoIP-services are facing the same regulation than PSTNvoice telephony, will be yes provided that the service is offered to the public.
P.202
another technology.Where the absence of regulation in the past seemed to foster the deployment of Voice over IP, it is likely that the application of regulation now will slow down that process. But in the long run, it seems to be almost certain that Voice over IP will win against traditional, switched fixed and mobile telephony as sole voice communication service.
-(. 8.3.4.1 Example: VoIP in the New Framework in the United Kingdom
The United Kingdom's regulator, Oftel15, recently took a closer look at the regulation of VoIP in the new framework and published its findings. In summary, Oftel states that it is regulating VoIP. The reason given for regulating VoIP services is that those services are electronic communication services for the purposes of the British Communications Act 2003 ('the Act').The Act regulates, amongst other things, the provision of electronic communications networks,electronic communications services and associated facilities.16 Oftel also concludes that interconnection is likely to be relevant for electronic communication networks and services irrespective of the underlying technology (e.g., circuit-switched networks or IP networks). It is still (just as in the previous legal framework) possible to make a regulatory distinction between publicly available
14. http://europa.eu.int/information_society/topics/telecoms/regulatory/new_rf/documents/ l_10820020424en00210032.pdf 15. Oftel is now part of Ofcom. Ofcom began its regulatory duties on 29 December 2003. It replaces UK's five previous regulators - the Broadcasting Standards Commission, the Independent Television Commission, Office of Telecommunications (Oftel), the Radio Authority and the Radio Communications Agency. 16. http://www.ofcom.org.uk/static/archive/oftel/publications/internet/2003/voip1103.pdf P.204
telephone services and services that are not publicly available. Oftel says that specific requirements for publicly available telephone services can be set forth in general authorisations.Where VoIP services are not considered to be publicly available telephone services, those conditions will not apply. Oftel states that a VoIP service should be regulated as, a publicly available telephone service if any of the following conditions apply: - the service is marketed as a substitute for the traditional public telephone service, or - the service appears to the customer to be a substitute for the traditional public telephone service over which they would expect to access emergency numbers, directory enquiries etc. without difficulty; or; - the service provides the customer's sole means of access to the traditional circuit-switched public telephone network. Where a VoIP service is clearly being offered as an adjunct to a traditional telephone service or as a secondary service it is, according to Oftel likely not to be considered as publicly available telephone service. Oftel would, however, expect VoIP providers selling secondary services to ensure that the customers and third parties using the VoIP service are fully aware of the nature and limitations of the service.17
The European Commission states that the availability of numbers for existing and new services is of crucial importance for competition and innovation. Member States should therefore design their numbering plans in such a way that they can cope with increased future demand and they should manage the existing numbering space to encourage efficient and effective use of numbers. 19 With Voice over IP being treated as any other electronic communication service,Voice over IP providers are also entitled to get numbers from the national numbering range. The European Commission says that numbers must be assigned to any undertaking providing or using electronic communications networks or services, within three weeks after receipt of a request. Procedures for assignment must be open, transparent and non-discriminatory. Short codes, e.g., carrier selection codes, and so-called golden numbers, e.g., numbers that are easy to remember, deserve special attention as they may represent a specific economic value. Member States may decide to assign such numbers or codes via competitive or comparative selection procedures, in which case, the assignment period may be extended until up to six weeks (Article 5 of the Authorisation Directive).20 Oftel says that communication providers may apply for public numbers for VoIP services in accordance with the requirements set out in the General Conditions for the allocation, adoption and use of numbers. Oftel considers about an appropriate number range specifically allocated for VoIP services.21
The Access Directive lays down a procedural framework for regulators to follow, and identifies factors to be taken into account when granting access, but does not specify precise access obligations. In general, access obligations are only imposed on operators that have significant market power in specific markets.Taking into consideration the above,VoIP providers are offering electronic communication services.Therefore they are entitled to ask other operators for access and enter into negotiations. Only operators with significant market power are obliged to offer access in a transparent, non-discriminative and cost-oriented way, whereby the regulator has the rights to control prices.
concerning services have traditionally been very high.There are a lot of features that are not regulated by law. Instead, features have been regulated by standardisation organisations.When it comes to voice, there are a lot of requirements to be fulfilled, e.g., answering times and priority routing for emergency calls. Taking a closer look at the legal requirements, quality of service parameters, definitions and measurement methods can be found in Annex III of the Universal Service Directive (2002/22/EC). According to Article 11 of the same Directive, national regulatory authorities are entitled to specify additional quality of service standards. In the UK, for example, the regulator can impose technical interface standards to ensure end-to-end connectivity and interoperability. Annex III of the Directive sets forth quality of service parameters, definitions and measurement methods only. Operators are therefore obliged to measure the specific service-quality in their networks and provide that data to the respective regulator.There are no specific quality -requirements to be fulfilled by networks or services, nor threshold values that have to be met. In other words, one could say that quality is not a regulatory obligation but a market request. One has to consider the fact that there may be demand for cheaper services that may be of a lower quality. Accordingly to that, Oftel expressed an interesting thought regarding quality expectations. Communications providers should note that when VoIP services are provided using traditional E.164 telephone numbers, calling parties may not be aware, in advance, that they are calling a customer connected to a VoIP service.When providing a VoIP service that uses E.164 numbers, communications providers should take account of the quality of service that a calling party would normally expect when calling an E.164 telephone number.
broadband Internet connections, using voice over Internet protocol (VoIP). It has customers in the state of Minnesota. In October 2003, the U.S. District Court (DMinn) overturned this decision and issued its Memorandum and Order in Vonage v. Minnesota Public Utilities Commission, holding that Vonage is an information service provider and that the MPUC cannot apply state laws that regulate telecommunications carriers to Vonage.25 In Virgina, the State Corporation Commission has also taken notice of Vonage and is of the opinion that it is subject to its jurisdiction. In Ohio, the State Public Utilities Commission started an inquiry into how telecommunications providers are using VoIP in Ohio to provide telecommunication services to Ohio consumers. It turns out that under Ohio law, companies that are, in fact,transmitting telephonic messages are a common carriers subject to the State Public Utilities Commission's laws. The Florida Public Service Commission is awaiting on answers to the pending AT&T petition to the FCC with regard to whether or not VoIP providers should be responsible for paying access charges to local phone companies when they offer similar services.There is a bill pending in Florida that will affect consumers living in Florida 26.
25. http://www.techlawjournal.com/topstories/2003/20031016.asp 26. The Florida State Senates VoIP Bill is available in the Internet, see http://tinyurl.com/b5nb/. P.209
A. 1 Evolute
http://evolute.intranet.gr
The Evolute project addresses the issue of supporting multimedia services in general and SIPbased Voice over IP service in particular in heterogeneous networking environments.The focus here is on supporting secure access to such services regardless of the used access authentication technology. In this context, a SIP platform was enhanced with acAAA functionalities as well as gateways to SMS and Jabber and user credentials saved in SIM cards were used for authentication of the user.The project finished in 01.2004.
A. 2 6NET
http://www.6net.org
6NET is a three-year European project to demonstrate that continued growth of the Internet can be met using new IPv6 technology. It also aims to help European research and industry play a leading role in defining and developing the next generation of networking technologies. In the context of Voice over IP, the 6NET partners are deploying and experimenting with Voice over IP solutions, both SIP and H.323, using IPv6.This work involves porting of open source Voice over IP solutions such as the SIP Express Router to IPv6, provisioning of components to allow transparent Voice over IP communication between IPv4 and IPv6 networks and finally testing and deploying SIP and H.323 IPv6 capable components over a European wide IPv6 network. The project will be finished in 12.2004.
This project was funded by various telecommunication companies in Europe including Deutsche Telecom,Telecom Italia, Elisa Communication, OTE and France Telecom.The major goal of the project was to investigate the major problems hindering a vast and fast deployment of SIP such as QoS and NAT traversal, provisioning of intelligent services over SIP and demonstration of SIP -based services.The project finished in 2001.
P.210
A. 4 HITEC
The project HITEC (H.323-based IP Telephony Control) have dealt with the planning, the implementation and the prototyping of PBX VoIP, a managing system for the packet voice communication into an administratively, homogeneous Voice over IP network.The project aims to the design an intelligent PABX VoIP system, which includes the functions of the H.323 terminal, the MCU system and the H.323-PSTN gateway in a GateKeeper Brain functional element. The prospective of an integration of telephone- and Web-based services enabled by the new technology.Voice over IP has produced the realisation of various commercial equipments offering the voice/data integration at different levels; the peculiar feature of these solutions is that they are in compliance with the standards in a more-or-less pronounced manner. In this framework, the HITEC project, carried out by META center of Consorzio Pisa Ricerche
(http://www.meta.cpr.it and funded by Fondazione Cassa Risparmio di Pisa (http://www.fondazionecaripisa.it/), aims to design a PABX VoIP system, which
includes the functions of the H.323 terminal, the MCU system and the H.323-PSTN gateway. Besides these, the system is characterised by the addition of gatekeeper traditional management functions, new auxiliary functions in an entity denoted as GateKeeper Brain (GKB). These new functions are necessary to support the H.323 entity in the implementation of services either already defined in the H.323 systems, such as the supplementary services of the H.450 series, or services not yet standardised.The innovative approach of the HITEC project is the realisation of a PABX VoIP prototype in compliance with the H.323 standard, and characterised by limited hardware requirements (a simple PC with Linux O.S. and cards needed for the implementation of the gateway and GKB functions).These features should permit to the designed prototype to provide, at lower cost, the same functions as commercial systems already present in the market (legacy PABX or VoIP architectures, often based on proprietary solutions), to guarantee the interoperability with system-compliant to H.323 standard, and to make available a platform where users can develop new services exploiting the voice and data integration. An example of such integration is the introduction of call-centre services for supporting traditional Web-based services such as home banking and electronic commerce.This enhancement permits to the service operators to offer vocal support, which can give an important added value to the customer. The project aims also at overcoming the limits of the H.323 architecture maintaining one rigid adhesion to the standard mechanisms, thanks to the introduction of new control centres of the H.323 zones.The intelligence of H.323 architecture is distributed on the gatekeepers, whose management operations (authorisations management of the H.323 clients, accounting of the calls, etc.) are not detailed by the H.323 standard.Thus, at the state-of-the-art, the implementations of gatekeepers is characterised either by a rather ingenuous management plan (for example, it is not possible to insert policy on the customers enabled to register themselves or to use the communication services), or by proprietary control architectures (an example is the AVVID architecture of the Cisco Systems).
P.211
The innovative contribution of this project is the definition of a system where the management functions (the GKB) are located.The GKB is defined in order to increase the flexibility and the capillarity of the management plane of the VoIP architecture while maintaining compatibility with the H.323 standards. In the project vision, the gatekeeper interacts with the GKB and depends on it for whichever decision related to the normal procedures of H.225/H.245 protocols.The transfer of some typical functions of gatekeeper in the auxiliary subsystem GKB and their integration with management function of the H.323 zone produces two main advantages: - Access to the management system (configuration, logging or accounting procedures) is allowed to several client levels (administrator or normal client), without influencing the standard mechanisms of the gatekeeper, by means of disparate management interfaces (e.g.,Web interface); - The subsystem GKB constitutes an interaction point among H.323 zones allowing the improvement of inter-zone communication processes. The realisation of the PABX VoIP system is based on the approach of open architecture Openh323, on platform IA32 with Linux O.S., according to the paradigm application/server. The advantages of this solution are the high reliability, flexibility and robustness of the Linux O.S. and in the perfect conformity to the H.323 standards implemented by the Openh323 library. Furthermore, this library constitutes a powerful development environment of H.323 applications, and, therefore, it is considered, not only by academic and standardisation entity, but, above all, by several manufacturers.
The Greek Research Network (GRNET) has been developing central videoconferencing services at the national level for the academic and research community.The main points of action of the project are: a scheduling interface for facilitating the organisation of meetings through automated invitations to conferences and for managing MCU and Gateway resource reservation.The Web interface is based on Apache/PHP/MySQL/LDAP. Authentication mechanisms for securing endpoint participation in specific, scheduled meetings are applied.The techniques involve gatekeeper interaction with RADIUS, MySQL, and LDAP, as well as the Cisco MCM GKAPI which has been explored as a means of controlling ARQs targeting scheduled MCU calls from legitimate, registered participants. Also, limited SNMP management of MCU conferences through a Web interface has been implemented.
A. 6 SURFWorks
http://www.surfnet.nl/innovatie/surfworks/voip
The SURFnet project called SURFWorks has a component to stimulate the use of Voice over IP and VC, obtain knowledge and disseminate it and provide an H.323 and SIP service.
P.212
A. 7 VC Stroom
http://www.surf.nl/projecten/index2.php?oid=136
VC Stroom is a project of multiple institutions in the Netherlands to promote the use of VC in the educational setting.
The CESNET IP Telephony project started in 1999 with the goal of investigating the possibilities of data and voice network convergence. CESNET operates the Czech NREN. A lot of experience was acquired about the optimal interconnection configurations of various telephony devices (PBXs with different interfaces, voice gateways, gatekeepers, IP phones, etc.). It turned out that most popular IP Telephony service has been least-cost routing. Over time, the 24 PBXs in universities and research institutes have been interconnected over the Czech NREN with two gateways to PSTN.The network structure is illustrated in Figure A.1. Figure A.1. CESNET IP Telephony Network
P.213
P.214
> Product Name: X-Pro, X-Lite Product URL: http://www.xten.com/ Vendor: Xten Networks Supported Protocols: SIP Platform: N/A Description: It is a good softphone with many interesting features. It has sophisticated NAT detection mechanisms. SIP support is good.There seem to be no interoperability issues (as far as we have tested). X-lite is a free version; X-Pro must be purchased.The softphone is also available also for WindowsCE-based PDAs.
B. 2 Hardphones
> Product Name: Cisco 7960 Product URL: http://www.cisco.com/warp/public/cc/pd/tlhw/prodlit/7960_ds.htm Vendor: Cisco Systems Supported Protocols: H.323, SIP Platform: N/A Description: Operational Experience: It supports H.323 under the assumption of having a Call Manager, which is a Cisco software product to manage Cisco hardphones.The communication between Call Manager and Cisco 7960 is done using the Cisco proprietary Skinny protocol (not a standard H.323 protocol!)and therefore the standard H.323 communication with an external client is only performed with the Call Manager and not with the phone itself (limited standard compliance of the phone). It supports also SIP protocol but from a standard point of view.With the following firmware (Application LoadID: P0S30203; BootLoadID: PC03A300. It was found to be perfectly interoperable with VOCAL system and with MSN messenger. Please pay attention that Power Cord is not included in default selling configuration.Take care when buying it or delays will occur before you can effectively use it (because of Cisco vendors slowness). Overall Evaluation: Good hardphone. It is a little bit too expensive and not completely H.323 compliant. The SIP part is very good and standard-compliant. The phone has excellent design. It is very comfortable to use, even during long conversations.The display is big enough to be seen even from a great distance.The phone has six lines. A SIP image has to be loaded into the phone before it can be used as a SIP phone. SIP-standard compliance is very good up to 6 SIP accounts can be registered simultaneously. Unfortunately it is not possible to decline an incoming call.The phone can be switched into Do-not-disturb mode, though. Short packets containing just four zeroes (often used to keep the NAT bindings alive) freeze the phone.This should hopefully be fixed in the latest SIP model (not tested yet). > Product Name: Adtech SI-150 IP Phone Product URL: http://www.adtech.be/text/si150.php Vendor: Adtech Supported Protocols: H.323, SIP Platform: N/A Description: Operational Experience: It supports H.323 but with a particular version of the
P.215
firmware we have experienced some interoperability problems with standard H.323 clients (NetMeeting). Regarding the SIP part, with the firmware version SIP 2.07.06 CS 49AC, it showed some interoperability problems with VOCAL systems and MSN messenger. Some bug fixes are needed in order to avoid hook and crash problems of called clients. Overall Evaluation: Not yet a mature hardphone (at least with the firmware version we tested). It is quite inexpensive. > Name: Komodo Fone (now Cisco ATA) Product URL: http://www.cisco.com/warp/public/cc/pd/as/180/186/index.shtml Vendor: Cisco (formerly Komodo) Supported Protocols: SIP, H.323 Platform: N/A Description: Black-phone-2-Ethernet/analogue-line adapter, both H.323 and SIP (currently SIP only for the adapter).The adapter supports two lines, only one of them at a time can use G.729 codec; the other one can use G.711 only. It supports symmetric signalling and media and can work from behind NATs. Standard-compliance is good. One of the nice features is the possibility to create dialling plans using regular expressions. Any analogue phone that supports DTMF dialling can be connected to the adapter. > Product Name: BudgetTone-100 Product URL: http://www.grandstream.com Vendor: Grandstream Supported Protocols: SIP Platform: N/A Description:This is the cheapest SIP phone available at the time of completing this document. The price is very low, but you get what you paid for.The phone is mostly standard-compliant; from time to time there are some interoperability problems but the manufacturer fixes them quickly.The biggest problem of the phone seems to be its HW.The phone can dial numbers only; it supports STUN and symmetric media and signalling. Many codecs are supported. iLBC support has been announced. If you need the cheapest phone available then BudgetTone is your choice. Be prepared to receive a phone that looks like a toy with a not very friendly user interface. > Product Name: 5055 SIP Phone Product URL:
http://www.netergymicro.com/products/reference_designs/ip_t2.html
Vendor: Mitel Networks Supported Protocols: SIP Platform: N/A Description:The 5055 is a high-quality SIP phone that meets the price/performance needs of business users. Also available is the 5305 desktop conference unit and the 5310 boardroom conference unit. Mitel is a traditional manufacturer of telephones. 5055 has very solid design and is comfortable to use.The phone has many programmable buttons.The display is very small but functional. SIP implementation is good without any serious interoperability problems.The phone is rather expensive compared to other SIP phones available on the market. Audio quality is very good.
P.216
> Product Name: XPressa Product URL: http://www.pingtel.com/products.jsp Vendor: Pingtel Supported Protocols: SIP Platform: N/A Description: A hardphone with unusual design.We had some problems with record routing (loose routing) which we were unable to solve so we did not use the phone much. > Product URL: Vendor: Siemens Supported Protocols: H.323 Platform: N/A Description:The former HiNet LP 5100 (in 1999) comes without an integrated switch and supports only 10 MBit/s.The supported codecs include G.711 and G.723.While in theory multiple firmwares can be used on this phone, the most popular was the H.323 (V2) firmware. Depending on the firmware/application version the phone can be remotely configured via HTTP (using port 80 or 8080 - depending on firmware) and (sometimes only) using a special Windows Deployment Tool that allows the configuration of multiple ones at once. To upload a new firmware, older versions required the use of DHCP and TFTP to update the firmware and FTP to access the application file. New firmware versions have been seen booting the phones once in a while - regularly, when the phones aren't registered to a gatekeeper and without obvious reason while registered. The telephones support the H.323 feature of Registration KeepAlive, but ignore the registration timeouts from the gatekeeper and resend their registrations every 60 seconds. If they are not currently registered the interval decreases to 30 seconds.The telephone does not support the FastStart protocol feature (at least not in the old versions). > Product Name: optiPoint 300 basic Product URL: Vendor: Siemens Supported Protocols: H.323 Platform: N/A Description: It is a H.323 phone with a limited display (numbers only), less function keys that its big brother 300 had and without G.723 support. It supports H.323 FastStart procedures (10 MBit/s only). > Product Name: optiPoint 400 standard Product URL:
http://www.siemens.com/index.jsp?sdc_rh=&sdc_flags=3&sdc_sectionid=2&sdc_ secnavid=110&sdc_3dnvlstid=&sdc_sid=10240442142&sdc_countryid=0&sdc_mpid= 0&sdc_unitid=0&sdc_conttype=3&sdc_contentid=1004068&sdc_ggid=17&sdc_langi d=1&sdc_m4r=
Vendor: Siemens
P.217
Supported Protocols: H.323, SIP Platform: N/A Description:This is a phone with integrated 10/100 Mbit/s mini switch, display and numerous features. Like the predecessor optiPoint 300 advanced, this phone can run different firmwares: HFA (CorNet), H.323 and SIP The H.323 protocol behaviour and the available features are pretty much the same as for the predecessor (see above). > Product Name: Snom 100 Product URL: http://www.snom.com/snom100_en.php Vendor: Snom.de Supported Protocols: SIP, H.323 Platform: N/A Description:The phone is easy to use with Graphical LCD display and four Softkeys. Caller Id, Hold, Divert and Transfer, Call Waiting Indication, Message Waiting Indication, Speed Dial, Phone Book, Call and Deny List, HTTP Server, Echo cancellation.The firmware can be upgraded over http. > Product Name: SoundStation IP 5000 Product URL:
http://www.polycom.com/products_services/0,1443,pw-182-3073,00.html
Vendor: Polycom Supported Protocols: H.323 (SIP and Skinny announced) Platform: N/A Description:This is a conference phone supporting multiple signalling protocols (depending on firmware).The H.323 firmware supports FastStart and Tunnelling (since version 2.5) but up to now (2.8) no H.450. It has very good audio quality and supports Power-over-LAN. > Product Name: IP Phone 7905 Product URL: Vendor: Cisco Supported Protocols: H.323 Platform: N/A Description:Very simple H.323 phone without H.450 support or integrated switch. It exists in two versions: Either with AC adapter or only with Power-over-LAN support. This is a cheap brother of popular 7960.The phone has smaller display but the design is as comfortable as in 7960.The SIP image is quite simple but standard compliant.The phone allows registration of just one line, it can dial numbers only and it is not possible to dial a domain (@iptel.org for example). It can be configured through a Web interface but the Web interface is very basic and has some shortcomings. If you are looking for a cheap but well designed phone and do not mind that you will be not able to dial SIP URIs, 7905 is a good choice. By default it is not shipped with a power supply (Cisco assumes power over ethernet) so do not forget to order one.
P.218
> Product Name: IP 200 Product URL: Vendor: innovaphone Supported Protocols: H.323 Platform: N/A Description: Excellent, full-featured (H.450, ...) H.323 phone with a fair sized display. Comes with an alpha-numerical keyboard and eases entering URL addresses. It can access phone-books via LDAP (not tested). Supports overlap dialling. Early protocol firmwares had a problem when an incoming call has been cancelled by the calling party (receiving a RELEASE COMPLETE while still ringing) when the phone continued ringing and showing a TRAP/error dump on the display when going off-hook. (This problem might be long fixed). Early hardware had a problem of an incorrectly applied capacitor leading to a fading display (contrast). Contact Innovaphone for a replacement. > Product Name: i2eye DVD-1000 Product URL: http://www.d-link.com/products/?pid=8 Vendor: D-Link Supported Protocols: H.323 Platform: N/A Description: A broadband videophone hardware with built-in camera.Video and audio signal can be accessed via cinch connectors to connect television hardware. An external microphone can be connected. The DVC-1000 has a very minimal H.323 support. H.323 is used to setup a call, while address resolution is done using D-Links LDAP server.The address of the LDAP server is fixed and can not be configured.The D-Link LDAP server can be used for free for all DVC users but doesn't offer resolving other addresses. To make really good use of the DVC hardware, one needs a proxy instance for dialling that calls the target and the DVC (set to auto reply) at the same time and passing messages through. > Product Name:VCON Escort Product URL:
http://www.vcon.com/solutions/videoconferencing/desktop/Escort_Cruiser/ index.shtml
Vendor:VCON Supported Protocols: H.323 Platform:Windows Description:The VCON Escort hardware H.323 and H.320 client is a PCI-based card that can be installed on any standard PC running a Windows OS. It allows connections at up to 1.5Mbps and includes features for data collaboration (T.120), quality of service (QoS) and interactive multi-cast for allowing viewers to watch a conference over a multicast network. It generally performs well, but compatibility with PC video cards seems to be crucial for trouble-free operation, as in some set-ups, sudden crashes during long operation are not uncommon.
P.219
> Product Name:VCON Falcon Product URL: http://www.vcon.com/solutions/videoconferencing/group/Falcon/ index.shtml Vendor:VCON Supported Protocols: H.323 Platform: N/A Description:The VCON Falcon is a set-top-box H.323 and H.320 client. It includes a quality camera and microphone. It has a wide array of audio and video connectors to allow it to interoperate with projectors, screens, multiple video and audio sources, as most often found in a group videoconferencing settings. It is a reliable device, but the remote controlled management interface is difficult to work with and a bit limited (e.g. H.323 aliases cannot include special chars at all).
B. 3 Servers
> Product Name: OpenH323 Gatekeeper - GnuGK Product URL: http://www.gnugk.org/ Vendor: Open Source Supported Protocols: H.323 Platform: Any platform where you can compile the OpenH323 Library (Linux,Windows, FreeBSD, Solaris, etc.) Description: Operational Experience:There are some minor problem with Netmeeting. Netmeeting does not support Gatekeeper Discovery, thus you should directly configure the gatekeeper address in the Advanced Calling Options. Netmeeting requests an incorrect bandwidth; disable bandwidth management to avoid problems with GnuGK. It has Radius, MySQL and LDAP support.The manual is written in English, Chinese and Portuguese. It is used in many commercial applications and it has nice graphical interfaces to configure it, to monitor the registrations, to define groups of endpoints, to do call management, etc. Overall Evaluation: it is simply the best Open Source gatekeeper available nowadays. For technical support there is the Gatekeeper Users mailing list. > Product Name:VOCAL (Vovida Open Communication Application Library) Product URL: http://www.vovida.org/ Vendor: Open Source Supported Protocols: H.323, SIP, MGCP Platform: Refer to http://www.vovida.org/applications/downloads/vocal/ platform/1_5_0.html for an updated list (Linux, etc.) Description: Operational Experience:The VOCAL software includes a Session Initiation Protocol (SIP)-based Redirect Server (RS), Feature Server (FS), Provisioning Server (PS), Marshal Server (MS) and Voice Mail Server (vmserver). Other applications are not included in the current release (1.5) and are: 1. SIP to MGCP translator 2. Policy server 3. Inet/Conference proxy server. 4. SNMP/NetMgnt 5. SIP to H323 Translator: It has IPv6 Support and a lot of subsidiary application (from the site http://www.vovida.org). Unfortunately, provisioning currently requires valid IPv4 addresses. For an updated list of know limitation please refer to:
http://www.vovida.org/downloads/vocal/1.5.0/doc/LIMITATIONS.txt.
P.220
Overall Evaluation: It is a al-in-one solution for small-medium size business unit. It needs complementary solutions to be deployed in tandem in order to become a distributed system (the management is still centralised with no possibility of interfacing to other domains). > Product Name: OpenMCU (H.323 Conferencing Server) Product URL: http://www.openh323.org/code.html Vendor: Open Source Supported Protocols: H.323 Platform: Any platform where you can compile the OpenH323 Library (Linux,Windows, FreeBSD, Solaris, etc.) Description: Operational Experience: It can accept multiple simultaneous connections. From the first four clients that get connected, it accepts audio and video capabilities, from the following ones only audio. It determines which conference is required via the 'rooms' feature and adds the call to that conference. New rooms are created automatically and there is a default room for people who do not specify a room or cannot specify a room (e.g. NetMeeting). It initiates calls from the MCU to remote endpoints and supports audio loop-back mode in a specific room (ideal for setup of audio hardware and testing network performance). No dynamic configuration is possible; once the program is started the client is configured using the command line options (only statistics on call in progress and initiating new calls is possible). Overall Evaluation: MCU software requiring a performing hardware infrastructure in terms of shared memory it is using. High customisation in terms of parameters (video compression and quality) makes it scalable in terms of computational requirements. It is really useful in case of multipoint conferencing. A drawbacks is the one of multipoint conferencing, i.e., it does not use multicast but multiple unicast connections. > Product Name: SIP Express Router Product URL: http://iptel.org/ser Vendor: iptel.org Supported Protocols: SIP Platform: POSIX-like systems Description: SER or SIP Express Router is a very fast and flexible SIP (RFC3621) proxy server. Written entirely in C, ser can handle thousands calls per second even on low-budget hardware. A C Shell like scripting language provides full control over the server's behaviour. Its modular architecture allows only required functionality to be loaded. Currently, the following modules are available: digest authentication, CPL scripts, instant messaging, MySQL support, a presence agent, radius authentication, record routing, an SMS gateway, a Jabber gateway, a transaction module, registrar and user location. The server has been optimised for speed and is being used on a couple of major SIP servers. One drawback might be the quite complicated configuration file.The configuration requires good knowledge of SIP. > Product Name: AppEngine Product URL: http://www.dynamicsoft.com/prod_sol/AppEngine/appenginev4.php Vendor: dynamicsoft Supported Protocols: SIP
P.221
Platform: Sun Solaris Description: It is a SIP application server written in Java.The server implements Java SIP servlets which allow creation of even complex SIP applications called servlets.The servlets can interact with HTTP servlets as well. Good documentation is available with many examples. > Product Name: Cisco IP/VC 3510 MCU Product URL: http://www.cisco.com/univercd/cc/td/doc/product/ipvc/ipvc2_2/ 2_2mcurn.htm Vendor: Cisco Supported Protocols: H.323 Platform: N/A Description:This MCU is an older product, identical to the RADVISION OnLAN MCU, but OEMed by Cisco and currently not supported any more, as it has been replaced by the 3511 MCU.The 3510 is capable of connecting twelve participants at 384Kbps each, or a combination of conferences at different rates and different numbers of participants.The default hardware does not provide audio/video transcoding between participants, so conference settings must be matched by all. Continuous presence is supported, but with asymmetric video rates, i.e., each participant sends 384Kbps video but receives 4x384Kbps back from the MCU, for viewing four participating sites simultaneously. Check the IP/VC Products page at
http://www.cisco.com/univercd/cc/td/doc/product/ipvc/ipvc2_2/
Vendor: Cisco Supported Protocols: H.323 Platform: Cisco router - IOS based Description:The Cisco Multimedia Conference Manager (MCM) is the name of the gatekeeper product bundled in special IOS feature sets (H.323 feature set) and can be installed on most Cisco routers that may be performing as gateways at the same time.The MCM is mostly geared towards VoIP and in supporting basic H.323 interoperability, but it has a number of extra Ciscoproprietary features as well. It can also act as an H.323 proxy for serving H.323 clients behind firewalls.The API that has been developed by Cisco allows extensive control of gatekeeper events by an external application, but it requires significant development effort to bear fruit. Check the Cisco Gatekeeper External Interface Reference page at
http://www.cisco.com/univercd/cc/td/doc/product/software/ ios122/rel_docs/gktmp4_1/index.htm
B. 4 Gateways
> Product Name: OpenISDN (H.323 Call Generator)
P.222
Product URL: http://www.gae.ucm.es/~openisdngw/home_en.php Vendor: Open Source Supported Protocols: H.323 Platform: Any platform where you can compile the OpenH323 Library (Linux,Windows, FreeBSD, Solaris, etc.) Description: Operational Experience: It requires ISDN cards to be properly installed and configured on the local machine in order to make connections with the ISDN. It works only with ISDN lines (no PSTN support) managing n calls simultaneously, as many as the ISDN channels available.The gatekeeper can be in a well-known IP address or it could be discovered in the network with broadcast RAS. It gives information about the call progress state to the user of the Switched Circuit Network that calls to the Gateway.This information is made with tones similar to those sent by the telephone offices. Support and development has now stopped and it requires a special old version of OpenH323 library to compile. No dynamic configuration is possible; once the program is started the client is configured using the command line options. Overall Evaluation: It is a simple H.323/ISDN Gateway. It needs to be better investigated for complete H.320 compatibility for ISDN conferencing. Right now it seems to be only an audio gateway. > Product Name: Asterisk Open Source PBX Product URL: http://www.asterisk.org/ Vendor: Digium Supported Protocols: SIP, H.323 Platform: N/A Description: Asterisk is an Open Source, full featured hybrid TDM and VoIP PBX and IVR platform. It allows you to seamlessly integrate TDM (T1, PRI, FXS, FXO) and VoIP (IAX, SIP, H.323) technologies in a single PBX while providing full IVR functionality through any scripting language available on Linux. > Product Name: Cisco IP/VC 3525 PRI Gateway Product URL: http://www.cisco.com/univercd/cc/td/doc/product/ pvc/ipvc2_2/2_2prirn.htm Vendor: Cisco Supported Protocols: H.323 Platform: N/A Description:This H.320 to H.323 Gateway is an older product, identical to the RADVISION OnLAN Gateway, but OEMed by Cisco and currently not supported any more, as it has been replaced by the 3526 Gateway.The 3525 is capable gatewaying 16 voice channels, or 8 128Kbps participants with H.261 video, or a combination of other rates for multiple BRI bonding.The default hardware does not provide audio/video transcoding, but there existed a hardware add-on for audio transcoding. Check the IP/VC Products page at
http://www.cisco.com/univercd/cc/td/doc/product/ipvc/ipvc2_2/2_2mcurn.htm
P.223
B. 5 Testing
> Product Name: CallGen323 (H.323 Call Generator) Product URL: http://www.openh323.org/code.html Vendor: Open Source Supported Protocols: H.323 Platform: Any platform where you can compile the OpenH323 Library (Linux,Windows, FreeBSD, Solaris, etc.) Description: Operational Experience: It can make and receive an exact number of calls, adjust the delay between each batch of calls and set the number of batches to repeat. It only produces signalling traffic (no audio data traffic). Support and development has now stopped and it requires special old version of a OpenH323 library to compile. No dynamic configuration is possible; once the program is started the client is configured using the command line options. Overall Evaluation: It is a simple H.323 Call Generator. It is very customisable using a number of parameters. It is really useful in testing environments where servers need to be tested under stress. Drawbacks are static configuration, no dynamic management and limited support. > Product Name: sipsak Product URL: http://sipsak.berlios.de/ Vendor: iptel.org Supported Protocols: SIP Platform: N/A Description: Free Diagnostic and Stress Utility. sipsak is a simple utility that can be used to test various functions of a SIP server. It includes proxy, registrar and digest authentication tests. It can also generate a load of SIP messages to stress a server. > Product Name: SIPStone Product URL: http://www.sipstone.org Vendor: Columbia University and Ubiquity Supported Protocols: SIP Platform: N/A Description: Currently, this is a draft about measuring SIP performance
http://www.sipstone.com/. A measurement tool is available from Columbia University - see http://www.cs.columbia.edu/IRT/cinema/sipstone/
B. 6. Miscellaneous
> Product Name: OpenAM (H.323 Answering Machine) Product URL: http://www.openh323.org/code.html Vendor: Open Source Supported Protocols: H.323 Platform: Any platform where you can compile the OpenH323 Library (Linux,Windows, FreeBSD, Solaris, etc.) Description: Operational Experience: It can accept multiple connections simultaneously and runs
P.224
a user-defined program after each call, which can be used to automatically send the recorded message as a MIME-encoded e-mail attachment to a known e-mail address. If the recorded message is encoded using G.723.1 codec, it requires equipping with the PC with additional cards (Quicknet). No dynamic configuration is possible; once the program is started, the client is configured using the command line options. Overall Evaluation: It is a simple answering machine using the H.323 protocol. It is really useful in unified messaging scenarios. It needs to operate in an environment where supplementary services are implemented. Drawbacks are static configuration and no dynamic management. > Product Name:Yxa Product URL: http://www.stacken.kth.se/projekt/yxa/ Vendor: Open Source Supported Protocols: SIP Platform: Any platform where you can use Erlang programming language (Linux,Windows, FreeBSD, Solaris, etc.) Description: Operational Experience:Yxa is a bunch of library-like functions for receiving, processing and sending SIP messages, and a couple of small programs that can do various things. The operational experience is poor right now because Yxa is not widely known (even if it is gaining popularity). It is a SIP server open source software written in Erlang (a programming language from Ericsson with open source releases). Basically, it has built-in some software for performing a number of functionalities. One of the main applications is the incoming proxy; it can handle REGISTER requests and authorise different users to make calls to different classes of PSTN numbers. It can proxy requests from UACs to other parts of the Yxa system, relay requests to remote servers/domains Routing features, do ENUM lookups of things that looks like E.164 phone numbers and do lookup addresses in LDAP. Overall Evaluation:The project just produced some nice results. No release has been made yet and downloading is done only through CVS. A mailing list is available for questions and inquiries.
P.225
Glossary
CPL See Call Processing Language. Call Processing Language An XML application to define rules for call processing (e.g., to route all calls to a cell phone during lunchtime). Decisions can be made upon the calling party number or the called party number, date or time - just to name a few, while actions usually include rejection or redirections of calls. Extensible Markup Language A standard methodology with formal syntax for adding information to a document relating to its structure and/or content by applying identifiers for elements of information in a neutral way, stored in a neutral form, independent of systems, devices and applications. Gatekeeper In the H.323 world, the gatekeeper provides several important functions. First, it controls access to the network, allowing or denying calls and controlling the bandwidth of a call. Second, it helps with address resolution, making possible e-mail-type names for end users, and converting these into the appropriate network addresses.A gatekeeper also handles call tracking and billing and call signalling. GK See Gatekeeper. Gateway A gateway is a communication instance that translates (call) data between different networks (e.g., IP and PSTN) or protocols. A signalling gateway translates between two or more signalling protocols (like H.323 or SIP), while a media gateway usually performs transcoding of media streams (e.g., G.711 to GSM). Of course a gateway may as well combine all functionality described above. GW See Gateway. H.323 ITU standard for videoconferencing over packet-switched networks such as Internet. Media Gateway Control Protocol A protocol for IP Telephony that enables a calling party with a PSTN phone number to locate the destination device and establish a session. MGCP See Media Gateway Control Protocol.
P.226
PBX See Private Branch eXchange. PSTN See Public Switched Telephone Network. Private Branch eXchange A device used by organisations to allow a single access number to offer multiple lines to outside calling parties and to allow internal staff to share a range of external lines. Public Switched Telephone Network The worldwide voice telephone network. QoS See Quality of Service. Quality of Service Measure of performance for a transmission system that reflects its transmission quality and service availability. Real-time Protocol RTP is designed to provide end-to-end network transport functions for applications transmitting real-time data, such as audio, video or simulation data over multicast or unicast network services. RTP See Real Time Protocol. SIP See Session Initiation Protocol. Session Initiation Protocol IETF standard for session initiation in multi-purpose communication systems. Voice over IP The transmission of voice over data networks that use the Internet Protocol (IP). VoIP See Voice over IP. XML See Extensible Markup Language.
P.227
P.228