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 Wanet Telecoms Ltd on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

PRI dropping calls...any ideas? 2

Status
Not open for further replies.

Phoneguy15

Vendor
Apr 23, 2002
458
US
I have a customer site that has a PRI w/ DID and calling name delivery on it.
The problem is when they recieve calls they will drop if they answer before the 3rd ring.
They also do not recieve Caller ID(number) info until the 3rd ring (coincidence? probably not!).
I am not sure if the caller id prob is a symptom of the calls being dropped on the PRI or if the dropped calls are a symptom of the caller id delay problem.
I have checked and double checked the the settings for the DS1, Signalling group and the Trunk group and thy all seem to be ok. I will post them here if I need to give more info...
I believe that it is a problem with the service provider (BellSouth) and possibly protocol issues. I cannot however prove it to them.
When I do a list trace on the trunk group or the station it just show up as idle trunk group member or idle station, as if one party has hung up.
I have checked to make sure that the sync timing is set and ok. It is set to the DS1 board that the PRI is on.
BellSouth did have a problem with there end earlier but it seems thay have corrected it.
I was showing errors on the DS1 before they fixed it.
I can also do a list measurments DS1 log and it will show some errors in the current 15 minute period, but when it updates to a new 15 minute period those errors are gone in the period I was just looking at and there are errors in the (new) current period. I don't understand that!

Well, that is all I cn think of right now as far as details are concerned.
I encourage any questions, comments or advice

Thanks in advance,
-Todd

 
Post your DS1 config, Signaling Group, and pages 1&2 of the trunk Group for the board in question. Also the error log (errors, not alarms)for that board only so that we can see what the issues may be. What type of CO switch is being used, and what release switch are you using.
 
Thanks, phonesrus.

The CO switch is a DMS100.
I did a display errors, it is clear.
I also did a list measurements log and summary. Both are showing all clear.
The end user is closed for day (holiday).

The system is an S8300/G700 R3.01

Here are the config's:

DS1

display ds1 1v3 Page 1 of 2
DS1 CIRCUIT PACK

Location: 001V3 Name: Local PRI
Bit Rate: 1.544 Line Coding: b8zs
Line Compensation: 1 Framing Mode: esf
Signaling Mode: isdn-pri
Connect: network
TN-C7 Long Timers? n Country Protocol: 1
Interworking Message: PROGress Protocol Version: b
Interface Companding: mulaw CRC? n
Idle Code: 11111111
DCP/Analog Bearer Capability: 3.1kHz

T303 Timer(sec): 4


Slip Detection? n Near-end CSU Type: other

Echo Cancellation? n Block Progress Indicator? n



display ds1 1v3 Page 2 of 2
DS1 CIRCUIT PACK

ESF DATA LINK OPTIONS

Network Management Protocol: tabs
Send ANSI-T1.403 One-Second Performance Reports? n
Far-end CSU Address: b







SIGNALLING GROUP

display signaling-group 1 Page 1 of 5
SIGNALING GROUP

Group Number: 1 Group Type: isdn-pri
Associated Signaling? y Max number of NCA TSC: 0
Primary D-Channel: 001V324 Max number of CA TSC: 0
Trunk Group for NCA TSC:
Trunk Group for Channel Selection: 1
Supplementary Service Protocol: a




TRUNK GROUP


display trunk-group 1 Page 1 of 20
TRUNK GROUP

Group Number: 1 Group Type: isdn CDR Reports: y
Group Name: OUTSIDE CALL COR: 1 TN: 1 TAC: 210
Direction: two-way Outgoing Display? n Carrier Medium: PRI/BRI
Dial Access? n Busy Threshold: 255 Night Service: 2525
Queue Length: 0
Service Type: public-ntwrk Auth Code? n TestCall ITC: rest
Far End Test Line No:
TestCall BCC: 4
TRUNK PARAMETERS
Codeset to Send Display: 6 Codeset to Send National IEs: 6
Max Message Size to Send: 260 Charge Advice: none
Supplementary Service Protocol: a Digit Handling (in/out): enbloc/enbloc

Trunk Hunt: ascend QSIG Value-Added? n
Digital Loss Group: 13
Incoming Calling Number - Delete: Insert: Format:
Bit Rate: 1200 Synchronization: async Duplex: full
Disconnect Supervision - In? y Out? n
Answer Supervision Timeout: 0


display trunk-group 1 Page 2 of 20
TRUNK FEATURES
ACA Assignment? n Measured: none Wideband Support? n
Maintenance Tests? y
Data Restriction? n NCA-TSC Trunk Member:
Send Name: y Send Calling Number: y
Used for DCS? n
Suppress # Outpulsing? n Format: public
Outgoing Channel ID Encoding: preferred UUI IE Treatment: service-provider

Replace Restricted Numbers? n
Replace Unavailable Numbers? n
Send Connected Number: n
Hold/Unhold Notifications? y
Send UUI IE? y Modify Tandem Calling Number? n
Send UCID? n
Send Codeset 6/7 LAI IE? y Ds1 Echo Cancellation? n

US NI Delayed Calling Name Update? n

Network (Japan) Needs Connect Before Disconnect? n



Thanks for the help,
-Todd





 
Is this PBX a part of a network of PBXes?
If so, then one PBX needs to be the master, and it needs to have all the other PBXes slaved off it by the trunks that connect to it.
I don't think that is your problem though. I am thinking that the setting at the central office and your pbx are not the same. Also 'slip detection' should be 'yes' on the DS1 form.
And the 'Trunk Hunt:' should be 'ascend' on one end, and the opposite on the other end.
 
Orypecos,
Thanks for the reply.
This system is a part of a DCS network of systems, but they are using local trunking because they are in a different city as the main Corporate site.
They are primarily using the DCS link for centralized voicemail and extension dialing between branches and corporate.
This particular PRI is for local trunking only, not for other sites to use.
The channel selection is set oposite from the C.O. they are set to decend.

I will change the setting for slip detection back to "y".
I think that I changed it for a test and didn't change it back.

-Todd
 
Check with your carrier and find what their protocol settings are. You are running National they might be running NTNAPRI which is a nortel to nortel custom protocol,their default. It works for a while then acts funny, because the messaging on the "D" channel is a bit different. What you need is U-449 in their LTDEF field.
Another thing I noticed is on the SigGp form you have the CA-TSC (call associated temp sig connection) is 0, It usually set to equal to the number of trunks, or 23 times the number of t-1's, if it is a multiple t-1 trunk gp.
 
phonesrus,
very interesting info. I am going to have BellSouth check those settings today.
I will also check the CA-TSC settings.
Thanks, I will let you know how it progresses.
I am sure that BellSouth will give some push back on the settings for their switch.

-Todd
 
Phoneguy15, I am running about the same setup and have Bellsouth as our provider. I see nothing in our setup that is different form yours. I too believe this to be some on Bells side. Our CA-TCS settings and Protcol A is the same in ours as well. Here we our also working behind a Northern Telcom DMS 100-200.



Mikey
 
Mikey,
Is your circuit operating ok?
Thanks for the support.
I am still checking on the settings that Phonesrus mentioned on the DMS-100 side.


-Todd
 
As far as your DCS network, the synch source should only be set to that trunk to the network if this pbx is the master pbx in the network. Otherwise, the syn should be set to the trunk that leads to the master switch. You will always have slips and problem on most if not all digital trunks if this is not done.
 
orypecos,
We are not using the PRI for DCS.
The DCSing is using IP Trunking across the data circuit.

-Todd
 
Ok you guys won't believe this,
Somehow the DMS-100 has magically turned into a 5ESS (huh!?).

So now with that knowledge, what settings am I looking for to make sure that the calls come in and stay up?

Thanks again,
-Todd
 
Since you are running National[NI2] (Protocol "b" in the DS1 form), with Name and Number delivery You want National "NI2" from the 5ESS.
You might want to run "list trace tac" against the trunk group and watch the trace on inbound and outbound calls to see what disconnect cause codes are issued, or get the carrier to run a "d" channel trace and make test calls.
BTW; the calling party number and name is sent in the setup message, unless the CO is running delayed NI calling party name update, which is a programmable option in your trunk group on page 2.
 
This is off a document I have, for all it's worth...

Protocol CO protocol CO
A AT&T Custom Lucent 4ESS (LD)
Lucent 5ESS(lcl&ld)
MCI using N499 Nortel DMS w/449
MCI using N599 Nortel DMS w/549
AT&T Standard DEC 600
B Nationsl ISDN 2(NI2) Lucent 5ESS(local)
Nortel DMS(local)
C Nortel Custom Nortel DMS(lcl&LD)
D national ISDN 98(NI98)Lucent 5ESS




 
We have had this problem as well. With our problem it turned out to be between two group of T1 circuits. We have one group that is PRI and another that is not PRI. In our call center, we get incoming calls over the PRI trunks. We then call out for an interpreter to connect to the first incoming call. If out volumn is higher than the available of our PRI trunks, the calls rollover to the non-PRI trunks. When this happens we will get occasional dropped calls after the call has been in progress for a minute or longer.

We are in the process of getting rid of the non-PRI circuits and bringing in more PRI circuits for overflow. Hopefully this will take of the drop call problem for us. Is it possible that you are mixing PRI and non-PRI calls?

Mike
 
Update!

Spoke with Avaya TSO friday.
They had us load a "Super Patch Combo 10994".
That patch(or update, whatever!) is comprised of 10986 + 10960.
Update 10986 is posted on the support site but niether 10960 or combo 10994 are availible yet on the support site.

This patch fixed the dropping calls problem but not the caller id problem.
We have heard that BellSouth supports calling name delivery on NI-1 custom. We will be trying that next.
I will keep you posted on that.

Again, thanks for all the input,

-Todd
 
That is a shame. All that trouble for a 'known problem'! Just another reason not to upgrade. I think we all need to write to Avaya to quit sending out the 'beta' loads for us to test!

Oh, and by the way, I'll have a Super Patch Combo Royale with cheese with a adlenine shot to the heart in the 57 Chevy. Can I have Chubby Checker for my waiter?
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top