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!

Fujitsu F9600 to Cisco Call Maneger via DMS-100 1

Status
Not open for further replies.

rnbarrett

IS-IT--Management
Jul 31, 2012
10
0
0
We're trying to test interoperability between a F9600 XL R15 and a Cisco Call Manager (8.x) using DMS-100. QSIG is not licensed on our F9600. We really want caller name and number flowing back and forth, if possible. Currently, caller name and number show up on Cisco handsets when calls come from the Fujitsu, but not vice versa. Calls from the Cisco to the Fujitsu only show the number. Can anyone offer advice about where to check settings and what they should be? I think the gateway is a Cisco 2921.
 
Thanks! We tweaked a few settings, including the "Send extra character" you mentioned, and have things working almost 100%. The only remaining item is that the Fujitsu is not sending the called name back when calls are going from Cisco to the Fujitsu. While calling name and number work well in both directions, called name is only going from Cisco to Fujitsu. We've done a few debug traces on the Cisco gateway - the data just doesn't seem to be coming from the Fujitsu. Still working on it...
 
The name usually does not display until the call is connected.
For the Fujitsu to send the name to the Cisco, verify the ARS route to the Cisco has the NAMF feild set to "1" and the SVP,2,180 is set to a "1"
CHA ARSR, ARSTB, POS, [FRL], [PTNNO],,,,,,,,,[LARF],[CMPF],[CDNFG],[TON],[NPI],[NAMF]

NAMF: Calling party name information sending
flag (0 or 1):
• 0: Sending not available.
• 1: Sending available.


Example of the Fujitsu ARS route
# ARS ROUTE TABLE LIST # 12-08-08 WED 13:10 PAGE-001

ARSTB TNN POS TGN FRL PTNNO T0 T1 T2 T3 T4 T5 T6 T7 LARF CMPF
(NARSTB) CDNFG TON NPI NAMF

500 0 1 500 0 0 * * * * * * * * 0 0
0 0 0 1 <--NAMF>
 
Will make sure I check that out - that's good information to know.
 
Mike - generally speaking: if you were migrating a few thousand users from a Fujitsu 9600 XL to just about any VoIP system, and you needed to migrate those extensions one at time, in non-consecutive order, and ensure people keep their phone number/extension, would you recommend using DMS-100 or QSIG? I'm asking from a non-Avaya VoIP perspective since Avaya supports FIPN with the help of Altura.
 
DMS-100, since I've seen very few Fujitsu systems have the optional QSIG software features installed.
As long a ISDN CO Pri Basic service was installed on the Fujitsu, you have the DMS-100 capability.
The worst part of the migration is when the migrating users want to keep their extension numbers.
The Fujitsu numbering plan can run out of space in the numbering plan tables. Usually the extensions are in the NPSYS as 1XXX. It’s when you start to put in individual numbers (1111, 1112, 1113...etc.) that the NPSYS table can run out of room to add new access codes (IE: TTID -8 CO trunk ).
Vacant DN routing can help. It’s also easier to put the new PBX platform in front of the old PBX platform. The newer systems have more room in the databases for programming. The Altura CS / Avaya feature is a great solution, until Avaya broke several parts of the inter-operability, as SIP became more of their focus. (The biggest problem is Message Waiting, when from a SIP endpoint, SIP MWI does not function with FIPN, but MWI from FIPN will travers the Avaya and Fujitsu)

 
Does Vacant DN require QSIG? My understanding is that you have to set up the PRI as a tie instead of a CO trunk in order to use Vacant DN (and you need QSIG to get the PRI tie).
 
Vacant DN is similar to call forwarding. It uses a DSTNO prefix to steer the call to a particular trunk group.
The feature is available on all Fujitsu 9600 systems.

UNASSIGNED DN TRANSFER TO ANOTHER PBX
DESCRIPTION This feature makes it possible for a station user to transfer a call to an outside directory number via a specified trunk group.
OPERATION When a user dials an extension number which does not appear in the user's telephone system, the F9600/F9600c will search for the
entry in the unassigned DN table. If the DN is registered in the table, the call is routed over a specified trunk group to a remote location. If
the unassigned DN is not found in the table, the call is handled by vacant number intercept or flexible intercept.
Station users may relocate their instrument from one switch to another and continue to receive calls from their original location by
assigning the extension to the unassigned DN table. Unassigned DNs should also be programmed at the new location to receive incoming calls.
Unassigned DNs can be programmed as the destination of the following features:
• Call forwarding.
• ACD conference VMS.
• Consultation hold.
• Eight-way conference.
• Flexible intercept.
• Hotline.
• System forwarding.


UNASSIGNED DN TRANSFER TO ANOTHER PBX
PREREQUISITE None
NUMBERING PLAN Refer to the Flexible Station Numbering Plan feature in Chapter 6 of the Feature Description manual.
CALL PRIVILEGE CONTROL None
INSTALLATION / ASSIGNMENT
Assign Transfer DN ASS VACDN, DEL VACDN, DIS VACDN
Format:
ASS VACDN,[<tenant no.>:0],<directory no. of vacant DN>,<forwarded destination no.>
Assign Forwarded Destination
ASS DSTNO, DEL DSTNO, DIS DSTNO
Format:
ASS DSTNO,<destination no.>,<dialing no.>
NOTE: The following services can be used with this feature:
• Call forwarding.
• Hotline.
TIMING PARAMETER
Tone Detect Timing and Pause Timing
Define the timing value by entering the dialing number using the ASS DSTNO command.
FEATURE ACTIVATION /
OPTIONS
None


ASSIGN VACANT DN DESTINATION COMMAND DESCRIPTION
This command is used to assign a forwarded destination when a vacant station directory number is dialed.
COMMAND FORMAT
ASS VACDN, [TNN:0], DN, DSTNO
PARAMETER DESCRIPTIONS
TNN: Tenant number (0 to 15)
DN: Vacant station directory number (3 to 5 digits)
DSTNO: Forwarded destination number (0 to 4062)
SECURITY LEVEL
Security level: 2
Stop function: Not available
Data save: Necessary
SPECIAL INSTRUCTIONS
1. Always omit the TNN parameter in a joint tenant system.
2. The vacant station directory number must be based on the system numbering plan (ASS DNRAN, ASS NPSYS).
3. The destination number (DSTNO) is used to specify a destination to which the calls will be forwarded. The actual dialing number of the destination is assigned using the ASS DSTNO command.
4. An actual station directory number (not vacant) can be entered at the DN parameter. Calls will not be forwarded, however, until the station directory number is deleted.
5. The virtual VMS directory number is assigned to use the ASS VVMDN and cannot be entered at the DN parameter.



 
Thanks, again (and again, and again) [shadeshappy]
 
One small update with a question. We've got our local Fujitsu provider on site and they/we can't set everything up so what we have a valid DSTNO to use fo rthe Vacant DN entries. We're being told that we need to use a tie, instead of a co trunk, between the Cisco and the Fujitsu so that we can have a valid DSTNO to use for the the Vacant DN's. We're also being told that we can't do a tie line with DMS-100, that we need to use QSIG.

Are we overlooking something basic here?
 
The Cisco to Fujitsu trunk group can be any TLT (Trunk line type), If your trying to use VACDN routing, the DSTNO would be an access code to either dial a trunk group access code or to send the call to AAR (Automatic Alternate Routing) using AARLC codes and ARS routes.

The ARSDM can be used in the ARS route, to remove any access code that the Fujitsu is passing on to the Cisco that are not desired.
If you already have QSIG on the Fujitsu, great then you can use those features. I have not seen many Fujitsu system with the QSIG features installed (DIS SOFT). Since you can not get new software, DMS-100 is the only choice.

It can get complicated if you have a range of one hundred extensions, and only a couple of these are moving to the Cisco in this phase.
I would build a AAR NPSYS access code to use the AARLC tables to send the call to a particular ARS route to get to the Cisco.
then use the DSTNO to dial the AAR access code to pass the call to the AARLC for routing instructions.

*** for best viewing, copy and paste into notepad and use the Courier New Font)

AUTOMATIC ALTERNATE ROUTING (AAR) – ASS NPSYS
FLEXIBLE ACCESS CODE
TTID: 0, 1, 4, 7, 8, or omit
TNN: 0 (omit) to 1
DS: feature access code
EDL: 30 (maximum number)
FNO: 304 (enbloc sending)
TGN: omit
TGX: omit (not used)
AJC: omit
RDD: number of DS digits (automatically set for enbloc sending if omitted)
DOC: omit
TTN: omit
Example When the AAR access code (DS) is 8:
DS EDL FNO RDD
8 30 304 1

Making a CO trunk a TIE line type.
DIS TG, CHA TG, ASS TG
[highlight #FCE94F]TLT:[/highlight] Trunk line type (0 to 8):
• 0: CO line.
• 1: FX line.
• 2: WATS line.
• 3: Tie line.
• 4: DID line.
• 5: CCSA line.
• 6: RLT line (release link tie trunk).
• 7: DNIS line.
• 8: Not used

ASSIGN AAR LOCATION CODE
COMMAND DESCRIPTION
This command is used to create an AAR location code table. These tables define the correspondence between
the AAR (extended) location code and the ARS / AAR route selection table number. A location code and an
ARS / AAR route selection table number are assigned to each AAR location code table.

COMMAND FORMAT
ASS AARLC, [TNN:0], CODE, [XLC], ARSTB, [EDL:7], [ID:0]
PARAMETER DESCRIPTIONS
TNN: Tenant number (0 to 15)
CODE: Location code (1 to 3 digits)
XLC: Extended location code (1 to 2 digits)
NOTE: The extended location code should be the first one or two digits of a station directory number.
ARSTB: ARS / AAR route selection table number (1 to 1023)
EDL: Effective digits length (1 to 30)
ID: Location code identification:
• 0 or OTHER: Location code of other system.
• 1 or OWN: Location code of resident system.



Examples
Fujitsu to Cisco B channel trunk group:

# TRUNK GROUP DATA LIST # 12-10-11 THU 10:27 PAGE-001

TGN TYP TID TNN SPC AKI COF [highlight #FCE94F]TLT[/highlight] DGN RGN COS RSM FRL TRS HNT NAME
AKW AKR AKB RGT AOT GRD REL HKS AFT SHK RHK OPR DMF
MIN PRE MAK BRK DGT PST PBO PBF COP PGT MID
PAC MBC STG DT IAS DTS ABS DTK OOC NOC PTF TCS TCR TDT VCM OGF
CRC
NSF NSFFG PRMFF PRMFV CDNFG TON NPI

500 5 38 0 5 0 0 [highlight #FCE94F] 3[/highlight] 0 1 1 5 7 0 1 'CISCO'
0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0
28 0 0 0 0 0 0 0 1 21 0 0 0 0 0

0 0 0 0 0 0 0


END 12-10-11 THU 10:27 (FUJITSU XL)

ARS route table
ARSTB TNN POS TGN FRL PTNNO T0 T1 T2 T3 T4 T5 T6 T7 LARF CMPF
(NARSTB) CDNFG TON NPI NAMF
500 0 1 500 0 0 * * * * * * * * 0 0
0 0 0 1

AAR Location code

# AAR LOCATION CODE LIST # 12-10-11 THU 10:30 PAGE-001
TNN CODE XLC ARSTB EDL CODE XLC ARSTB EDL CODE XLC ARSTB EDL
0 308 500 5

END 12-10-11 THU 10:30 (KCMO CITYHALL XL)

Example of extension range 308XX being assigned to the Cisco using AAR in the NPSYS.

# NUMBERING PLAN LIST # 12-10-11 THU 10:32 PAGE-001
TNN= 0
TTID= 0
DIGIT EDL FNO TGN TGX AJC RDD DOC TTN DN SVN
308 5 304 0 3 0


Example of a trunk group access code
# NUMBERING PLAN LIST # 12-10-11 THU 10:36 PAGE-001
TNN= 0
TTID= 0
DIGIT EDL FNO TGN TGX AJC RDD DOC TTN DN SVN
*#500 30 512 500 5 0

Example if striping the access code from the Fujitsu when using TG access code (Fujitsu will always send the access code, so it needs to be stripped off using Trunk digit modification)
# TRUNK DIGITS MANIPULATION LIST # 12-10-11 THU 10:37 PAGE-001
TGN SKP SE DIGIT MFEDL
500 5 0




 
That's a great explanation that even I can understand. Thanks.

We have about 4,000 extensions that will be migrated over in non-sequential order, so we're trying to ensure we have a solution that will enable a piecemeal migration without over running the capacity of the Fujitsu.

We don't have QSIG licensed, but we (and anyone else) *can* get QSIG licensed, along with the appropriate disks to update the PBX, direct from Altura.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top