DNIS delivery over TIE trunks

[teekow]

Site A receives DNIS 3602 and it is IDC'd to DSC 8280. 8280 is a CDN at site B which is acquired by Symposium. The CDR record at site A shows "DNIS 3602". The CDR record at site B shows "DNIS 8280". I think I am missing a configuration at one or both PBXs. I don't think it is a symposium issue. I have DNIS:Yes for all routes and OPTNI in the CDB FTR gate opener. I have tried using IDC to a dummy ACDN and a phantom TN both forwarded to 8280 with same result.

Any ideas?

Rob

 

[3Sixty]

What about IDC have you it set to yes and pointed to the correct IDC table.

Marshall

http://www.nortelsupport.net

 

[teekow]

Yes, I have IDC:yes DCNO:2. DCNO 2 has my conversion from 3602 to 8280. That part works, but after it gets to site B, it is presented as DNIS 8280 instead of the original DNIS 3602.

 

[3Sixty]

Hi teekow

What are you trying to do?

Have you a call coming in from the public network to site A and the forwarding it on to site B to be answered by a syposium server.

Marshall

http://www.nortelsupport.net

 

[teekow]

Yes, that is exactly what I am doing. Calls come in to site A on LD T1 with DNIS. I forward to site B over virtual trunks with SL1 dcchannel. My problem is the DNIS has changed after it is tandemned. I am confident that the carrier is sending the DNIS properly and the SCCS is fine. When I test inbound calls direct into site B, my DNIS routing works fine.

Any other thoughts?

Rob

 

[3Sixty]

How have you set up the CLID on the route OGDN,OGIS etc.

Marshall

http://www.nortelsupport.net

 

[Slackliner]

We just resolved a problem similar to this using a patch...

Nortel called it a designer patch, or at least in our case they said this patch is a "PI patch so it won't go in the DEP"...
p21402_2.cpp (for a pentium processor)

In any case, before we voiced a big complaint over their original intended design (to pass the CLID of the number making the transfer), they told us there was no fix.

(Specifically, on our site, the patch resolved a symptom where calls coming to Site A were handled by Call Pilot, and then when Call Pilot transferred the number to Site B, Site B was only presented with the CLID of the Call Pilot DN, not the original caller.) Not sure if the patch would apply to your situation, but it might be worth asking your service provider.

 

[teekow]

I found those prompts in the I/O document but it doesn't look like they show up when I print out the route. The description is "Outgoing Route Dn" and "Outgoing Identifier Send". Am I looking in the wrong place? Here are printouts of the 2 routes at "site A" Route 2 is my LD T1 and Route 30 are my virtual trunks:

REQ: PRT
TYPE: RDB
CUST 0
ROUT 2

TYPE RDB
CUST 00
DMOD
ROUT 2
DES LD
TKTP TIE
NPID_TBL_NUM 0
ESN NO
CNVT NO
SAT NO
RCLS EXT
VTRK NO
DTRK YES
BRIP NO
DGTP DTI
ISDN NO
DSEL 3VCE
PTYP DTT
AUTO NO
DNIS YES
NDGT 4
DDLY NO
DCDR YES
ICOG IAO
SRCH RRB
TRMB YES
STEP
ACOD 89002
TARG 01
CLEN 1
BILN NO
OABS
INST
IDC YES
DCNO 2
NDNO 2 *
DNAM NO
ANTK
SIGO STD
STYP SDAT
TIMR ICF 512
OGF 512
EOD 4096
DSI 34944
NRD 10112
DDL 70
ODT 1792
RGV 640
GRD 896
SFB 3

IENB 5
TFD 0
VSS 0
VGD 6
SST 5 0
NEDC ETH
FEDC ETH
CPDC NO
DLTN NO
HOLD 02 02 40
SEIZ 02 02
SVFL 02 02


PAGE 002

DRNG NO
CDR YES
INC YES
LAST NO
QREC NO
OAL YES
AIA NO
OAN NO
OPD NO
CDRX NO
NATL YES
VRAT NO
MUS NO
MANO NO
EQAR NO
FRL 0 0
FRL 1 0
FRL 2 0
FRL 3 0
FRL 4 0
FRL 5 0
FRL 6 0
FRL 7 0
OHQ NO
OHQT 00
CBQ NO
AUTH NO
TTBL 0
ATAN NO
OHTD NO
PLEV 2
ALRM NO
ART 0
SGRP 0
AACR NO

REQ: PRT
TYPE: RDB
CUST 0
ROUT 30

TYPE RDB
CUST 00
DMOD
ROUT 30
DES VIRTUAL
TKTP TIE
NPID_TBL_NUM 0
ESN NO
CNVT NO
SAT NO
RCLS EXT
VTRK YES
ZONE 005
PCID H323
NODE 1005
DTRK NO
ISDN YES
MODE ISLD
DCH 10
IFC SL1
PNI 00001
NCNA YES
NCRD YES
TRO YES
FALT NO
CTYP UKWN
INAC YES
ISAR NO
DAPC NO
PTYP ATT
AUTO NO
DNIS YES
NDGT 4
DDLY NO
DCDR NO
ICOG IAO
SRCH LIN
TRMB YES
STEP
ACOD 89030
TCPP NO
TARG 01
CLEN 1
BILN NO
OABS
INST
IDC YES
DCNO 2
NDNO 2 *
DNAM NO
ANTK
SIGO ESN5
ICIS YES
TIMR ICF 512
OGF 512
EOD 13952
DSI 34944
NRD 10112
DDL 70
ODT 4096
RGV 640
GRD 896
SFB 3


PAGE 002

NBS 2048
NBL 4096

IENB 5
TFD 0
VSS 0
VGD 6
SST 5 0
NEDC ORG
FEDC ORG
CPDC NO
DLTN NO
HOLD 02 02 40
SEIZ 02 02
SVFL 02 02
DRNG NO
CDR YES
INC YES
LAST NO
QREC NO
OAL YES
AIA NO
OAN NO
OPD NO
CDRX NO
NATL YES
VRAT NO
MUS NO
MANO NO
FRL 0 0
FRL 1 0
FRL 2 0
FRL 3 0
FRL 4 0
FRL 5 0
FRL 6 0
FRL 7 0
OHQ NO
OHQT 00
CBQ NO
AUTH NO
TTBL 0
ATAN NO
OHTD NO
PLEV 2
ALRM NO
ART 0
SGRP 0
AACR NO

REQ:

 

[johnpoole]

had me for a second.. 3602 idc to 8280, site b sees 8280, idc is the only load i know that kills the original dialed dn.. if you need 3602 on the far end , idc 8280 back to 3602, or on the dsc delete 4 and insert 3602

call flow:
dial 3602.
idc to 8280
dsc to far end as 8280
far end see's 8280, not 3602,,

that is what i would expect, the original dialed dn dies at the idc.. a dgt table, or another idc entry can be used..

john poole
bellsouth business
columbia,sc

 

[teekow]

I would suspect that as well for the "dialed DN" but keep in mind I am trying to get the original DNIS field not to change. These should be independent of each other as it relates to SCCS.

Any other ideas?

Thanks
Rob

 

[Muntanha]

I´m from Brazil, and my route is a E1 route (DTI2 card) The E1 trunk route has a item called CNIE. This item send the same CNI received for the PSTN to other route (for example, other trunk route to connect your PBX with other location). You must configure this item to "YES" on the "Site A" route. Best Regards.