Business Phone Systems

Previous Thread
Next Thread
Print Thread
Rate Thread
Page 1 of 2 1 2
Joined: Jan 2011
Posts: 6
Member
OP Offline
Member
Joined: Jan 2011
Posts: 6
Trying to support a local vendor here; we have a system that just flat out refuses to make outbound calls using a SIP trunk. I'm an engineer with the SIP carrier, we have a loaner from the vendor here on the bench and we're working together to figure it out.

The unit is an SV8100 with a pair of blades -- a CD-CP00 and a CD-LTA -- with a single digital handset directly connected to the CD-LTA card. The unit is licensed for SIP and has an extremely basic configuration in place, with changes limited the 10, 14, and 84 series programs -- I can post them here if someone wants to see.

The behavior is pretty straightforward; we can receive phone calls but we cannot make outbound calls.

The system does register the SIP trunk, with complete and successful digest authentication, and re-registers periodically per the timer set in 10-29-15, conclusively demonstrating 2-way SIP connectivity and the validity of the SIP configuration. Calls from the carrier to the handset possess 2-way audio, so we're confident we're not looking a network error.

The handset, ext101, is configured to seize a trunk automatically, and the trunk and trunk-group options are set to use the first available SIP trunk, which in the defaulted configuration is Line 005. Lifting the handset results in a busy signal and a "BUSY" indicator on the handset's LCD. No SIP traffic occurs on the network. Likewise, attempting to forcibly select the trunk from the handset (dialing 9, then 5) also results in busy.

Based on what I think I know, we apepar to be using the correct trunk configuration, but the system behaves as if we're selecting the wrong trunk. The vendor seems confident we're configured to use the correct trunk.

I've heard now, a couple of times, the dreaded "Well, carrier X works just fine, so t must be a problem with you guys," but from what I see here, the phone system isn't even trying to connect.

We're stumped. The SV8100 clearly can communicate with the carrier via SIP. What would cause it to fail to use the trunk?

Atcom VoIP Demo
VoIP Demo
Joined: Mar 2014
Posts: 365
Member
Offline
Member
Joined: Mar 2014
Posts: 365
NEC has released a series of documents on those SIP providers that they have tested. If you provide the name of the provider then I can search their list to see if a document exists.

Joined: Jan 2011
Posts: 6
Member
OP Offline
Member
Joined: Jan 2011
Posts: 6
It doesn't. Speaking in my capacity as the lead VoIP engineer for the carrier, we've done no official interop with NEC to date.

That said, we're using a Metaswitch VP2510 softswitch. This provides service to the PBX on the carrier side, and there are a number interop studies and documents for the VP2510 platform itself against various NEC platforms, including the SV8100, up to Metaswitch CFS software 7.3, which we have reviewed to no avail...

Joined: Sep 2004
Posts: 4,128
Likes: 1
Member
*****
Offline
Member
*****
Joined: Sep 2004
Posts: 4,128
Likes: 1
Are you using ARS? Also the number needs to be set to enblock which I think is by default for DID trunks (which this is).

Joined: Jan 2011
Posts: 6
Member
OP Offline
Member
Joined: Jan 2011
Posts: 6
No changes have been made in any 26-XX (ARS) program in the current config.

As far as enblock, we did tinker with 22-02 and make it a DID trunk, which informed changes to 22-09-01 and 22-11-01. These changes had an impact on inbound call behavior, but outbound behavior was not changed. We've since reverted back to "normal" in 22-02.


Joined: Sep 2004
Posts: 4,128
Likes: 1
Member
*****
Offline
Member
*****
Joined: Sep 2004
Posts: 4,128
Likes: 1
I can tell you right now your programming is wrong. You must be set for DID and set your translations accordingly.

Joined: Jan 2011
Posts: 6
Member
OP Offline
Member
Joined: Jan 2011
Posts: 6
Believe it or not, that's what I had hoped to hear. Now I just have to figure out what needs to be corrected.

If I set 22-02 (trunk 5 is the SIP trunk) to DID, and change nothing else, I get a "486 Busy" response from the SV8100 on inbound calls. That's expected,since we haven't mapped the number.

So if then I go to 22-11-01 and match the last four of the incoming test DID (5096, in this case) and set 22-11-02 to the test extension (101 in this case), inbound is restored and I can deliver test calls to the test handset. All is well again.

This has no impact on outbound call behavior, however. We still get an instant busy, and no traffic of any sort from the SV8100.

Since (again based on what I >think< I know) I've made no changes to outbound, this does not surprise me.

Program 14-01-07 for Line 005 is selected for outbound calls, and 14-05 trunk 5 is assigned to trunk group 1, and 14-06 table 001 has trunk group 1 selected as priority 1. Finally, 15-01-02 for the test handset is selected (automatic trunk line seizure).

If not this, then what is the equivalent change to outbound that must be made in order to inform the system that this is a DID trunk it needs to use for outbound calls?

Am I missing something else?

Joined: Sep 2004
Posts: 4,128
Likes: 1
Member
*****
Offline
Member
*****
Joined: Sep 2004
Posts: 4,128
Likes: 1
Remove automatic line. Verify your trunk groups. By default its dial 9 access. Wire shark it cause something simple is being missed here.

Joined: Jan 2011
Posts: 6
Member
OP Offline
Member
Joined: Jan 2011
Posts: 6
Originally Posted by Coral Tech
Remove automatic line. Verify your trunk groups. By default its dial 9 access. Wire shark it cause something simple is being missed here.

I'll try that. I also agree that there has to be something simple and obvious that's getting overlooked. I may head into the shop tomorrow to frown at this some more -- I'm very motivated to solve this.

As for wireshark, we've been running tcpdump against the interface from the router that the SV8100 is physically connected to, so we're reasonably confident of the IP behavior. That said, I will absolutely go ahead and hook the system into a switch, span the port, and then use wireshark to make sure I'm not losing packets in the kernel or some other silliness on the router. It wouldn't be the first time I'd been bitten by something obscure.

Last edited by Evan Kisbey; 02/06/16 04:25 AM.
Joined: Jul 2015
Posts: 15
Member
Offline
Member
Joined: Jul 2015
Posts: 15
This couldn't be as simple as the extension needing some CAP keys, could it?

Page 1 of 2 1 2

Moderated by  ttech 

Link Copied to Clipboard
Forum Statistics
Forums84
Topics93,835
Posts636,794
Members49,652
Most Online5,661
May 23rd, 2018
Popular Topics(Views)
Today's Birthdays
ArmorSecSys, ILSMitel, IPMoni, Pweber462
Newest Members
machinegod, Gtownpaper, Lazlo, devben, bubblegum
49,651 Registered Users
Top Posters(30 Days)
ramo 13
pvj 11
Toner 9
dans 5
Who's Online Now
2 members (Curlycord, TVCTech), 72 guests, and 18 robots.
Key: Admin, Global Mod, Mod
Contact Us | Sponsored by Atcom: Business Phone Systems | Terms of Service

Sundance Communications is not affiliated with any of the above manufacturers.
©Copyright Sundance Communications 1998-2023
Powered by UBB.threads™ PHP Forum Software 7.7.5