Is it Possible to Have Multiple ATA's in a LAN, with a single External IP?
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:
Quote from: giqcass on June 11, 2013, 04:08:58 pm
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!
Navigation
[0] Message Index
[#] Next page
[*] Previous page