Connecting to a NEC sv8100

[dmac]

One of our business units chose to go with a NEC sv8100 for their ACD phone system. We are using a 4430 SBC for our SIP trunk and mostly 7100's for phone systems in other areas.The installing vendor said he had to have 5 IP addresses for the SV8100. We created a small network for the system.10.40.0.32 mask:255.255.255.240. The question is the correct configuration for the 4430 to route calls. The address we agreed on to use for calls was 10.40.0.40 however only the SIP goes across this IP address and the RDP traffic is using 10.40.0.36. This was confirmed in WireShark. Calls are working but we have been seeing issues with dropped calls and stale connections on the 4430. Has anyone else connected to an NEC sv8100?

[Anonymous]

:

Thank you for asking this question in the Support Community.  It appears you have opened a ticket with ADTRAN Technical Support.  When you get a chance, will you reply with the outcome of your ticket?

Levi

[Anonymous]

Hi dmac:

We often connect to SV8100 PBXs.  You have correctly observed that RTP connection IP is separate from the SIP IP.  But this is not typically an issue for the SBC as each call should include SDP.  The SV8100 RTP media gateway will source the first call from UDP port 10020, the second call from 10022, and so on.  After the first call disconnects, port 10020 will again be used.  It does not use RTP source ports in round-robin fashion.  Again, this should cause no trouble for the SBC so long as SIP/SDP is correct; just wanted to describe the behavior.

SV8100 does not support PBX media bypass for trunk calls.  IP phones (normally) send RTP peer-to-peer for internal calls, but all trunk calls must hairpin RTP through the PBX.  Not normally problematic, but it does add complexity to the active sessions in your SBC, assuming phones are in subnets outside the PBX network and must route (or NAT) in to the PBX.

Speaking of NAT, this is supported for SV8100 stations, but the PBX must be explicitly configured with a table of non-NATed subnets (when NAT is enabled in the PBX).  Failure to configure this table can result in one-way or no-way audio.

You won't be able to leverage AOS SIP proxy for these phones as NEC did not use a standard SIP implementation for their multi-button terminals.  Standard SIP UACs are supported on the SV8100, but only as single-line devices (not useful for ACD agents and other normal office cases).

Could there be an IP conflict for 10.40.0.36 or .40?  We have observed some cases where another host is found with an overlapping IP as the SIP or media interface.  This seems unlikely, given your small, controlled subnet, but it might be worth double-checking.

These are the characteristics we try to keep in mind when integrating to NEC SV8100 systems.  We encourage media-anchoring in the SBC for trunk-side RTP to the SV8100.  I wouldn't think any HMRs are necessary, outside any special needs you may have.

Let us know what you learn--I know some other Community members work on NEC UC and PBX systems too!

Chris

[dmac]

Chris, thanks for the reply.  I think what I need is a more understanding of how to make these systems co-exist in our environment. The NEC vendor has admitted that they have never setup a system in this type of environment.

The SV8100 is using digital phones, we are only supplying the SIP connection to the SBC. Complex is an understatement on this setup. We have Anchoring turned on for the SIP trunk on the SBC and our 7100 work great however problems arise connecting internal calls from the SV8100 to phones on 7100's. Our original concept was to use only the 7100's but this business unit went out on their own for the NEC system.

   Doug

[Anonymous]

Yeah, things can get difficult when you break from the standard configuration sometimes.  Hopefully this all works out in the end.  There should be no trouble at all integrating SV8100 with an ADTRAN SBC.  If you're encountering audio issues or dropped calls, then I would suspect a fundamental issue like IP conflict or a bad cable or even a faulty piece of equipment somewhere.  The setup is a little different than a 7100, but straightforward and similar in principle.

One option is to use PRI into the SV8100, but you'd have to use a Total Access (and equip the SV8100 with a PRI interface).  I know that merely avoids the issue rather than solve it.

Do you have any AOS debug output and/or packet captures for example calls that fail?  Be careful not to post any sensitive information.  If there's nothing obvious in the configurations or fundamental network, we may have to dig deeper.

Chris

[dmac]

I did some debugs when the system was installed. I saw right away that the SV8100 was dropping the calls and had tech support check the debug. Turned out the SV8100 would not accept a re-invite from the 7100 when sending a call to voicemail. The 8100 would just drop the call. I found where to change the settings in the SV8100 in the NEC SV8100 Customized Trunk Manual. Turns out the NEC vendor cannot make the change, he has to have NEC make the change but has been unwilling.

Tech support gave me 2 settings to put on the 7100 as a work around for the re-invites but it is causing other issues with the 7100's when using UCD ring groups at other locations.

  no prefer double-reinvite

  no prefer reinvite-without-sdp

I like the idea of using a TA908e, just need to sell my boss and get the vendor to install the PRI cards. That would isolate the system. We already use the TA908e's for legacy NEC 2400's in 2 of our locations.

    Doug

   Doug

[Anonymous]

dmac:

I went ahead and flagged "Assumed Answered" on this post to make it more visible and help other members of the community find solutions more easily. If you feel like there is a better answer, feel free to come back to this post and select it with the applicable buttons.  If you have any additional information on this that others may benefit from, please come back to this post to provide an update.  If you still need assistance, we would be more than happy to continue working with you on this - just let us know in a reply.

Thanks,

Levi

[dmac · Accepted solution]

Follow-up:

Turns out the NEC tech left the Carrier Type setting at default since he did not know what to change it to and NEC did not tell him he needed to change it until he sent them a packet capture of a failed call. They gave him several Carrier Type options to try. Type "B" was the one that worked. We are still testing and are optimistic that all the current issues have been cleared up.

        Doug

[Anonymous]

Good deal!