Jump to content

Redundancy of snom one servers using trunk failover


Ganesh
 Share

Recommended Posts

We have 2 snom one servers at a central location on IP address 10.10.11.9 and 10.10.11.10. The remote location snom one server has 2 SIP gateway trunks configured to the central location servers. In the trunk 1 we have specified the domain as 10.10.11.9 and outbound proxy as 10.10.11.10. Similarly on trunk 2 we have specified the domain as 10.10.11.10 and outbound proxy as 10.10.11.9. The failover on both the trunks is set to "Always except when busy". In the dial plan of the remote location server the first preference is set to 10.10.11.9 and second is 10.10.11.10. When the remote location users call the central site the call is well handled by the server 10.10.11.9.

 

During a failover of the server 10.10.11.9 at central site, the remote location snom one server is automatically routing calls to 10.10.11.10 and this is working fine. But during the failover of server 10.10.11.10, the remote location server stops routing calls even to 10.10.11.9. Why is it so? The server 10.10.11.9 works only if the other server is connected and working. Else this stops responding. Whereas the server 10.10.11.10 works fine even if the first server becomes unavailable. Has someone tried this?

 

Regards

Ganesh

Link to comment
Share on other sites

Hi Ganesh,

 

If the preference in your dial plan is to always send calls to 10.10.11.9 first, then the call routing will only get to 10.10.11.10 when 10.10.11.9 already failed. After 10.10.11.10 also fails, why do you want it to try 10.10.11.9 again (since we already know it fails)?

 

Anyway, if you do want this, you can try to simply add one more dialplan rule for 10.10.11.9, after ther rule to 10.10.11.10.

Link to comment
Share on other sites

Hi Ganesh,

 

If the preference in your dial plan is to always send calls to 10.10.11.9 first, then the call routing will only get to 10.10.11.10 when 10.10.11.9 already failed. After 10.10.11.10 also fails, why do you want it to try 10.10.11.9 again (since we already know it fails)?

 

Anyway, if you do want this, you can try to simply add one more dialplan rule for 10.10.11.9, after ther rule to 10.10.11.10.

 

Thanks for your reply.

 

When 10.10.11.9 fails, the call routing is happening with 10.10.11.10.

The problem observed is only when 10.10.11.10 fails while 10.10.11.9 is in working state. Ideally it should continue to work with 10.10.11.9 but it does not.

 

Let me try the option of adding one more dial plan.

 

Regards

Ganesh

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...