Author Topic: ARS digits dialed sharing  (Read 4665 times)

Offline phiphi

  • Contributer
  • *
  • Posts: 13
  • Country: fr
  • Karma: +0/-0
    • View Profile
ARS digits dialed sharing
« on: June 20, 2016, 05:25:11 AM »
Hi everyone,

Infrastructure :
- One IP-PBX we will named it IPPBX A (ICP/PBX Number 501)
- One IP-PBX we will named it IPPBX B (ICP/PBX Number 502)

I have succeed sharing my two IP-PBX, but only by removing two necessary ARS digits dialed rules.

The two rules are :
IPPBX A has an ARS digits dialed "*502"
IPPBX B has an ARS digits dialed "*501"

As far as I know, these two rules are helping the two IP-PBX. For example, if I am using an IP phone connected on the IP-PBX A and wanting to call someone connected to the IP-PBX B as the IP-PBX A checking if the number is in its registry/database if not calling all next IP-PBX for checking/calling.
The fact is for sharing the two IP-PBX, I have to add in the IP-PBX A an ARS digits dialed pointed directly to itself and the same for the IP-PBX B but not possible because an issue occurred saying the ARS digits dialed already exist. So I have remove these two rules and sharing the ARS digits dialed sharing but doing the test by calling someone from IP-PBX A to IP-PBX B is not working, because the two rules are not added.

Instead of not doing an ARS digits dialed sharing nor adding the database of the IP-PBX B into the IP-PBX A with the specific ARS route (hardly manageable for a sys/network administrator), have you a solution for this issue ?
I can also give more information/explanation.

Many thanks.

Best Regards


Online ralph

  • Mitel Forums Admin
  • Hero Member
  • *****
  • Posts: 5768
  • Country: us
  • Karma: +469/-0
  • Published Author: http://amzn.to/2dcYSY5
    • View Profile
Re: ARS digits dialed sharing
« Reply #1 on: June 20, 2016, 07:58:18 AM »
If your two systems are clustered then you don't need to set up ARS for each extension.
You need to set up ARS for the PBX number found in the cluster element form.

Ralph

Offline phiphi

  • Contributer
  • *
  • Posts: 13
  • Country: fr
  • Karma: +0/-0
    • View Profile
Re: ARS digits dialed sharing
« Reply #2 on: June 20, 2016, 08:36:04 AM »
Hi Ralph,

Thanks for your answer.

The two Mitel system are clustered :
School A (IP-PBX A 501, IP-PBX B 502)
School B (IP-PBX A 501, IP-PBX B 502)

Maybe I was unclear in my explanation, for all external phone number I have add ARS route but for internal number I have use these two rules :
IP-PBX A ARS digits dialed "*502" pointing to IP-PBX B
IP-PBX B ARS digits dialed "*501" pointing to IP-PBX A
To avoid to add ARS route for each intern phone number.

But I have tried to add an ARS digits dialed "*501" pointing to IP-PBX A in the IP-PBX A itself but does not work because "The digits already exist".

Without these two ARS digits dialed added into the two systems, I can't do an ARS digits dialed form sharing.

Thanks !!!!!

Waiting for your answer.

Online ralph

  • Mitel Forums Admin
  • Hero Member
  • *****
  • Posts: 5768
  • Country: us
  • Karma: +469/-0
  • Published Author: http://amzn.to/2dcYSY5
    • View Profile
Re: ARS digits dialed sharing
« Reply #3 on: June 20, 2016, 09:03:07 AM »
Do you know where *50X exist now?

Try the maintenance command "Locate Number *501" and see what you get.

Ralph

Offline phiphi

  • Contributer
  • *
  • Posts: 13
  • Country: fr
  • Karma: +0/-0
    • View Profile
Re: ARS digits dialed sharing
« Reply #4 on: June 20, 2016, 10:14:57 AM »
Hi Ralph,

Here is the system response from the IP-PBX A:
LOCATE NUMBER *501
The number is a local cluster element identifier.

LOCATE NUMBER *502
The number is not use. (because I remove this ARS digits dialed from the IP-PBX A)


Here is the system response from the IP-PBX B:
LOCATE NUMBER *501
The number is not use. (because I remove this ARS digits dialed from the IP-PBX B)

LOCATE NUMBER *502
The number is a local cluster element identifier.

What I know, maybe it will help you :
- The ARS digits dialed for *501 and *502 are rules using directly cluster number

Because of it, I can't write a rule *501 directly in the IP-PBX A as it pointing to itself
The only way to remove it is by using this method (from the Mitel edoc):
"If the system displays the error message "The associated cluster element digits should be deleted first", complete the following steps to delete the ARS entry:

In the Cluster Elements form, temporarily change the Local Cluster Element ID Digits to a different digit string.

Delete the ARS entry from this form.

Change the Local Cluster Element ID Digits in the Cluster Elements form back to the original value."

 
Feel free to ask any questions/details for helping you to understand my problem.

Thanks.

Best Regards,

Offline phiphi

  • Contributer
  • *
  • Posts: 13
  • Country: fr
  • Karma: +0/-0
    • View Profile
Re: ARS digits dialed sharing
« Reply #5 on: June 23, 2016, 05:44:29 AM »
Hi,

Maybe it's too complex, I will ask my question more clearer.

Is it a way to add in one IP-PBX, an ARS Digits Dialed looking as *cluster_number to itself ?
For example, in my IP-PBX A with its cluster number is 501 and I wonder if it's a way to add in itself an ARS Digits Dialed as *501.

I know this ARS Digits Diales rule is to avoid to add manually each number of another IP-PBX, but looking for a way like a loopback rule or anything.

Feel free to ask any details.

Thanks.

Offline johnp

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 2209
  • Country: us
  • Karma: +67/-0
    • View Profile
Re: ARS digits dialed sharing
« Reply #6 on: June 23, 2016, 07:43:22 PM »
Think you may be missing how remote numbers work. If clustered all you need is the ceid in ars to point to the correct element. Direct IP Route would likely do the trick.

Offline phiphi

  • Contributer
  • *
  • Posts: 13
  • Country: fr
  • Karma: +0/-0
    • View Profile
Re: ARS digits dialed sharing
« Reply #7 on: June 24, 2016, 11:58:45 AM »
Hi Johnp,

Thanks for your answer.

The fact is I already use this method as IP-PBX A with a CEID at 501 can't have an ARS Digits Dialed entry like *501 because its pointing on itself so no possible.

No sure if is a way to bypass this or do an ARS Digits Dialed sharing without entry like *CEID entry.

Thanks.

Offline johnkeri

  • Jr. Member
  • **
  • Posts: 56
  • Country: ca
  • Karma: +2/-0
    • View Profile
Re: ARS digits dialed sharing
« Reply #8 on: June 24, 2016, 01:41:26 PM »
Too many fields.
Cluster definition form:
- PBX number is just a PBX number and you can not use the same twice in a cluster
not to be confused with
- Cluster Element ID Digits: this is a dial number to reach the specific system, not to conflict with any other dial number such as ARS or extension numbers, Feature access codes . . .
- Feature DN: used to access features on specific controller by background processes, some features will not work without this, and is shall not conflict with other Dial numbers, similar to other FAC

When you assign the CeID Digits a warning will pop for ARS configuration you must do.
- program either IP Trunks in the IP/XNET section or in newer release just use Direct IP route medium
Direct IP makes routing based on the RDN (Remote Directory Number) list.
- looks up the number and the system it belongs to, then searches the CeID digits of that system in ARS and sends the call to the PBX specified in the route (not necessarily the same one)

If you want to create a loop-back pick another than the local CeID number for ARS, whatever you want to loop, and send it to a route pointing to the local system.
- blocking the local CeID digits in ARS digits dialed is intentional: it would create a dialing loop and bring down the system

PS: The local loop is used in advanced emergency call handling, review documentation for more details.

Offline johnp

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 2209
  • Country: us
  • Karma: +67/-0
    • View Profile
Re: ARS digits dialed sharing
« Reply #9 on: June 26, 2016, 04:46:26 PM »
FWIW I have never shared this form. I will export and import parts across systems that my reside in the same area, but I think there are enough things local that need special handling that precludes such sharing.

Offline phiphi

  • Contributer
  • *
  • Posts: 13
  • Country: fr
  • Karma: +0/-0
    • View Profile
Re: ARS digits dialed sharing
« Reply #10 on: June 27, 2016, 08:07:52 AM »
Hi,

Thanks you two.

I will analyse your answers and give feedback.

Thanks.

Best Regards,

Offline phiphi

  • Contributer
  • *
  • Posts: 13
  • Country: fr
  • Karma: +0/-0
    • View Profile
Re: ARS digits dialed sharing
« Reply #11 on: June 28, 2016, 11:44:44 AM »
Hi all,

After analyzing the two answers.

If I am right, an ARS entry like *PBX_Number is what I have, but why do I need an ARS entry like *501 or *502 (*PBX_number) if the remote DN is already shared ?

I also understand about the loopback using CEID value can bring down the system but it seems the same for using *pbx_number. Have you a solution to avoid to add ARS Digits dlaled entry like *501 and *502 (as the remote DN is already shared)?

Thanks.

Best Regards,

Offline johnkeri

  • Jr. Member
  • **
  • Posts: 56
  • Country: ca
  • Karma: +2/-0
    • View Profile
Re: ARS digits dialed sharing
« Reply #12 on: June 28, 2016, 01:27:15 PM »
Not sure if I understand your question correctly, no criticism intended.

There is only one ARS entry per system is necessary, that is for the CeID Digits of the destination systems.
- in some sense you are correct, the software could generate that entry, but the routing medium (either IP/XNET or Direct IP) must be assigned in a route first, and that is your choice

The simplest example, assuming that your systems are in an SDS cluster and sharing is established and working.
The RDN form includes the remote numbers and their hosting system.

As part of the cluster configuration you must complete the ICP/PBX Networking form under Trunks - IP/XNET.
- ensure the 'Local" system assignment is correct (Yes)
- the second tab, IP Networking must have the correct IP addresses (also used/required for resiliency)
- the third tab, unless you are really setting up ISDN must be blank
Completion of the rest of the IP/XNET forms is required for systems with no Direct IP route option.
- older software loads
IP/XNET can also be used for inter-cluster call routing for sharing PSTN trunks.

To reach those RDN numbers program a route using Direct IP with the PBX number of the destination system.
- in complex scenarios it might won't be a direct route to the destination system. it could be an intermediary that will reach the final destination interpreting the call by it's own ARS
Assign the destination system's CeID number in ARS digits dialed and point it to the route above.
- the number of digits to follow can be fixed and can act as a safety barrier or set to Unknown
- !! Do not set to anything else !! - the system will wait for the specified exact number of digits

Done! Dial the remote extensions in the destination system.


Online ralph

  • Mitel Forums Admin
  • Hero Member
  • *****
  • Posts: 5768
  • Country: us
  • Karma: +469/-0
  • Published Author: http://amzn.to/2dcYSY5
    • View Profile
Re: ARS digits dialed sharing
« Reply #13 on: June 28, 2016, 01:28:54 PM »
If  your ARS Digits Dialed looks something like:
*501  4digits to follow Or (Unknown)
Then you're stuck.
This is how a PBX cluster knows how to route numbers between systems and you probably shouldn't be trying to change it at this point.

You'll have to find some other digit string to use for your application.  (Maybe #501)

Ralph

Offline johnkeri

  • Jr. Member
  • **
  • Posts: 56
  • Country: ca
  • Karma: +2/-0
    • View Profile
Re: ARS digits dialed sharing
« Reply #14 on: June 28, 2016, 02:12:22 PM »
Sorry, I missed the point. Was concentrating on ARS, but your question is about SDS.

You can share the ARS digits dialed form, but be very careful with the route assignments.
The real answer to your question is in the SDS Form sharing exception list.
- exclude the CeID digit strings from the sharing scope
The rest of the digit strings like outside access will be shared and work just fine.
- one dangerous aspect of this is during troubleshooting, you change the destination route in one system and if lucky it will not update the other ones, just generate SDS errors


 

Sitemap 1 2 3 4 5 6 7 8 9 10