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

QSIG CS1000 4 to Cisco Unity MWI Woes

Status
Not open for further replies.

buttercool

IS-IT--Management
Mar 22, 2018
31
0
6
US
Hello,

As always, I want to highlight how much I enjoy this forum for learning, problem solving, and interesting reading about nortel technical issues/configs/resolution.

My latest home project has been a QSIG Cisco Unity integration to my 11c. All the general QSIG functionality works great, calls both ways, caller ID both ways, etc. Unity recognizes the Nortel phones and auto logs in to the mailbox as expected. I also have the mailboxes shared with my Cisco phones (using an alt extension, and secondary MWI entry in Unity for the Meridian phones, and the CM phones are primary). Long story short almost everything works perfectly....

Before I get into the technical details I have read virtually all of Cisco's CUCM / Unity to Nortel Meridian integration guides out there, that I could find, specifically for QSIG with MWI noted as a working capability, and have determined that the best topology in my case is a direct Nortel QSIG > Cisco ISR (SIP) > Cisco Unity integration. I've also tried the same config with a CUCM in the middle, so Nortel QSIG > Cisco ISR (SIP) > Cisco CUCM > Cisco Unity, and the results are the same.

MWI on the other hand continues to be a challenge. I've configured Cisco's suggested SIP MWI settings and SIP to QSIG MWI settings (adding qsig decode in voice service voip, mwi on the voice ports, and mwi-server in sip-ua) on the ISR. On the ISR side of things everything seems to work as expected. I can see the SIP NOTIFY message hit my Cisco ISR, then I see it get converted to a QSIG message and sent out the Serial1/0:23 port towards the Meridian. At the same time on the Meridian, in LD 96, with MSGO and MSGI set to 0, I do see the QSIG message arrive on the DCH, then the connection establishes and almost immediately terminates (cleanly?) however I don't see anything in the DCH output that screams ERROR (although I'm admittedly very green at reading the DCH output).

Below are the outputs of my config. Also, apologies in advance for the super long post, but wanted to have the full complement of data for review :)


===== Of Note ====
The 11c does have all of the relevant NMS/QSIG packages.
An MSDL card is being used.
Nortel DN in these examples is 3201
This DN *does* appear as the primary on several phones -- is this an issue?
5000 is the Unity 'pilot' number, routed via DSC from the Nortel to the ISR, which then connects to unity via a SIP dial-peer via udp

CALL SERVER/MAIN CAB
VERSION 2121
RELEASE 4
ISSUE 00 T +
IDLE_SET_DISPLAY MWI DONT WORK

===== Loop =====

CEQU
MPED 8D
SUPL 000 004 008 012
016 032 036 040
044 048 064 068
072 P096
TDS 000
CONF 029 030 031 062
094 095

DLOP NUM DCH FRM TMDI LCMT YALM T1TE TRSH
PRI 01 24 ESF NO B8S FDL - 00
02 24 ESF NO B8S FDL - 00
MISP

===== DCH =====

ADAN DCH 11
CTYP MSDL
CARD 01
PORT 1
DES pri1_to_ccm
USR PRI
DCHL 1
OTBF 32
PARM RS422 DTE
DRAT 64KC
CLOK EXT
IFC ISGF
PINX_CUST 0



PAGE 001

ISDN_MCNT 300
CLID OPT0
CO_TYPE STD
SIDE USR
CNEG 1
RLS ID **
RCAP COLP NDI CCBI CCNI PRI DV3I CTI QMWI
PR_TRIGS DIV 2 3
CNG 2 3
CTR2 2 3
PR_RTN NO
MBGA NO
OVLR YES
DIDD 0
OVLS NO
T310 120
T200 3
T203 10
N200 3
N201 260
K 7

===== RDB =====

TYPE RDB
CUST 00
DMOD
ROUT 101
DES PRI1_ROUTE
TKTP TIE
NPID_TBL_NUM 0
ESN NO
CNVT NO
SAT NO
RCLS EXT
VTRK NO
NODE
DTRK YES
BRIP NO
DGTP PRI
ISDN YES
MODE PRA
IFC ISGF
SBN NO
PNI 00001
NCNA NO
NCRD NO
CHTY BCH
CTYP UKWN
INAC NO
ISAR NO
CPFXS YES
DAPC NO
INTC NO
DSEL VOD
PTYP PRI
AUTO NO
DNIS NO
DCDR NO
ICOG IAO
SRCH LIN
TRMB YES
STEP
ACOD 3820
TCPP NO
TARG 01
CLEN 1
BILN NO
OABS
INST
ANTK
SIGO STD
ICIS YES
TIMR ICF 512
OGF 512
EOD 13952
NRD 10112
DDL 70
ODT 4096
RGV 640
GRD 896
SFB 3
NBS 2048
NBL 4096

IENB 5
TFD 0


PAGE 002

VSS 0
VGD 6
DRNG NO
CDR NO
VRAT NO
MUS NO
OHQ NO
OHQT 00
CBQ NO
AUTH NO
TTBL 0
ATAN NO
PLEV 2
ALRM NO
ART 0
SGRP 0
AACR NO

===== TIE =====

DES PRI1
TN 001 01
TYPE TIE
CDEN SD
CUST 0
TRK PRI
PDCA 1
PCML MU
NCOS 0
RTMB 101 1
B-CHANNEL SIGNALING
TGAR 0
AST NO
IAPG 0
CLS UNR DTN WTA LPR APN THFD HKD
P10 VNL
TKID
AACR NO
DATE 14 MAY 2019

===== CDB (Extracts) =====
TYPE NET_DATA
CUST 00
OPT RTA
AC1 INTL NPA SPN NXX LOC
AC2
FNP YES
ISDN YES
VPNI 0
PNI 1
PINX_DN
MBG 0
BSGC 65535
PFX1
PFX2
HLOC
LSC
RCNT 5
PSTN NO
TNDM 15
PCMC 15
SATD 1
OCLI NO
DITI YES
TRNX YES
EXTT YES
FTOP FRES
VNR NO
NIT 8
NAS_ATCL YES
NAS_ACTV NO
FOPT 14
CNTC
NATC
INTC

TYPE IMS_DATA
CUST 00
IMS NO

===== Cisco Config =====

voice service voip
ip address trusted list
ipv4 10.1.20.15
< other IPs redacted >
ip address trusted call-block cause not-in-cug
gcid
clid substitute name
qsig decode
allow-connections sip to sip
no supplementary-service sip moved-temporarily
no supplementary-service sip refer
sip
bind control source-interface FastEthernet0/0
bind media source-interface FastEthernet0/0
session transport tcp
session refresh
e911
transport switch udp tcp
asserted-id ppi
localhost dns:vgw2.MYDOMAIN.TLD
midcall-signaling passthru
no call service stop
!

sip-ua
retry invite 3
retry response 3
retry bye 3
retry cancel 3
timers trying 100
timers notify 1000
timers info 1000
mwi-server ipv4:10.1.20.15 expires 60 port 5060 transport udp unsolicited
registrar 1 dns:denver.voip.ms expires 300
notify ignore substate
!

=======================

Below is a trace, first from the Cisco ISR, second the DCH messaging from the Nortel.

===== Cisco Call Trace =====
May 17 14:58:52.333: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
NOTIFY sip:3201@10.1.20.55 SIP/2.0
From: sip:5000@10.1.20.15:5060;tag=4a51eef4883d4b6da3eea669f7d2c496
To: sip:3201@10.1.20.55
Via: SIP/2.0/UDP 10.1.20.15:5060;branch=z9hG4bK096b8819fe34430e911586cb19e2fbec
Max-Forwards: 70
Contact: sip:5000@10.1.20.15:5060;automata
Call-ID: 4792c68d05754214b975a6482060dba7@10.1.20.55
CSeq: 300 NOTIFY
Event: message-summary
Content-Length: 23
Content-Type: application/simple-message-summary

Messages-Waiting: yes

May 17 14:58:52.353: ISDN Se1/0:23 Q931: Sending SETUP callref = 0x0092 callID = 0x8013 switch = primary-qsig interface = Network
May 17 14:58:52.353: ISDN Se1/0:23 Q931: TX -> SETUP pd = 8 callref = 0x0092
Bearer Capability i = 0xA880
Standard = ISO/IEC
Transfer Capability = Unrestricted Digital
Transfer Mode = Circuit
Transfer Rate = Packet - not specified
Channel ID i = 0xAC
Exclusive, Channel 5
Called Party Number i = 0x80, '3201'
Plan:Unknown, Type:Unknown
May 17 14:58:52.393: ISDN Se1/0:23 Q931: RX <- CALL_PROC pd = 8 callref = 0x8092
Channel ID i = 0xAC
Exclusive, Channel 1
May 17 14:58:52.409: ISDN Se1/0:23 Q931: RX <- CONNECT pd = 8 callref = 0x8092
Channel ID i = 0xAC
Exclusive, Channel 1
May 17 14:58:52.413: ISDN Se1/0:23 Q931: TX -> CONNECT_ACK pd = 8 callref = 0x0092
May 17 14:58:52.413: ISDN Se1/0:23 Q931: TX -> CONNECT_ACK pd = 8 callref = 0x0092
May 17 14:58:52.421: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.1.20.15:5060;branch=z9hG4bK096b8819fe34430e911586cb19e2fbec
From: sip:5000@10.1.20.15:5060;tag=4a51eef4883d4b6da3eea669f7d2c496
To: sip:3201@10.1.20.55;tag=3C25884-1D72
Date: Fri, 17 May 2019 14:58:52 GMT
Call-ID: 4792c68d05754214b975a6482060dba7@10.1.20.55
CSeq: 300 NOTIFY
Content-Length: 0


May 17 14:58:52.425: ISDN Se1/0:23 Q931: TX -> RELEASE pd = 8 callref = 0x0092
Cause i = 0x9090 - Normal call clearing
May 17 14:58:52.465: ISDN Se1/0:23 Q931: RX <- RELEASE_COMP pd = 8 callref = 0x8092
Cause i = 0x8190 - Normal call clearing


===== Nortel DCH Trace =====
>ld 96
DCH000
.set msgo 11 mon 0
.set msgi 11 mon 0
.enl msgi 11
.enl msgo 11
.
DCH000
.
DCH 11 UIPE_IMSG CC_SETUP_IND REF 00004900 NCALL TOD 8:58:52 CK 077D6883
CALLED #:3201 NUM PLAN: UNKNOWN TON: UNKNOWN

DCH 11 UIPE_OMSG CC_SETUP_RESP REF 0000C900 NCALL TOD 8:58:52 CK 077D6890

DCH 11 UIPE_IMSG CC_RELEASE_IND REF 00004900 NCALL TOD 8:58:52 CK 077D6900
CAUSE: #16 - NORMAL CALL CLEARING

DCH 11 UIPE_OMSG CC_RELEASE_RESP REF 0000C900 NCALL TOD 8:58:52 CK 077D6908
CAUSE: #16 - NORMAL CALL CLEARING

==========================================

I'm really hoping someone here has some insight into perhaps a misconfig on my end. My suspicion is that it's something lurking in the CDB perhaps, OR it's a bug requiring a patch....

As always, any and all help is immensely appreciated!

Thanks,
bc
 
The 3201 appearing on several phones very well could be the issue because it has no idea what TN to light the MWI, this is definitely an issue with Call Pilot. Easy enough to test though, right?
 
Thats a great point... I'll have to try this today :)

I did try this *partially* this weekend, but with no success, but I think I need to take it one step further during today's test....
My current config is that 3201 appears as the Primary DN (SCR) on 2 phones in my home office, then I have it as an SCR on key 04 on a phone in my workshop. In my last test this weekend, I had removed the 3201 DN from the secondary phone in my office, but I had not tried to remove the appearance on key 04 on the workshop phone.

Either way I'll try it out in a few and will post back with results. This is definitely an interesting one.

Thanks again KCFLHRC!

bc
 
I Know nothing about Unity or Cisco but Call Pilot definitely needed a unique single appearance DN for the MWI, hope that solves your issue.
 
No worries at all. From what I can see in the Cisco logging everything looks good, and the detail of CP requiring a unique single appearance is very helpful in that I'm guessing Cisco's QSIG implementation would (hopefully) follow suit, so removing the additional SCRs I have for 3201 would make perfect sense as a next step.

I'm also trying to dig up an example trace (mostly googling) of a successful QMWI messaging interaction from a DCH perspective. I see the output that I posted above from LD 96 so there is acknowledgement and it looks like the call sets up but is immediately terminated -- is that normal for that, or is anything else exchanged?

Either way, thanks again, I'll drop updates in here once I try removing all the other SCR 3201s.

bc
 
Just tried removing the SCR from all but my desk phone, EDD'd, and rebooted the whole Nortel system. After 3 tests looks like its made no difference so far.

I'll keep looking :)

---

Thanks,
Dmitry Barsky, REM
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top