Intermittent incoming DID calls getting either busy or message

[mindamartine]

I over over 1300 DID numbers coming in over 2 Century Link PRI on a OPT.81C. They either stay in that main building or are
CDP to one of several Opt. 11. About a week ago I started getting complaints that when customers are calling in (does not matter what DID) sometimes they get a busy or a message that says "your call cannot be completed as dialed
>> dialed" followed by a code: 6NV02ML. I know that message is being generated proabaly CL. However I don't know if my PBX is causing them to generate that message by something on my end. The only error I have spitting out is a BUG 5947 and if I am reading the code correctly it is telling me that d-channel 255 in invalid. I don't have a d-channel 255
Any ideas?

BUG5947
BUG5947 : 255 1
BUG5947 + 0471B49C 04DE51A4 04DE4C84 04DE4C1E 04F294F6
BUG5947 + 04F27B16 04F27AB8 04E2AC70 04E2AB6E 04E29FF8
BUG5947 + 04E23788 04E23698 04DE15C2 04DE1336 04DE108A
BUG5947 + 04DDFAD0 04DDFA04 04BFF8AE 04BFCC42 04BFC9D8
BUG5947 + 04B4AF1E

BUG5947
BUG5947 : 255 1
BUG5947 + 0471B49C 04DE51A4 04DE4C84 04DE4C1E 04F294F6
BUG5947 + 04F27B16 04F27AB8 04E2AC70 04E2AB6E 04E29FF8
BUG5947 + 04E23788 04E23698 04DE15C2 04DE1336 04DE108A
BUG5947 + 04DDFAD0 04DDFA04 04BFF8AE 04BFCC42 04BFC9D8
BUG5947 + 04B4AF1E


BUG5947 {DCH#} {BUG cause value} Set UIPE PRI D-channel pointers failed.
The following is a list of cause values for BUG5947:
1 = Invalid D channel number
2 = The log_io_ptr is nil

 

[Firebird Scrambler]

This is old, but could explain what is happening?. It should only apply to your Option 11 systems.

Continuous BUG5947s on a rls 5 system and possible DCH corruption.

The problem was caused by setting the port of the msdl to 0 instead of 1 on a DCH config.
Up to now, in small systems and CS1000S the prompt was defaulted to 1 whereas in release 5 the prompt is configurable.

27 August 2008
-------------------
Patch MPLR26314_1 is now available for use with MG1000E PRI gateways.
MPRL26314 replaces patch MPLR26085 previously released. This patch allows the configuration of a port 0 Dchannel in this configuration of the MG1000E PRI gateway, and additionally allows the configuration of two 96 port DSP daughterboards with the MG1000E PRI gateway.

This patch also merges several other patches and will be added to the PEP dependency list shortly. Although the patch addresses the changes required by the merged patches, it will allow the MG1000E PRI gateway changes only for CS1000E systems (pkg 402)

NOTE: This patch is available for Rls 5.0 systems only and the following does not apply to Rls 5.5 systems where the changes in this patch have been integrated.

Note: this patch is not applicable to Option 61C-81C, CS1000M SG & MG and Option 11C using SSC or other systems using TMDI cards, as noted below.

Analysis
----------
There are 5 scenarios that systems on Release 5.0 will fall under. The recommendations below will cover all 5 scenarios:
1. Option 61C, 81C and CS1000M Single Group and Multigroup systems These types of systems are not impacted in any way by the patches listed above. These systems can already have port 0 configured as part of their normal installation.
2. Option11C using SSC cards on Rls 5.0, this patch will not impact these systems
3. CS1000E and CS1000B (CPPM/MGC) with TMDI but without HD PRI gateways. The Dchannel on the TMDI card can only be programmed as port 1. These will not be affected by the patches above.
4. CS1000E and CS1000B (CPPM/MGC) with NTBK50 (E1) PRI but without HD PRI gateways.
The Dchannel on the NTBK50 (E1) should only be programmed as port 1 for all CS 1000E systems as per current programming and operation practice before the patch introduction.
In spite of this, if a DChannel is assigned as port 0, this configuration will not function and the reference to port 0 should be removed and reassigned to port 1. The exception would be if the installer tried port 0 and, finding it didn't work, created port 1 on a different loop and mistakenly forgot to remove the first loop with port 0. Although not consistent with current practices, in this scenario, port 0 must be removed from the configuration before the patch removal.
5. CS1000E and CS1000B (CPPM/MGC) with HD PRI gateways. If all Dchannels are assigned as port 1, the patch will have no impact if removed. If port 0 is assigned to any Dchannel, the patch cannot be removed, without first removing all port 0 assignments from the configuration. (See special instructions for removal of the patches or replacement of the Call server CPPM card under Recommendations).
Note: For CS1000E with HD PRI gateways and Dchannel port 0 assigned, the patch should be preserved when installing/refreshing new MDPs that do not contain the patch. Use these options with caution.

Recommendations:
----------------------
Scenario 1, 2 & 3 listed under analysis. Sites are not affected by the listed patches. Patches can be removed without impact.

Scenario 4: Although not consistent with current installation practices, a site using the NTBK50 (E1) card with a DChannel assigned to port 0 mistakenly left in its database can reprogram it to port 1 with no impact, provided the patch has not been removed.

With the installation of new patch MPLR26314_1, there will be a warning message that you have a port 0 Dchannel assigned. If you get this message and do not have an HD PRI gateway, you should remove the port 0 Dchannel(s) immediately. A report of the Dchannels and their assignment can be generated by running an 'ADAN DCH' print in LD 22. All port 0 Dchannels should be removed.

Scenario 5: Sites with High Density PRI gateways and Dchannels configured as port 0, are advised to follow the required actions listed below

MPLR26314_1 - will generate a message that you have port 0 Dchannels in the configuration. These should be assigned to port 1 at the earliest opportunity. Although the patch will leave any existing port 0 Dchannels intact and operational, you will not be able to add any new port 0 Dchannels. Any new Dchannels must be assigned port 1.
Note: This patch also merges several other patches, which will function normally for all machine types. The MG1000E PRI gateway modifications are only activated with the presence of package 402 (CS1000E).

MPLR26085 - Enables the support of ports 0 & 1 on the NTBK51AA Dchannel daughterboard and the configuration of 2 -NTDW64AA - 96 DSP d'boards on the same media gateway controller. It should be replaced by MPLR26314_1.

IMPORTANT NOTE: These patches have special handling instructions requiring that the patch be made permanent. Please read the following instructions:
Patch MPRL26314_1 (and MPRL26085 previously) was created in order to support 2 ports on each DDCH card in small Call Server machines (DDCH in IPMG shelves). It also allows the use of 2- 96 DSP daughterboards to be configured on the same MGC card.

When the patch is active, it is possible to define a D Channel on port 0 of an DDCH as well as on port 1. While doing so, the database of the Call Server is changed in a manner that was not possible or supported without the patch. As long as the patch is in service, the patched code knows how to handle the new data, but if the patch is taken out of service AFTER D channels on port 0 have been defined, the software may handle the new data incorrectly, resulting in corruption of the D-channel data.

Therefore, the patch should be defined so that it will not go out of service due to Sysload.
This can be specified when loading the patch as detailed below:
pdt> pload
Patch filename? p26314_1.cpm
Retain patch (y/n)? [y] y
Days patch vulnerable to sysload? [3] 0
In-service initialize threshold? [5] 0
In-service days to monitor inits? [7] 0

Required Actions:
---------------------
Scenario 4 sites: All port 0 Dchannels should be removed.

Scenario 5 sites: Sites requiring the removal of patch MPLR26314_1 must use the following procedure.

Removal of patch MPLR26314_1
The following notes should be taken into account when removing either patch:
1. If the patch was inserted, and no new D channel was defined, or only D channels on port 1 were defined- then the patch may be taken out of service without any negative impact.
2. If the patch was inserted, and a new D channel was defined on port 0 - then only after deleting ALL the D channels of port 0 AND ALL the D channels of port 1, which had a D channel on port 0 on the same DDCH , and a data dump must be done - only then may the patch be taken out of service.
3. If for some reason the patch was taken out of service while it should not have been, e.g. a D-channel on port 0 was defined: If no data dump and no SYSLOAD took place since the taking of the patch out of service - then re-INSERT the patch - no harm has been done yet.
If no data dump took place, but there was a SYSLOAD since taking the patch out of service - re-INSERT the patch and perform another SYSLOAD - data should be preserved and things will come up
correctly. This procedure should be followed for replacing MPLR24331 or MPLR26085 with MPLR26314_1.
4. If for some reason the patch was taken out of service while it should not have been, the data for D channels on port 0 was left in, a data dump was performed and you suspect that your data is now corrupt, assistance from Nortel may be required in order to recover the system data.

Replacement of call server for scenario 5 site
-------------------------------------------------------
Special handing is required if a call server is replaced on sites in the scenario 4 category. Since patch MPLR26314_1 affects the call server database, the following procedure is required to change a call server if the patch is installed and Dchannels are assigned to port 0.

When bringing up the replacement call server, install the default database provided with Rls 5.0 software. Once the card is up and running, install the patches first before recovering the customer database.

All the best

Firebird Scrambler
Meridian 1 / Succession and BCM / Norstar Programmer in the UK

http://www.linkedin.com/in/davidbromley

If it's working, then leave it alone!.

 

[mindamartine]

I do not have any CS100 or any software on RLS 5

 

[trvlr1]

Check your circuits in LD 60, they may be full at times, causing calls to be blocked. 1300 DID's is a lot for 2 PRI's to handle if it is even just averagely busy. Sometimes smaller CO's do not have enough greeting options to give the right one out for every condition so fall back to a default greeting.