Table of Contents
- 5.1. Gatewaying
- 5.2. Supplementary services
- 5.3. Multipoint Conferencing
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).
Please refer to Section 4.1 for a general architecture of SIP-H.323 and PSTN gatewaying. This section is dealing with analysis of characteristics of gateways and configuration principles for the gatewaying functions to be set up in an advanced environment. The topics detailed in this section are ranging from VoIP - PSTN gateways to SIP - H.323 gateways configuration, ending with short considerations on accounting.
One of the most important interfaces in IP telephony is between a PBX and voice gateway (VoGW). It enables communication between PBX phones and IP phones (H.323 or SIP) and can also facilitate communication to PSTN, see Figure 5.1. When a PBX phone dials a number which is not another PBX extension, the PBX can forward to voice gateway either calls to numbers beginning with a specified prefix (so called access prefix that the users dials before the required number to get to IP telephony network) or all calls. Similarly, a voice gateway can forward to the PBX calls to PBX phones.
When a PBX phone dials a number in PSTN, the PBX can forward the call directly to PSTN (e.g. over ISDN) or it can forward the call to voice gateway, which forwards it to a selected PSTN operator over the Internet.
There are different kinds of PBX to voice gateway interfaces with different features and cost. Your choice of the interface type will probably depend on which features you require, acceptable cost and availability (whether there is already some interface present in PBX and voice gateway). In this section we provide some technical details on different kinds of PBX to voice gateway interfaces. We also shortly describe signalling systems, such as Channel Associated Signalling (CAS), E&M signalling methods, Q-signalling and Q.931 call control protocol and give examples of exchanged messages during correct communication.
A subscriber loop, also called U-interface, is a 2-wire interface used primarily when connecting a telephone set to a Subscriber Line Module Analog (SLMA). SLMA is the name of the analog module in a PBX. A corresponding module in a Voice Gateway is called Foreign Exchange Station (FXS).
FXS and SLMA modules can also be interconnected to trunk modules. Trunk Module Analog (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 a common terminal equipment). This is a very simple mode, it only detects a ringing signal, provides digit dialling and switching between off-hook (to close the loop) an on-hook (to open the loop).
- FXS/SLMA - subscriber line circuit emulation. In this mode, the SLMA or FXS wait for a closed loop that will generate a current flow and a signalling tone of 425 Hz (with 10% tolerance). The Subscriber Lin 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 16 possible combinations 12 are used on the keypad. DDI (Direct Dialling In) is possible only through a DTMF suffix, that is during the connection time when the caller normally already pays for the connection.
E&M is commonly alternately explained as Ear and Mouth or recEive and transMit. E&M interfaces allow DDI without restrictions before the conversation starts. There are several different types of E&M interfaces according to signalling and number of interconnecting wires. Type V (see Figure 5.2) is very popular in Europe. In the commonly used 6-wire interconnection the individual wires are used as follows:
- one pair of wires (wires E and M) is used for signalling
- one pair of wires is used for outgoing voice path
- one pair of wires is used for incoming voice path
This 6-wires connection can be reduced into 4-wires:
- one pair of wires (wires E and M) is used for signalling
- one pair of wires is used for voice path in both directions (which can cause a problem with echo cancellation and inhibits a possibility to use an amplifier)
Signalling is carried out with direct current via the E and M control wires for call set-up 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
CAS (Channel Associated Signalling) exists in many varieties that operate over analog or digital interfaces. A common digital interface with CAS signalling is called E1 (European version). The physical layer is working in accordance with the ITU recommendation G.703/G.704 for PCM30/32. The endpoints continually send Backward and Forward marks in 16 TSLs (Timeslot of PCM30/32, bits ABCD) as a supervision signal to indicate various states of the connection. Additionally, the MFC-R2 (Multi Frequency Compelled) signalling is used (in TSL 1-15 and TSL 17-31) to support for several features:
- malicious call tracing (used to transfer calling party numbers)
- override authorization
- free calls
- called party hold
ISDN (Integrated Service Digital Network) is a preferred current method of PBX to VoGW interconnection. We will describe it in more detail and give some illustrative examples of exchange of its Q.931 signalling messages. ISDN is a system of digital connections allowing to establish a call with end-to-end digital connectivity of nx64kbps. Original recommendations of ISDN were in CCITT Recommendation I.120 (1984), which described some initial guidelines for implementing ISDN. The first commercial implementation of ISDN was in PBX Hicom300 (Siemens AG). Several different signalling protocols have emerged. It was 1TR6 protocol in Germany, NI (National ISDN) in the USA and French National ISDN VN3 protocol in France. The absence of an international standard, led each European country to make its own version of ISDN, which meant incompatibility and increased costs. 26 communication organizations signed in 1992 the "Memorandum of Understanding on the implementation of a European ISDN". The signing countries were obliged to offer a common technological substructure for the ISDN network development, connecting all Europe. As a result Q.931 signalling has been internationally standardized.
Two types of access methods exist for ISDN:
- BRI (Basic Rate Interface)
- PRI (Primary Rate Interface)
BRI delivers two 64 kbps B channels and one 16 kbps D channel. The reference configuration of ISDN defined in the ITU specification I.411 is illustrated in Figure 5.3
- 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.
- 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 (non-ISDN, connected to NT2 via terminal adapter), and handles the layer 2 and layer 3 ISDN protocols.
- Network Termination NT (divided into NT1 and NT2; NT1 is working 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 ISDN compatible device (TE1 is connected to NT2 via a four-wire 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.)
As a PBX can provide NT2 functions, the T interface is commonly used for interconnection of a PBX and a Voice Gateway. The PBX is working in the user-side operation mode and the Voice Gateway in the network-side operation mode.
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, debugging was enabled with "debug isdn q931" command
- The call was initiated from Technical University in Ostrava to Czech Technical University in Prague, PBX was connected through ISDN/PRI, called number was sent as the en-bloc in the SETUP message
- Calling Party Number was 596991699
- 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. This example corresponds to the following setup:
- Cisco AS5300 was used as a Voice Gateway, debugging was enabled with "debug isdn q931" command
- The call was initiated from Czech Technical University in Prague to PSTN (Public Switched Telephone Network), PBX in Prague was connected through ISDN/PRI, called number was sent as the digit by digit (overlap) in the SETUP and INFOMATION messages
- Calling Party Number is 224355406
- Called Party Number is 224324997
Figure 5.5. Q.931 call control messages in call-setup with overlap
 |
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
One of the most useful H.323 services, is the ability of VoIP callers (H.323 world) to reach the PSTN (classic telephony world). This service is provided by H.323/PSTN gateways and the functionality they provide is:
- forwarding of incoming calls from PSTN and call signalling to H.323
- termination of incoming calls from H.323 and forwarding to PSTN
- accounting for calls utilizing the gateway
- optional support for H.320 (ISDN) capable conferencing endpoints
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 being interconnected with PSTN. Moreover details on gateways configuration are given in order to give guidelines on how to configure gateways to be part of a H.323 network.
The Radvision OnLAN 323 L2W-323 Gateway is a hardware-based H.323 to H.320 gateway, which allows H.323 endpoints to reach destinations on the PSTN or specialized H.320 (ISDN-based) endpoints and vice versa. The L2W-323, in its most common configuration, has four Ethernet (LAN) interfaces and two ISDN BRI (WAN) interfaces. It is designed for stand-alone use and thus integrates the functions of a gatekeeper, as well as a gateway, under the same hood. It is presently not available for sale but it has quite a large installed base, considering that the Cisco 3520 is essentially the same product marketed by Cisco.
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.
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").
We are interested in the second option only, 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.
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.
The next screen, "Services Definition Table", is the most important one, since it defines the services that the gateway will make available to callers, by registering them with its controlling gatekeeper.
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 will require. By defining different services, the callers 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 customize and that is the service prefixes in order to make them match your local dialling scheme.
The next screens refer to "WAN Port Settings" which for an ISDN interface present relative settings. 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 ports are 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.
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 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
194.257.8.150 1820 194.257.8.150 1024 gk.mydomain.org CH320-GW
H323-ID: GW4134522623
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 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 unregistering 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.
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 (of the format GWnnnnnnnnnn, where n is a number generated by the gateway itself and it 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.
In this subsection we will present an example how a CISCO Voice Gateway should be configured for interconnection with a PBX. See Figure 5.11 for illustration of interconnection. The same procedure could be used for interconnecting CISCO Voice Gateway with PSTN/ISDN
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 connected through PRI/ISDN to the PBX and is registered to a Gatekeeper. Configuration examples were cut off from Cisco CLI command show running-config output and commented.
Gatekeeper peering and gateway id are set up in this section. Cisco gateway could serve as voice gateway for both H.323 and SIP protocols at one time, but SIP protocol specific part is configured in completely different configuration section of the gateway (not sip-gateway, see Section 5.2.2). It is recommended to use h323-gateway command set in loopback interface configuration section. Usage of loopback IP address in registration and accounting messages helps to manage the system easily if the gateway has more than one interface used for VoIP.
h323-gateway voip interface h323-gateway voip id GK1-CESNET2 ipaddr 195.113.113.131 1718 priority 100 h323-gateway voip id GK2-CESNET2 ipaddr 195.113.144.85 1718 h323-gateway voip h323-id VoGW-ZCU h323-gateway voip 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
Interconnection to PBX or PSTN has to be also properly set-up at interface level (router(config-if)#). Telephony interface configuration is independent on the used VoIP signalling protocol. In this section are configured ISDN parameters for signalling channel (sixteenth channel has number 15 by CISCO).
interface Serial0/0:15 isdn switch-type primary-net5 isdn overlap-receiving T302 5000 isdn protocol-emulate network isdn send-alerting isdn sending-complete isdn outgoing-voice info-transfer-capability 3.1kHz-audio
- primary-net5 is the setting of DSS1 (EuroISDN) signalling protocol on the primary interface PRI (basic-net3 is used on the BRI)
- timer T302 is 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, 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
Next configuration step is setting up the call rules. This is done by dial-peer command set from basic config mode (router(config)#) of the CISCO gateway. If the gateway should provide calls from both sides (to and from PSTN/PBX) set of minimum two dial-peers has to be configured.
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 PSTN(PBX) from VoIP side.
- the called number prefix is 42037763 and must be followed with four digits of extension (four dots substitution pattern). 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 interconnection and allows to resolve a possible problem with ring back tone
- the rules are written into 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 VoIP side from PSTN(PBX).
- the called number prefix is 420, 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), default configuration is VAD with CNG function (Comfort Noise Generation)
User is reminded that here listed configuration may not be sufficient to run voice gateway on CISCO routers. Commands may depend on the type of the router and used IOS version.
How to set up services using GNU Gatekeeper was already described in Section 4.5.3, here we describe enhanced configuration and operation for GnuGK to be used with a gateway in order to reach people who are using ordinary telephones.
The gatekeeper has to know which calls are supposed to be routed over the gateway and what numbers shall be called directly. Using the [RasSrv::GWPrefixes] section of the config file the administrator tell the gatekeeper the prefix of numbers that shall be routed over the gateway.
[RasSrv::GWPrefixes] gw-PSTN=0 gw-MOBILE=3
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 E.164 numbers starting with 3 to the gateway that has registered with the H.323 alias "gw-MOBILE". If there is no registered gateway with those alias the call will fail. Note that you must use the gateway alias - you can't 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 we do not advice such a solution because it leads to errors when a network reconfiguration happens.
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 that.
[RasSrv::RewriteE164] 12345=08765
In these example we configured the gatekeeper to replace the numbers 12345 at the beginning of the E.164 number dialled to 08765 (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
Configuration of SIP gateway is almost same as configuration of H.323 gateway and because H.323 gateway is already described in Section 5.1.2.2, we will not describe the same settings here again (for example interface configuration which is exactly the same). We will describe only configuration specific to SIP. Readers should read Section 5.1.2.2 first.
Dial-peer configuration is almost same as described in Section 5.1.2.2, the only difference is that “ras” will be replaced by “sip-server”. Example:
dial-peer voice 112 voip
destination-pattern 420.........
session target sip-server
no vad
All the SIP parameters are configured in sip-ua section. An example configuration might look like:
sip-ua nat symmetric role passive nat symmetric check-media-src retry invite 4 retry response 3 retry bye 2 retry cancel 2 sip-server dns:iptel.org
The first parameters configures the gateway to be passive. That is good for Connection Oriented Media. Value passive means that if there is a direction=active parameter in SDP then the gateway will wait with sending of media until it receives first media packet from the remote party. This feature can be very useful for NAT traversal. It can be enable 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 it's media there if it is in symmetric mode. This option is related to the previous one.
Retry parameters specify how many times various SIP messages should be retried.
And 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
SIP to H.323 gatewaying and vice versa is a complex matter since, up to now, only basic translations of services are possible using this gatewaying. A great development effort in this topic is useless since the gatewaying makes the users loosing the native protocol (H.323 / SIP) supplementary services. These kind of gateways, even if valuable for connecting SIP and H.323 worlds are not yet widely deployed because the adoption of proprietary protocols provides the users with more value added services. Anyway, for sake of thoroughness, this section deals with operations, descriptions and simple configuration of SIP-H.323 gateways.
A SIP / H.323 gateway allows users to make an audio call from SIP network to H.323 network and vice-versa. The entities making the calls using such a gateway can be:
- a SIP user agent;
- a H.323 terminal;
- a SIP proxy server;
- a H.323 gatekeeper;
- another gateway (e.g., SIP-PSTN).
Various types of operations can be performed using a SIP / H.323 gateway and can basically divided in five categories (detailed described in the following of this section):
- user registration;
- call from SIP to H.323;
- call from H.323 to SIP;
- media switching and capabilities negotiation;
- call termination.
There are different modes in which a SIP / H.323 gateway can operate; in this section we describe basic operation modes (for more detailed operations please refer to Interworking Between SIP/SDP and H.323) in order to give the reader basic functionalities examples 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 if the internal gatekeeper / internal SIP register are activated or not.
If a SIP / H.323 gateway is configured appropriately it should try to register both with a H.323 gatekeeper using RAS procedures and with a SIP registrar in order to perform gateway's address resolution from either side. A SIP entity can query the registrar, whereas a H.323 entity can query the H.323 gatekeeper to locate SIP / H.323 gateway. If internal gatekeeper is activated then no registration to external gatekeeper should be performed. If internal SIP registrar is activated then no registration to external SIP registrar should be performed. Anyway, at least one H.323 gatekeeper and at least one SIP registrar should be always specified / activated for operations to be successful.
If 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 a 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 (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.
In this section, we give details on different architectures for user registration / address resolution. User registration servers are SIP registrars and H.323 gatekeepers. If SIP / H.323 gateway has direct access (either built-in or configured) to user registration servers this simplifies locating users independent of the signalling protocol. The user registration server forwards the registration information from one network, to which it belongs, to the other.
Depending on the internal architecture of the SIP / H.323 Gateway we can distinguish three different cases:
SIP / H.323 gateway contains SIP proxy and registrar (Figure 5.12). The H.323 gatekeeper maintains the registration information and thus H.323 users register via the usual procedure. On the other hand, when a SIP REGISTER request is received by the SIP registrar server, it generates a registration request (RRQ) to the H.323 gatekeeper, the RRQ contains the translation of a SIP URI into H.323 Alias Address.
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 is independent of proxy or gatekeeper (Figure 5.14). User registration is done independently in the SIP and H.323 networks.
We are going to describe the SIP / H.323 gateway operations only when it acts an active intervention. Since, when the SIP / H.323 gateway contains a SIP proxy and registrar, the SIP registration information is also available through the H.323 gatekeeper, any H.323 entity can resolve the address of SIP entities reachable via the SIP server, thus an active intervention is performed only in the case of calls originated from the SIP domain towards the H.323 one.
In such a case, if a SIP user agent wants to talk to another user located in the H.323 network, it sends a SIP INVITE message to the SIP server which, in turns, forwards an H.323 location request (LRQ) to the configured gatekeeper (if no gatekeeper was configured then a broadcast LRQ is sent). The gatekeeper responds with the IP address of the H.323 user making the SIP server able to route the call to the destination. Drawbacks of this approach are that the H.323 gatekeeper may be highly loaded because of all the registrations in the SIP network.
Of course when the SIP / H.323 gateway is independent of proxy or gatekeeper it must query the other network for user location, acting an active intervention in the call.
Similarly to the previous case, calls from the H.323 domain to the SIP one requires an active intervention of the SIP / H.323 gateway only when the originating domain contains an H.323 gatekeeper. Such a consideration applies since H.323 terminals appear as SIP URLs within the same domain to the SIP user agents (for further information on how H.323 addresses are translated to SIP URLs please refer to Interworking Between SIP/SDP and H.323).
In this case, if an H.323 user wants to talk to a user located in the SIP network, it sends an admission request (ARQ) to its gatekeeper. The gatekeeper has to send the location request (LRQ) to all the gatekeepers it has configured as neighbours. If the SIP / H.323 built-in gatekeeper receives the LRQ, it tries to resolve the address of a SIP user. This address resolving is done by sending a SIP OPTIONS request. If this operation succeeds and the user is currently available to be called, the SIP / H.323 gateway replies to the H.323 network gatekeeper with the location confirmation (LCF), after the H.323 terminal knows that the destination is reachable. Drawbacks of this approach are, like in the previous case, that the SIP proxy has to store all H.323 registration information.
Of course when the SIP / H.323 gateway is independent of proxy or gatekeeper it must query the other network for user location acting an active intervention in the call.
SIP / H.323 gateway should be configured in order to have media transport directly connected between the SIP and the H.323 entities; when, in some cases, this is not possible, the SIP / H.323 gateway should have a built-in media switching fabric activated to forward RTP and RTCP packets from one client to the other. A great interworking effort is carried out in 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 have to start a muted SIP call and re-negotiate the capabilities later unless the H.323 client support the use of FastStart procedure. If both these conditions can not be ensured, the gateway must use the default codecs for both sides and, eventually, perform media transcoding.
Since a call can be terminated from both H.323 and SIP clients, appropriate message translation / forwarding is required from the SIP / H.323 gateway: a SIP BYE message is mapped to a H.323 Release Complete message and vice-versa.
In this section we are going to give the reader basic configuration principles abstracting them from a specific software in order to give general guidelines and not information becoming rapidly out-of-date. Apart from low impact configuration information (log files location, log level setting), in order to configure a SIP / H.323 gateway it is likely that there will be the need of configuring:
- enabling / not enabling of built-in SIP proxy / registrar and related configuration, please refer to section on setting up SIP services for information on how to configure a SIP proxy / registrar server;
- the remote address / port of the H.323 network gatekeeper (either if SIP built-in proxy / registrar is enabled and no broadcast requests has to be sent or if the SIP / H.323 gateway is independent of proxy or gatekeeper);
- enabling / not enabling of built-in H.323 gatekeeper and related configuration, please refer to section on setting up H.323 services for information on how to configure a H.323 gatekeeper;
- the remote address / port of the SIP network proxy / registrar (either if H.323 built-in gatekeeper is enabled or if the SIP / H.323 gateway is independent of proxy or gatekeeper);
Accounting may be performed both on Gatekeepers and on Gateways. Even if, in principle, accounting done on Gateways is possible, the best solution is to centralize the accounting on Gatekeepers which are able to maintain all the call information (if configured in call signalling routed mode). Information on how to perform accounting may be found in Section 4.3.