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?

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.

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...

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).

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.

I can tell you right now your programming is wrong. You must be set for DID and set your translations accordingly.

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?

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.

This couldn't be as simple as the extension needing some CAP keys, could it?

Could be.

Check program 10-29-16(Register Sub Mode) and make sure it is NOT checked.

When you change your SIP Carrier Choice in 10-29-14, it automatically selects this and isn't needed...

If possible, turn to the SIP providers which NEC supports.

I have tried some SIP lines from a small SIP provider, it almost works other than some hang up issues. If the callee hang up first on a outgoing call, the SIP line could not be released.

When I called NEC they said "Unfortunately, we do not support issues related to 3rd Tier carriers, like XXX. "