Succession 3.0 upgrade issue

[dixiedogger]

Has anyone had any issues with external calles forwarding to menus? After upgrading to 3.0 any external calls that were forwarding to MM menus now say "the subscriber "forwarding number" does not subscribe to this service". Like it was an internally forwarded call. I have found a work around by placing the forwarding number in the vsdn table but INMHO you should not have to do this. External calls have always followed the called number not the forwarding number.

 

[one234]

Hi, what's the mmail release? Only rls 12 and 13 are compatible with succession 3


Marc D.

If Bill Gates had a nickel for every time Windows crashed... Oh wait, he does...

 

[dixiedogger]

Its 13

 

[Reusser]

I suspect the problem is from an outside line forwarded to a DID. With ISDN, the original called number (the outside line) is sent to voicemail - that number is not in the VSDN options.
If this is the problem, it has been a problem before 3.0

If however your problem is an internal DID extension number forwarded to voice mail then make sure the originally dialed DN is in the VSDN table.

You can test by forwarding to a set with display rather then voice mail - you will see the info voice mail sees.

 

[dixiedogger]

Reusser that is exactly the problem but we had no issues with it until 2 nights ago when we did the upgrade to 3.0. Then all of the sudden all the external people forwarding calls didnt go to the menus any more. We were on 25.30. Perhaps it is because of packages that were added and not the software version but at any rate is there a fix aside from putting every number in the vsdn table?

 

[0ut3rbank5]

Did you get resolution to this problem? Mine was just upgrade to Succession 3.0 from Rls. 25.40 and have vmail rls 13. I tried external number and I get the "you have been forwarded to the vmail system, however, the (10-digits) does not subscribe to this server, call answering is not available". I also tried to forward my call to another number in the office and I received the same only when I dial out. If I forward my call to the internal 4 digit extension, the vmail box picksup fine. Opened a ticket with Nortel (2 days had gone by). Adding 10 digits to my VSDN table is my temporary fix. I hope someone can shed some light on this for me. Thanks.

 

[johnpoole]

yes that has been a problem even with rls 24 with pri, i just put the 10 digit number into the voice service dn table or on the dept mailbox that needed the msg.. i haven't tried to add a 10 digit to an idc table but that may work.. if you idc a 4 digit number, the call will go to the voice ms of the output number, not the original dialed.. one of the few work arounds for

john poole
bellsouth business
columbia,sc

 

[0ut3rbank5]

Thanks, Johnpoole. This seems like a cumbersome fix. It was seamless before and why now we have to enter 10 digits of non-subscriber numbers to our system? I have 100s of external numbers that are forwarded to an emergency 800 number and I won't know those numbers until I get a 22-32 SEER code that indicates that calling number. I have used the mailbox and VSDN fix. Anybody else out there has a fix?

 

[dixiedogger]

Unfortunatly we had to use the same fix as John mentioned. I think it is more related to packeges in the switch that release. Its just they throw in alot of free packages into the succession that you had to buy previously.

 

[wdhb]

I had similar experience, but my setup was a bit different.

When users dialled a ddi for an extn at a remote site, (connected with an E1 tie), I had this set up as an ARRN, stripping the leading digits & outputting the internal extn number. Both switches where Rls25.40 & the issue only arose when I upgraded the remote site to Succesion 3.0. The extns at the remote site extns are setup as ACD's, NCFW back to voice mail, (Rls12) on the originating site. I found that if I set TRO to no on the RDB it cured this. As the d-ch still has TAT set in RCAP, I figure this wont cause any real problems.

I see the comments that this issue has been around for a while, but I only experienced this with the upgrade, and no customer data was changed during this.

 

[0ut3rbank5]

I have ISDN=YES; NCRD=YES but not getting the TRO prompt to define yes or no. RDB does not show the TRO prompt either. Where in the world is it hiding?

FYI - I have a technical user who was positive that he experienced the same exact problem I have and there were patches to fix it. He had 20 patches downloaded and out of those 20 I didn't have but 2 patches. I asked TAC to downloaded these two last night and it didn't solve my issue so I'm thinking there might be another prompt(s) I need to tweak to make it to work.

 

[wdhb]

TYPE RDB
CUST 00
ROUT 52
DES WAITAKERE
TKTP TIE
NPID_TBL_NUM 0
ESN NO
RPA NO
CNVT NO
SAT NO
RCLS EXT
DTRK YES
BRIP NO
DGTP PRI2
ISDN YES
MODE PRA
IFC SL1
PNI 00052
NCNA YES
NCRD YES
TRO NO
CTYP UKWN
INAC NO
ISAR NO
DAPC NO
DSEL VOD
PTYP DTT
AUTO NO
DNIS NO
DCDR NO
ICOG IAO
SRCH RRB
TRMB YES
STEP

 

[srmega41]

Has anyone seen or heard of any patches that correct this? We have 76 Option 11's, with about 1/2 upgraded to Succession 3.0 in the last 4 months. We are aware of the TRO issue, but no one is saying if there is a patch. We had to turn of TRO on all routes that conencted two Succession sites as we did the upgrades. 3.0 - 25.40 works fine, 25.40 - 25.40 works fine, but 3.0 - 3.0 breaks with TRO enabled.

Many of the new VoIP products, based on H.323, use TRO-BA and TRO-CM to avoid multiple transcodings. This could be a major issue, if it has an impact.

Scott

 

[wdhb]

My instance is a 25.40b to Succ 3.0, (was 25.40b to 25.40b) & I had to turn TRO off for things to work as before

 

[spanton]

Nortel has developed a patch for this issue...I don't have the patch number with me but will get it tomorrow and update

 

[johnpoole]

yes if you look at your seer table you'll see an admin error " non-user 1803434xxx was for...ext, put that number either as an exten on as a voice service dn, on in your idc table.. i have several that are used as exten dn's and that puts them where they belong, my cell phone if fna to the switch to dump into my did mailbox, i had to add the full number to mb as a ext

john poole
bellsouth business
columbia,sc

 

[NTAK10]

Has anyone encountered a problem after upgrading to succession 3.0, customer started having problem with phones on the IP Expansion Cabinet. They sometimes encounter crackling noise where only they can hear the noise while the other party don't hear any noise.

Just don't know if this problem is related to the upgrade or not. The Expansion cabinet has no survivability as this not included in their package and they are using a NTDK8305 cable with a NTDK20EA SSC Card. The following are the datafill:

>LD 117
OAM000

MEM AVAIL: (U/P): 906063 USED U P: 186669 86915 TOT: 1179647
DISK RECS AVAIL: 369
SURVIVABILITY AVAIL: 0 USED: 0 TOT: 0
=>

=> PRT SURV 2
Media Gateway/Expansion Cabinet 2 SURV NO



=> PRT CAB 2
Cab Capability OperMode Autosb Swoto
-----------------------------------------------------
2 NON_SURVIVABLE SLAVE YES 120

=> STAT AUTONEG IPR

AUTO-NEGOTIATE LINK PARTNER STATUS - EXPANSION/MEDIA GATEWAY PORTS
------------------------------------------------------------------
PORT Bandwidth Duplex Mode AutoNegotiate
========================================
IPR 1 UNKNOWN UNKNOWN -
IPR 2 100Mbps full duplex ON
IPR 3 UNKNOWN UNKNOWN -
IPR 4 UNKNOWN UNKNOWN -

=> STAT HOST
*** Active Internet Host Table ***
ID Hostname IP Address
-- localhost 127.0.0.1
1 PRIMARY_ENET 137.135.128.253
2 SECONDARY_ENET 137.135.128.254
3 LOCAL_PPP_IF 137.135.192.4
4 REMOTE_PPP_IF 100.1.1.1
-- REMOTECAB2 10.0.2.2

=> PRT IPR 2
port MAC address IP Address mask zero bw autoneg
----------------------------------------------------------------------
IPR 2 00:90:cf:05:b3:a2 10.0.2.2 255.255.255.0 YES ON

 

[tekice]

there is a patch to solve this issue can't remember the patch handle but will post it asap

 

[NortelGuy1979]

TTT...
Has anyone discovered the patch for the MM issue above? Spanton was going to post?
Thanks, Matt


Matt H.
TMC - KCMO, USA

 

[NortelGuy1979]

All,
Not sure if this correct (answering my own post) but our vendor's ATAC group said this is a new 'feature' or enhancement in the way the switch handles d-channel messages, or rather that it can interpret them in a new way, or something... I dunno! Anyone have any more info?
Thanks -M

Matt H.
TMC - KCMO, USA