Trunk Settings

From Pbxnsip Wiki

Contents 1 Purpose 2 Current Trunks 3 Name and Type 4 General Parameters 5 Outbound Settings 6 Inbound Settings 7 Troubleshooting SIP Trunk Problems 8 Outbound Calls on Trunk 9 Inbound Calls on the trunk 10 ENUM

Purpose

The purpose of Trunks are used to send and receive calls to devices that are not registered with the PBX. When a call is received by the PBX it checks to see if it is another extension and if not the dial plan is consulted to determine which Trunk to route the call to. The name Trunk comes from the premise that there is a physical connection between the PBX and an external device, like it used to be with traditional TDM based PBX's. In pbxnsip all trunks are SIP trunks. If a connection to the PSTN is needed then we use a SIP gateway for that. For outbound calls extensions are linked to dialplans which select a trunk depending upon the number dialed. Inbound calls are received by the trunk and routed to the appropriate extension or account.

There are three types of trunks on the pbxnsip system:

• Registrations. The PBX registers to a remote system and itself looks like an extension to the upsteam system. This model is typically used when you have an account with an Internet Telephony Service Provider (ITSP) and you use this account for terminating your traffic. In this model, the PBX uses the number of the registration as caller-ID, regardless what extension is actually using the trunk. You can use this mode if the service provider supports SIP soft or hard phones. This type of trunk can also be used if you want to connect two pbxnsip systems together in a branch/head office configuration. The branch office can create a trunk and register to an extension on the head office pbx which can be called by any extension and routed to the branch office accordingly.

• Gateway. The gateway model does not register; it just sends the traffic to the destination. In this model, the PBX uses the caller-ID of the PBX to indicate the extension that initiates an outgoing call (if that extension did not turn block caller-ID on). This model is typically used with customer premises PSTN gateway hardware. However one can link two pbxnsip systems together by using gateway trunks as long as they are routable to each other i.e. both are on public IP addresses or on the same private network.

• Proxy. The proxy model is similar to the gateway model. The difference is the way anonymous calls are made and how the proxy represents its own domain. As the name suggests, the proxy model assumes that you are talking to a SIP proxy or Session Border Controller, while the gateway model assumes that you are talking to a SIP user agent. However, the two models are quite similar.

Trunks are usually in scope of a domain. But you can also make a trunk visible in all domains. For example, if you want to share a PSTN gateway amongst all domains, you would set up a trunk in a separate domain and make it visible to all domains.

Current Trunks

In the trunk list, you can see which trunks are available in the current domain. If the trunk is a registration, the PBX will show the registration status. A 200 OK is the desired state of the Trunk status. To force a re-registration request of this trunk, you may click on the register link.

To delete a trunk, you may click on the delete icon. To edit the details of a trunk, you can click on the edit icon.

At the bottom of the page you find a form for creating a new trunk. Trunk names may include alphanumeric characters and space. The system assigns a number to each trunk, so that it is ok if different domains choose the same name for a trunk.

Name and Type

After you have created a trunk, you may change the name and the type. The name must consist of alphanumeric characters and may contain spaces. The trunk type can be selected by a selection box.

You may limit the direction of the trunk to accept only inbound traffic, to send only outbound traffic out. Limiting traffic to inbound only avoid that users use trunks for unauthorized calls. For example, when using a trunk for ENUM without outbound proxy, you may want to avoid outbound traffic on that trunk. If you are using a trunk only for outbound traffic, it makes it easier for the PBX if you explicitly set the trunk to outbound only. Then the trunk will not try to match inbound traffic to this trunk.

General Parameters

The "Display Name", the "Account" and the "Domain" are used to construct the address that the PBX registers. The account must be a valid SIP account identifier and the display name is used for display purposes. For example, the display name could be "Test Account", the account "test-account" and the registrar "test.com". Then the PBX would register "Test Account" <sip:test-account@test.com>.

The "Username" and the "Password" are used for authentication purposes. Some registrars use a different username for authentication; therefore the PBX includes this field as well. The password needs to be entered twice, so that accidental wrong entries can be detected.

The "Outbound Proxy" defines where requests of this trunk will be sent. If this setting is set, it will always send requests to this other address. Otherwise, the dial plan replacement field will determine where the request is being sent.

The outbound proxy field follows the definitions of RFC 3263 ("Locating SIP Servers"). You may use the fully qualified domain name (FQDN) for a SIP server. If you add a colon with the port number after the FQDN, DNS A resolution will be used; otherwise, the PBX will try DNS NAPTR and DNS SRV first. You can force the SIP connection to use TCP by supplying an outbound proxy in the following format: sip:hostname:5060;transport=tcp

The outbound proxy is a important setting. If you don't use an outbound proxy then the PBX will assume that SIP requests on this trunk can come from any location. This will make it difficult for the PBX to match incoming SIP requests. Unless you want to receive requests from any location in the Internet, you should specify an outbound proxy.

The "CO-Lines" and "Dialog Permissions" settings are discussed separately in CO Lines.

If the "Codec Preference" setting is set, the PBX will use a different codec preference on this trunk. By default, the PBX has no specific codecs set specifically for that trunk and it will use the codec preference of the system. You will see no codecs selected on the left side of the codec selection box. This has the advantage that the PBX may negotiate codecs in such a way that transcoding can be avoided.

If you have to enforce specific codecs on a trunk, then you may add them with the "Add" button from the list of available codecs. They will be appended to the list of preferred codecs; so you should add the codec with the highest preference first. In order to delete a codec, click the "Remove" button. If you want to move a codec up or down in the preference list, use the "Up" and "Down" buttons.

According to the IETF standards, the registrar defines the duration of the registration. However, some providers follow the proposed duration of the trunk. Therefore, the PBX includes a "Proposed Duration" which is in seconds. One hour (3600 seconds) is a reasonable value here.

There are some providers that accept the proposed duration, but don't really take care about refreshing the NAT binding. In such a case what you can do is ignoring the service provider's registration duration and force the PBX to renew the registration in a shorter period of time. The setting "Keepalive Time" is used for that. However, this setting may cause a lot of traffic to your service provider, so don't make it shorter than necessary. Typically you can leave it blank.

If you register a trunk, it is quite important to know if a trunk looses the registration. For example, when your service provider goes offline, you would like to get an email about such an event. The PBX will send an email to the administrator account in case that the trunk changes the registration status ("Send email on status change").

The setting "Strict RTP Routing" is necessary, because the IETF allows that RTP traffic send ports may be different from RTP receiving ports. Because this is extremely NAT-unfriendly, today most implementations use the same port number for sending and receiving RTP. However, some gateways still insist on strict IETF compatibility. In this case you need to turn this setting on. Our recommendation is to keep this flag on "no" unless you really need to have asymmetrical ports.

If your registrar does not support UUID (RFC 4122), it usually ignores this unknown additional information. However, some SIP implementations are not able to deal with UUID. In this case, they will report a "Bad Request" to indicate that they were not able to process the request. We added the option "Avoid RFC4122 (UUID)" to explicitly suppress the UUID in REGISTER requests. The UUID is used to indicate that a registration replaces another registration; this is useful to avoid double registration after a restart of the system.

The setting "Accept redirect" is necessary if your trunk should respect redirect codes. By default, this introduces significant security risks, because the PBX cannot determine if these redirects introduce additional costs (redirection to expensive numbers). Therefore, you should turn this flag on only if you are sure that your service provider or SIP gateway does not abuse this feature. This flag is especially important when you use the PBX with Microsoft Exchange or other Microsoft products like the speech server. You should turn the flag also on when you have a trunk that comes from another or the same PBX in a server farm; this will make it possible to call from one domain to another.

When a call comes in, the PBX needs to know how to interpret the number. In SIP, the URI contain a domain name, which is part of comparisons for example for the address book. However, in most cases, the domain name should be ignored when interpreting the URI coming from this trunk (because the user part is just a telephone number). Usually this indicated with the parameter "user=phone", but there are some service providers that don't sent this flag. By turning the "Interpret SIP URI always as telephone number" you make the PBX believe that this flag was set on the trunk call.

When you are using a analog PSTN gateway (e.g. FXO), you will run into the problem of hangup detection. In FXO, the hangup signal might just be a tone that needs to be detected. Unfortunately, there is no international standard for the disconnect tone; even if you are located in a specific country, incoming international calls might give you a disconnect tone that the system has to recognize. Of course, if your PSTN gateway is capable of detecting this, you should leave this job to the PSTN gateway. As a fallback, you may also ask the PBX to perform the hangup detection. The disadvantage of having the PBX doing this is that it costs additional CPU resources and that you might randomly disconnect calls, for example if the other party is playing back a tone that just sounds like a busy tone. The best way to avoid these kind of problems is to use a digital line, e.g. a SIP trunk.

Outbound Settings

The settings "Prefix" and "Trunk DID" are used for the representation of the PBX when making an outbound call. This topic is covered in Outbound Calls on Trunk.

The "Global" flag is usually used when you have more than one domain. This flag tells the PBX that calls that come in on this trunk can jump into other domains if there is a match on a global alias name (tel:-alias). If the flag is off, the PBX does not search for tel:-alias names. If the flag is set to "on" and the driection is not only inbound, then other domains may use this trunk in their dial plans for outbound calls.

The setting "Remote Party/Privacy Indication" tells the PBX how to present the Caller-ID on the trunk. This setting is discussed in Outbound Calls on Trunk. Please note the "Remote Party/Privacy Indication" field in the latest version setting is default as "RFC3325 (P-Asserted-Identity)", you must change it to "No-Indication" instead.

When you are using a trunk, you might have to represent the telephone number is a specific format. For example, in the NANPA area, you might want to use 10 or 11 digits to represent a national number. If you are using several trunks, you can represent the same number in different styles depending on the trunk.

When the trunk receives an error code, it may send the call back to the dial plan and continue the matching process. The PBX continues the dial plan with the next higher priority; entries with a lower or same priority are not used. This is useful when this trunk is just a "trial" to place the call, for example when several PSTN gateways are available for terminating the call and one gateway does not accept any more calls. Another example is when you first try to route the call via a peer-to-peer call using ENUM or other location methods and only if such resolution does not result in a connection fall back to a PSTN call. The setting allows three behaviors:

• Never failover. That is the default behavior. In this case, the caller will receive the error code as the result of the call attempt.
• On all error codes. In this case, all error codes will trigger the failover process. Note that also call redirect will be treated as an error code, as the redirection destination can easily be abused to route calls though expensive routes.
• Only 5xx error codes. This will trigger failover only when a 5xx or 6xx class error code is being received. PSTN gateways typically return 5xx class error codes when all channels are in use, and using this mode you can switch to the next PSTN gateway only in this case, while a caller busy will not trigger the failover.

If you are using failover, you may also specify the "Request Timeout" value for the trunk. By default, this is 32 seconds (the SIP default request timeout). However in many cases it makes sense to specify a shorter value. After the request timeout, the PBX will internally generate a "408 Request Timeout" response code and process it according to the failover rules.

The "Is Secure" flag is available in the professional version and is used to indicate that outbound calls on this trunk can be treated as secure calls. For example, when the trunk goes to a local PSTN gateway you might decide to treat this call as a secure call. In the professional version, incoming calls with the sips scheme ask the PBX to ensure that the call should be kept secure end-to-end.

The "ICID" setting is used in the IMS environment. The setting is sent in the P-Charging-Vector header of the SIP packets on this trunk and it is essentially a token that identifies the trunk. If your provider uses this header, you should put it into this field.

Inbound Settings

The setting "Send call to extension" is discussed in the section Inbound Calls on Trunk.

The setting "Assume that call comes from user" is used for trunks that accept redirects (see above). The settings must be an extension in the domain of the trunk. This setting is necessary in order to determine what dial plan to use; and it is also necessary to charge a user on the system for the call. For regular trunks, you should leave this field empty.

The "Ringback" feature was introduced to deal with network operators that are obviously not able to deal with early media. Using the 180 Message simplifies the signaling in forking calls scenarios, however, it means additional delay when the called party picks the handset up and the first samples on the conversion may not be transported. We strongly recommend leaving the flag to the Media state, which is default and ask the operator to fix their problems with early media.

Many service providers today offer SIP termination services running over the Internet. This document tries to help you locating problems and gives advice on getting a stable connectivity. Please see also a PowerPoint presentation that we put together on this topic (http://www.pbxnsip.com/download/qos.ppt).

Troubleshooting SIP Trunk Problems

No Registration

If you can not register at all, check the following items:

• Is your password correct? Are you using the right authentication?

• Does your ISP support SIP? You can cross check easily by trying to register a soft phone (e.g. Xten from http://www.counterpath.com). If you can't register the soft phone, you will most probably also not be able to register a SIP trunk as well.

• If there is a firewall between the PBX and the registrar, it might be worth checking the traffic before and after the firewall. Some firewalls filter SIP traffic, and this can cause problems which are really hard to find.

Instable Registration

In some environments, the registration is not stable. Symptoms are that sometimes you can call in, while on other times you don't get through. This is typically caused by a too long refresh interval.

In such a case, you can override the refresh time in the setting "Keepalive Time" in the trunk settings. For example, try setting it to a value like 20 seconds.

There are still operators who believe that sending refresh traffic (white space, OPTIONS) from the ITSP to the PBX solves the problem. Because those keep-alive packets can get lost (e.g. when there is a lot of traffic on the line), this kind of service is unstable and extremly difficult to debug. Also, there are firewalls that do not accept outside-initated traffic as keep-alive traffic. Better set the registration time to something like 20 seconds.

If your internet connection is not stable, don’t be surprised that your registrations are also not stable. There are several tools available that monitor the quality of your internet connection. In case that you have trouble, we recommend that you start using such a tool.

One-way audio

One-way audio means that one party can hear the other, but is not heard. This is typically caused by the router/firewall that allows that the audio packets are sent to the service provider, but misinterprets the incoming traffic as attack.

Most service providers today deal with this topic my learning from what IP address and port they receive RTP packets. They simply send the traffic back to that destination and then two-way audio is established. If the PBX is run on public IP, it does the same trick to make VoIP phones work behind firewalls.

This usually works when routers are used that are not aware of SIP. Some routers try to “help out” and change the packets – which usually causes an even bigger chaos. If you see a flag that mentions SIP or UPnP you may try to turn this feature off and see if the voice stream passes the router without problems.

Especially more advanced firewalls offer serious SIP support. These firewalls would like to know if the data stream that they are relaying is audio data or there is a Trojan horse uploading valuable corporate data. Fortunately, their SIP support is usually better than on low-end devices and turning the SIP inspection on really increases your corporate security. If you are using such a firewall and experience problems, check if you are using the latest firmware and it is also worth a try to temporarily disable the SIP features to see if that changes anything.

There was a time when operators were trying to fix the problem by asking clients to use so-called “STUN” servers in the Internet. But because there are so many complex scenarios (and a lot of frustrating support), it seems that almost all of the service providers gave up on that approach and instead just to that RTP address learning trick. If your service provider insists that you must provide a routable IP address, the only serious advice is to get a (real) public IP address or change the service provider.

For more information, also check One-way Audio.

Bad Audio Quality

Bad audio typically means that the voice stream gets interrupted from time to time. This is a sign that you have some serious problems with the Internet connection. You can check the line quality for example by pinging a nearby location over a longer period of time and watch the delay in the answers. If there is a big jitter, you will probably hear that in the conversation.

• If you are sharing the line with other applications (like email and web), you must make sure that the quality of service (QoS, see Type of Service) is respected in both directions of the call. That means that you must make sure that all components that are between the PBX and the Internet line respect QoS.

• Also your service provider must respect QoS bits. If you get the Internet connection from the same service provider, it is usually relatively simple for him to provide that service for you. If you are running your traffic on a different service provider, it is usually difficult to get such a commitment from the service provider carrying the traffic.

• If you force a specific codec on a trunk, the PBX probably has to perform transcoding. While transcoding might help to save bandwidth (and this way reduce the risk of packet loss and delay), every transcoding reduces the audio quality. Especially when transcoding from one low-rate codec to another low-rate codec, the quality suffers significantly. Therefore forcing a specific codec on a trunk is always a trade off.

• Sometimes audio problems also just come from networking equipment that cannot deal with the packet load or is just running for too long. There were cases reported where a reset of the network switch solved problesm with the bad audio quality.

There are web sites that help you to find out how good your Internet connection works for SIP. For example, check out http://www.testyourvoip.com.

DTMF Not Working

DTMF is usually transported over out-of-band DTMF (RFC 2833). There are still some providers who believe that this is not necessary. But because RTP stream might loose packets, inband DTMF detection is an unnecessary burden and source for problems on the PBX. Make sure that your service provider supports DTMF according to RFC 2833.

A short-term workaround is to turn on inband DTMF detection (in Overall System Settings). However, this will cost more CPU power and it will be much more unstable than using RFC 2833.

Outbound Calls on Trunk

How to Present Caller-ID

When the PBX sends a call to a trunk, it has to present the source of the call. Usually the source of the call is the caller-ID of the calling extension; this source is the number that the called party should see in the display and this number is also the number that the carrier uses for billing purposes.

However in cases of redirected calls, things get more complicated. Here the original caller-ID should be in the display of the called party, while for billing purposes a local identity on the PBX must be used.

In many cases, local numbers (e.g. "sip:123@localhost") must be translated to a global telephone number (e.g. "sip:9781234567@itsp.com;user=phone"). The "user=phone" parameter indicates that the domain name should be ignored when presenting this number. This number is also referred to as an ANI (Answer Number Identification).

If you are using FXO gateway, things are different because of the physical nature of FXO. If you want to assign DID numbers for FXO, check out Assigning DID numbers for FXO.

Generating the ANI

When the PBX generates an outbound call on a trunk, it checks if the SIP URI in the To/From-Header and the identity headers (P-Preferred-Identity, P-Asserted-Identity or Remote-Party-ID) already have the user=phone flag. If that is the case, those numbers remain unchanged.

If they do not contain the flag, the PBX checks the following locations:

• If the local account has an ANI number set, it replaces this number. Every extension or any other account that has a dial plan also has an ANI number field, where this value can be set. By entering this information it is clear how this account will be presented to the outside world.

• If that ANI is not set, the PBX checks if there is a Prefix set in the trunk. If this is the case, it puts the prefix in front of the primary account number and uses that as ANI. This is very useful in cases when a trunk deals with a range of numbers (typical outside of the NANPA area, e.g. Europe). The "extension" number is just put behind the prefix.

• Otherwise, the PBX checks if the DID number has been set for this trunk. If this is the case, the PBX just uses this setting. This is a typical scenario in the NANPA area, where a trunk has a primary number associated with it. When someone calls this number, the caller will typically hit an auto attendant that processes this DID number.

Representing the Source

The PBX differentiates between two numbers that need to be presented on the trunk.

• The first number is the "display" number. This number is the number that the user should see on the display of the phone. In the case of a redirected call, this number would be the original caller-ID that the PBX saw on the incoming call.

• The second number is the "network" number. That number is the number that the provider wants to see for billing purposes.

Over the last couple of years, different providers developed different ways to represent the two numbers:

• RFC3325 describes a way to represent these two numbers. In most cases it makes sense to use the "P-Asserted-Identity" header. In this case, the "From" header in the INVITE represents the display number, while the "P-Asserted-Identity" header has the network number.

• A similar representation can be done with the "P-Preferred-Identity" header. The PBX only changes the name of the header from "P-Asserted-Identity" to "P-Preferred-Identity"; the rest stays the same like in the first method.

• "No Indication" just discards the display number and uses only the network number in the "From" header. This method is a fallback when the provider cannot deal with any other method. The disadvantage here is clearly that any redirection information gets lost.

• The "Remote-Party-ID" is described in a draft that expired years ago; however there is still a lot of equipment outside that is supporting this method. In this case, the "From" header in the INVITE represents the network number, while the "P-Asserted-Identity" header has the display number.

• The method "RFC3325, but don't hide" should not be used. It is used in environments where the fields got mixed up, which is causing even more confusion.

Inbound Calls on the trunk

How the PBX identifies the trunk

When a new call is requested from the PBX, it must find out if the call is being initiated from a known extension or from a trunk. It does this in the following way:

• If the Request-URI contains the line parameter, it is clear which trunk is called. The line parameter is set by the PBX when the trunk is registered. The support of the line parameter must be supported by RFC-compliant components. Most SIP devices today are RFC compliant, so that you usually do not have a problem if the parameter is present. However, for gateways and proxies this method is not possible, therefore the PBX must continue searching the trunk if the line parameter is not present.

• The PBX determines to which IP addresses and ports a trunk may send requests. This is done by a recursive DNS-resolution of the outbound proxy of that trunk. The outbound proxy is used as "inbound proxy" as well. The PBX then tries to find trunks with the following priority:
  • The incoming call matches a domain name of the trunk and a IP address and port of the outbound proxy of that trunk
  • The incoming call matches a domain name of the trunk and a IP address of the outbound proxy of that trunk
  • The incoming call matches a IP address and port of the outbound proxy of that trunk
  • The incoming call matches a IP address of the outbound proxy of that trunk
  • The incoming call matches a domain name of the trunk

The domain name "localhost" matches any domain name presented in the Request-URI, as usual.

If the From-header identifies a extension on the PBX, the trunk identification will be cancelled and the PBX assumes that the call comes from that extension, no matter if the extension is registered on the perceived IP address or not.

Please note that this way of "inbound proxy" is a kind of IP-based authentication of requests. If you are using UDP, there is a inherent risk that someone is spoofing the IP address of the PSTN gateway. In order to avoid this, you can use TCP or even TLS transport layer.

How the PBX identifies the extension

After the trunk has been identified, the PBX must determine where to send the call inside the domain. For this purpose, the PBX uses the setting "Extension" in the trunk. The PBX writes a log with the message "Trunk sends call to ..." into the log file (log level 5). There are two modes for this job. The simple mode just looks the extension up and the extended mode uses patterns to identify the destination.

Simple Mode

In the simple mode, the extension is just the user-part of the Request-URI. For example, if you want to send all calls on this trunk to a specific auto attendant, just put the name of the account into the extension setting.

If you set tel: alias to an account, you can easily set up the necessary information to map an extension to a DID. For example, an extension might have a primary name of "123" and an alias name of "tel:8124353423".

Extended Mode

In the extended mode, the extension setting must consist of the following four parts in the form <delimiter> <pattern> <delimiter> <replacement> [ <delimiter> [ <flag> [ <delimiter> [ <default> ]]]] (for example, ![0-9]{7}([0-9]{3})!\1!). The parts must be separated by any unique character which is not used elsewhere in the setting string (for example, an exclamation mark).

• The "pattern" is an extended regular expression which is matched against the user part of the Request-URI (or the To-header if you use the t flag below). This pattern uses the same mechanism as the dial plan.

• The "replacement" tells the PBX which extension to dial. It also uses the same mechanism as the dial plan. Typically it will reference matches from the pattern with \1.

• The flag tells the PBX weather to look into the Request-URI ("u") or into the To-header ("t"). The default is "u". Some Internet service providers provide the destination information in the To-header, although SIP recommends to use the Request-URI. Please note that you cannot just put two delimiters without anything in between, therefore if you want to specify a default you must use either the "u" or the "t".

• If the PBX cannot find the extension, you may specify a default extension. This extension must exist and it will be chosen in case that the replacement pattern does not produce an existing extension.

Please note that you may have more than one expression. The PBX will try to match the expressions until it finds a match. If no match is being found, the default extension of the last pattern will be used.

Locating Global Extensions

After the extension was identified, the PBX might find out that the extension is actually in a different domain that the trunk is. This can happen if the extension has a tel: name. In this case the call will be taken into the destination's extensions domain.

Examples

• The first example is common in Europe. You want to strip the main number of the PBX and use the remaining numbers to identify the extension. If the extension is not found, you send it to the auto attendant. The example assumes that the number starts with 7 digits (e.g. 0228123) and that the auto attendant is located at 100: "![0-9]{7}([0-9]*)!\1!t!100".

• The second example always uses the last 4 digits of the number, no matter how long it is: "!([0-9]{4}$)!\1!t!100". This example assumes that the number of digits is always the same.

• In a typical US office, you send all calls to an auto attendant. Then the value for the extension is very simple: Just use the string "100" if the auto attendant is located on account 100.

• If you are using tel: alias names for accounts, you can leave the Extension field just empty and just match the DID number to a tel: alias.

• To strip the first digit from a DID number, you can use the pattern "!1([0-9]*)!\1!u!100" (default destination would be 100).

ENUM

Purpose

ENUM (see for example http://en.wikipedia.org/wiki/ENUM) is used to locate a service in the Internet by using a telephone number. Typically, this service is voice communication.

There are several ENUM trees available in the Internet. Several countries started ENUM trials with numbers that are publicly available. Therefore, is makes sense to be able to use different ENUM trees apart from the official e164.arpa tree.

There are two problems that need to be addressed with ENUM:

• Inbound calls must be accepted from any location in the Internet. Things get tricky when the PBX is running more than one domain; then the PBX must locate the right domain. This problem does not only apply to ENUM calls; it applies to all calls that are not coming from a specific location in the Internet. For example, when outside parties are calling SIP URI the PBX faces the same problem.

• Outbound calls may go to any location in the Internet. Thanks to the support of DNS NAPTR and DNS SRV, that job is easy for the PBX. However, the dial plan must give a hint to the routing subsystem that the call should be routed using the ENUM rules.

The PBX supports ENUM by adding a special flag when resolving a SIP URI. If the parameter "enum" is set to "true" while routing a packet, the PBX will apply the RFC 2916 algorithm to the packet.

Setup

First, you need a trunk that is used for routing ENUM requests. This trunk should be a gateway trunk with no outbound proxy set. You may use other features like trunk failover as you like.

If you only want to accept incoming calls, but not use the trunk for outbound calls, then you may set the trunk to "inbound only". On the other hand, if you only want to place outbound calls, then you select "outbound only"; in this case the PBX will not accept any incoming traffic on this trunk.

In order to use this trunk, you need to make a entry into the dial plan. This dial plan must insert the enum parameter in the replacement URI. The domain name of the URI will be used for the ENUM root location. For example, you can use the string "sip:\1@e164.org;enum=true" in the replacement field. It will use the root domain "e164.org".

Example

In this example, you can see the log messages when dialling a number on an ENUM trunk:

[5] 2006/10/10 11:25:37: Dialplan: Match 9420222745121@localhost to <sip:420222745121@e164.arpa;enum=true> on trunk ENUM 
[8] 2006/10/10 11:25:37: Converting phone 420222745121 into 1.2.1.5.4.7.2.2.2.0.2.4.e164.arpa 
[8] 2006/10/10 11:25:37: Resolve destination 414: enum 1.2.1.5.4.7.2.2.2.0.2.4.e164.arpa 
[8] 2006/10/10 11:25:37: DNS: Add dns_naptr 1.2.1.5.4.7.2.2.2.0.2.4.e164.arpa 100 50 u E2U+sip !^.*$!sip:echo@nic.cz! (ttl=3600) 
[8] 2006/10/10 11:25:37: Resolve destination 414: enum 1.2.1.5.4.7.2.2.2.0.2.4.e164.arpa 
[8] 2006/10/10 11:25:37: Resolve destination 414: url sip:echo@nic.cz 
[8] 2006/10/10 11:25:37: Resolve destination 414: naptr nic.cz 
[8] 2006/10/10 11:25:37: DNS: Add dns_naptr nic.cz (ttl=3600) 
[8] 2006/10/10 11:25:37: Resolve destination 414: naptr nic.cz 
[8] 2006/10/10 11:25:37: Resolve destination 414: srv tls _sips._tcp.nic.cz 
[8] 2006/10/10 11:25:38: DNS: Add dns_srv _sips._tcp.nic.cz (ttl=3600) 
[8] 2006/10/10 11:25:38: Resolve destination 414: srv tls _sips._tcp.nic.cz 
[8] 2006/10/10 11:25:38: Resolve destination 414: srv tcp _sip._tcp.nic.cz 
[8] 2006/10/10 11:25:38: DNS: Add dns_srv _sip._tcp.nic.cz (ttl=3600) 
[8] 2006/10/10 11:25:38: Resolve destination 414: srv tcp _sip._tcp.nic.cz 
[8] 2006/10/10 11:25:38: Resolve destination 414: srv udp _sip._udp.nic.cz 
[8] 2006/10/10 11:25:38: DNS: Add dns_srv _sip._udp.nic.cz 100 100 sip.nic.cz 5060 (ttl=1800) 
[8] 2006/10/10 11:25:38: Resolve destination 414: srv udp _sip._udp.nic.cz 
[8] 2006/10/10 11:25:38: Resolve destination 414: a udp sip.nic.cz 5060 
[8] 2006/10/10 11:25:38: DNS: Add dns_a sip.nic.cz 217.31.204.193 (ttl=1800) 
[8] 2006/10/10 11:25:38: Resolve destination 414: a udp sip.nic.cz 5060 
[8] 2006/10/10 11:25:38: Resolve destination 414: udp 217.31.204.193 5060 
[8] 2006/10/10 11:25:38: Send Packet INVITE 
[6] 2006/10/10 11:25:38: SIP Tx udp:217.31.204.193:5060: