Is it Possible to Have Multiple ATA's in a LAN, with a single External IP?

[Torvette]

Hi, folks.

Here is the setup:

One external (Internet) IP address, with the following behind the router, (no inbound NAT/port forwarding):

ATA #1 (Obi202, latest firmware)

SP1 = Google Voice Account 1
SP2 = Google Voice Account 2

ATA #2 (Obi202, latest firmware)

SP1 = Google Voice Account 3
SP2 = Google Voice Account 4



The expected behaviours:
 
(1) Inbound calls to GV Account 1 go to ATA #1, Phone Port 1
(2) Inbound calls to GV Account 2 go to ATA #1, Phone Port 2
(3) Inbound calls to GV Account 3 go to ATA #2, Phone Port 1
(4) Inbound calls to GV Account 4 go to ATA #2, Phone Port 2



What's actually happening:

(1) Inbound calls to any of the GV accounts are ringing to phone ports on both ATA's.



My assumptions:

(1) The fact that we have only one external IP address is somehow causing an issue. It seems that I might need to map an external IP address to each ATA in my internal network.

(2) (In error?) since I have no inbound NAT/port forwarding, all ATA network sessions are initiated outbound, so my router should be handling each ATA's network socket/session independently via its state table.   ... Just like how multiple PC's in a LAN can browse the Internet with HTTP, all hidden behind a single external IP address.

(3) Google Voice ain't SIP; it's its own ... protocol, I guess.  I have no idea if it's even TCP or UDP (unless I break out the sniffer).



My Questions to you:

(1) How do I set things up such that I have one single external IP address, yet can properly direct inbound calls to a specific GV accounts, that reside only on specific ATA's, rather than have phones on distinct ATAs all ringing for the one call?

(2) Would I expect to see the same behaviour with all SIP accounts, instead of all GV accounts?

Many thanks in advance for your insight!

[CoalMinerRetired]

Answers:
(1): It should work without you having to do anything extra or special. Some routers are exceptions and fall in the category of needing something changed from a non-default setting.
(2): All SP providers and GV work the same way, you can have multiple ATAs behind a router and all the incoming and out going phone calls work correctly.

Since using multiple ATAs works for everyone else, look at your router. Quick guess is disable 'SIP ALG', or if it's disabled, then enable it.  Next test would be eliminate router and test on a different router (friends, family, neighbors) and see if you get the same behavior.

You did not mention what model router, port forwarding gets some discussion on here and is typically tied to a specific router model.

[QBZappy]

Torvette,

The OBi202 has the following features which is unique to the OBi202 model. You may have to play with these settings. The settings here might be responsible for making both phones ring. Try disabling it on one of the OBi202 units.

Voice Services->SPX Service->Calling Features->X_XMPPPriority
Voice Services->SPX Service->Calling Features->X_GTalkSimultaneousRing           (<-disable and test)

[CoalMinerRetired]

Voice Services->SPX Service->Calling Features->X_GTalkSimultaneousRing           (<-disable and test)

At first I thought that might be the cause, but note that Torvette says there are four different GV accounts in use, and no one account is in use on both Obis.

However, maybe one GV account is using another GV account as a forwarding number?

Torvette, I didn't think of this check when I replied above: You get a call on GV1 on Obi #1. But Obi #2 rings, what does Obi #2's call history show, what SP did the call "come in" on? That should point to something.

Call History: Not viewable via the ObiTalk Portal. You have to access via the Web Server-Based Local Configuration  (also called The OBi Device Management Web Page also called direct IP address interface), How to link.

[Torvette]

This is great news, folks - thanks!

Not that I obviously have a configuration issue somewhere... but that what I am trying to do is very possible.

As for forwarding numbers on the GV accounts, they all have distinct IPKall/Callcentric numbers to point to.  But I should really double-check that.

I don't use the ObiTalk portal at all, in fact I disengaged all the auto-provisioning stuff because I thought I had more control and more configuration options on the ATA web GUI itself.  Since the calls were ringing both ATAs, I just assumed the call logs would be identical.  I will check those as well.

BTW - Router model is Linksys e3000.

Cheers!

[giqcass]

Make sure none of the accounts are using the same incoming ports.  The Obi does not look at auth user names unless you put that into your dial plan.

X_UserAgentPort must be different for each service provider.

[CoalMinerRetired]

Make sure none of the accounts are using the same incoming ports.  The Obi does not look at auth user names unless you put that into your dial plan.

X_UserAgentPort must be different for each service provider.

That's interesting, I have two Obi202s behind the same router. Both setup via the Obitalk Portal. X_UserAgentPort is the same for SP1 and SP2 on both devices, and I have no issues making or receiving calls (SP1 and SP2) on either device.  Assuming what you are saying is so, I would have expected (hoped?) the ObiTalk portal to realize there are two devices behind the same router (same IPv4 NAT Address) and increment the different ports accordingly.

I think for Torvette problem, one inbound call ringing two Obis, looking at both Obi call histories, and then comparing to both GV Call records will point to something.

[giqcass]

CoalMinerRetired you are right to "hope"  it will increment but with the intricacies of networking and the different combinations of hardware who knows if it actually will in every scenario. Torvette did not use the portal to set everything up like you did.  I also wonder this. CoalMinerRetired do you have Ipkall and Callcentric in the mix on your Obi202s?  I think the combination of Ipkall and using the same ports might be the problem.  Ipkall doesn't do registration last I knew.  If there isn't registration it would be hard to negotiate the ports.  Best practice would be to just assign unique ports and be done with it.

[Lavarock7]

Once I had configured an Obi both directly and through the web interface. Later when I looked, some of the old config was still on the deice.

You might go into the device directly and see if you have old data sitting there. If so, reset the device and start over.

[Torvette]

So this was interesting.

For this deployment, the ATAs were set in 'router mode' (never again; there is no need for this!).  There was a dedicated switch between the ATAs' external (WAN) NIC and the router.  The LAN side had a distinct switch.

The external NIC of the ATAs currently have different IP addresses, but in the recent past, ATA 2 was given the IP address of ATA 1, and ATA simply changed its IP address to something else.   It seems that the external switch did not keep up with the ARP entry changes.

The external switch seemed to have an issue with its ARP table, as the table would refresh for everything but ATA  1.  It was almost as if someone had statically published the ARP entry onto the switch; if this was the case, the ARP entry is pretty much permanent.  This obviously created an ARP conflict, as the switch had two entries representing the external NIC of ATA 1.

Long story short, manually deleting the 'poisoned' ARP entry seems to have resolved the issue.

So this really had nothing to do with the VoIP implementation, just with simple Layer 2 switching.

Thanks to all for the suggestions... I learned a lot by researching all those paths!

[Shale]

So this was interesting.

For this deployment, the ATAs were set in 'router mode' (never again; there is no need for this!).  There was a dedicated switch between the ATAs' external (WAN) NIC and the router.  The LAN side had a distinct switch.

I looked up 'router mode'. The Admin Guide has this:

IP Routing and LAN Switching Features (OBi202 Only)

OBi202 has two Ethernet ports labelled as the Internet port and the LAN port. The OBi works as a router by default.  All the native voice services and features use the WAN port only when the OBi202 is in router mode. The OBi can also be set to work as a 3-port switch (a.k.a. Bridge mode), by changing its OperationMode parameter from Router to Bridge.  Note: One of the switch ports is for OBi202 internal use only.

I think maybe you are saying that one OBi202's WAN port connected to the modem in router mode, and its LAN port was connected to an unmanaged switch.  The other OBI2022's WAN port, and everything else, was  connected to that switch, and that setup did not work right. So the "never again" applies to just having 2 OBis with that configuration?

[Torvette]

It's a 'never again' because it was over-engineered.

The idea was to ensure QoS for voice traffic was pushed all the way to the perimeter of the network; I agree with this idea in principle, but anytime you are adding extra hops , extra equipment, extra layers and extra complexity to the environment, there has to be realized benefit.  The only benefit here was a skipped trip to the barber, since I was able to pull my own hair out trying to resolve the issue.

In most cases of SOHO, setting the ATA in 'bridge mode' is absolutely acceptable.  If this was an enterprise environment, with multiple internal WAN sites, and all sorts of data competing against the ATAs for bandwidth, I can see the need to further isolate and enhance the VoIP traffic into VLANs and QoS from start to finish.

[Shale]

So what would your future plan be?

For example, with a single OBi202 and a dumb modem, put OBi202 into bridge mode,

  Modem -> OBi202 > switch
That's not going to work because nobody is doing DHCP. Now if the modem has a built-in router, that should work.

  Modem -> Router ->OBi202
That is what most of us do, with computer plugged into the router, but it does not have QOS unless the router does it. That may be what you refer to the not over-engineered setup. With nothing hooked to the OBi LAN port, then I don't think it matters whether OBi202 is in router or bridge mode.

Modem -> Router ->OBi202 -> computer
The other things, such as printer, would be plugged into the router.

[Torvette]

Future Plan:

Modem -> Router/FW -> Switch -> (rest of the LAN, of which is the ATAs are but a node on the same subnet as the users, but with static IPs).  In the case of Obi, you use the external NIC, not the internal NIC, for bridge mode.

There is no need for the Obi's to route/NAT/filter the users' day-to-day traffic.  The router/FW was built for that feature set.  The ATA's are just for VoIP (the fact that the Obi can do it is just a nice-.
to-have, not a requirement).

DHCP (for workstations, etc) is provided by the router/FW.