SL2100 VOIP phone "hangs up" when trying to access trunk

[1tannerweir]

I just installed an NEC SL2100 phone system at my church. We got the ' 12 button digital quick start kit' bundle (

https://www.thetelecomspot.com/nec-sl2100-12-button-digital-quick-start-kit-nec-be117449.html)

that included 4 of the digital phones (NEC-BE117451), then I purchased a VOIP phone (NEC-BE117453). We have 2 analog trunks through our phone company. The digital phones were plug and play and are working as intended, but the IP phone that I installed in our 2nd building is not able to access the CO1 or CO2 trunk (to make/receive external calls). The IP phone is in a building right next to our church (the buildings are 10 feet apart, connected with an ethernet cable (I know not ideal, but for our uses it has worked)), not sure if that has any affect on this issue.
We can make internal calls between the extensions (to the digital phones in the main building), page the digital phones, etc., and even see an external call coming in on Trunk CO1. When I attempt to answer that call however, the screen immediately shows "Hang up" on the screen and the call is not answered (not sure if it ends the call on the caller's end, or just doesn't allow the IP phone to answer). If I try to make an external call, I click the CO1 button on the IP phone, but get a busy tone. I also try picking up the phone and press 9 (the trunk access code), then start dialing an external number, but after typing around 4 of the digits I get the busy tone.

The phone is assigned extension 111 and is able to make internal calls, so I am thinking this is just a programming issue? This is my first time setting up a business grade phone system, so I am still using a lot of the default programming. The IP phone is connected with a POE injector into a TP-Link unmanaged switch, if that matters. I will try moving the phone into our main building and connect it straight to our HP POE managed switch and see if it makes a difference, but I figured this would be a programming issue since I can make internal calls. We have the SL2100 connected to our network switch on the built in CPU card, we do not have the expansion card or additional licenses, as this is our only IP phone.

Any ideas of where I can check in the programming? I'd be happy to post screen shots of my configuration, or upload the PC Pro config file if that is allowed.

 

[1tannerweir]

I did find that link when first setting up the phone, but it seemed to contradict itself from how I read the article. It mentions in the top of the article that these instructions are for setting up the system using the CPU network card with the built in 8 IP phone capability. However later in the article, it mentions the VOIP daughter board (which is the additional VOIP card you can purchase for the SL2100 for 8+ VOIP phones) and setting that IP address. Maybe I read or understood it incorrectly though, so I will give that a try and see if it helps the phone work as intended.

 

[daddybadger]

There's no VoIP IP address? The CPU settings IP needs changing and populating into the VoIP IP. Make sure you then use an IP in a different subnet from VoIP ip

So
CPU settings
IP address 10.10.10.10
Subnet mask 255.255.255.0

InVoip
IP address 192.168.0.136
Subnet mask 255.255.255.0
Resource IP 192.168.1.138
Default Gateway 192.168.0.1
Subnet mask 255.255.255.0

I presume your subnet is 24 bit?

 

[1tannerweir]

I will make that change in person on Sunday so that I can test the results myself (I usually make the changes remotely and have the staff test the phone).

Just curious, why would the CPU IP Address need to be in a different subnet from the VOIP IP address? I am only using the built in CPU card ethernet port (with 8 built in VOIP phone licenses), I do not have the VOIP daughter card. Would I still be able to access the SL2100 in PC Pro if I changed the CPU IP Address to a different subnet than what our network uses? We are only using 1 VOIP phone, so I am not concerned with isolating the VOIP phone from our other network devices.

 

[daddybadger]

@1tannerweir do you have the advanced cpu card as if you have the c1 only card and no voip then that will be why you cannot make/receive calls on the external line.

 

[meyer1y2k]

From what I understand on the 2100, you will use whatever address you assign to the VoIP card to access the system. This is true on the 9100.

As a safety net, when you test, you could assign something like 10.1.0.100 to the Ethernet port with a mask of 255.255.255.0 Then you have a back door into the system if something goes awry with the VoIP test.

As I explained earlier, I am not really proficient on the 2100 but going over the docs and experience with the 9100 would lead me to believe you will be OK doing this and your VoIP should work. Again, I am sure someone with experience will call this out if it is not correct.

NEC is a little counter-intuituve. The VoIP card (or resource) gets an IP that must be on a different subnet than the LAN for the processor (again this is on the 9100 with an IP card installed). We then use the IP card address to admin the system. We must also define an IP address for the VoIP to DSP resource. While there is no physical connection for this, it is pingable once it is done if the IP card is connected to the LAN.

I think you are pretty close to getting this working.

 

[daddybadger]

An IP Terminal can send and receive RTP packets to/from another IP Terminal without using the DSP
resources on the VoIPDB. This operation only allows intercom calls between the IP Terminals.
If a digital multiline terminal or trunk is part of the call a DSP resource on the VoIPDB is required. If,
while on a peer to peer call, a conference call is initiated, the peer to peer connection is released and
a new non peer to peer connection is created using the VoIPDB. If the third party drops out of the
conversation, the call reverts to a peer to peer call (silence may be heard while this conversion is
made by the system).
Although the peer to peer feature is supported for IP Station-to-IP Station calls, the SL2100 chassis
must still have a registered VoIPDB installed in the system.

 

[daddybadger]

Can you show us a snip of this from your SL?

 

[1tannerweir]

 

[daddybadger]

Thanks for that. Your CPU is a standard so there's no DSP resources, if you wish for the IP phone to access trunks you will need the voipdb card or the Advanced CPU card.

 

[1tannerweir]

NEC and the vendor I purchased the phone system from state that the CPU card supports 8 VOIP phones/channels. The VOIP Daughter Board only provides 16 additional VOIP channels from what the sales page suggests. I do not see any mentioning of DSP resources being added with the VOIPDB card, and I only see 1 model number for the CPU card for the SL2100(BE116496). Is there a different CPU card that can be purchased that is "Advanced"?

So does that mean the SL2100 doesn't actually support 8 VOIP phones with the built in CPU card? If the built in hardware doesn't allow trunk access, then I would consider that not supported.

I will try setting the IP address on Sunday and see what happens. It sounds like with the built in CPU card I should be able to access voicemail and virtual extensions at the very least.

 

[daddybadger]

Maybe I'm getting confused with sip trunks. Try the IP address and see how that goes. Yes 2 CPU available BE116498 and BE117657

 

[1tannerweir]

I do know that SIP trunks require an additional card to be installed. From what I found online and what I've been told by sales reps, the hardware I have should work with the IP phone.

I will try setting the IP address Sunday and let everyone know how it goes. I also got a reply from a seller of the SL2100 that explains a little more in detail how the CPU card with 4 built in VOIP lines work.

 

[OzzieGeorge]

Ok so this is from my Australian experience so it may be different for you. The 2100 comes with 4 IP trunk licenses and can be programmed for 4 trunks. It has 8 DSP resources and that is why you can only do 4 trunks as a trunk call can consume 2 DSPs you can however connect 8 IP phones because they only use one DSP. The issue is when you try to mix and match the number of IP phones and VoIP trunks.

The VoIP will only work properly if there is a valid address in 10-12-09 and it is supposed to be different to the address in 10-12-01 (that said we were always told that best practice is to zero out the address in 10-12-01 eg 0.0.0.0) and pc pro will baulk at you trying to enter addresses in the same subnet. Interestingly though you can use addresses in the same subnet in web pro and I have seen systems set that way (I have no idea what the risks are in doing this though). There is no reason you can't administer the system using the VoIP address.

You do need an address in 84-26-01 in the same subnet as 10-12-09 but in my experience if that is wrong, it won't drop the call, it will just give lack of audio.

If your system is set up on your network using an address in 10-12-01, simply transfer that address to 10-12-09 ( it won't take effect till you log off) and test. You can always move the address back via handset programming if all turns to you know what!

 

[1tannerweir]

I was able to resolve the issue by setting the CPU IP address to 0.0.0.0 and setting the IP for the "VOIP IP Address" in the InVoip section using Easy Edit. I enabled Peer to Peer mode in case we decide to install more IP phones in the future. So it looks like there wasn't any settings causing the issue, it was just the IP address being set under the CPU instead of InVoip section. I was still able to connect to the SL2100 to program using the IP address in the InVoip section, so everything seems to be working correctly now.

I got the below reply from OnTheWire, a company that had a guide online on how to setup an IP Phone without the daughter board installed:

"You are setting up the inVoIP "card". In EasyEdit you can see what it is called. It is the built in VoIP type. It is separate from the CPU settings. If you don't need VoIP, you set up a CPU address. If you want the built in VoIP for SIP or IP phones, you zero out the CPU settings and use the InVoIP instead. If you install a VoIP card, the VoIP Type changes to VoIP Card and the settings apply to it instead of the InVoIP.