Table of Contents
Advertisement
● 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
H323:xxxx@enterprisepartner.com.
This type of dial string modification is also useful if you are using Lync conference dial strings with
prefixes. To route a dial string with a prefix to a Lync conference ID, configure a Resolve to Lync
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 (see
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.
Note: SIP<->H.323 gateway considerations
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). See
•
Assign each SIP peer a prefix or prefix range. See
•
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. See
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.
See also:
Dial Rules
Edit Dial Rule Dialog
Preliminary/Postliminary Scripting
Polycom, Inc.
Edit External SIP Peer
Dialog.
Preliminary/Postliminary
Call Server Configuration
Add External SIP Peer
Edit External SIP Peer
Dialog.
Scripting.
Dialog).
245
Advertisement
Table of Contents
