Call Server Configuration

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 Add External SIP Peer Dialog).

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 Edit External SIP Peer Dialog.

Assign each SIP peer a prefix or prefix range. See Edit External SIP Peer Dialog.

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 Preliminary/Postliminary Scripting.

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.

245

Page 245
Image 245
Polycom 7000 manual H323xxxx@enterprisepartner.com