September 12, 2011 at 14:36Avaya Definty feat. IP Office 500
Classical telephony has always scared me. It’s like some kind of secret knowledge. It is transmitted only by word of mouth, from teacher to student. And despite all attempts to stay away from her, by the will of fate, I threw my whole body at the embrasure of the ATS, E1, and other CO trunks there.
Before I wrote about setting up IP Office 500 PBXs . Since then, many time slots have been freed up and a new task has arisen before me: to configure a trunk between two PBXs (Definity and IP Office) and make city calls through this transit possible.
Interested in secret knowledge, I ask
Avaya Definity PBX to be our old guest with a good hundred rooms for three holding organizations. Until now, I managed to get off only by adding new extension numbers and changing the order of the call.
The PBX was connected through a composite channel with two Ethernet-E1 conversions. In addition to the complex setup of such a connection and opaque logic, this caused a number of difficulties and problems.
1) A very long time waiting for a connection with the subscriber.
2) The presence of only 12 time slots in the stream and, accordingly, only 12 possible simultaneous calls. This is due to the characteristics of the cisco transit router.
3) When the channel falls, in addition to the local network, telephony also ceases to work.
4) Complex debugging process and a large number of failure nodes.
But not so long ago it was required to purchase IP Office for another organization, and for financial and technical reasons it was decided to connect it with a trunk to Definity. In addition, this makes it possible to hypothetically set up a single numbering plan for all holding organizations.
At the same time, it was decided to switch this PBX but a new flow, and leave the old transit only for local telephony.
So, the final scheme will look like this:
And the setup will actually be done from scratch. So let's go this way together, colleagues?
Let's start by connecting to the operator.
The first thing we need to do is put the E1 boards in the Definity PBX. It supports hot swapping, so that by checking the position of the dip switches, you can safely stick them into a working station.
Dip switch two. One of them we indicate the type of physical line: coaxial or twisted pair. As a rule, this is still twisted pair and therefore choose 120 Ohms.
The second indicates the standard of operation of E1 / T1, respectively 32/24 channel. Of course, Russia uses E1 - 32 channels.
We take two streams from the operator, respectively, 2 boards are needed. Immediately after the boards took up space in their slots through the Avaya Terminal Emulator, using the #list conf all command, you can verify that the PBX saw them:
At this point, you can make a physical connection. No matter what the board costs: digital or analog ports on 24 lines, E1 with four wires or Ethernet, the connector is universal: 50-pin. I call it Amphenol, although I’m not sure that this term does not only mean a telephone jack.
For E1, a pair of 23.48 is used for transmission and 22.47 for reception. This can easily be verified by connecting the LED to the Tx transmission pairs. It is necessary to connect the operator’s transmission to our reception and vice versa: our transmission to their reception.
The next step is to add the ds1 interface.
#add ds1 xxx with the following parameters
xxx is the board number, in our case it is 01b06 You
may need to run #ch sync if you are setting up the PBX for the first time.
Since we are connecting to the operator, then most likely the network parameter should be specified in the Connect parameter . In general, you should, of course, find out all these parameters from the operator.
If everything is done correctly at this stage, then the #test board xxx command , where xxx is the board number, should return PASS for all tests. FAIL on test 138 means no reception signal.
As you know, the 16th time slot E1 is used for signaling, so the next step is to configure the signal group.
#add sig next
The last two digits of the Primary D-Channel are the time slot number in the stream.
Avaya here does not require you to specify the trunk group number (especially since we don’t have it yet). But it’s better to do this in order to avoid various problems ( Trunk Group for Channel Selection parameter ). We
check the status of the signal group with the following commands.
#test sig x
Tests should return PASS or ABORT . ABORT is not a sign of a problem, but only indicates the inapplicability of this test. If the result of the FAIL test is very likely to say that it’s the Connect settings - for example, Network or Line-side is on both stations
#Status sig x The
signal group must have the statusin-service
Now everything is ready to set up a trunk group, which will be used to transfer calls.
But first you need to check your numbering plan. It must be given the number dac.
#disp dial
In our case, this is a number starting with 7 and consisting of 3 digits.
This number should be indicated on the first page of the command #add trunk next
Important parameters are underlined
Starting from the 4th page, time slots used in the trunk are indicated here. This is a fairly flexible mechanism: it is possible to make several trunks in one thread by breaking the stream, or you can combine several streams into one trunk. We have just the second case, since up to 50 simultaneous calls are possible. Therefore, in one trunk group I add all 60 time slots of two E1 streams, with the exception of service 16 and 32.
So, now we already have a full-fledged connection with the operator, it remains to receive city numbers from him, as well as indicate how our extension numbers will call the city.
Let's start with the outgoing numbers.
Here is what we need to do for this.
First, create a route-pattern . With it, we will set where and by what rules the call will be redirected.
Since connecting to the operator, this is actually the “default” route for our calls, we won’t be
tricky : Now, let's touch on a very important configuration item: ARS routing algorithm - Automatic Route Selection.
It is configured by two commands: #ch ars analisys and #ch ars digit .
In my case, the output of the #ch ars analisys command looks like this:
In essence, this means that all calls with called numbers that meet the following patterns must be sent to route-pattern 2, which is trunk group 4, as we configured above.
The #ch isdn public command will help you configure the rules for matching internal numbers with city numbers, in other words, AON.
This entry means that for all three-digit internal numbers starting with 1, the city number will be 2390013 and this will be sent to trunk group 4, and for number 102 there will be a separate number 2390012
Actually, the numbers are six-digit and “2” is indicated here because in this format, the operator expects the number, it should also be clarified in advance with representatives.
If you specify an invalid number or an incorrect trunk group here, the call will be rejected.
If the PBX is configured for the first time, then you must also specify in the numbering plan an access code to the routing algorithm. This is usually "9". Yes, yes, this is the very “nine” that you constantly have to type if you use a PBX.
Actually, these settings will already be enough to make an outgoing call.
With incoming numbers a little more complicated.
The first thing to do is set in the settings of the trunk group that the prefix "9 *" is added to the number of the dialed phone (namely the city). That is, someone dialed number 390045, along the operator’s routes, this number comes to our PBX in trunk group number 4, but here it is indicated that you need to add the characters “9 *” to the number. "9" indicates that the call must be sent to the routing algorithm. We will configure the routing rule a bit later.
This is done on the third page of the #ch trunk.
In the configuration of the trunk group, you can specify that this happens with all incoming messages, or you can specify specific number templates, as I have done (six-digit numbers starting at 390, 396, 680).
Next, we configure the routing algorithm for incoming calls. This is done with the command #ch ars digit
First, the “*” is not forgotten, then we indicate that from 7 characters of the number we delete all 7 and insert 3 digits of the internal number and send it immediately to extention, that is, the phone. As a result, it turns out that the call that came to number 390013 is redirected to the internal 110.
Now you can make incoming calls.
Well, it remains to learn how to pass calls through the trunk group to IPO500.
Physically connected, everything is very simple. The pairs on Definity are the same; on the IPO, these are the 9th and / or 10th ports of 1.2-4.5. Of course, we connect the reception to the transmission.
Until the routing is set up, everything is done in the same way, with amendments to the board number, the number of time slots and serial numbers of the parameters. It is necessary to point out only one difference: in the DS1 settings we specify not network , but line-side .
You can find out how the IPO is configured from my previous article , I’ll only give a screenshot of the setup page:
If everything is configured correctly, the indicator on the E1 board in Definity should turn yellow and turn green on IP Office:
In addition, we will immediately configure incoming calls for IPO :
And outgoing . Here, again, remember that the number must be specified in the format in which the operator is waiting for it.
These settings on IP Office are sufficient.
Since we now have several trunks, we need to come up with some identifier for the new trunk, which will simultaneously be a prefix for city numbers, which determines which route-pattern it should be inserted into. Take, for example, the prefix "10". That is, the call arriving at 680053 will be processed by the routing algorithm and the number will be changed to 10680053.
Naturally, you need to add a new route-pattern, in which we configure a new trunk group, as well as delete two characters - the same prefix so that the number reaches the IPO virgin clean.
With the next Makar, we will add a prefix and process the call:
Voila:
Now I’ll say that I rested my forehead on and broke more than one spear.
After all the settings, outgoing calls did not work. On Definity tracks, nothing was visible on this trunk. Tracing on IP Office shows that the call goes to the 1st line with Outgoing Group ID 701, but “Cause = 34, No cct / chan available” comes in response, which means there are no free channels for the call. Long, long, unsuccessful debugging, but only a friend’s advice helped. It turns out, returning to what I said at the beginning of the article, you need to configure the trunk group number in the signal group. That was the whole problem. The situation was complicated by the fact that for other trunks configured on the PBX, this parameter was not specified.
For sim end. Download link
Before I wrote about setting up IP Office 500 PBXs . Since then, many time slots have been freed up and a new task has arisen before me: to configure a trunk between two PBXs (Definity and IP Office) and make city calls through this transit possible.
Interested in secret knowledge, I ask
Avaya Definity PBX to be our old guest with a good hundred rooms for three holding organizations. Until now, I managed to get off only by adding new extension numbers and changing the order of the call.
The PBX was connected through a composite channel with two Ethernet-E1 conversions. In addition to the complex setup of such a connection and opaque logic, this caused a number of difficulties and problems.
1) A very long time waiting for a connection with the subscriber.
2) The presence of only 12 time slots in the stream and, accordingly, only 12 possible simultaneous calls. This is due to the characteristics of the cisco transit router.
3) When the channel falls, in addition to the local network, telephony also ceases to work.
4) Complex debugging process and a large number of failure nodes.
But not so long ago it was required to purchase IP Office for another organization, and for financial and technical reasons it was decided to connect it with a trunk to Definity. In addition, this makes it possible to hypothetically set up a single numbering plan for all holding organizations.
At the same time, it was decided to switch this PBX but a new flow, and leave the old transit only for local telephony.
So, the final scheme will look like this:
And the setup will actually be done from scratch. So let's go this way together, colleagues?
I
Let's start by connecting to the operator.
The first thing we need to do is put the E1 boards in the Definity PBX. It supports hot swapping, so that by checking the position of the dip switches, you can safely stick them into a working station.
Dip switch two. One of them we indicate the type of physical line: coaxial or twisted pair. As a rule, this is still twisted pair and therefore choose 120 Ohms.
The second indicates the standard of operation of E1 / T1, respectively 32/24 channel. Of course, Russia uses E1 - 32 channels.
We take two streams from the operator, respectively, 2 boards are needed. Immediately after the boards took up space in their slots through the Avaya Terminal Emulator, using the #list conf all command, you can verify that the PBX saw them:
At this point, you can make a physical connection. No matter what the board costs: digital or analog ports on 24 lines, E1 with four wires or Ethernet, the connector is universal: 50-pin. I call it Amphenol, although I’m not sure that this term does not only mean a telephone jack.
For E1, a pair of 23.48 is used for transmission and 22.47 for reception. This can easily be verified by connecting the LED to the Tx transmission pairs. It is necessary to connect the operator’s transmission to our reception and vice versa: our transmission to their reception.
The next step is to add the ds1 interface.
#add ds1 xxx with the following parameters
xxx is the board number, in our case it is 01b06 You
may need to run #ch sync if you are setting up the PBX for the first time.
Since we are connecting to the operator, then most likely the network parameter should be specified in the Connect parameter . In general, you should, of course, find out all these parameters from the operator.
If everything is done correctly at this stage, then the #test board xxx command , where xxx is the board number, should return PASS for all tests. FAIL on test 138 means no reception signal.
As you know, the 16th time slot E1 is used for signaling, so the next step is to configure the signal group.
#add sig next
The last two digits of the Primary D-Channel are the time slot number in the stream.
Avaya here does not require you to specify the trunk group number (especially since we don’t have it yet). But it’s better to do this in order to avoid various problems ( Trunk Group for Channel Selection parameter ). We
check the status of the signal group with the following commands.
#test sig x
Tests should return PASS or ABORT . ABORT is not a sign of a problem, but only indicates the inapplicability of this test. If the result of the FAIL test is very likely to say that it’s the Connect settings - for example, Network or Line-side is on both stations
#Status sig x The
signal group must have the statusin-service
Now everything is ready to set up a trunk group, which will be used to transfer calls.
But first you need to check your numbering plan. It must be given the number dac.
#disp dial
In our case, this is a number starting with 7 and consisting of 3 digits.
This number should be indicated on the first page of the command #add trunk next
Important parameters are underlined
Starting from the 4th page, time slots used in the trunk are indicated here. This is a fairly flexible mechanism: it is possible to make several trunks in one thread by breaking the stream, or you can combine several streams into one trunk. We have just the second case, since up to 50 simultaneous calls are possible. Therefore, in one trunk group I add all 60 time slots of two E1 streams, with the exception of service 16 and 32.
So, now we already have a full-fledged connection with the operator, it remains to receive city numbers from him, as well as indicate how our extension numbers will call the city.
II
Let's start with the outgoing numbers.
Here is what we need to do for this.
First, create a route-pattern . With it, we will set where and by what rules the call will be redirected.
Since connecting to the operator, this is actually the “default” route for our calls, we won’t be
tricky : Now, let's touch on a very important configuration item: ARS routing algorithm - Automatic Route Selection.
It is configured by two commands: #ch ars analisys and #ch ars digit .
In my case, the output of the #ch ars analisys command looks like this:
In essence, this means that all calls with called numbers that meet the following patterns must be sent to route-pattern 2, which is trunk group 4, as we configured above.
The #ch isdn public command will help you configure the rules for matching internal numbers with city numbers, in other words, AON.
This entry means that for all three-digit internal numbers starting with 1, the city number will be 2390013 and this will be sent to trunk group 4, and for number 102 there will be a separate number 2390012
Actually, the numbers are six-digit and “2” is indicated here because in this format, the operator expects the number, it should also be clarified in advance with representatives.
If you specify an invalid number or an incorrect trunk group here, the call will be rejected.
If the PBX is configured for the first time, then you must also specify in the numbering plan an access code to the routing algorithm. This is usually "9". Yes, yes, this is the very “nine” that you constantly have to type if you use a PBX.
Actually, these settings will already be enough to make an outgoing call.
III
With incoming numbers a little more complicated.
The first thing to do is set in the settings of the trunk group that the prefix "9 *" is added to the number of the dialed phone (namely the city). That is, someone dialed number 390045, along the operator’s routes, this number comes to our PBX in trunk group number 4, but here it is indicated that you need to add the characters “9 *” to the number. "9" indicates that the call must be sent to the routing algorithm. We will configure the routing rule a bit later.
This is done on the third page of the #ch trunk.
In the configuration of the trunk group, you can specify that this happens with all incoming messages, or you can specify specific number templates, as I have done (six-digit numbers starting at 390, 396, 680).
Next, we configure the routing algorithm for incoming calls. This is done with the command #ch ars digit
First, the “*” is not forgotten, then we indicate that from 7 characters of the number we delete all 7 and insert 3 digits of the internal number and send it immediately to extention, that is, the phone. As a result, it turns out that the call that came to number 390013 is redirected to the internal 110.
Now you can make incoming calls.
IV
Well, it remains to learn how to pass calls through the trunk group to IPO500.
Physically connected, everything is very simple. The pairs on Definity are the same; on the IPO, these are the 9th and / or 10th ports of 1.2-4.5. Of course, we connect the reception to the transmission.
Until the routing is set up, everything is done in the same way, with amendments to the board number, the number of time slots and serial numbers of the parameters. It is necessary to point out only one difference: in the DS1 settings we specify not network , but line-side .
IPO
You can find out how the IPO is configured from my previous article , I’ll only give a screenshot of the setup page:
If everything is configured correctly, the indicator on the E1 board in Definity should turn yellow and turn green on IP Office:
In addition, we will immediately configure incoming calls for IPO :
And outgoing . Here, again, remember that the number must be specified in the format in which the operator is waiting for it.
These settings on IP Office are sufficient.
Now tricky with Definity
Since we now have several trunks, we need to come up with some identifier for the new trunk, which will simultaneously be a prefix for city numbers, which determines which route-pattern it should be inserted into. Take, for example, the prefix "10". That is, the call arriving at 680053 will be processed by the routing algorithm and the number will be changed to 10680053.
Naturally, you need to add a new route-pattern, in which we configure a new trunk group, as well as delete two characters - the same prefix so that the number reaches the IPO virgin clean.
With the next Makar, we will add a prefix and process the call:
Voila:
Now I’ll say that I rested my forehead on and broke more than one spear.
After all the settings, outgoing calls did not work. On Definity tracks, nothing was visible on this trunk. Tracing on IP Office shows that the call goes to the 1st line with Outgoing Group ID 701, but “Cause = 34, No cct / chan available” comes in response, which means there are no free channels for the call. Long, long, unsuccessful debugging, but only a friend’s advice helped. It turns out, returning to what I said at the beginning of the article, you need to configure the trunk group number in the signal group. That was the whole problem. The situation was complicated by the fact that for other trunks configured on the PBX, this parameter was not specified.
For sim end. Download link