Debugging

NBE Driver failed to Install Because Windows took over installation

1. Go under Control Panel => Add/Remove Programs

2. Uninstall the Sangoma windows driver package entries

3. Go under C:/Windows/System32

4. Search for sdladrv string

5. Delet all the .INF and .sys files resulting from your search request

6. Uninstall NBE

7. Reboot the System

8. Re-Attempt installation!

It is important to note that you must explicitly deny Windows during the setup process.  Our driver only installs properly when using our installation scripts, and the Windows Installation Wizard will not be able to install our cards.

 NBE fails to start

If NBE Gateway fails to start, the reason will provided in GatewayDebug.log. 

From the WebGUI: File Browser -> logs -> GatewayDebug.log

Open

If you get the following message, you will need to download the GatewayDebug.log file:

Open

To do this, right-click on GatewayDebug.log and select Download

If the GatewayDebug.log files contains the following message, this means your Sangoma card does not have a hardware echo cancellor.  NBE requires that your Sangoma card has a hardware echo cancellor.  Please contact your reseller to make arrangements as your current card cannot be used with NBE:

Server With Multiple IP Addresses Will Not Start

Edit gw.properties files from the WebGUI, and change netborder.net.primaryIPAddress to the IP address you want NBE to listen on

or via your windows file management:

Edit the following file:

Place the following line anywhere in the above file:

X being the ip address that you want NBE to listen on.

After this is done start NBE again and it will start up.

After installation there are no Sangoma cards available

After performing a new install or a re-install of NBE you find that there are no Sangoma ports active, Windows says it found new hardware, and/or after configuring the cards in NBE the gateway fails to start.

The problem is that the Sangoma drivers did not install correctly and need to be re-installed.  You can confirm this by looking at the "Device Manager".  The Sangoma card(s) will show up as "Network Controller"

To solve the problem, uninstall the drivers, reboot and install the drivers again.

1. Go to the Windows "Device Manager" and uninstall the "Network Controller" by right-clicking and selecting "Uninstall".

2. Go to the Windows "Add or Remove Programs" and remove all "Windows Driver Package - Sangoma Technologies...", if there are any there

3. Reboot the computer

4. After reboot Windows will report that new hardware has been found and will try to install the drivers, click "cancel" to this window.  You will see a window for each Sangoma card you have.

5. Click on "Start -> All Programs -> Netborder Express Gateway -> Install Device Drivers".  A Command Prompt window will open up and the drivers will be installed.  If any "New Hardware Found" windows pop-up, click the "cancel" button.

6. Once the drivers are installed check in the device manager that the cards are detected properly.  In the example the system has an A200 and an A104 card installed.

Analog

 B-Channel[0] failed to setup callerID detector" In Application Log

 If you are seeing this error in your Application log then your ToneDecoder.dll file has not been registered correctly. 
To fix this go to "\Program Files\Netborder\Express\Gateway\drivers\sangoma\hw_abstraction_driver\" from the command prompt and run the command:

Once this is done then try to start NBE again to be sure the issue is corrected.

 NBE 2.0 can't open Analog B-channel

Symptom:  

NBE starts but on the "System Status" page of the Gateway Manager you see the following error message:

This error could occur if: - WANPIPE is not a valid wanpipe ID. 
 Edit the pstn-config.xml to specify a valid wanpipe for sangoma interface ID=<NBE ID value for A200>

Solution:

You can get this error message if you do not have your FXO modules plugged in the correct socket on the A200.  The modules have to go sequentially into the sockets, starting at the lowest numbered socket, and without any gaps.
The lowest numbered socket is the socket furthest away from the metal bracket on the lowest numbered card.
The lowest numbered card (when using an A200 with atleast 1 Remora card connected via a Backplane) is the left-most card in the bundle when looking from the metal bracket to the backplane.

Why Are Calls Not Hanging Up?

On analog lines the telco (FXS) has to tell the phone (FXO) to hangup.  The reason for this is the FXS can not control if the line is on-hook or off-hook as this is the FXO's role.  Example of this is if you leave a analog phone (in your house) off hook you will hear a fast busy tone, this is the telco indicating to you the call is over and to hangup.  The telco can have many different ways to indicate to your FXO to hangup the line. 
NBE by default has enabled most types of hangup detection, but it is possible that not the right method has been enable, for your telco.

1. Log into the webui and go to Configuration -> PSTN Config -> Call Control -> Analog Configurations -> Config1-FXO -> Disconnect Supervision Info as shown below. Then simply check off ALL the hangup detection options to make sure whichever hangup detection your telco is using is selected. Once this is done then SAVE the config.s as seen in the pic below, we still need to select 'Sit tone'.

2. Restart the gateway. Go to "Status and Controls -> Controls" then select "Restart Gateway". Then test to insure the issue is resolved. 

Cannot dial outbound

There is typically two reasons you can not call outbound with Analog.

1. Dial Tone Detection - There is no dial tone found on the line so NBE does not send the call out

2. Dialing Too Fast For The Telco To Collect Digits - Some telco's are slower then others and therefore a longer delay between picking up the line and sending DTMF is required

Below is how to correct both issues:

1. Dial Tone Detection
   Simply go to Configuration -> PSTN Config -> Call Control -> Analog Configurations -> Config1-FXO -> Outbound Call - Dialing Info -> Wait for Dial Tone, then simply set this option to "NO". Once done insure you save the config. 

   Once Config is saved restart the gateway. Go to "Status and Controls -> Controls" then select "Restart Gateway". Then test to insure the issue is resolved. 

    

2. Dialing Too Fast For The Telco To Collect Digits

   Simply go to Configuration -> PSTN Config -> Call Control -> Analog Configurations -> Config1-FXO -> Outbound Call - Dialing Info -> Pre Dial Delay (ms) then change "100" to "1000". Once done ensure you save the config

    

   Once Config is saved restart the gateway. Go to "Status and Controls -> Controls" then select "Restart Gateway". Then test to insure the issue is resolved. Also note if this does not resolve the issue then simply try "1500" instead of "1000" as this will allow for a longer delay. 

    

Analog Caller ID not working

 If your caller ID is not working then your caller ID type is either sent via DTMF which is not supported by NBE, or the caller ID comes before the first ring and is not being advertised with a polarity reversal from the telco (UK specific fsk caller id variant). Now to configure NBE to support caller ID coming before the first ring please follow the steps below. 

1. Log into the web interface http://<IP of NBE>:7783/.

2. Go to configuration -> PSTN Config -> Physical Configurations -> Analog Config -> Analog FXO Configuration.

3. In the FXO Configuration simply set "Enable Fake Polarity" to YES and "Fake Polarity Threshold" to "-12". As shown in the picture below. 

4. Click SAVE and go to "Status and Controls" to restart the gateway. Once restarted CID should work. 

Digital

Caller Name not showing up

The caller name arrives in a FACILITY message and the gateway is configured to get the caller name from a DISPLAY IE in the SETUP message. To get the caller name right, you will need to change the path configuration of the gateway as follows:

1. In the Pstn config tab of the Gateway Manager, choose "Call Control"-> "ISDN Configurations" in the panel on the left.

2. Double-click on the Call control config name in the ISDN Configuration Grid (usually FAS1-T1)

3. A Fas Configuration display menu will then appear, in the "Caller Name Location Method" scrolling menu, choose "IN-FACILITY-MSG"

4. In the "Wait Facility Delay (ms)" menu enter 100

5. Save the new configuration by clicking on the Save button.

6. If you've got more than one Call Control Configuration, you will need to perform operations 3 to 5 for all your Call Control configurations.

7. Restart the gateway

No Ringing on inbound Calls

To resolve this issue, there are two options:

• Set "Inband Progress Tones Generation" to ALWAYS

• Treat a SIP 183 as a 180

To Set "Inband Progress Tones Generation" to ALWAYS:

• In the NBE WebGUI, navigate to Configuration-> PSTN config->Call Control->ISDN configurations

• restart the NBE Gateway for changes to take effect

• if there is still not ringing on inbound calls, try chaging "Inband Progress Tones Indicator" (as seen in picture above) to  ALERTING, then BOTH (if persists), making sure to restart the NBE gateway after each change.  BOTH has the same effect as the default PROGRESS on 4ESS and 5ESS ISDN variant.

How to treat a SIP 183 as a 180 

1. If setting the "Inband Progress Tones Generation" to to ALWAYS does not resolve the issue then we can try treating a SIP 183 as a 180

2. To do this edit your routing rules using the "Routing Rules" tab in the webUI

3. Next go to your "primary_sip_out" rule and add the line <param name="sip.out.accept183" expr="true"/> as shown below. You can also add this to your "primary_sip_out_restricted" rule or any customer rules you have made from PSTN to SIP. Once done click "Submit Changes" then wait 10 seconds and place a inbound call to test. 

4. If this still fails then enable call recording and then go to NBE Troubleshooting Information  to enable logging as well. Then reproduce the call and send in all of the information requested at Collecting Debug  to support@sangoma.com.

    

 PRI span debugging

1. The first step is to check the physical layer connection between NBE and the telco.To do this we will need to use the wanpipemoncmd line tool.

   1. Open the windows command line tool : Windows Start -> Run -> "cmd.exe"

   2. To view T1/E1 Alarms on the first T1 of your sangoma digital card : 

      wanpipemon -i wanpipe1_if1 -c Ta

      The output of the command above will present status of all the different T1/E1 alarms, plus some error counters.

      OOF means the line framing is out of frame so we are receiving bad data. Also on E1 you can toggle the framing and this may correct the issue.
      AIS means one of the repeaters down stream are in alarm so speak with the telco about this.
      YEL means the telco is in alarm so call them and find out what alarm they are in
      LOS means loss of signal so the line is probably not connected. If the line looks good try a cross over cable. Note this is not the same as a ethernet cross over; pinouts are available at Cable Pinouts

   3. To view Communications/Error statistics

      wanpipemon -i wanpipe1_if1 -c sc

      If there are no positive alarms on the first T1 (wanpipe1_if1), check the next T1 (wanpipe2_if1), then the third (wanpip3_if1)...etc

2. If there are no physical layer issues, the next step is to ensure your signaling (D channel) is up.
   To do this simply open your NBE gateway manager (http://localhost:7783/) and click on "Status and Controls" and then select "Channel Status" in there. 
   Then ensure the status looks as shown below=idle (Blue colour)

3. Now if you have a different status other then "Idle" then refer to the legend below.

4. If you can not resolve the issue please visit NBE troubleshooting material and send all the log information to support@sangoma.com
   
   

5. If the D channel is up but calls do not complete:
   
   

   • place NBE into development mode by following the steps at Debugging . Once in development mode there will be a new log for each time in 

     eg. \Program Files\Netborder\Express\Gateway\logs\call-logs\2009\11November\27\11\.

     or you can simply locate the call-logs via the NBE WebGUI:

6. Now to start tracing the calls simply start with an inbound call first if inbound is not working. Now below is a trace of a working inbound call and one where the PBX does not respond to NBE's SIP messages.

   Inbound Call Where PBX Does Not Respond --> Coming Soon!
   Inbound Call That Works --> Coming Soon!
   
   

7. Below is a trace of an outbound call that the pstn side rejects the call and the other call is a working outbound call. Also note if you call out and the log file is not being made you ether do not have development mode enabled (step 4), or your pbx is not sending the SIP message to IP and port you setup in the quick setup.

   Outbound Call That Is Rejected From The Telco --> http://wiki.sangoma.com/NBE-pri-span-debugging-outbound-rejected
   Outbound Call That Works --> http://wiki.sangoma.com/NBE-pri-span-debugging-outbound-working
   
   

8. If you can not sort out the issue please visit NBE troubleshooting material and and send all that information to support@sangoma.com.

 How To Configure BRI Overlap Dialing Reception

On inbound calls, some switches (particulary in Germany) send the called party number (DNIS) in chunks using INFO ISDN messages after the initial SETUP message instead of the usual 'En-Block' mechanism which consists in sending the whole DNIS in the Called Party Number Information Element of the initial SETUP message. This method called 'Overlap Dialing' as opposed to the traditional 'En-Block' dialing method, is used to reduce call SETUP time and also to allow various combinations for number extensions. 

Since the 4.3.2 version of Netborder Express Gateway, reception of 'Overlap Dialing' is supported for BRI channels, for inbound calls. Thus NBE has now the capacity of collecting overlap digits from the PSTN for BRI inbound calls. Note that NBE does not relay the collected PSTN overlap digits to the SIP side in overlap mode, it waits for all digits to be collected from the PSTN before sending the SIP INVITE message containing all the collected digits 'En-Block". By default, this feature is disabled. To enable it you should follow these steps for each BRI call control configuration:

#1. In the Web UI, In the PSTN Config tab, click on the name of a specific BRI call control config under the ISDN configurations.

#2. In the BRI Call Control Config tab, expand the BRI  Overlap Dialing Configuration menu.

#3. In BRI  Overlap Dialing Configuration menu enter the Overlap Dialing Reception parameters as Follows:

• ISDN Overlap Digits Reception: ENABLED

• Minimum Number Of Digits: This parameter indicates the expected minimum number of digits to receive if Overlap Digits Reception is ENABLED. If the gateway timeouts while collecting overlap digits and the number of collected digits did not reach at least the value specified by this parameter, the call will be cleared with ISDN cause code 28 (invalid number format  - address incomplete). To Disable this behavior, set this parameter to 0. Default value is 0 (i.e parameter is disabled).

• Maximum Number Of Digits: If not 0, this parameter value should always be greater than the Minimum Number Of Digits parameter. If this value is reached while collecting overlap digits, the gateway will assume that Overlap Digits reception is done and will proceed with the call. If this parameter is set to 0, this parameter will be ignored and Overlap digits collection will end if the gateway times out or if an End Collection Sequence or a Send Complete Information element is received from the remote ISDN side. Default value is 0 (i.e paramter disabled).

• End Collection Digits: This parameter is a regular expression that will be used to verify if Overlap Digits reception is done. If blank (i.e not specified or only contains space characters) this parameter will ignored Overlap digits collection will end if the gateway times out or the Maximum Number of Digits (if not 0) is reached or if a Send Complete Information Element is received from the remote ISDN side. Default Value is ([0-9a-dA-D]+)?[\#\*]$ (i.e overlap digits collection will be stopped upon reception of one of the # or * characters).

   

 #4. Save your BRI configuration

 #5. Restart Netborder Express Gateway

Outbound Calls Failing

First enable development mode using the steps at Debugging . Once this is enabled, make a incoming call into the system. When the call is completed simply go to "File Browser -> logs -> Call logs" then navigate until you have found the log for the inbound call you made. Once you found the call it should look something like the one below. Find the circled parts below of the inbound call and take note of the value of each. In this example the ANI fields are not populated, then the DNIS values are both set to 1. 

 With these values you now know how the telco is sending inbound calls, so most likely the telco will want the same values set on an outbound call. So go to Debugging  to see how to set these values for your outbound call. Once this is done then outbound calls should start working. 

If the outbound calls fail still then look over the trace of the outbound call as you have done in the previous step for inbound calls. Verify the caller ID and caller name in the "pstn.out.ani" and "pstn.out.callerName" are set correctly. The telco may not allow you to set a ANI value of a DID you do not own. Below is an example of what it will look like. 

If the issue continues after this then send everything at Collecting Debug into support via emailing support@sangoma.com  

Inbound Calls with Unknown Caller Name Fail

In scenario T1/E1-->NBE-->SIP

When an inbound call comes, and the caller has an "unknown" caller id, the call is being rejected.

We need to distinguish between "Anonymous" and "Unknown", when the first one is just legit caller id but it's details are not shared and displayed, and the second is a completely unavailable caller id 

Ususally this happens with the older NBE firmware.

See below an example of dialling to 901-333-8820  from Unknown Caller Name

The call is being rejected due to the fact that the anti action in the dial plan did not fire any rule since this action was restricted.

Please tak a look in the "routing-rules.xml"

As we can see in the "routing-rules.xml" when a call comes to "default_sip_out" rule and it doesn't match, it goes next to "default_sip_out_restricted" and then we can see that the pstn.in.ani.presentationIndicator is being set to "restricted", which actually brakes the rule and nothing is being processed.

The solution, is to delete the entire line in the "default_sip_out_restricted" rule:

Then save the file "routing-rules.xml", and restart the NBE.

So then in this way you are solving the problem when two scenarios happen, when a caller id is restricted and cannot be hared, and when the caller id does not exist at all.

 Inbound Calls fail with "407 Proxy Authentication Required"

In scenario when an inbound call comes in the following path: NBE --> SIP --> 3CX, the 3CX rejects the call with 407.

>>>The INVITE is being sent from NBE towards the 3CX>>>

 INVITE sip:4190@192.168.100.250:5060;transport=udp;user=phone SIP/2.0
From: "unknown-caller-name" <sip:616489009@192.168.100.250:5066>;tag=pxip-callid-1436522429 -848400-3297-856ds-6144-b9ab19d0
To: "4190" <sip:4190@localhost:5060>
Contact: <sip:netborderexpressgateway@192.168.100.250:5066;transport=udp>
Call-ID: 7ef1c221-26ea-11e5-833d-e89ad7ccd111@Centralka
CSeq: 31761 INVITE
Content-Length: 286
Expires: 179
Allow: INVITE, ACK, BYE, CANCEL, NOTIFY, INFO, OPTIONS, REFER
Supported: replaces
Supported: 100rel
User-Agent: Netborder Express Gateway/4.4.6
Content-Type: application/sdp
Date: Fri, 10 Jul 2015 10:00:29 GMT
Via: SIP/2.0/UDP 192.168.100.250:5066;rport;branch=z9hG4bK7ef2d391-26ea-11e5-88ba-c19e45591929
Max-Forwards: 70

 >>> 3CX ends with rejecting the call with 407>>>

SIP/2.0 407 Proxy Authentication Required
Via: SIP/2.0/UDP 192.168.100.250:5066;branch=z9hG4bK7ef2d391-26ea-11e5-88ba-c19e45591929;rport=5066
Proxy-Authenticate: Digest realm="3CXPhoneSystem",algorithm=MD5,nonce="414d535c0bb028bd85:cedf713a672701757a04c32e379f03df"
To: "4190" <sip:4190@localhost:5060>;tag=ca4f4b61
From: "unknown-caller-name" <sip:616489009@192.168.100.250:5066>;tag=pxip-callid-1436522429 -848400-3297-856ds-6144-b9ab19d0
Call-ID: 7ef1c221-26ea-11e5-833d-e89ad7ccd111@Centralka
CSeq: 31761 INVITE
User-Agent: 3CXPhoneSystem 12.5.39117.982 (38810)
Content-Length: 0

The reason for this behaviour is behind authenticaiton that is being enabled here on the 3CX side which normally can be disabled on the 3Cx side.

An altenative way to resolve this issue on the NBE side is as follows:

1.  Login to the NBE GUI.

2.  Click on the File Browser tab.

3.  Navigate to root > config > sip-client-registration.xml, and click on this file

4.  On the right side of the screen you'll be able to see the content of the file. Scroll down until you reach <!-- Registrar --> section.

5.  In this section please replace the "company.com" by a hostname/IP of the IP-PBX(3CX) that the NBE is communicating to.

6.  Save the file by clicking Save Changes and restart NBE. This should fix the problem.

NOTE: The resolution provided above was applicable with 3CX interaction, and wasn't tested with other IP-PBXes 

If from what ever reason the method above did not work, then the best practise is to disable the registration on the 3CX side

To be able to do it please navigate in the 3CX:

3CX > VoIP/PSTN gateway > Sangoma > Advanced : Registration settings. Under "Require registration for", chose the "Do not require".

Then apply and generate the config file then upload back into the sangoma provisioning in the NBE.