Current Publication | x
Close

Default Dial Plan 

The Polycom RealPresence DMA system is configured by default with a generic dial plan that covers many common call scenarios. The following table describes the default dial plan:

Default Rule Description

Effect

1Dial registered endpoints by alias

If the dial string is the alias or SIP URI of a registered endpoint, the call is routed to that endpoint.

2Dial by conference room ID

Otherwise, if the dial string is the dial-in number of a conference room on the Polycom RealPresence DMA system, the call is routed to that conference room.

3Dial to SIP conference factory

Otherwise, if the dial string is the dial-in number of a SIP conference factory, the call is routed to that SIP conference factory.

4Dial by virtual entry queue ID

Otherwise, if the dial string is the dial-in number of a virtual entry queue on the Polycom RealPresence DMA system, the call is routed to that VEQ.

5Dial to on-premises RealConnectTM conference

Otherwise, if the dial string is the dial-in number of a Skype for Business conference on the Skype AVMCU, the call is routed to an available Polycom MCU that supports Skype for Business and is automatically connected to the corresponding Skype conference on the AVMCU. (If no Polycom MCUs that support Skype for Business are available, the conference fails to start).
Note: This rule is disabled by default.

6Dial services by prefix

Otherwise, if the dial string begins with the configured prefix of a service (such as an MCU, ISDN gateway, SBC, neighbor gatekeeper, SIP peer proxy, or simplified ISDN dialing service) the call is routed to that service.
Note: For a SIP peer, the dial string must either include the protocol or consist of only the prefix and user name (no @domain). For instance, if the SIP peer’s prefix is 123, the dial string for a call to alice@polycom.com must be one of the following:

sip:123alice@polycom.com

123alice

7Dial external networks by H.323 URL, Email ID, or SIP URI

Otherwise, if the address is an external address, the call is routed to that external address (H.323 and SIP calls use the designated SBC for the originating site to reach addresses outside the enterprise network.
Examples of external addresses:

johnsmith@someothercompany.com sip:johnsmith@someothercompany.com

8Dial endpoints by IP address

Otherwise, if the address is an IP address, the call is routed to that IP address (H.323 calls use the designated SBC for the originating site to reach addresses outside the enterprise network).
Examples of IP addresses:

1.2.3.4
1.2.3.4##abc
sip:abc@1.2.3.4
sip:1.2.3.4@mycompany.com

9Dial to RealConnectTM conference by external Lync system conference ID

Otherwise, if the dial string is the dial-in number of a Lync or Skype conference on an external Lync or Skype system, the call is routed to an available Polycom MCU that supports RealConnectTM conferences for external Lync or Skype systems. (If no Polycom MCUs that support RealConnectTM conferences for external Lync or Skype systems are available, the conference fails to start).
Note: This rule is disabled by default, but is required if any external Lync or Skype systems are defined.

Suggestions for Modifying the Default Dial Plan

If you have special configuration needs and want to modify the default dial plan, be aware that some of the default dial rules are necessary for “normal” operation. Removing or modifying them takes the system out of compliance with ITU and IEEE standards.

Consider the following suggestions and guidelines if you modify the dial plan:

Polycom recommends ordering dial rules so that the rule with the action Resolve to external SIP peer appears last in the list. If a dial rule with the action Resolve to external SIP peer doesn’t successfully route a call, the call is aborted and no subsequent dial rules will be attempted. Polycom also recommends that this rule not appear higher than its default order in the list of dial rules, because this can prevent valid aliases, VMRs, and VEQs from being dialed and can result in reduced system performance.

To add an MCU, ISDN gateway, SBC, neighbor gatekeeper, SIP peer, or simplified dialing service that can be dialed by prefix, configure the prefix range of the new service on the appropriate page. No dial plan change is necessary, since the rule Dial services by prefix of the default dial plan takes care of dialing by prefix.

You can remove or disable a default dial rule if you don't want the associated functionality.

Note that the rule Dial endpoints by IP address is used in several scenarios where calls are received from neighbor gatekeepers or SBCs. Removing it breaks these scenarios.

If certain dial strings are matching on the wrong dial rule, you may need to re-order the rules.

In some circumstances (depending on the dial plan and the network topology and configuration), dial rules using the Resolve to external address action or the Resolve to IP address action can enable dialing loops to develop, especially if servers reference each other either directly or via DNS. Common ways to avoid dialing loops include:

ØUse domain restrictions to ensure that the RealPresence DMA system and its peers are each responsible for specific domains.

ØUse a preliminary script like the sample script “SUBSTITUTE DOMAIN (SIP)” (see Sample Preliminary and Postliminary Scripts) to change the domain of a SIP URI dial string to something that will not create a dialing loop.

ØUse a postliminary script to similarly change the domain before sending to a peer.

ØUse configuration options on the peers to prevent loops.

ØCreate a dial rule that uses the Block action and a preliminary script to enhance the system’s ability to prevent dialing loops for specific types of calls. The preliminary script ensures that the dial rule only matches the types of calls you want to block. This dial rule should be ordered after other dial rules that are expected to resolve the intended call requests.

For example, a dial rule with the Block action using the following preliminary script blocks all call requests that use a prefix of “44” if they have not been resolved by previous dial rules:

println("DIAL_STRING=" + DIAL_STRING);

var prefix='44'

var re = RegExp('^(sip:|sips:|h323:|tel:)?'+ prefix +'.*')

if(! DIAL_STRING.match(re))

{

  println("NEXT_RULE");

  return NEXT_RULE;

}

println("ACCEPT and terminate 44 prefix calls if they were not resolved by previous dial rules"); 

You can add a filtering preliminary script to any dial rule to restrict the behavior of that rule.

For example, if you know that all the aliases of a specific neighbor gatekeeper are exactly ten digits long, you may want to route calls to that gatekeeper only if the dial string begins with a certain prefix followed by exactly ten digits.

To accomplish this, add a preliminary script to the service prefix dial rule that rejects all dial strings that begin with the prefix, but aren’t followed by exactly ten digits.

To exclude certain dial strings, combine a filtering preliminary script with the Block action.

You can use a preliminary script to modify the dial strings accepted by any of the rules.

For example, to be able to call an enterprise partner by dialing the prefix 7 followed by an alias in the partner’s namespace, configure a Resolve to external at transforms the string 7xxxx to xxxx@enterprisepartner.com.

This type of dial string modification is also useful if you are using Skype for Business conference dial strings with prefixes. To route a dial string with a prefix to a Skype conference ID, configure a Resolve to Skype conference ID action with a preliminary script that removes the prefix from the dial string (1234567 would become 4567, for example).

If your enterprise includes another gatekeeper and you want to route calls to that gatekeeper without a prefix, add a dial rule using the Resolve to external gatekeeper action.

If your enterprise includes a SIP peer and you want to route calls to that peer without a prefix, add a dial rule using the Resolve to external SIP peer action.

If you have multiple SIP peers, a call matching the rule is routed to the first one to answer. You may want to specify the domain(s) for which each is responsible.

When routing to a SIP peer, the Polycom RealPresence DMA system gives up its ability to route the call to other locations if the peer rejects the call. Consequently, a dial rule using the Resolve to external SIP peer action should generally be the last rule in the dial plan.

In a mixed H.323 and SIP environment, the Polycom RealPresence DMA system acts as a seamless gateway. If an H.323 device sends it a Location Request (LRQ) and the dial plan contains a dial rule using the Resolve to external SIP peer action, the RealPresence DMA system will respond with a Location Confirm (LCF) because it can resolve the address by routing the H.323 call through its gateway to the SIP peer(s). You can prevent H.323 calls from being routed to SIP peers by restricting which calls are routed to them in one or more of the following ways:

ØAssign each SIP peer an authorized domain or domains (this is a good idea in any case in order to avoid dialing loops).

ØAssign each SIP peer a prefix or prefix range.

ØAdd a preliminary script to the dial rule using the Resolve to external SIP peer action that ensures that the rule will only match a SIP address.

ØMake the dial rule using the Resolve to external SIP peer action the last rule and ensure that all H.323 calls will match against one of the preceding dial rules.

Related Topics

Machine Translation

You are cautioned that the translation of this document is generated by a machine; therefore, the translated document may have errors and be inconsistent with the original English language version of the document.

The English language version of this document shall be considered the governing document related to the Polycom product.

If there is any contradiction between the English language version of the document and the translated version of the document, the English language version of the document shall take precedence.

The translation is provided for your convenience only. Neither Google nor Polycom shall be responsible for translated content or for the performance of the translation tool. If you require further assistance on non-translation issues, please contact Polycom support.

Translated documents are not available in PDF format.