Open Multiprotocol IP Telephony Dynamic Routing System
CESNET
technical report number 20/2006
also available in PDF,
PostScript, and
XML formats.
Miroslav Vozňák, Jan Růžička, Lukáš Macura
11.12.2006
1 Abstract
The aim of the project is to create a multi-protocol system using SIP, H.323 and MGCP standards, which would ensure routing to various types of VoIP networks. The priority is to provide multi-protocol support to SIP and H.323 signalling and the support of the routing using the ENUM standard (which is to pass from the trial phase into full operation in the Czech Republic in 2007). The document describes the system's architecture and the components used. It also briefly describes ENUM. The appendices list supported RFC and describe the configuration of individual components.
2 Introduction
In 2006, the multi-protocol routing system was designed and implemented. It consists of five key components and enables connecting voice gateways, end users and peering with other IP telephony providers. The whole system was incorporated into the current IP telephony system and its functionality was tested in trial operation. Although it is not publicly accessible, it demonstrates the variety of connection by means of different equipment by various producers using various protocols; this is project's key contribution.
3 Architecture of the Open Multi-protocol Routing System
The key component of the system is hipath 8000 ("h8k") - a SIP soft switch developed and produced by Siemens. In the course of the trial operation in the Czech Republic, CESNET managed to obtain h8k software, its installation and workshop held in Vienna free of charge. All we had to buy were the servers. We would like to thank the management of the Siemens Division COM for their support and the engineers who participated in installation and debugging of the configuration.
The h8k used by CESNET is built on Suse Linux and IBM x346 HW platform. Its core consists of two IBM x346 servers operating in a fully redundant mode. H8k is complemented by one servers for management and by one media server.
The system's primary protocol is SIP, see [Sin05], [Col02], [Voz06], and the communication with H.323 is ensured by means of a protocol gateway. The system is managed through a web interface. The implemented h8k supports the Privacy Mechanism for the Session Initiation Protocol and IPsec security, which is a means of communication security which we have not yet tested since it was not available under the open-source solutions used.
Figure shows interconnection of the components and routing prefixes.
The system consists of following components:
soft switch hipath8000 (Siemens),
translation gateway H.323-SIP (IP2IP GW Cisco),
SIP Express Router (open-source for Linux),
Asterisk used as the translation gateway H.323-SIP-MGCP (open-source for Linux),
GNU Gatekeeper (open-source for Linux).
The translation between SIP and H.323 is currently carried out at the Cisco IP2IP gateway but we are also looking for different solutions based on open-source and we are testing Asterisk as the translation gateway. We are going to run the IP2IP gateway in parallel with Asterisk until we have verified the full functionality of the translation on Asterisk. The above mentioned components are part of the architecture which provides services to equipment (gateways, IP phones) connected to it. In order to verify whether these are compatible, we drafted a list of devices based on which the soft switch acceptance protocol was designed. The devices were chosen from the following four categories:
translation protocol gateway,
SIP Proxy,
voice gateway,
IP telephones.
The test routing prefixes are mapped statically in order to simplify the verification of component accessibility and to make it more transparent. The critical spot is the SIP-H.323 translation gateway. The prefix enables routing the call to a particular translation gateway in both directions. Later on, we focused on ENUM, i.e. mapping of E.164 number to URI via DNS. At present, we have a fully functional and verified ENUM on the SIP Express Router. Besides the e164.arpa public tree we also use the access into nrenum.net and the cesnet.cz private tree.
In 2006 we ensured the delegation of most prefixes of the members of the CESNET association in the ENUM system. Our experience and achieved results enabled us to participate in developing the new communication architecture of the European infrastructure of national research networks under TF-EFC (Task Force Enhanced Communication Services) of TERENA association.
In our system, SER, h8k, ASTERISK and GnuGK support ENUM. We set up ENUM on SER, GnuGK and Asterisk. The SER and GnuGK servers are also used as border components in the CESNET VoIP network for communication with other VoIP networks and therefore ENUM NAPTR records in DNS are directed to them. Unfortunately, Enum did not operate properly in this version of h8k. The following chapters describe individual system components.
4 Hipath8000
Hipath8000 is a soft switch based on SIP scalable to serve up to 100 000 users. Its redundancy is ensured by interconnection of two identical servers. These servers are connected through multiple redundant 1Gbps interfaces. Figure shows the interconnection of servers, we can see the physical interconnection of interfaces for individual networks (Signalling, Billing, Cluster Interconnect and Administration). The redundancy ensures an uninterupted operation in case one of the servers breaks down and in theory also a smooth upgrade without outage.
H8k was installed on two IBM servers x346. Each of the servers has seven Gigabit ethernet interfaces and together they form a cluster which is subdivided into four VLANs:
Signalling,
Administration NMC/SMC,
Billing,
Interconnect.
Beside these two IBM x346 servers, another server - media server Convedia CMS-1000 is connected to the h8k system. CMS communicates with h8k using MGCP and SIP signalling and enables creating conferences and attaching audio announcements to calls. This Media server is connected to switch by means of two ports designed for:
management,
control and media.
The h8k system is managed by two applications running on one Primergy RX100 S3 server. These are iNMC (Network Management Control) and iSMC (Subscriber Management Control) applications. The latter enables.managing through the web. All configuration tasks can also be carried out via CLI (Command Line Interface) which runs directly on the h8k console on Suse Linux or via a secure shell. The currently installed version of h8k is 2.1. At the Vienna workshop organized for us by Siemens, we had opportunity to test the higher version which works with the Assistant. The Assistant replaces iNMC and iSMC and unifies the access to the system. The management is easier in it. However, this version was not released at the time of the installation. In the Siemens laboratories, the future development of h8k was described to us. Hipath8000 version 3 will be released in 2007. It has a wider support for ENUM. Hipath8000 version 3 has been developed but not yet approved for the release. The SS7 support is a very interesting extension of the h8k operator version. As we have been using the SS7 open-source solution on Asterisk [RVR06], it might be possible to connect these two systems through SS7. The SS7 signalling system is used in IN (Intelligent Networks) of the telecommunications operators of both fixed and mobile networks. These operators make peering solely on SS7.
We chose Convedia CMS-1000 as the Media server for our solution. The Media server is the terminal mixing point of RTP streams. It contains the codecs that perform mixing, audio recording and playback. CMS is a stateless device. It allocates media channels when directed to it by the soft switch or by the application server but does not attempt to maintain call state. The Media Server has the following features:
Tones,
Announcements,
DTMF collection, generation, relay,
Fax support (detect T.30 / T.38),
Conferencing (n-way, meet-me),
Lawful Intercept (CALEA) support,
Multi-lingual options,
Integration with ASR and TTS (via MRCP),
Support SIP and MGCP control,
CSTA and VXML applications interfaces,
Record and Playback options,
SNMP Management.
H8k enables connecting SIP phones and gateways and their interconnection with SIP Proxy. H8k supports H323 but this solution is not fully compatible with H.323 standards used in CESNET2 network and will be completely removed from the later version. This is why we use translation gateways.
5 SER
Another component used is the SIP Express Router (SER). SER is an open source project written in C language. It covers the function of the registrar, redirect and proxy server for communication by means of the SIP protocol. It was originally developed as a backbone SIP router with strong focus on its performance. It can serve thousands of calls per second on the two-processor PC and hundreds of calls on IPAQ.
Server supports stateless and transaction statefull processing of SIP communication. This processing is controlled by a powerful script language. But the powerful language means that its configuration is rather complex. The server is modular and as such is very well extendable. As the number of users keeps growing, new modules are created. SER can be controlled remotely via FIFO or UNIX socket. SIP stack supports communication over the IP protocol, versions 4 and 6, transport protocols UDP and TCP and can also support TLS with the appropriate add-on module. The server also supports multiple user domains, aliases and ENUM. The authentication and authorization can be done via Radius or modules using memory storage or database (Mysql, Postgress). The registration information can also be stored in a SQL database. It is not necessary to use the database to run SER. The registration information are thus stored only in the memory which is fast but these records are lost upon a restart. The SER is able to help with NAT traversal (nathelper, rtpproxy, mediaproxy) and its potential could be extended by external scripts written for example in Perl. The SER is designed for Linux, BSD (NetBSD, FreeBSD) and Solaris.
Recently, the project has split into two separate projects. The original project continues at iptel.org and the new project has its home at openser.org . However, the compatibility of the two projects cannot be guaranteed, in particular for the extensions such as SerWeb. The SER is used in CESNET as the access router and as a server for users.
You can download the current version of the SER is available either as a package for Debian or as a zipped tar ball of source files. Afterwards, you could modify the Makefile to set up which modules will be compiled. For instance Mysql module is not compiled by default. Compilation and installation is done using the following commands:
# make # make modules # make modules install
The ser.cfg configuration file is by default located in /usr/local/etc/ser. The configuration snippet in Appendix shows routing according to prefixes and ENUM.
6 GnuGK
GnuGK runs in CESNET2 network on server gk1ext.cesnet.cz and is, together with the SER, one of the key elements of the system. Its configuration and functions were described in detail in the technical report last year, see [VN06]. Under the project, the support for ENUM has been set up. The configuration is saved in the file /etc/gatekeeper.ini, but before the GK is launched, the PWLIB_ENUM_PATH variable has to be set up. Once it has been tested, it can be set up in /etc/profile. We set up the ENUM queries into two trees - e164.arpa and nrenum.net. This is done by means of the following command:
# export PWLIB_ENUM_PATH=e164.arpa:nrenum.net
The GNU Gatekeeper depends on OpenH323 library which is dependent on PWLib. ENUM requires at least PWLIB V1.8.0. We have bad experience with older versions of PWLIB and OPENH323 and therefore recommend downloading a newer version. However, not all versions are compatible; the latest verified couple is PWLIB V1.10.0 and OPENH323 V1.18.0. The latest released version of GnuGK - GnuGK 2.2.4 uses these versions.
# wget http://surfnet.dl.sourceforge.net/sourceforge/openh323/pwlib-v1_10_0-src-tar.gz #wget http://optusnet.dl.sourceforge.net/sourceforge/openh323/openh323-v1_18_0-src-tar.gz
Once the file is downloaded and unpacked, the standard compilation may be carried out.
# ./configure # make # make install
The GNU GK documentation at GNU Gatekeeper site contains a mistake in the ENUM description. A quote from the gnugk documentation: "To specify your own server you have to specify an environmental variable PWLIB_ENUM_PATH with the address of your preferred enum servers separated by a semicolon (;)." But semicolon (;) is wrong (for Linux), the right syntax is colon (:).
Setting up the /etc/gatkeeper.ini file is quite easy. All you have to set up in the [RoutingPolicy] section is the directions which should be available via ENUM, e.g.:
[RoutingPolicy] 123456=enum,dns 789847=enum,dns
or default rule
[RoutingPolicy] default=explicit,internal,neighbor,parent,enum,dns
The next configuration snippet shows routing of calls to h8k either via the IP2IP or Asterisk translation gateway. We describe only the part of the configuration relating to routing.
[RasSrv::GWPrefixes] IP2IPGW=950051 GW-CESNET-AST=950052 [RasSrv::GWRewriteE164] IP2IPGW=out=950051=420950051 GW-CESNET-AST=out=950052=420950052 [RasSrv::PermanentEndpoints] ipaddressGWAsterisk:1720=GW-CESNET-AST;420950052 ipaddressGWIP2IP:1720=IP2IPGW;420950051
7 Asterisk as SIP-to-H.323 gateway
In our project, we use Asterisk as the translation gateway between SIP and H.323 in the same way as Cisco IP2IP Gateway. Asterisk is designed as a multi-protocol PBX. SIP and H.323 are only two of the various protocols which Asterisk is able to use and the translation between these two protocols is just one of possible ways to use Asterisk. As Asterisk is not designed directly for such a translation, the configuration is broken down into several files. Asterisk is described in detail in our last year's technical report, see [VZW05]. We will therefore move directly to the configuration of the significant parts used in the project.
The configuration of the SIP channel is stored in the sip.conf file. All SIP clients or superior servers are set up there. For our purposes, we configured only few clients (IPphones). The configuration is divided into several sections: the general section which contains the initial settings for all / non authenticated clients and individual sections which describe peers.
[general] context=guest ; Default context for incoming calls port=5060 ; UDP Port to bind to (SIP standard port is 5060) bindaddr=0.0.0.0 ; IP address to bind to (0.0.0.0 binds to all) srvlookup=yes ; Enable DNS SRV lookups on outbound calls tos=lowdelay ; lowdelay,throughput,reliability,mincost,none maxexpirey=3600 ; Max length of incoming registration we allow defaultexpirey=400 ; Default length of incoming/outoing registration videosupport=yes ; Turn on support for SIP video disallow=all ; First disallow all codecs ;allow=ilbc ; Note: codec order is respected only in [general] ;allow=speex ;allow=gsm allow=alaw ;allow=h261 allow=h263 allow=h263p rtptimeout=60 ; Terminate call if 60 seconds of no RTP activity rtpholdtimeout=300 ; Terminate call if 300 seconds of no RTP activity ;Number 950052 11 ; all calls from this number will nbe routed to context sip. [950052 11] username=950052 11 secret=nejakeheslo callerid=Pepa Nos type=friend context=sip host=dynamic canreinvite=no qualify=6000 nat=yes
The ooh323.conf file describes the setting of the ooh323 channel. Asterisk supports more H.323 channels: the original asterisk's h323, oh323 built on the openh323 stack and Objective Open H.323 (ooh323c). For our purpose, we used ooh323c because it is written in purely in C and does not, like the oh323, depend on other external libraries. Thanks to these qualities it is more convenient for the possible embedding. The setting of ooh323.conf is described in Appendix.
The next configuration file is extension.ael. The new syntax of dial plan in Asterisk (Asterisk Extensions Language) is very synoptic. Unlike the extensions.conf, AEL has a higher-level syntax. We used AEL to define the enum macro according to a contribution found at the voip-info.org Wiki.
Asterisk does supports ENUM but only at a low level (see the enumlookup manual page). Anything more complicated depends on user functions, but it gives the ENUM lookup a substantial variety. The initial configuration of ENUM in enum.conf is not used in this case and zones are defined directly within the macro (divided by minus), see Appendix. It is necessary to interconnect these channels so that the call from the first protocol is routed to the second as well as in the opposite direction which is done in extensions.conf. We selected ENUM because it is much easier, more legible and clearer than Asterisk itself. For routing we used the ready made macro defined in Appendix.
Now we need to interconnect everything, the authenticated clients from SIP will call via context sip and non -authenticated via guest (see sip.conf). The process for H.323 is rather more complicated because we only support anonymous users that can be routed based on their IP address only. We did not use this option and we route everything from H.323 to the h323 context (see ooh323.conf). We should stress that one should not rely on the order of lines in individual contexts. The sole truly reliable element is the order of include directives. Further we note that the lines written directly in the contexts are assessed first and then the includes. The configuration of extensions.conf is described in Appendix.
8 IP2IP Gateway
Appendix shows the IP2IP GW configuration. We used Cisco 2651XM as the translation gateway with the c2600-adventerprisek9_ivs-mz.124-3b image. The configuration was done according to the documentation. The following syntax in configuration allows the translation:
voice service voip allow-connections h323 to h323 allow-connections h323 to sip allow-connections sip to h323 allow-connections sip to sip
In the SIP direction, the SIP server is set as the session-target. The SIP server is set up in sip-ua section and resolved via DNS.
dial-peer voice 211 voip destination-pattern 950051... session target sip-server
In the H.323 direction, RAS is set as the session-target. The setting for ras can be found at the Fast Ethernet interface in which we configured the registration of gateway at gk1ext.cesnet.cz.
dial-peer voice 1 voip destination-pattern 420......... session target ras
At IP2IP GW we also use translation of numbers and codec preferences which is set up in the Voice class codec section and Translation rules, see Appendix.
9 ENUM
ENUM plays an important role in the interconnection of VoIP islands. Its base function could be described as the mapping of the space of E.164 telephone numbers into the space of URIs (uniform resource identifications). The most often IP telephony URIs used begin with sip:, h323: or eventually tel:. The core ENUM functionality has been described quite frequently and therefore we will not deal with it further. Let us only remind that the DNS system is used to distribute information (translation rules), in particular NAPTR of records.
An example NAPTR of the record for 9.8.2.5.5.3.4.2.2.0.2.4.e164.arpa:.
IN NAPTR 100 50 u "E2U+sip" "!^\+(.*)$!sip:\1@cesnet.cz!" . IN NAPTR 200 50 u "E2U+h323" "!^\+(.*)$!h323:\1@gk1ext.cesnet.cz!" .
These rules transform E.164 number +420224355289 into URIs sip:420224355289@cesnet.cz and sip:420224355289@gk1ext.cesnet.cz
The DNS system is quite suitable for this purpose thanks to its stability and the distributed approach. In addition, the mechanisms resolving the address for the target element also use DNS. Besides the common translation of names to IP addresses the SRV records can also be used. SRV records publish the places of the operator of individual services. The following SRV records show service points for the SIP protocol using transport protocols TCP and UDP for the cesnet.cz domain:
_sip._udp.cesnet.cz SRV 100 10 5060 cyrus.cesnet.cz. _sip._tcp.cesnet.cz SRV 100 10 5060 cyrus.cesnet.cz.
The disadvantage of using DNS is a rather low security level because DNSSEC is not that widely used and the transmitted information cannot be protected against forgery. The system is designed so that anyone can ask for information. The way in which various answers are created based on the address of the participant who poses the question is rather complicated, in particular where recursive queries are used.
The benefit of the system is that the owner of the telephone number controls information that is made public about his number. The most frequent has so far been the exchange of routing information (prefixes and addresses of border elements) while interconnecting various islands. When the information has changed, it had to be distributed to all participants and their systems adjusted accordingly. The probability that a mistake will occur increases with a larger number of participants. When every participant only publishes own information, the system is much flexible.
We distinguish several types of ENUM, public and private. The public part can be further subdivided for user and infrastructure usage. Anyone can create a private tree in his own domain, many such trees exist. One group is represented by nrenum.net, e164.org and it serves for a slow start or when the public tree is not available. The second group can be used for internal routing, for instance in big companies. The public user ENUM uses the e164.arpa tree. The first level for assigning sub-trees is the national prefix - 420 for the Czech Republic. The assignment is made through ITU-T which asks the national regulator (National Telecommunication Office or the Ministry) for the approval. Subsequently, the registrant can only register the domain (number or prefix) to which the applicant can confirm his right to use - i.e. to carry out the validation by means of an SMS, contract or invoice. It is clear that in the public user tree, the information is inserted by the user himself and by not the operator of the number. On other hand, ENUM is very important for the connection between operators and that is why the ENUM infrastructure has been created.
We stored prefixes of operators which we are connected to us in a private tree. All NAPTR records about them are stored directly in a single zone, i.e. not delegated. This not only enables every participating operator to transfer the whole zone to himself and thus obtain faster responses, reduces the likelihood that the records will change during the transport but it reduces the possibly for every operator to manage his own records in his name server. We try to remove this disadvantage by designing such a zone management system in which the participants could also publish contact persons' information and testing numbers which facilitates solving possible issues. The system consists of a web interface built upon MySQL database, a functionality which ensures that the zone is generated and of DNS server BIND. The validation has not been automated and it will carried out be based on information published by CTU (Czech Telecommunication Office). The aim is to make the operators aware of ENUM by means of this particular project and to show them how to use it to their advantage.
10 Conclusion
The output of our work is the implementation of a multi-protocol system working with standards SIP, H.323 and MGCP which uses both the static routing and ENUM. We tested the functionality of the two-way translation between H.323 and SIP by means of a load test using the IP2IP gateway. Moreover, we added a new feature into the system based on Asterisk. We explored open-source solutions and used the GNU GK, SIP Express Router and Asterisk open projects. The core of the tested solution consists of the Hipath8000 soft switch produced by Siemens which supports several advanced functions and enables interconnecting advanced enterprise or operator oriented system with our largely open source systems and provides the background for such cooperation. ENUM ensures the openness and availability of the connection. The next phase is to build up a system of trust on the interconnected networks of IP telephony islands.
11 Appendix A - Supported RFC's in hipath8000
RFC 0826: ARP Ethernet Address Resolution Protocol
RFC 1034: DNS Domain Name System
RFC 0959: FTP File Transfer Protocol
RFC 0792: ICMP Internet Control Message Protocol
RFC 0791: IP Internet Protocol
RFC 1305: NTP Network Time Protocol
RFC 1905: SNMP v2 Simple Network Management Protocol
RFC 0793: TCP Transmission Control Protocol
RFC 0854: Telnet
RFC 0768: UDP User Datagram Protocol
RFC 0894: Standard for the Transmission of IP Datagrams over Ethernet Networks
RFC 822: Format of ARPA Internet Text Messages
RFC 1123: Requirements for Internet Hosts
RFC 3261: SIP: Session Initiation Protocol
RFC 1889 & RFC 1890: RTP - Real-Time Transport
RFC 2327: Session Description Protocol (SDP)
RFC 2705: Media Gateway Control Protocol (MGCP)
RFC 2806: URLs for Telephone Calls
RFC 3015: Megaco Protocol
RFC 2916: E.164 Numbers and DNS
RFC 3204: Mime Type for ISUP and QSIG
RFC 2976: SIP INFO Method
RFC 3262: Reliability of Provisional Responses in SIP
RFC 3265: SIP-specific Event Notification
RFC 3272: SIP for Telephones (SIP-T): Context and Architectures
Draft-ietf-sipping-e164-00.txt: Resolution of e.164 Numbers in SIP Applications
Draft-ietf-sipping-isup-00.txt: ISUP to SIP Mapping
Draft-ietf-sip-session-timer-09.txt: Session Timer for SIP
Draft-ietf-sip-privacy-general-01 SIP Privacy Mechanism
Draft-levy-sip-diversion-01.txt: Diversion Indication in SIP
Draft-ietf-sipping-mwi-00.txt: SIP Message Waiting
Draft-ietf-sipping-3pcc-02.txt: SIP Third Party Call Control
ITU-T Q.701 through Q.707 SS7 MTP
ITU-T Q.761 through Q.767 SS7 ISUP
ITU-T H.323 v2 Packet Based Multimedia Communications
ITU-T H.225 v2 H.323 Call Signalling Protocols
ITU-T H.245 v2 H.323 Media Control
ITU-T E.164 The International Pub. Telecommunications Numbering Plan
ITU-T X.680 Abstract Syntax Notation One (ASN.1)
ITU-T X.690 Specification of Basic Encoding Rules (BER)
ITU-T Q.1214 Intelligent Network CS-1
12 Appendix B - Configuration file for SER
# load selected modules
loadmodule "/usr/local/lib/ser/modules/sl.so" #stateless operations
loadmodule "/usr/local/lib/ser/modules/tm.so" #statefull operations
loadmodule "/usr/local/lib/ser/modules/enum.so" #Enum module
# set module parameters
modparam("enum", "domain_suffix", "e164.arpa")
#main routing logic block
route{
# Route to gw according to prefix
if (uri= "^sip:(420)?950055[0-9]{3}@") { #match the number prefix in URI
if (uri= "^sip:420") {strip(3);}; #test the URI, strip 420 from it
rewritehostport("a.b.c.d:5060"); #change the destination set
route(1); #process routing block No.1
break;
};
# Route H8k prefix
if (uri= "^sip:(420)?950055[0-9]{3}@") { #match the number prefix in URI
if !(uri= "^sip:420") {prefix("420");}; #test the URI, add 420 to it
rewritehostport("e.f.g.h:5060"); #change the destination set
route(1); #process routing block No.1
break;
};
# ENUM
if (uri= "^sip:[1-9][0-9]{5,15}+@") { #match the number prefix in URI
prefix("+"); #add a plus sign to URI - needed for ENUM query
if (enum_query("e164.arpa")) { #query the public user enum tree
route(1);
break;
}; # no answer in public user tree
if (enum_query("nrenum.net")) { # query the private NREN tree
route(1);
break;
};
strip(1); #query was not succesfull strip the plus sign
};
}
# ENUM internal
if (uri= "^sip:420[0-9]{9}+@") { #match the number prefix in URI
#staring with 420 - used only for CR
prefix("+"); #add a plus sign to URI - needed for ENUM query
if (enum_query("e164.internalzone.cesnet.cz")) { #query the internal tree
route(1);
break;
};
strip(1); #query was not succesfull strip the plus sign
};
# routing logic block No.1
route[1]
{
if (!t_relay()) { #send the reguest out staefully
sl_reply_error(); #something is wrong send an info statelesly
}
}
13 Appendix C - Configuration file ooh323.conf
; Objective System's H323 Configuration example for Asterisk ; ooh323c driver configuration ; ; [general] section defines global parameters ; ; This is followed by profiles which can be of three types - user/peer/friend ; Name of the user profile should match with the h323id of the user device. ; For peer/friend profiles, host ip address must be provided as "dynamic" is ; not supported as of now. ; ; Syntax for specifying a H323 device in extensions.conf is ; For Registered peers/friends profiles: ; OOH323/name where name is the name of the peer/friend profile. ; ; For unregistered H.323 phones: ; OOH323/ip[:port] OR if gk is used OOH323/alias where alias can be any H323 ; alias ; ; For dialing into another asterisk peer at a specific exten ; OOH323/exten/peer OR OOH323/exten@ip ; ; Domain name resolution is not yet supported. ; ; When a H.323 user calls into asterisk, his H323ID is matched with the profile ; name and context is determined to route the call ; ; The channel driver will register all global aliases and aliases defined in ; peer profiles with the gatekeeper, if one exists. So, that when someone ; outside our pbx (non-user) calls an extension, gatekeeper will route that ; call to our asterisk box, from where it will be routed as per dial plan. [general] port=1720 ;This parameter indicates whether channel driver should register with ;gatekeeper as a gateway or an endpoint. ;Default - no gateway=yes ;Whether asterisk should use fast-start and tunneling for H323 connections. ;Default - yes faststart=no h245tunneling=no ;H323-ID to be used for asterisk server ;Default - Asterisk PBX h323id=GW-CESNET-AST e164=950052 ;Whether this asterisk server will use gatekeeper. ;Default - DISABLE ;gatekeeper = DISCOVER ;gatekeeper = a.b.c.d ;gatekeeper = gk1ext.cesnet.cz gatekeeper = 195.113.222.2 ;Location for H323 log file ;Default - /var/log/asterisk/h323_log ;logfile=/var/log/asterisk/h323_log ;Sets default context all clients will be placed in. ;Default - default context=h323 ;Type of Service ;Default - none (lowdelay, thoughput, reliability, mincost, none) ;tos=lowdelay ;The codecs to be used for all clients.Only ulaw and gsm supported as of now. ;Default - ulaw ; ONLY ulaw, gsm, g729 and g7231 supported as of now disallow=all ;Note order of disallow/allow is important. ;allow=gsm allow=ulaw allow=alaw ; dtmf mode to be used by default for all clients. Supports rfc2833, q931keypad ; h245alphanumeric, h245signal. ;Default - rfc2833 dtmfmode=rfc2833
14 Appendix D - Configuration file extensions.ael
macro route-enum(exten, IsPOTS, Timeout, DialOpts) {
// based on http://www.voip-info.org/wiki/view/RFC+Compliant+ENUM+Macro
Set(DIAL_NUMBER=${exten});
Set(E164NETWORKS=e164.arpa-nrenum.net);
if ("${ENUMDEPTH}" = "")
ENUMDEPTH=0;
ENUMDEPTH=1 + ${ENUMDEPTH};
if (${ENUMDEPTH} > 5) { // max enum depth we will go
// This is to prevent a looping enum entry; there is no other safe way to be sure we don't get stuck in such a trap.
Set(DIALSTATUS=EnumMaxDepth);
goto end;
};
if ("${DIAL_NUMBER:0:1}" != "+")
Set(DIAL_NUMBER=+${DIAL_NUMBER}); // Add a plus to the start, becasue ENUMLOOKUP needs it.
// Checking here to see if there are any e164 networks left to check.
for (&iterator(${E164NETWORKS},ENUMNET); "${ENUMNET}" != ""; &iterate(ENUMNET)) {
// OK, this is now quite complex. To remain compliant, we have to iterate through, in order, the returned records.
// Since we want to make this call over the network, we can ignore tel: lines. Even if it's first priority.
Set(ENUMCOUNT=${ENUMLOOKUP(${DIAL_NUMBER},ALL,c,${ENUMNET})});
// Documentation is wrong. It can return nothing if the enum lookup fails. Grr.
// Now the count may be zero, so if it is, check the next network
if ("${ENUMCOUNT}" = "")
ENUMCOUNT=0;
// Now, let's start through them.
for (ENUMPTR=1; ${ENUMPTR} <= ${ENUMCOUNT}; ENUMPTR=${ENUMPTR} + 1) {
Set(ENUM=${ENUMLOOKUP(${DIAL_NUMBER},ALL,${ENUMPTR},${ENUMNET})});
// Sanity check the return, make sure there's something in there.
if (${LEN(${ENUM})} = 0)
continue;
Set(DIALSTR=);
Set(DIALSTATUS=);
switch(${CUT(ENUM,:,1)}) {
case sip:
// If the prefix is 'sip:'...
Set(DIALSTR=SIP/${ENUM:4});
break;
case iax2:
// If it's IAX2...
Set(DIALSTR=IAX2/${ENUM:5});
break;
case h323:
// It doesn't matter if you don't have h323 enabled, as when it tries to dial,
// it cares about dialstatus and retries if there are any enum results left.
// Or even if it's H323.
Set(DIALSTR=H323/${ENUM:5});
break;
case tel:
// redirect to another number... potentially dangerous (looping)
&enumtest(${ENUM:4});
break;
default:
// If we're here, it's not a protocol we know about. Let's increment the pointer and
// if it's more than ENUMCOUNT, we know we've run out of options. Try the next e164 network.
Set(DIALSTATUS=CHANUNAVAIL);
break;
};
if ("${DIALSTR}" != "") {
Dial(${DIALSTR},${Timeout},o${DialOpts});
NoOp(Dial exited in enumtest with ${DIALSTATUS});
};
// Now, if we're still here, that means the Dial failed for some reason.
// If it's CONGESTION or CHANUNAVAIL we probably want to try again on a different channel.
// However, if it's the last one, we don't have any left, and I didn't keep any previous dialstatuses,
// so hopefully someone looking throught the logs would have seen the NoOp's
if ("${DIALSTATUS}"!="CONGESTION"&"${DIALSTATUS}"!="CHANUNAVAIL") {
NoOp(Enum Dial(${DIALSTR}) failed due to ${DIALSTATUS});
goto end;
};
};
};
end:
NoOp(EnumLookups failed);
};
macro iterate(varname) {
current=${${varname}_current} + 1;
SET(${varname}=${CUT(${varname}_choices,,${current})});
SET(${varname}_current=${current});
};
macro iterator(choices, varname) {
SET(${varname}_choices=${choices});
SET(${varname}_current=0);
&iterate(${varname});
};
15 Appendix E - Configuration file extensions.conf
; enum context. This is used only for inclusion. We will use it in more
contexts.
[enum]
; _ in the start of pattern is needed to determine start of the number!
; It has to be always there
exten => _XXXXXXXXX,1,Macro(route-enum,420${EXTEN},,50,m);
exten => _420XXXXXXXXX,1,Macro(route-enum,${EXTEN:3},,50,m);
exten => _+.,1,Macro(route-enum,${EXTEN:4},,50,m);
exten => _00.,1,Macro(route-enum,${EXTEN:5},,50,m);
; Default context for SIP clietnts which are not authenticated.
; Non-authenticated clients in this context!
; Keep this safe, and do not put any non-costfree service here!
; Enum is probably ok ;)
[h323]
include => enum
[sip]
include => enum
include => nonfree
; Non-authenticated clients in this context!
; Keep this safe, and do not put any non-costfree service here!
; Enum is probably ok ;)
[guest]
include => enum
16 Appendix F - Configuration of IP2IP Gateway
R104_ip2ipgw#sh ver Cisco IOS Software, C2600 Software (C2600-ADVENTERPRISEK9_IVS-M), Version 12.4(3b), RELEASE SOFTWARE (fc3) System image file is "flash:c2600-adventerprisek9_ivs-mz.124-3b.bin" Cisco 2651XM (MPC860P) processor (revision 0x300) with 253952K/8192K bytes of memory. Processor board ID JAE0817EBG6 (2511081877) ! voice service voip allow-connections h323 to h323 allow-connections h323 to sip allow-connections sip to h323 allow-connections sip to sip h323 call start interwork sip ! voice class codec 200 codec preference 1 g711alaw codec preference 2 g711ulaw codec preference 3 gsmfr codec preference 4 g729r8 ! translation-rule 200 rule 1 9991 22435 ! voice class h323 500 call start slow ! dial-peer voice 1 voip destination-pattern 420......... voice-class codec 200 session target ras incoming called-number 420......... ! dial-peer voice 211 voip destination-pattern 950051... voice-class codec 200 session protocol sipv2 session target sip-server dtmf-relay rtp-nte ! gateway timer receive-rtp 1200 ! sip-ua nat symmetric role passive nat symmetric check-media-src sip-server dns:cesnet.cz !
References
| [Sin05] | Sinnreich H.: SIP Beyond VoIP. VON Publishing LLC, New York, 2005, ISBN 0974813001. |
| [Col02] | Collins D.: Carrier Grade Voice Over IP. McGraw-Hill, 2002, ISBN 0071406344. |
| [VN06] | Vozňák M. - Neuman M.: GNU Gatekeeper a jeho nasazení v síti CESNET2 [GNU Gatekeeper and its Deployment in the CESNET2 Network]., Technical Report 10/2005, CESNET, 2005. |
| [VZW05] | Vozňák M. - Zukal D. - Wija T.: Asterisk a jeho použití [Asterisk and its application]. Technical Report 12/2005, CESNET, 2005. |
| [Voz06] | Vozňák M.: Signalizace SIP [SIP Signalling]. In: Proceedings of the seminar Teorie a praxe IP telefonie. Sdělovací technika, ČVUT and ProTel engineering, Praha 2006, p. 35-75. |
| [RVR06] | Rudinský J. - Vozňák M. - Růžička J.: Asterisk SS7. Technical Report 26/2006, CESNET, 2006. |