I have a 908e that will be connected to two different Internet providers via two Ethernet interfaces. For redundancy purposes, I'd like to be able to receive SIP calls over both interfaces simultaneously from the same SIP provider. That means that the 908 will need to remember which interface a call comes from, so that it can send reply traffic back out the same interface. Because it's the same SIP provider with the same remote IP address, there won't be any other criteria to make a routing decision. Is this possible? In Linux I'm doing it using nf_conntrack.
Thanks!
Best application if you have available ports is to have the two channel banks with the FXS ports from each 908 going into the call center device. That would eliminate a single point of failure.
If you don’t have enough ports then you can do what you stated with two 908s. have the primary 908 with its FXS ports going to the call center device. Then have the primary 908 connect to the secondary 908 via Ethernet with SIP trunks built in both directions. the secondary one would need to run SBC with media anchoring enabled to force the RTP to come back through it instead of out the primary 908 default route. So if the sip server sends call to secondary, it will send it to the primary via eth and then out fxs and the SBC would force the RTP to come back through it back out the secondary 908.
Does that make sense? If not let me know.
-Mark
Your SIP provider can only send calls to the IP that is registered to the phone number . So inbound calls will only come in one eth interface. If that interface goes down or changes then the adtran will re-register out the backup connection.
I assume that one Ethernet is your primary connection and your secondary is your backup connection?
If that is the case, then follow this config guide on how to configure failover.
https://supportforums.adtran.com/docs/DOC-2299
Let me know if that is not the case.
-Mark
My SIP provider will send a call to my primary IP, and if that call isn't answered, they'll re-send it to my secondary IP. That's a much more efficient way to determine whether I'm up than for me to do a ping test. This is for a critical call center, and I don't want to miss any calls before failing over.
So yes, it's a primary/backup scenario from the provider's perspective, but I'm hoping to avoid the process of detecting a failure, failing the interface, and updating the routing table.
Well in that scenario we use the route table to route our sip messages so if a calls comes to secondary eth and default route is still pointing out primary eth, then we will send 100 trying out the prim eth connection to the sip server.
For that application to work you have to configure ping probe with PBR as the config guide states.
We then failover to secondary based on your time settings and we remove prim eth default route from route table and seconday eth def route becomes active.
Sorry that it does work to your desire. Let me know if you still have questions.
-Mark
I'm planning on running two 908's anyway - I'll try connecting one to the primary Internet, and the other to the secondary Internet, and routing calls between them. Does that sound crazy, or just a matter of carefully setting up the voice routes?
Best application if you have available ports is to have the two channel banks with the FXS ports from each 908 going into the call center device. That would eliminate a single point of failure.
If you don’t have enough ports then you can do what you stated with two 908s. have the primary 908 with its FXS ports going to the call center device. Then have the primary 908 connect to the secondary 908 via Ethernet with SIP trunks built in both directions. the secondary one would need to run SBC with media anchoring enabled to force the RTP to come back through it instead of out the primary 908 default route. So if the sip server sends call to secondary, it will send it to the primary via eth and then out fxs and the SBC would force the RTP to come back through it back out the secondary 908.
Does that make sense? If not let me know.
-Mark
Makes sense. Thanks!
Matt