Difference between revisions of "SHD FAQ"

Latest revision as of 11:01, 12 May 2015

What is frame-synchronization signal?

Frame synchronization signal is used for determining whether the clock on the local receiving end is synchronized with that on the remote sending end. A normal local frame synchronization signal means that physical links from the remote sending end to the local receiving end are working fine.

What new features do C-/D-/E-type boards have, compared with the old A-/B-type boards?

In addition to functions native to A-/B-type boards, C-/D-/E-type boards carry the following new features or improvements.

1) Enhanced stability of soft-faxing.

2) Used DMA technique for data reading and writing, minimizing host CPU cost for large-capacity voice recording and playback.

3) Improved echo-cancellation capability.

4) C-/D-type boards are compatible with PCI-X slot.

5) E-type boards support PCIe slot.

What does it mean if the synchronization indicator is off or blinking?

An unlit synchronization indicator means that the frame synchronization signal on E1 is abnormal and has skipped detection by the board; a blinking indicator means the frame synchronization signal is unsteady.

These could be due to:

1) Reversed reception/transmission cable;

2) Incorrectly configured master/slave clock on a digital board;

3) Bad or improper board grounding;

4) Reception cable not connected properly;

5) CRC-4 not set properly.

What causes an SS1 call to be abnormal?

1) Abnormal frame synchronization or multi-frame synchronization signal on local or remote E1;

2) Improperly configured trunk direction on a channel (it is required to configure a channel as outgoing or incoming trunk channel);

3) Improperly configured rule of number-reception for an inbound trunk channel;

4) The telecoms service provider does not offer the relative service or service data concerned are not ready.

What causes an ISDN call to be abnormal?

1) Abnormal frame synchronization signal on local or remote E1;

2) ISDN is not properly configured as network side or user side;

3) Incorrectly configured CRC check switch;

4) Incorrectly set TEI (terminal endpoint identification) value;

5) Incorrectly configured representation of channel identification information (number or timeslot diagram) for outgoing calls on ISDN link;

6) The telecoms service provider does not offer the relative service or service data concerned are not ready.

A good way to deal with such problem is to record the PBX information by our boards and then modify the on-board information to be consistent with that about PBX.

What does the SS7 server program Ss7Monitor.exe do? Must we run it?

The server program Ss7Monitor.exe sets up MTP3 protocol for SS7 and posses signaling message distribution and system monitoring functions. The sever program must be run in order to handle SS7 signals. Detailed information about the SS7 server can be found in the section on signaling server in SynCTI Programmer’s Manual.

What causes the following issues when running SS7 TUP or ISUP protocol?

• Issue 1: SS7 server (Ss7Monitor.exe) is out of service.

Possible causes:

1) Abnormal frame synchronization signal on local or remote E1;

2) Timeslot 16 not set by the remote PBX to transfer signaling messages;

3) Incorrectly configured IP address or parameters concerning signaling in the SS7 server program;

4) The telecoms service provider does not offer SS7 service or service data concerned are not ready;

5) Incorrectly configured local DPC or OPC;

6) Bad or improper board grounding;

7) You might have set the analog board to be master clock when using both digital and analog boards on a single computer. Note that the digital board should always provide the master clock.

• Issue 2: SS7 signaling links appear to be in a state of circuit reset.

Possible causes:

1) Abnormal frame synchronization signal on local or remote E1;

2) Incorrectly configured CIC number of PCM;

3) The telecoms service provider does not offer the relative service or service data concerned are not ready.

• Issue 3: SS7 server repeatedly receives SNT signal from remote end.

Possible causes:

1) When SS7 is not in service: MTP3 level of the PBX is not activated (mostly due to improper allocation of the CIC number of the PCM).

2) When in normal conversation: The PBX is checking if the lines are working fine.

• Issue 4: CFL signal is received during an outgoing call.

Possible causes:

1) The message sent out by Synway board is inconsistent with that identifiable by PBX. For example, the remote PBX accepts only IAI messages with caller-IDs, but the sending party makes a call without setting caller-ID and the driver automatically sends an IAM instead of an IAI message.

2) The telecoms service provider of the remote end does not offer the relative service or service data concerned are not ready.

• Issue 5: The SS7 board takes 1 to 2 minutes upon service set-up before it goes into an ‘idle’ state.

This is perfectly normal. The Synway’s SS7 board automatically sends a circuit-reset message to the remote end immediately after the service is set up. It then changes the relative channel to “idle” upon receipt of a circuit-reset message from the remote end. However, certain PBXs will wait for 1 to 2 minutes before they send out a circuit-reset message.

• Issue 6: How many signaling link sets does an SS7 board support? How many signaling links does each set support? Are multiple DPCs and OPCs supported?

An SS7 board supports up to 48 signaling link sets. Each set supports up to 16 signaling links. At most 48 OPCs and 48 DPCs are supported.

• Issue 7: When calling out in SS7 TUP or ISUP, the remote PBX sees the received calling-party number to have an extra ‘0’ at the end.

This can be resolved by setting the item ‘SetSTSignal’ to ‘1’ (the end pulse signal to be sent after sending calling-party number) in the configuration file ‘ShConfig.ini’.

• Issue 8: Why not call in when the TUP or ISUP channel is IDLE?

Possible Causes:

1) The PBX did not route the incoming call to the corresponding trunk channel of the board. Check the information “MP3 monitoring terminator: MSU from remote end” on the Ss7Monitor.exe interface. If neither IAM nor IAI message is displayed, it indicates that the PBX did not send the call data to the board. In such case, you shall examine the user layer business data at the PBX end to see if they are correct.

2) The number-receiving rule for SS7 at the board end is not set accurately. Check the receiving and transmitting interfaces of Ss7Monitor.exe. For TUP channels, if you see from those interfaces that the board sends the UNN (Unallocated Number) or ADI (Address Incomplete) message after receiving the IAM or IAI message from the remote end, it indicates that there is something wrong in the settings of the number-receiving rule. For ISUP channels, if you see from those interfaces that the board sends the REL (Release) message with the cause indicator 80 or 81 after receiving the IAM message from the remote end, it indicates that there is something wrong in the settings of the number-receiving rule. In such case, you shall execute ShCtiConfig.exe and set the number-receiving rule according to your actual calling-party number.

• Issue 9: Why not call out when the TUP or ISUP channel is IDLE?

Possible Causes:

1) The number-receiving rule at the PBX end is not set accurately. In such case, you shall examine the user layer business data at the PBX end to see if they are correct.

2) The called-party number is insufficient in length. You shall append digits to complete it.

3) The remote end cannot recognize the callerID as the board did not send the ST signal following the callerID. You shall set the configuration item SetSTSignal=1 under the section [TUP] or [ISUP] in ShConfig.ini.

4) The PBX rejects or disconnects the call because some other parameters at the board end (e.g. the nature of connection indicator, the forward call indicator, the calling/called party number, the calling party’s category indicator, the transmission medium requirement, etc.) do not match those at the PBX end, or because of some other reasons (e.g. the calling-out feature is restricted by the PBX). In such case, a common solution is to modify the message sent out from the Synway board to be the same as those sent in to the PBX. For example, if the transmission mediums for ISUP are different at the board and the PBX ends, change it to comply with the PBX.

How to deal with call failure or PCM instability in connecting digital board to optical transceiver?

1) Check if the board has a correct clock setting and if it is grounded properly.

2) Use the PBX to perform a self-loop testing on the board to ensure the good condition of lines.

3) Directly connect the board to the PBX and not through the optical transceiver, to find out if something is wrong with the connection of optical transceiver.

4) See if the impedance of board conforms to that of optical transceiver.

5) Check if the CRC-4 check switch is set properly.

Why there is so much noise and why do calls sometimes cut off when using digital trunk boards?

This is mostly due to line fault in the digital trunks, for instance, loose contact between the head and jack or broken lines. It is suggested that the remote PBX perform a self-loop testing on both incoming and outgoing trunk lines when the board is properly grounded to check if the lines are working fine.

How does a digital trunk voice board receive numbers with different prefixes?

Configure the number-receiving rule to prefix mode.

Is it mandatory to set TS16 for signaling transfer on a digital board which supports SS7?

The A-type, B-type and C-type SS7 digital boards support signaling transfer on TS1 or TS16, but not on both at the same time. The D-type and E-type SS7 boards can support signaling transfer on whichever timeslot except TS0 by proper configuration.

How to deal with the echoes produced by the device connected to Synway digital boards?

Echoes are cancelled at the end they are produced. Therefore, for echoes produced at the end of digital boards, you can cancel them by changing the board model to SHD-120D-CT/PCI/EC or SHD-240D-CT/PCI/EC which supports echo cancellation in hardware.

How to deal with link breakup on digital trunk boards and its induced call cutoff?

1) Check if the board has a correct clock setting and if it is grounded properly. Refer to Question 9 in Chapter 1 for the correct grounding method.

2) Use the PBX to perform a self-loop testing on the board to ensure the good condition of lines.

3) See if the impedance of board matches that of PBX.

What is probably the cause for appearance of alarm, PCM asynchronization or unusable channel state on the end of PBX when it connects to Synway E1 boards?

If the remote PBX alarms during its connection to Synway E1 boards that there is a block at the board end which causes failure in calls or the PBX shows with instable PCM synchronization or unusable channel state, this is probably because of improper CRC-4 setup.

CRC-4 is used to perform a cyclic redundancy check of multiframe signals, viewing if there is something wrong with the multiframe transmission. The driver sends the CRC-4 package through Timeslot 0 and the configuration item CRC-4[i] determines if the package is opened or closed. 0: Closed; 1: Opened (default). The driver does not do any thing about the CRC-4 package passed from the remote PBX. The effect of the CRC-4 check switch on E1 lines are as follows.

1) The remote PBX asks the Synway board to send CRC-4 but the board does not. Then the PBX gives the alarm information saying it fails to make normal calls. In such case, the channel seems to stay in idle or other states which are all not true,

2) The remote PBX does not ask the Synway board to send CRC-4 but the board sends. If the PBX works well, it means there is no effect on the PBX; if the CRC-4 is used to solve such problems as instable PCM synchronization and unusable channel state, it means there are some effects on the PBX.

What is the problem and what to do if the impedance of digital board does not match that of PBX?

The following problems may appear:

1) PCM synchronization goes instable;

2) Channels on Synway boards stay in an unusable state;

3) Instability in links induces call cutoff.

See below to find proper ways to solve these problems in 3 different situations.

1) For 16E1 and C-/D-/E-type digital boards, modify the configuration item PcmLinkType[n] in Section [boardId=x] of the file ‘ShConfig.ini’ to reset the impedance. 0 means 120Ω twisted pair cable is used as PCM link, while 1 means 75Ω coaxial cable is used as PCM link.

2) For digital boards with impedance jumpers, simply change the jumping mode to switch the impedance between 75Ω and 120Ω. The default factory setting is 75Ω in which condition the jumper cap short-circuits two contact pins. Once pulling out the jumper cap, the impedance becomes 120Ω.

3) For other digital boards which neither have impedance jumpers nor allow impedance change by resetting configuration items, the impedance is determined by hardware. If there is a mark ‘120Ω’ on the label of board model on the back of board, it is a digital board with impedance of 120Ω; or otherwise, it is a digital board with impedance of 75Ω.

Refer to relevant hardware manuals of those digital boards with impedance jumpers for particular location and treatment of jumpers.

How to enable the Hide-A-Caller function for digital trunk boards?

The Synway digital board sends the calling party number and the PBX once receiving the message sends only rings without the calling party number to the telephone. This is called Hide-A-Caller function. It is enabled in slightly different ways for various signaling protocols.

• SS7 TUP

Modify the Calling Line Identity indicator before sending the IAI message. To be exact, invoke the function SsmAutoDialEx(ch , szPhoNum, wParam) and modify the parameter wParam, such as SsmAutoDialEx(0, 110, 0x04).

• SS7 ISUP

Modify the Limit on Providing Address indicator in the calling party number before sending the IAM message. To do so, you may reset the configuration item DefaultIAM_CallerParam or invoke the function SsmSetIsupFlag.

Set under Section [ISUP] in the file ShConfig.ini: DefaultIAM_CallerParam＝0x1401;

Invoke the function SsmSetIsupFlag(ch, nType, dwValue, pV) and modify the parameter dwValue, such as SsmSetIsupFlag(0, 1, 0x1401, NULL).

• ISDN

Modify the Presentation indicator in the calling party number before sending the SETUP message. To do so, reset the configuration items under Section [ISDN] in the file ShConfig.ini (if the following configuration items can not be found in this file, they should be added manually).

PresentNumber =1: Sets the field in the signaling message that determines whether to display the calling party number. 0: not display; 1: display (default).

What problems may be caused if board clock is wrongly configured? How to set it properly?

The incorrect clock configuration may result in the following problems.

1) A blank screen appears and the computer fails to start;

2) Fax data transmission may be interrupted, which brings about code slip;

3) An E1 link goes instable or becomes disconnected, which disrupts the call.

There are two clock settings: one is for the system involving all voice boards concerned, and the other is for PCM on digital station tap boards. They both should be performed properly.

1) Clock setting for whole board system

By using the configuration item WhoSupplySysClock in the file ShConfig.ini under Section [SystemConfig], you can set the ID number of the board that provides the clock for the whole system, with the value range of 0~N-1 or N.

i. The value N indicates all board clocks within the system should be enabled. It is applicable to such situation that all boards within a system do not connect to each other over bus.

ii. The value -1 indicates the board is independently used as a slave board. However, to set this value, you should manually modify the item WhoSupplySysClock in shconfig.ini. Especially in such situation that you use boards from Synway and other manufacturers within a system, don’t forget to select a manufacturer’s board to provide system clock. If boards from different manufacturers all provide system clock, the computer probably can not start with a blank screen on it, or other abnormal phenomena may occur.

iii. 0~N-1 indicates the board specified by this parameter provides the clock, while other board clocks are all disabled. It is applicable to such situation that all boards within the system connect to each other over bus. In a system containing both digital and analog boards, you’d better choose the digital trunk board which connects with the PBX to provide the clock.

2) Clock setting for PCM on digital trunk boards

This clock setting is for a system involving digital trunk boards to get the synchronization of system clock and PBX clock. The Synway driver offers three modes for such clock setting: line-synchronization mode (master clock), free-run mode (master clock) and slave clock. Usually, if the PBX can provide a clock, the board which supplies system clock sets a PCM on it with the line-synchronization mode (master clock) and other PCM with the slave clock mode; if the PBX can not provide a clock, the board which supplies system clock sets a PCM on it with the free-run mode (master clock) and other PCM with the slave clock mode.

When you use a DTP series board monitoring the ISDN E1 line, if such problems as "what you have recorded is nothing but silence", "a single call is divided and recorded into several voice files", or "several calls are recorded into a voice file" occur, what is the reason for them and how can you deal with them?

There are two ways allowed for E1 devices to number the channels: using the continuous codes (1-30), and using the discontinuous codes (1-15, 17-31). Generally speaking, E1 devices use discontinuous codes to number the channels, that is, use Timeslot 16 to deliver signaling messages and the rest Timeslots 1-15 and 17-31 to deliver voice data. However, some particular devices (such as T1-to-E1 converter) may use continuous codes to number the channels, that is, use Timeslots 1-30 all to transport voice data.

Such situations as we mentioned above in the question will probably occur when the numbering method set by the Synway driver is different from that set by relative parameters for the monitored lines. As the Synway DTP series boards use discontinuous codes to number channels by default, if the device you use adopts continuous codes to number lines, the signaling messages and voice data on Timeslots 16-31 will become staggered. For example, the status displayed for Channel 18 is actually the status of Channel 19, but what you have recorded is still the voice data on Channel 18. In such situation, if there is a call on Channel 19 but no call on Channel 18, what you record is just silence but the status displayed is ‘Connected’ or ‘Talking’; if there are several calls on Channel 20 but only one call on Channel 19, what you record is only a call but it is divided into several voice files to correspond to the several calls on Channel 20; if there is only a call on Channel 19 but several calls on Channel 18, what you record are several calls but they are put together into a voice file to correspond to the only call on Channel 19.

To solve these problems, you can modify the setting of the configuration item SpyT1TransE1Line in the Synway configuration file ShConfig.ini, Section [SpyPcm], to change the numbering method. Once the issues mentioned above appear, change the value of this configuration item to 1.