I have a avaya v11 pbx (node1) that I need to 4-digit dial to a v7 pbx (node3) through another pbx v8 (node4). Node 1 is dcs'd to node 4 (tie trunk) and node 4 is dcs'd to node 3 (isdn tie trunk). For some reason, node 3 CAN 4-digit dial back to node 1 through node 4, but node 1 CANNOT 4-digit dial to node 3 through node 4(I get a ring no answer). In essence, it only works 1-way. Node 4 and node 3 can communicate fine between eachother. What forms do I need to change in order for node 1 to talk to node 3. Routing patterns are fine.
Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Chriss Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Dialing 4-digit from one switch, thru another to the destination switc 1
- Thread starter Gabilini
- Start date
Never implemented this situation, but maybe the problem is in your node number routing administration at one end. From what I understand, this controls what route pattern leads to what node. (referenced from the AAR anaylsis that the UDP points to).
Paul Beddows
Avaya Implementation
Telus
Vancouver, Canada
E-mail via
Paul Beddows
Avaya Implementation
Telus
Vancouver, Canada
E-mail via
- Thread starter
- #4
Node 3 was set up in a different facility and was directly linked to node 1. All noded could communicate at that time. Now node 3 has moved and is connected to node 4 (in the same building). UDP and routing patterns all set up. Node 4 and node 1 can talk to eachother. Is it something in the communication processor interface form that needs to be changed?
Maybe the processor channel assignment form? Maybe the port number & machine ID of the remote switch is missing.
Paul Beddows
Avaya Implementation
Telus
Vancouver, Canada
E-mail via
Paul Beddows
Avaya Implementation
Telus
Vancouver, Canada
E-mail via
- Thread starter
- #6
- Thread starter
- #7
Here's where my knowledge comes to a sceaming halt. I'm not even absolutely sure you need it if you are using dcs+. If it is dcs+, I think you need the NCA TSC assignment form. Like I said, i've never done this. I had a course in it a few years ago, & never used it.
Paul Beddows
Avaya Implementation
Telus
Vancouver, Canada
E-mail via
Paul Beddows
Avaya Implementation
Telus
Vancouver, Canada
E-mail via
-
1
- #9
I don't know if you have figured out where to look for information yet. But most likely you have missing administration from the ISDN TSC Gateway
Channel Assignments in node 4.
The ISDN TSC Gateway Channel Assignments page is what transfers the DCS+ information from the tsc to the processor channel. Then the processor channels are administered to transfer data. A great book that explains the forms involved and general setup is book number 555-233-501 the Administration for Network Connectivity. Diagrams of various setups will be in the Private Networking chapter named Distributed Communications Systems. That book can be found online at this link. For an explanation of all of the form's fields try looking in the Administrator's Guide book number 555-233-506. I hope this helps.
T.J.
Channel Assignments in node 4.
The ISDN TSC Gateway Channel Assignments page is what transfers the DCS+ information from the tsc to the processor channel. Then the processor channels are administered to transfer data. A great book that explains the forms involved and general setup is book number 555-233-501 the Administration for Network Connectivity. Diagrams of various setups will be in the Private Networking chapter named Distributed Communications Systems. That book can be found online at this link. For an explanation of all of the form's fields try looking in the Administrator's Guide book number 555-233-506. I hope this helps.
T.J.
- Thread starter
- #10
Thanks for the great post, and I did go through all the setup documentation, still nothing. Both node1, 3, and 4 are ISDN compatable. Node 1 ties to Node 4 through a common channel tie line with a PPP data module. Node 4 ties to Node 3 through an ISDN tie line with signaling. Node 1 and Node 4 can talk and Node 4 and Node 3 can talk. Node 3 can talk to Node 4 AND Node 1. I am amost convinced that it has something to do with the routing pattern that node 1 cannot talk to node 3. When I do call an extension from node 1 to node 3, I am being intercepted by node 4's intercept treatment. Any more thoughts?
Have you checked the AAR analysis screen to see if there is a route for node 3. Should look similar to below:
Dialed Total Route Call Node
String Min Max Pattern Type Number
221 7 7 11 aar 1
223 7 7 11 aar 3
Then check the uniform dial plan and make sure that the stations on node 3 are there with the correct dial length and dial string. In the below example extension 9999 is on node 3 and will have 223 inserted as the prefix. And in the above example 223 points to node 3.
Matching Insert Node
Pattern Len Del Digits Net Conv Num Pattern
9999 4 0 223 aar n
Dialed Total Route Call Node
String Min Max Pattern Type Number
221 7 7 11 aar 1
223 7 7 11 aar 3
Then check the uniform dial plan and make sure that the stations on node 3 are there with the correct dial length and dial string. In the below example extension 9999 is on node 3 and will have 223 inserted as the prefix. And in the above example 223 points to node 3.
Matching Insert Node
Pattern Len Del Digits Net Conv Num Pattern
9999 4 0 223 aar n
Here are the gotchas and tricks I can think of right off of my head. On the aar/ars analysis form there is a field for node number this does need to be filled out properly. The TSC does need to be turned on the route pattern and the CA-TSC field does need to be set to as-needed or at-setup. As-needed is the suggested setup. Also, in the signaling group make sure your TSC is setup for permanent for the least amount of hassle. That is basically the only thing that could be wrong as far as the route pattern setup.
Ensure that the Session Local and Session Remote fields show the local processor channel and remote processor channel respectively. This only matters in your Node 4 and Node 1 setup. Note the session local and remote field still need to be set properly when using DCS over PPP. Since you are going from ISDN TSC to processor channel to TCP/IP. (Look at Node 3's ISDN TSC gateway and Node 1's processor channel forms in Chapter 3 of the Administration for Network Connectivity for examples.)
Since you have release 11 you should be able to do a list trace on the trunk group the call goes across or station you are calling from. It should give you an indication of what is going on.
One thing to mention about intercept tone and DCS is that you will receive it if the number sent across is not one of the four digit numbers assigned to Node 3. (Meaning ars/aar digit conversion is running on it multiple times. Running list trace in the R11 switch should show if this is the case.)
If none of this works, I can help you go through your admin.
Good luck
Ensure that the Session Local and Session Remote fields show the local processor channel and remote processor channel respectively. This only matters in your Node 4 and Node 1 setup. Note the session local and remote field still need to be set properly when using DCS over PPP. Since you are going from ISDN TSC to processor channel to TCP/IP. (Look at Node 3's ISDN TSC gateway and Node 1's processor channel forms in Chapter 3 of the Administration for Network Connectivity for examples.)
Since you have release 11 you should be able to do a list trace on the trunk group the call goes across or station you are calling from. It should give you an indication of what is going on.
One thing to mention about intercept tone and DCS is that you will receive it if the number sent across is not one of the four digit numbers assigned to Node 3. (Meaning ars/aar digit conversion is running on it multiple times. Running list trace in the R11 switch should show if this is the case.)
If none of this works, I can help you go through your admin.
Good luck- Thread starter
- #13
Yes, that is all there and correct. To give you some more history: Node 3 was located in another city and was connected to node 1 through an ISDN PRI T1. All was good and everyone could talk to everyone. We moved node 3 in the same building as node 4(we are using node 3 now as an emergency back-up) and now node 3 is connected to node 4 through a T1. Node 3 works perfectly in communicating through node 4. I just don't understand why it doesn't work the opposite way (even though node 4 can talk to node 3)
- Thread starter
- #14
TJStar. Thanks for the great assistance, however, there are some problems. Node 1 will not let me assign a DCS in the processor interface form (it says feature not assigned) even though there are other channels with dcs applications.
I did a list trace and the call went over the common channel tie line to node 4, connected to node 4 then went to my intercept announcement on node 4's annoucement board.
Is there something in my sys fea para or other setting since node 4 has never acted as a gateway before?
I did a list trace and the call went over the common channel tie line to node 4, connected to node 4 then went to my intercept announcement on node 4's annoucement board.
Is there something in my sys fea para or other setting since node 4 has never acted as a gateway before?
In node 1 as long as there is a dcs channel setup to goto machine id 1 and the link is up then you should be ok. The reason you are getting feature not assigned from the processor interface form is because you probably don't have a PI board. The processor interface form contains the link number. It can be used for assigning an ISDN D-channel using x.25, other x.25, ethernet and ppp links. Also, I believe in release 7 or 8 Avaya started making that screen more of a display only page because the data module form was used to set the link number and data module extension. Either way the processor interface form is not the form we need to change.
The only thing that needs to be turned on is DCS basic in system parameters customer options which is already on or DCS would not be working at all. There are no fields in features related system parameters that will turn on or off features of DCS per-se. So you do not have to worry about features related system parameters or customer options.
The only administration needed for a setup that had DCS working in a directly connected configuration, like you had, would be the addition of a gateway in Node 4. A walk through of where the information for all the gateway fields that need to be populated is provided below.
---------
In Node 4 assume signaling group 1 contains your TSCs and TSC #3 carries your info to Node 3. So look at the signaling group form and the tsc gateway form we would see something like:
change signaling group 1 Page 2 of 5
ADMINISTERED NCA TSC ASSIGNMENT
Service/Feature: __________ As-needed Inactivity Time-out (min): __
TSC Local Adj Mach.
Index Ext. Enabled Established Dest. Digits Appl. Name ID
3: 1903 y permanent 3903 gateway
change isdn tsc-gateway Page 1 of 2
ISDN TSC GATEWAY CHANNEL ASSIGNMENT
Sig Adm’d NCA Processor Appli-
Group TSC Index Channel cation
2: 1 3 16 dcs
What this basically does is it takes the DCS information from processor channel 16 and transfers it to TSC 1/3 (sig grp/tsc#). So on the processor channel form you would see something like...
change communications-interface processor-channels
Page 1 of X
PROCESSOR CHANNEL ASSIGNMENT
Proc Gtwy Interface Destination Session Mach
Chan Enable Appl. To Mode Link/Chan Node Port Local/Remote ID
14: y dcs s 4 5003 ppp41 0 14 14 4
16: y gateway s 4 6005 ppp41 0 16 16
Where the local processor channel is 16. The session local is normally equal to the processor channel number on the left. The session remote is the processor channel number from the TSC gateway. Which in this case is 16 as well. The port 6005 is the actual TCP port that the information is carried on over your PPP link, link 4 in this example. This gateway acts as the server to receive the DCS information. Also the link number should be the same as the link number on the processor channel number going to node 1. (See the line in red) Notice the gateway does not have a machine id associated with it.
So in Node 1 you should see
change communications-interface processor-channels Page 1 of X
PROCESSOR CHANNEL ASSIGNMENT
Proc Gtwy Interface Destination Session Mach
Chan Enable Appl. To Mode Link/Chan Node Port Local/Remote ID
16: y dcs c 1 0 ppp14 6005 16 16 3
Where the local processor channel is 16. The session local is normally equal to the processor channel number on the left. The session remote is the processor channel number from Node 4. Which in this case is 16 as well. The port 6005 is the actual TCP port that the information is carried on over your PPP link and this processor channel acts as the client to send the data. The Destination node is the name for the ip address and the mach ID is the node number.
Once all of this is set, in node 1, go to the processor channel enable field and set it to n. Then go back and enable it. Then type status proc <processor channel number> , i.e status proc 16 in this case. Verify that the processor channel was established. If it was, then try to make your phone call. If something is unclear or does not make sense just let me know. Let me know how it goes.
The only thing that needs to be turned on is DCS basic in system parameters customer options which is already on or DCS would not be working at all. There are no fields in features related system parameters that will turn on or off features of DCS per-se. So you do not have to worry about features related system parameters or customer options.
The only administration needed for a setup that had DCS working in a directly connected configuration, like you had, would be the addition of a gateway in Node 4. A walk through of where the information for all the gateway fields that need to be populated is provided below.
---------
In Node 4 assume signaling group 1 contains your TSCs and TSC #3 carries your info to Node 3. So look at the signaling group form and the tsc gateway form we would see something like:
change signaling group 1 Page 2 of 5
ADMINISTERED NCA TSC ASSIGNMENT
Service/Feature: __________ As-needed Inactivity Time-out (min): __
TSC Local Adj Mach.
Index Ext. Enabled Established Dest. Digits Appl. Name ID
3: 1903 y permanent 3903 gateway
change isdn tsc-gateway Page 1 of 2
ISDN TSC GATEWAY CHANNEL ASSIGNMENT
Sig Adm’d NCA Processor Appli-
Group TSC Index Channel cation
2: 1 3 16 dcs
What this basically does is it takes the DCS information from processor channel 16 and transfers it to TSC 1/3 (sig grp/tsc#). So on the processor channel form you would see something like...
change communications-interface processor-channels
Page 1 of X
PROCESSOR CHANNEL ASSIGNMENT
Proc Gtwy Interface Destination Session Mach
Chan Enable Appl. To Mode Link/Chan Node Port Local/Remote ID
14: y dcs s 4 5003 ppp41 0 14 14 4
16: y gateway s 4 6005 ppp41 0 16 16
Where the local processor channel is 16. The session local is normally equal to the processor channel number on the left. The session remote is the processor channel number from the TSC gateway. Which in this case is 16 as well. The port 6005 is the actual TCP port that the information is carried on over your PPP link, link 4 in this example. This gateway acts as the server to receive the DCS information. Also the link number should be the same as the link number on the processor channel number going to node 1. (See the line in red) Notice the gateway does not have a machine id associated with it.
So in Node 1 you should see
change communications-interface processor-channels Page 1 of X
PROCESSOR CHANNEL ASSIGNMENT
Proc Gtwy Interface Destination Session Mach
Chan Enable Appl. To Mode Link/Chan Node Port Local/Remote ID
16: y dcs c 1 0 ppp14 6005 16 16 3
Where the local processor channel is 16. The session local is normally equal to the processor channel number on the left. The session remote is the processor channel number from Node 4. Which in this case is 16 as well. The port 6005 is the actual TCP port that the information is carried on over your PPP link and this processor channel acts as the client to send the data. The Destination node is the name for the ip address and the mach ID is the node number.
Once all of this is set, in node 1, go to the processor channel enable field and set it to n. Then go back and enable it. Then type status proc <processor channel number> , i.e status proc 16 in this case. Verify that the processor channel was established. If it was, then try to make your phone call. If something is unclear or does not make sense just let me know. Let me know how it goes.
- Thread starter
- #16
TJStar, thanks so much for taking the time to walk me through this. I have everything set according to your design except I have 2 problems:
Problem #1
In node 4, under Processor Channel Assignment, I cannot create a DCS to node 3- your line 14 (there is nothing on this form that originally had a dcs to node 3). When I do, I get the response "local node number not unique for DCS across dial plan, sig group, and processor channel forms".
Problem #2
In node 1, under Processor Channel Assignment, it will not let me use DCS as an application. It says "Distributed Communication Service (DCS) feature not assigned"(sorry, I used the wrong form in my description, last post). I also lost my "cha sys-para cust options" is has now turned to "cha sys-para ip-options since I upgraded to Version 11, so I can't check on my DCS options.
Is there some other application I can use in node 1 except for DCS under processor channel assignment? I so appreciate you spending time on this and if you are exhausted (as I am) I totally understand. However, if you have any thoughts on this, I would love to hear from you.
Problem #1
In node 4, under Processor Channel Assignment, I cannot create a DCS to node 3- your line 14 (there is nothing on this form that originally had a dcs to node 3). When I do, I get the response "local node number not unique for DCS across dial plan, sig group, and processor channel forms".
Problem #2
In node 1, under Processor Channel Assignment, it will not let me use DCS as an application. It says "Distributed Communication Service (DCS) feature not assigned"(sorry, I used the wrong form in my description, last post). I also lost my "cha sys-para cust options" is has now turned to "cha sys-para ip-options since I upgraded to Version 11, so I can't check on my DCS options.
Is there some other application I can use in node 1 except for DCS under processor channel assignment? I so appreciate you spending time on this and if you are exhausted (as I am) I totally understand. However, if you have any thoughts on this, I would love to hear from you.
In node 4, the error message that you are getting: "local node number not unique for DCS across dial plan, sig group, and processor channel forms" means that in either your signaling group, processor channel, or dial plan form something has the machine id 3. Which you do because node 3 is connected to node 4 via a TSC. So there is a DCS TSC assigned in your signaling group. Line 14 in red has an error is should be the processor channel going to node 1. It should be PPP link across your tie line. Sorry about that. (Also, in your case that line should already be in the switch because a DCS call to node 1 from node 4, and vice versa, works. The only thing we need from that line is the link number because the gateway processor channel below it will also be carried on that link.)
change communications-interface processor-channels
Page 1 of X
PROCESSOR CHANNEL ASSIGNMENT
Proc Gtwy Interface Destination Session Mach
Chan Enable Appl. To Mode Link/Chan Node Port Local/Remote ID
14: y dcs s 4 5003 ppp41 0 14 14 1
16: y gateway s 4 6005 ppp41 0 16 16
Ok, I understand about node 1. The change system-parameters customer-options form's functionality was changed in release 9.5 when Avaya went to license files. So try just displaying for now to see if DCS basic is turned on. I am hoping that DCS-Basic is not set to yes. Which is why you would get the message "Distributed Communication Service (DCS) feature not assigned." If this is the case this gets a bit more complicated. Because one of two things happened when you were upgraded, 1) the installer did not turn on DCS in the license file in RFA or 2) just forgot to turn on DCS in the system-parameters customer-options form. The reason why you can see other processor channels with DCS turn on is because most likely they were already administered that way before the upgrade. So the upgrade carried over all the translations and ignored the fact that DCS was not turn on.
Now, if DCS Basic is turned on you'll have to call Avaya and they will have to have their Tier 3 group look at it because it means that there is something set in the switch that thinks DCS is not turned on when it is.
Let me know how it goes. I enjoy a good challenge.
change communications-interface processor-channels
Page 1 of X
PROCESSOR CHANNEL ASSIGNMENT
Proc Gtwy Interface Destination Session Mach
Chan Enable Appl. To Mode Link/Chan Node Port Local/Remote ID
14: y dcs s 4 5003 ppp41 0 14 14 1
16: y gateway s 4 6005 ppp41 0 16 16
Ok, I understand about node 1. The change system-parameters customer-options form's functionality was changed in release 9.5 when Avaya went to license files. So try just displaying for now to see if DCS basic is turned on. I am hoping that DCS-Basic is not set to yes. Which is why you would get the message "Distributed Communication Service (DCS) feature not assigned." If this is the case this gets a bit more complicated. Because one of two things happened when you were upgraded, 1) the installer did not turn on DCS in the license file in RFA or 2) just forgot to turn on DCS in the system-parameters customer-options form. The reason why you can see other processor channels with DCS turn on is because most likely they were already administered that way before the upgrade. So the upgrade carried over all the translations and ignored the fact that DCS was not turn on.
Now, if DCS Basic is turned on you'll have to call Avaya and they will have to have their Tier 3 group look at it because it means that there is something set in the switch that thinks DCS is not turned on when it is.
Let me know how it goes. I enjoy a good challenge.
- Thread starter
- #18
Thanks for the quick response. Problem number 1 is fine then and set up correctly. I did check cust option in node 1 and basic DCS is turned off. I have a call into Avaya to have them turn it back on or to make sure that I can use dcs as an application in the comm procc chan form.
Once they do that, I will attempt to program it correctly and will let you know when you and I are successful. We can then celebrate!!!! Thanks again for all your time and energy! I'll be in touch!
Once they do that, I will attempt to program it correctly and will let you know when you and I are successful. We can then celebrate!!!! Thanks again for all your time and energy! I'll be in touch!
- Thread starter
- #19
TJStar: well, you said you were up for a challenge. Avaya did turn back on DCS basic in Node 1. This is how I have it set up including questions for you:
Notes: Sign 4 is between node 3 and node 4
Link 2 is between node 4 and node 1
Link 4 is between node 1 and node 4
Node 4 configuration(switch in between node 3 and node 1):
Signaling group 4 (btwn node 3 and 4)
TSC Ext Enabled Established Dest Digits App MachID
1: 5996 y permanent 7600 gateway
2: 5995 y permanent 7601 gateway
3: 5995 y permanent 7602 dcs 3
ISDN TSC-gateway
Sig Grp Adm NCA/TCS Processor Channel Appl
index
1: 4 1 9 dcs
Comm Processor Channels
Proc Enab Appl Gway Mode Interface Dest. Session Mach
Chan to link/chan node/port lcl/rem ID
9 y gtwy s 2 5006 node3 0 9 9
Notes: when I do a status proccessor 9, session layer status states: awaiting session and socket status states: listen
Node 1 configuration:
Comm Processor Channels
Proc Enab Appl Gway Mode Interface Dest. Session Mach
Chan to link/chan node/port lcl/rem ID
9 y dcs c 4 0 node3 5006 9 9 3
Notes: when I do a status proccessor 9, session layer status states: out of service and socket status states: no socket assigned.
Can you see anything in this configuration that does not look right? I did not touch anything in node 3. Thanks again for your thoughts and time on this!
Notes: Sign 4 is between node 3 and node 4
Link 2 is between node 4 and node 1
Link 4 is between node 1 and node 4
Node 4 configuration(switch in between node 3 and node 1):
Signaling group 4 (btwn node 3 and 4)
TSC Ext Enabled Established Dest Digits App MachID
1: 5996 y permanent 7600 gateway
2: 5995 y permanent 7601 gateway
3: 5995 y permanent 7602 dcs 3
ISDN TSC-gateway
Sig Grp Adm NCA/TCS Processor Channel Appl
index
1: 4 1 9 dcs
Comm Processor Channels
Proc Enab Appl Gway Mode Interface Dest. Session Mach
Chan to link/chan node/port lcl/rem ID
9 y gtwy s 2 5006 node3 0 9 9
Notes: when I do a status proccessor 9, session layer status states: awaiting session and socket status states: listen
Node 1 configuration:
Comm Processor Channels
Proc Enab Appl Gway Mode Interface Dest. Session Mach
Chan to link/chan node/port lcl/rem ID
9 y dcs c 4 0 node3 5006 9 9 3
Notes: when I do a status proccessor 9, session layer status states: out of service and socket status states: no socket assigned.
Can you see anything in this configuration that does not look right? I did not touch anything in node 3. Thanks again for your thoughts and time on this!
In node 4 and 1 there should be two processor channels on each link. For example, in node 1 there should be a processor for DCS between itself, node 3 and node 4. Both processor channels, 9 and the other processor channel, should have the same node name since they are going to the same endpoint. Are both processor channels using the same node name?
In node one it would look something like this:
change communications-interface processor-channels Page 1 of X
PROCESSOR CHANNEL ASSIGNMENT
Proc Gtwy Interface Destination Session Mach
Chan Enable Appl. To Mode Link/Chan Node Port Local/Remote ID
9: y dcs c 4 0 node3 5006 9 9 3
10: y dcs c 4 0 node3 5008 10 10 4
In node one it would look something like this:
change communications-interface processor-channels Page 1 of X
PROCESSOR CHANNEL ASSIGNMENT
Proc Gtwy Interface Destination Session Mach
Chan Enable Appl. To Mode Link/Chan Node Port Local/Remote ID
9: y dcs c 4 0 node3 5006 9 9 3
10: y dcs c 4 0 node3 5008 10 10 4
- Status