ENUM support
From FreeSWITCH Wiki
Contents |
ENUM Support
CLI
from the CLI issue something similar to the following
enum 18002255288
Configuration
The main file for configuring ENUM functionality (assuming you've done "make samples" and are working with the provided sample configuration files) is: conf/autoload_configs/enum.conf.xml
The contents of this file are as of such:
<configuration name="enum.conf" description="ENUM Module">
<settings>
<param name="default-root" value="e164.org"/>
<param name="default-isn-root" value="freenum.org"/>
<param name="query-timeout" value="10"/>
<param name="auto-reload" value="true"/>
</settings>
<routes>
<route service="E2U+SIP" regex="sip:(.*)" replace="sofia/$${sip_profile}/$1"/>
<route service="E2U+IAX2" regex="iax2:(.*)" replace="iax/$1"/>
<route service="E2U+XMPP" regex="XMPP:(.*)" replace="dingaling/$${xmpp_server_profile}/$1"/>
</routes>
</configuration>
If you have difficulty in getting ENUM to work because of this error:
2008-09-09 20:21:11 [ERR] switch_ivr_originate.c:958 switch_ivr_originate() Cannot create outgoing channel of type [sofia] cause: [DESTINATION_OUT_OF_ORDER] 2008-09-09 20:21:11 [ERR] mod_sofia.c:1946 sofia_outgoing_channel() Invalid Profile
See TECHNICALS section below for some "workarounds" which I'm sure someone will either correct me on, or perhaps even wind up being a bug in JIRA.
Dialplan
The enum dialplan requires you only to dial a number and an ENUM lookup will be done. If results are found, the ones supported will be called in order of priority and weight of the DNS records.
The ENUM dialplan can be set from one of the Endpoints configuration XML as follows:
<param name="dialplan" value="enum"/>
In the example configuration files provided by "make samples" you would find this in the conf/sip_profiles directory.
Application - Example 1 (Basic Usage)
The ENUM application can be called from the dialplan by executing it from within your condition as follows:
<action application="enum" data="$1 e164.org"/>
It will return a "bridge" value in the variable ${enum_auto_route}
From what I understand, you can specify the domain as the second parameter, above it is "e164.org" the parameter $1 contains what has been dialed. In the example below you'll note the line that indicates:
<action application="set" data="continue_on_fail=true"/>
This is being set so that the dialplan will continue on to the next option for bridging in case the enum lookup fails and a bridge is attempted to a "null" result. Since we can't nest <conditions> in the XML dialplan, setting continue_on_fail to true will insure that the call progresses should the enum lookup fail.
Application - Example 2 (PSTN 11 Digits)
For a US Number an example of an extension for the XML dialplan that would use ENUM is:
<extension name="Outbound to PSTN 11 Digits">
<condition field="destination_number" expression="^(1[2-9][0-9][0-9][2-9][0-9][0-9][0-9][0-9][0-9][0-9])$">
<action application="set" data="continue_on_fail=true"/>
<action application="enum" data="$1 e164.org"/>
<action application="bridge" data="${enum_auto_route}"/>
<action application="bridge" data="sofia/gateway/myVoIPGateWay/$1|sofia/gateway/myVoIPGateWay-backup/$1|sofia/gateway/LastVoIPGateWayAttempt/$1"/>
</condition>
</extension>
Application - Example 3 (10 Digits)
On occasion you'll find that some people may prefer a 10 digit dial. This is popular in locations (such as Washington DC) where local calling may span several area codes, and you need only dial a (1) when it is long distance. This is also handy for selecting the number from the caller ID and hitting dial on the phone without having to re-enter the number with a 1 in front of it.
In this instance you'll notice that we preceded the $1 argument with a 1 in front of it, thereby changing the number passed to enum from say 800-555-1212 to 1-800-555-1212.
<extension name="Outbound to PSTN 10 Digits">
<condition field="destination_number" expression="^([2-9][0-9][0-9][2-9][0-9][0-9][0-9][0-9][0-9][0-9])$">
<action application="set" data="continue_on_fail=true"/>
<action application="enum" data="1$1 e164.org"/>
<action application="bridge" data="${enum_auto_route}"/>
<action application="bridge" data="sofia/gateway/myVoIPGateWay/1$1|sofia/gateway/myVoIPGateWay-backup/1$1|sofia/gateway/LastVoIPGateWayAttempt/1$1"/>
</condition>
</extension>
When implementing this, please be sure to check that you won't need to dial a 10 digit number for anything other than a PSTN call within your dial plan.
SUMMARY
E164 has several domains to look up numbers in such as:
e164.org e164.arpa
Hence, one could try:
<action application="enum" data="$1 e164.org"/>
<action application="bridge" data="${enum_auto_route}"/>
<action application="enum" data="$1 e164.arpa"/>
<action application="bridge" data="${enum_auto_route}"/>
And there are numerous others spanned across the globe, but please research them fully before using them lest calls be "hijacked" to somewhere else. You could in fact institute your own dialplan within your own DNS domain by using ENUM lookups for particular extensions, however it has been reported that it might be possible to have your DOMAIN hijacked and in the process your telephone traffic may also be exploited. So do your own research into the security of such a deployment.
Incidentally, although the e164.org organization does have several interesting thing about it, the one thing that they don't "police" is numbers that have been "changed" or "disconnected", etc... Hence, they rely on the individual that "owns" the record to delete the record for their old number. Hence, over time it is possible that if enough people "forget" to delete their old numbers that a call could get improperly routed to the wrong (old) destination and not arrive to the person/organization that presently owns that PSTN number.
In short, use at your own risk.
TECHNICALS
If you insert the "info" application into the Dialplan as such:
<action application="enum" data="$1 e164.org"/>
<action application="info"/>
<action application="bridge" data="${enum_auto_route}"/>
and at the console type:
console loglevel info
You'll note you get back a lot of information on the console performed after the enum lookup. This will contain the data below, and should be a way of verifying that the enum lookup was successful and returned a properly formatted "bridge" for use in placing the call.
Below you'll note there are several records for the PSTN Number of 1-800-555-1212 You will also notice that the enum lookup returned the "variable_enum_auto_route" properly formatted.
variable_enum_route_1: [sofia/internal/18005551212@tf.voipmich.com] variable_enum_route_2: [sofia/internal/16416418005551212@sip.tollfreegateway.com] variable_enum_route_3: [sofia/internal/18005551212@tollfree.sip-happens.com] variable_enum_route_count: [4] variable_enum_auto_route: [sofia/internal/18005551212@tf.voipmich.com,sofia/internal/16416418005551212@sip.tollfreegateway.com,sofia/internal/18005551212@tollfree.sip-happens.com] variable_current_application: [info]
WORKAROUNDS:
If you get this error:
2008-09-09 20:21:11 [ERR] switch_ivr_originate.c:958 switch_ivr_originate() Cannot create outgoing channel of type [sofia] cause: [DESTINATION_OUT_OF_ORDER] 2008-09-09 20:21:11 [ERR] mod_sofia.c:1946 sofia_outgoing_channel() Invalid Profile
Insert an "info" as such into your XML dialplan:
<action application="enum" data="$1 e164.org"/>
<action application="info"/>
<action application="bridge" data="${enum_auto_route}"/>
Type:
console loglevel info
into your console window and attempt to make a call.
If you get this result for the enum_routes:
variable_enum_route_1: [sofia//18005551212@tollfree.sip-happens.com] variable_enum_route_2: [sofia//18005551212@tf.voipmich.com] variable_enum_route_3: [sofia//16416418005551212@sip.tollfreegateway.com]
It means that this line in the enum.conf.xml file:
<route service="E2U+SIP" regex="sip:(.*)" replace="sofia/$${sip_profile}/$1"/>
is somehow malfunctioning.
My workaround is this:
<route service="E2U+SIP" regex="sip:(.*)" replace="sofia/internal/$1"/>
Where the sip_profile to be used is hardwired to be internal. I'll probably catch holy heck for this as a published workaround, and frankly I don't recommend using it as a "fix" but until I find out why it doesn't work I'm sticking by my example.
