I’ve always been intimidated by classic telephony.It’s like some kind of secret knowledge.It is transmitted only by word of mouth, from teacher to student. And despite all my attempts to stay away from it, as fate would have it, Iwas thrown with my whole body into the embrasure of PBX, E1, and other CO trunks.
I have written before about PBX setup IP Office 500 Since then a lot of time-slots are free and I have a new task: to configure a trunk between two PBXs (Definity and IP Office)and to make possible city calls via this transit.
Interested in the secret knowledge please
The Avaya Definity PBX is our old resident with a good hundred numbers for three holding organizations. So far I have only been able to add new internal numbers and change the order of the call.
The PBX was connected via a composite link with two Ethernet-E1conversions. In addition to the complex configuration of this connection and the opaque logic, it caused a number of difficulties and problems.
1) Very long waiting time for the connection with the subscriber.
2) There are only 12 time-slots in the stream, and therefore only 12 possible simultaneous calls. This is due to the characteristics of the cisco router, which performs transit.
3) When the channel goes down, apart from the local network, the telephony also stops working.
4) Difficult debugging process and large number of failure nodes.
But not so long ago it was necessary to buy IP Office for one more organization, and for financial and technical reasons it was decided to connect it to Definity by trunk. Besides, it allows you to set up one single number plan for all organizations of the holding.
At the same time it was decided to switch this PBX to the new stream, and leave the old transit only for local telephony.
So, the final scheme would look like this :
And the setup, in fact, will be done from scratch. So let’s go down this road 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 after checking the position of the dip-switches, you can safely plug them into a working station.
There are two Dip-Switches. With one of them we specify the type of physical line: coaxial or twisted pair. As a rule it is twisted pair and therefore we choose 120 Ohm.
The second specifies the standard of E1/T1, respectively 32/24 channels. Of course, in Russia E1 is used – 32 channels.
We take two streams from the operator, so we need two boards. Immediately after the cards are placed in their slots via Avaya Terminal Emulator with the command #list conf all you can verify that the PBX has seen them :
At this point you can make the physical connection. Regardless of the board : digital or analog ports with 24 lines, E1 with four wires or Ethernet, the connector is universal : 50-pin. I call it amphenol, although I’m not sure if the term doesn’t just mean phone connector.
The pair used for E1 is 23.48 for transmitting and 22.47 for receiving. This can easily be checked by connecting an LED to the Tx – transmit pairs. Connectthe operator’s transmission to our reception and vice versa: our transmission to their reception.
The next step is to add a ds1 interface.
#add ds1 xxx with the following parameters
xxx – board number, in our case it is 01b06
You might need to run #ch sync If this is the first time you are setting up a PBX.
Since we are connecting to an operator, it is likely that the parameter Connect should be set to network. But in general, of course, you should ask the operator about all these parameters.
If everything is done correctly at this step, the command #test board xxx where xxx – board number, should return PASS For all tests. FAIL on test 138 means there is no signal on reception.
As you know, the 16th time slot E1 is used for signaling, so the next step is to set up a signaling group.
#add sig next
The last two digits Primary D-Channel – time slot number in the stream.
Avaya does not require to specify trunk-group number here (moreover, we do not have it yet). But it is better to do it to avoid different problems (parameter Trunk Group for Channel Selection )
Check the status of the alarm group with the following commands.
#test sig x
The tests should give the result PASS or ABORT ABORT is not a sign of a problem, it only indicates that the test is not applicable. If the test result is FAIL, it is very likely that the problem is with the Connect – For example, both stations have Network or Line-side
#status sig x
The signal group must have the status in-service
Now you are ready to set up a trunk group, which will be used to transmit calls.
But first you need to check your number plan. It should have the number dac set in it.
In our case, it is a number that starts with a 7 and consists of 3 digits.
This is the number you have to put on the first page of the command #add trunk next
Important parameters are underlined
From page 4 onwards, the time-slots used in the trunk are specified here. This is quite a flexible mechanism: you can make several trunks in one thread by splitting the thread, or you can combine several threads into one trunk. This is exactly the second case, since we can have up to 50 simultaneous calls. Therefore, I add all 60 time-slots of two E1 streams into one trunk group, except for service 16 and 32.
So, now we have a full-fledged connection with the operator, it remains to accept the city numbers from him, as well as to specify how our internal numbers will call the city.
Let’s start with the outgoing numbers.
Here’s what we need to do to do this.
First, create route-pattern With it we will set where and by which rules the call will be redirected.
As the connection to the operator is actually the "default" route for our calls, we won’t make any tricks:
Now let’s touch on a very important setting element: the routing algorithm ARS – Automatic Route Selection.
It is configured by two commands : #ch ars analisys and #ch ars digit
In my case, the output of the command #ch ars analisys looks like this :
This essentially means that all calls with calling numbers that satisfy the following patterns must be sent to route-pattern 2, which is trunk group 4, as we configured above.
Command #ch isdn public will help you configure the rules of correspondence of internal numbers to city numbers, in other words AON.
This entry means that for all three-digit internal numbers beginning with 1, the city number will be 2390013 and this will be sent to trunk group 4, and for the number 102 will be a separate number 2390012
In fact, the numbers are six digits and "2" is here because this is the format the operator expects the number, this should also be clarified in advance with representatives.
If an invalid number or invalid trunk group is specified here, the call will be rejected.
If the PBX is set up for the first time, you must also specify the access code to the routing algorithm in the dial plan. Usually this is "9". Yes, yes, this is the same "nine" that you constantly have to dial if you use a PBX.
As a matter of fact, these settings will already be enough to make an outgoing call.
Incoming numbers are a bit more complicated.
The first thing to do is to set in the trunk group settings that the prefix "9*" is added to the dialed telephone number (city number). That is, someone dialed the number 390045, according to the routes of the operator, this number comes to our PBX in trunk group number 4, and here it is specified that the number must be added to the characters "9*". "9" indicates that the call needs to be sent to the routing algorithm. We will set up the routing rule a little later.
This is done on the third page #ch trunk
In the trunk group setting, you can specify that this happens to all incoming calls, or you can specify specific number patterns, as I have done (six-digit numbers starting with 390, 396, 680).
Next we configure the routing algorithm for incoming calls. This is done with the command #ch ars digit
At the beginning we do not forget "*", then we specify that from the 7 characters of the number we delete all 7 and insert 3 digits of the internal number and send it directly to the extention, that is the phone. As a result, the call that came to the number 390013 is redirected to the extension 110.
It is now possible to make incoming calls as well.
Well, all that’s left is to learn how to run calls through the trunk group on the IPO500.
Physically connecting everything is very simple. The pairs on Definity are the same, on IPOthey are ports 9 and/or 10 1, 2-4, 5. Of course, we connect the reception to the transmission.
Up to the routing setup, everything is done similarly with corrections to the board number, the number of time-slots and the serial numbers of the parameters. Only one difference must be pointed out: in the DS1 settings we do not specify network , and line-side
How the IPO is set up, you can learn from my previous article I will only show a screenshot of the configuration page here:
If everything is set up correctly, the LED on the Definity E1 card should turn yellow and the LED on the IP Office should turn green:
In addition, the IPO will immediately set up incoming calls :
And outgoing Here again, remember that the number must be specified in the format in which the operator expects it.
These settings on the IP Office are sufficient.
Now for the Definity trick.
Since we now have several trunks, we need to think of some new trunk identifier, which at the same time will be a prefix for city numbers, determining in which route-pattern it should be put. Take, for example, the prefix "10". That is the call coming to the number 680053 will be processed by the routing algorithm and the number will be changed to 10680053.
Of course, we have to add new route-pattern, where we will set up a new trunk group, and remove two characters – the prefix, so that number will come to IPO pristine.
Next we add a prefix and process the call :
Now I’ll tell you what I’ve bared my forehead and broken more than one spear.
After all the adjustments, the outgoing calls didn’t work at all. The Definity trace showed nothing on this trunk. The trace on the IP Office, shows that the call is sent to Line 1 with Outgoing Group ID 701, but the answer comes "Cause=34, No cct/chan available", which means no channels available for the call. Long long fruitless debugging, but only a friend’s advice helped. Turns out, going back to what I said at the beginning of the article, you had to configure the trunk group number in the signal group. That was where the whole problem lay. The situation was complicated by the fact that for the other trunks configured on the PBX, this parameter was not specified.
And now I am done. To download. link