Nortel Cisco Unity QSIG Integration 1

[YYCDave]

We're running into a consistent error generating situation which isn't readily apparent as to the cause. Any suggestions as to where to start looking?

The call sequence when this occurs is as follows:



1) Nortel DN 8949 calls Cisco DN 8901 – Call is routed over PRI from Nortel to Cisco

2) Cisco DN 8901 does not answer and forwards to Cisco Unity Voice Mail (DN 5577)

3) Nortel DN 8949 (calling DN) receives “Voice Mail 5577” on display from Cisco

4) Error 9013 is generated:



ERR9013 TN: 00001914 N: 00000001 P: 00005817 S: 00000004 L: 00000010

DTA: 300E0A01 030A0102 A0068004 35353737



5) Cisco Voice Mail DN 5577 seems to be identified in this error message (even number characters of 35353737)

6) Periodically the ERR9013 message is followed by a BUG message which refers to “Path Replacement Error”:



BUG9024

BUG9024 : 5 9

BUG9024 + 0475B3B8 050977B0 0509C974 0509C714 0509557C

BUG9024 + 04BCBC74 04BCB494 0DAFA7E6 04BC8724



Here’s the DCH print as well:



REQ prt

TYPE

ERR225 0 3

adan dch 17



ADAN DCH 17

CTYP MSDL

GRP 1

DNUM 10

PORT 3

DES Cisco

USR PRI

DCHL 51

OTBF 32

PARM RS422 DTE

DRAT 64KC

CLOK EXT

IFC ISGF

PINX_CUST 0

ISDN_MCNT 300

CLID OPT0

CO_TYPE STD

SIDE NET

CNEG 1

RLS ID **

RCAP COLP NDI CCBI CCNI PRI DV3I

PR_TRIGS DIV 2 3

CNG 2 3

PR_RTN NO

MBGA NO

OVLR NO

OVLS NO

T310 120

T200 3

T203 10

N200 3

N201 260

K 7

 

[johnpoole]

here is a paper publiushed here back when i had a simular problem.. not my work but it may help

Within any environment where Nortel PBX's will be used to trunk to another vendors PBX, a Q.SIG trunk is usually used. Once there becomes a need to add multiple facilites, there also becomes a need to network them together. For this, there are several options within the Q.SIG standard that allow for call pruning and path replacement. Nortel does this internally using a feature called TRO-CM (Trunk Route Optimization - Call Modification). This feature was part of an enhancement to Release 25.40.

In a Q.SIG scenario, there is a prompt within the D-Channel that controls if this is available, and how it is used. The options are CTR1 and CTR2 within the PR-TRIGS field of the D-Channel. (If you want to read the Feature Doc, search for Document Release Note MSC-0603-021 within the Helmsman web site)

A D-Channel configured would look like this
CODE
PR_TRIGS DIV 2 3
CNG 2 3
CTR2 2 3

In a nutshell, CTR1 and CTR2 tell the PBX which system in a Transfer process is responsible for triggering a Path Replacement request. CTR1 states the PBX from which the call originally started is responsible for the request; CTR2 defines the final destination as the responsible party. The transfer notification is handeled in the out-of-band signaling provided by the D-Channel.

Think of it like you have three sites: A, B, and C. If A calls B, and B then transfers the call to C, route optimization would need to take place to prune the unecessary call path. This is especially important in VoIP applications, where a call that is not optimized will take up unnecessary bandwidth, talk paths, as well as add additional encodings to the call, thereby reducing the quality of the call.

With CTR1 defined in the above scenario, as soon as Site C answers, Site A would send a path replacement request to Site C. This process would then create a seperate talk path between Site A and C. Call processing would then shift the talk path from the inital path thru B to the direct talk path between A and C. As soon as the shift occurs, the old call path thru B is torn down. CTR2 does the same thing, only C is responsible for making the request. Nortel states in Documentation that CTR2 is the default when setting this type of D-Channel. I have had personal experience where the option does not even populate when you build the D-Channel, but can be added during the programming or as a change.

CTR1 and CTR2 are mutually exclusive, and MUST be configured consistent across your entire network. If in the same scenario above Site A was configued as CTR2 and Site C was configured as CTR1, path replacement would never happen. I have asked Nortel which is better, and have yet to get a response that makes sense. Since CTR2 is the default, one would assume that is the better way to go.

NOTE: Path replacement is only true when a transfer key is used. Using a conference key to make the transfer will not trigger any type of path replacment, since the PBX requests and uses a conference resource on the PBX where the key was pressed. Even if that caller releases themselves from the call, the conference resource in the middle is still being used to connect the other two callers. This is especially important if users are not sure what happens when they transfer a call, or you tried to save space on a 2008 set and only programmed a conference key.

Hope this is helpful to someone out there,

john poole
bellsouth business
columbia,sc

 

[YYCDave]

Thanks, John, but the scenario described in your response doesn't really address our scenario. Calls are being FNA'd out of the PBX via CDP to the Cisco environment so there isn't a user initiated transfer. Also, the issue seems to be in how the Cisco world and the PBX are communicating with each other using QSIG.

Can anyone offer advice on how to decode the ERR9013 and BUG9024 messages that I'm receiving?

 

[Triton101]

try adding

RLS ID 26

RCAP COLP NDI QMWI

 

[YYCDave]

I adjusted the DCH as recommended and now I'm receiving this error message (immediately following the ERR9013 message) that I can't find an NTP reference to:

BUG348
BUG348 : 6 115 0 0 00000000 0000189C 8D525028
BUG348 + 0475B3B8 05261C34 05277960 052729BC 0DC396F0
BUG348 + 0526D674 0526C7EE 052633D0 05269DAA 0525DE6E
BUG348 + 04E9D9CE 04E9D756 04E9B3E0 04516A3A 04E9DF9E
BUG348 + 04E9D756 04E9B3E0 05265398 0528E97E 05290ED6
BUG348 + 0DC3939A 05280FB8 0525DD9A 04EAFD38 04EAD47E
BUG348 + 04E9F75E 04F15234 04F105C0 04F0FE2C 0DC22646
BUG348 + 04E9F75E 04E96D6A 04E96AA0 04E967F4 04E94A6C
BUG348 + 04E949A0 04C836E0 04C80634 04C80370 04BCE5E2
BUG348 + 04BC8706

 

[Triton101]

Since this is an MSDL, did you DownLoad the dch to it?

Also make sure you have the latest DEP list and patches on the PBX.

 

[Triton101]

Forget the RLS ID only applies to Nortel to Nortel Ties, but looks like there are Patches for the other message you have ERR9013

 

[stfontaine]

Hi YYCDave.

I have the same setup with a Nortel 81C and a Call Manager & Unity.

I have this same bug9024 as you

Did you fix this problem ?

Triton101 suggest that some patches exist to fix those problem. Did you had any chance to install thoses patches with good result ?

Thanks.

Stfontaine

 

[trvlr1]

We have a test set up similar to yours 81 to Call manager
I have 4 differences to your settings: CNEG 2, RLS ID 26, RCAP (addition of) QMWI and CTR2 2 3
I am not seeing the errors you talk about, the only issue I have at this time is Cisco Unity VM will not light the lamp on Nortel phones, I still have to work on this as I get time.