4501 with SIP(PSTN) and NEC PRI(PBX) Routing Issues


Hello. I’m new here but not to the world of telephony, just my first rodeo w/ this specific device.

I have a registered SIP Trunk w/ 23 call paths (NetSapiens).
I have an ISDN PRI w/ 23+D channels - NEC 2000 IPS. (4 digit DID/esf/b8zs/NI2/unknown/unknown/master/pri_net)
Both show registered (blue status).

Inbound rule - from PRI (PBX outbound call, any digits, any length)

Inbound rule - SIP from PSTN (incoming from world) i.e. 1555803XXXX

Outbound rule (top rule) - to PRI (incoming 4 digits to PBX)
strip 7 (11 - 7 = 4 digits)

Outbound rule - to SIP (outbound to PSTN)

I can place outbound calls from the PBX intermittently, calls to the same number go out the PSTN (SIP provider). The caller ID shows the SIP account number instead of what the outbound caller-id the PBX is presenting.

The CDR records will show green when an outbound call goes through. They will show orange, red and sometimes not even list the call even though we received out of service tone. The CDR logs don’t seem to log every instance.

  1. What might cause the same outbound call pattern to be intermittent like this?

Shouldn’t we expect the same dial pattern = same results?

Inbound calls result in fast busy, call attempts do not show in the CDR logs. Checking the PRI trace I can see the outbound calls that completed, calls that don’t and calls that do not show in the CDR at all.

I have a screenshot of the CDR report showing mix of results + the PRI trace log but being new to thins forum I’m not exactly sure how to share it here.

Any help is greatly appreciated.


You can share a download link for the logs, and also screenshots of your pri interface settings

Did capture an ethernet trace to verify the sip logs as well?


Thanks. The Ethernet and PRI traces have given us the best help so far.

Interestingly, my PRI settings have changed and we now have inbound routing terminating consistently, the only issue is caller-ID where the p-asserted priority is sending the SIP account number instead of the caller-id the PBX is presenting over the PRI span.

Outbound calls are still hit and miss, even for the same exact dialed numbers, sometimes they go through and other times they do not. I am seeing 401 authentication errors in the pcap logs and have opened a ticket w/ the provider.

Oddly, before inbound would work, I had the switch type matching the PBX at NI2 but then I found changing it to anything else (4/5ESS, NI1, DMS100) and inbound works! The PBX is still set at NI2.

Outbound was tested under each type, most calls would fail but some did go through. DMS100 seems to be the most forgiving allowing more calls to complete. I am considering changing NI2 on the PBX side to match DMS100 and I still question if we have a dirty clock, I suppose I’d have to check SS7 logs for CRCs?

All this and it may be for nothing, the unit has locked up now 4 days in a row requiring reboot to gain access and function. Are these units susceptible to a misconfiguration causing lockups?


Try to disable the Facility Enable
and also set the CRC validation to NONE

You can check if there is any crash under Maintenance / System events


Thank you. CRC validation appears to be an E1 only setting.

!!! Disabling Facility Enable has made a world of difference with inbound calls, where calls are consistently routing successfully and showing the proper caller information every time.

Outbound is still hit and miss, only 11 digit works, seems 10 digit does not go through and oddly shows only the first 6 digits attempted in the CDR logs. i.e. if 714-555-1212 was dialed, the CDR log shows 714555 was sent to the SIP Trunk and the System Event logs shows:

SIP outgoing call through trunk failure! Provider name: BlahBlah, From user: 5557771234, To user: 714555, SIP response code: 403 Call Rejected

Outbound success:

  • Call to my office, comes through every time and caller-id is correct
  • Call to my Google Voice, comes through every time and caller-id is correct

Outbound failures:

  • Call to another’s cell, always fails and shows busy in CDR logs (no SIP trunk failure in log)
  • Call to another’s wife’s cell (same plan), hit and miss, busy in CDR logs (no SIP trunk failure in log)
  • Call to another’s home, always fails and shows following SIP failure in System Event log

SIP outgoing call through trunk failure! Provider name: BlahBlah, From user: 5557771234, To user: 15558884321UCM hung up the call (send SIP BYE)! Hungup cause: Invalid call reference value

Digit patterns for placing outbound calls:

  • Inbound Rule PBX PRI (dialing out from the phone system): _X.
  • Outbound Rule SIP Trunk (placing outbound call PSTN): _X.

No digit manipulation, working through traces atm.


Did you check the pri logs for the incoming calls?
It is better to capture a trace including syslog (modules: chan_dahdi, pjsip, and pbx) and check if there are any relevant logs, and also if the gxw is receiving the right number, then verify it and set the inbound pattern accordingly

It could be also an issue with the sip server that is terminating/rejecting the calls, the logs will confirm this


Thanks, I am working w/ GrandStream’s ITSP support to determine the issue of the lockups, just happened again about 15m ago.

Currently we are back to matching NI2 w/ the PBX, inbound is still flawless, except when the unit is locked up. Lockups still occur daily, sometimes several times a day.

Outbound still sporadic but mostly succeeding.
Found SIP ALG enabled on the router, so we turned that off, outbound still sporadic.
Thought maybe the ISP was doing something w/ 5060, switched ports both on our (provider) side and on the GXW side, matching 5080, outbound still sporadic.

Every call that fails appears in the PRI log as incomplete, just poof no more Message Type indices such as DISCONNECT, no q931_hangup message and we see a new SETUP for the same call details on the next B channel which then fails later as the GXW sends a RELEASE with a ‘invalid call reference value’ as the reason, just as the call was about to proceed.


Likely a final update for me here. Unfortunately we were unable to get to resolve the problems, the client has requested to port out to another provider.

-The unit was never replaced.
-It locked up daily
-outbound calls intermittently fail, always showing “Invalid call reference value”

PRI logs shows fractured calls, where calls are seen setting up but never tear down, messages just stop, mid invite/ack/alerting/etc, intermittent on which side stops responding first but they both just stop processing an existing call, then a new call is created on another channel which always results in the reference error

Thanks for the help.