| Author |
|
mfitzgerald
Vetran
Joined: June 14 2006
Location: United States
Posts: 142
|
| Posted: September 08 2008 at 2:53pm | IP Logged
|
|
|
We are looking at an environment where we would have redundant SIP Proxies. These Proxies would belong to different IP addresses, but would host the same endpoints.
I have looked at this in two ways:
Given:
SIP Proxy A, B
Endpoint K
LS set for a single phone line.
#1.
* LS registers endpoint K with Proxy A.
* Proxy A crashes / fails.
* LS would detect this by a timed-out keep-alive REGISTER request.
* Either:
-- LS itself immediately sends the register request for endpoint K with Proxy B
-- OR our app would have a callback function that LS would trigger in the event of a REGISTER timeout or watch the SIP Messages as they come and go for a time-out message. (CANCEL maybe?) Once detected, we have LS Register endpoint K with Proxy B
#2.
* LS registers endpoint K with Proxy A and B
* Proxy A crashes / fails.
* No action is performed aside from expecting further SIP messages to be sent to/from Proxy B.
Note: The fail scenario is this. When Proxy A fails, Proxy B will be used as the active Proxy. If Proxy B fails, Proxy A will be used as the active Proxy.
I believe we could get #1 to work. However the preferred method would be #2.
Suggestions / Advice / Questions?
Looking forward to hearing from you.
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: September 09 2008 at 9:58am | IP Logged
|
|
|
Hi Fitz,
Basic scenario #2 is probably what we would want to pursue.
We have had other requests to support multiple SIP proxies, registrars and SIP realm logins in the past. Some of the requests are associated with high availability and redundancy and other requests are related to simply supporting multiple SIP providers.
What kind of time line are you looking to deploy the redundancy?
Support
|
| Back to Top |
|
| |
mfitzgerald
Vetran
Joined: June 14 2006
Location: United States
Posts: 142
|
| Posted: September 09 2008 at 1:43pm | IP Logged
|
|
|
I've passed this onto my boss and have his response:
Quote:
We have started running production traffic knowing that
in the case of a SIP Proxy failure we will have to
change a database entry to have the workstations use a
different SIP Proxy server. This is acceptable for the
short-term, but we would like to have dual SIP Proxy
server support as soon as possible.
|
|
|
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: September 15 2008 at 3:58pm | IP Logged
|
|
|
Hi Fitz,
We have not forgoten about this... We are still thinking....
We will repost to discuss further and formulate plans with you.
Thanks,
Support
|
| Back to Top |
|
| |
mfitzgerald
Vetran
Joined: June 14 2006
Location: United States
Posts: 142
|
| Posted: September 26 2008 at 9:03am | IP Logged
|
|
|
We look forward to hearing your reply.
Thanks.
|
| Back to Top |
|
| |
hermes
Junior
Joined: October 27 2006
Posts: 64
|
| Posted: October 19 2008 at 7:19pm | IP Logged
|
|
|
Had you thought a solution based in a NLB cluster? It could be a good solution.
Something like this:
Do you think that it could be possible?
|
| Back to Top |
|
| |
hermes
Junior
Joined: October 27 2006
Posts: 64
|
| Posted: October 19 2008 at 7:31pm | IP Logged
|
|
|
A NLB cluster is very easy to implement with Microsoft Windows Server 2003 and there are too NLB clusters via hardware.
I´m not sure if in this architecture all SIP Proxies could be associated to the same Media Proxies, could you confirm this?
One more thing is that the cluster must to be configured with 'single or C class' affinity because SIP Proxies need to preserve the session.
|
| Back to Top |
|
| |
gcamp0730
Intermediate
Joined: June 12 2006
Location: United States
Posts: 35
|
| Posted: October 20 2008 at 8:33am | IP Logged
|
|
|
We are using vendor-provided SIP proxy servers (the vendor is Aspect) and as such we are limited to what they support.
|
| Back to Top |
|
| |
hermes
Junior
Joined: October 27 2006
Posts: 64
|
| Posted: October 20 2008 at 9:10am | IP Logged
|
|
|
I thought you were using your own proxies.
Anyway, if somebody could confirm me that architecture based in a NLB cluster is a good solution, I´d be very grateful to him.
Thanks again
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: October 20 2008 at 12:16pm | IP Logged
|
|
|
Hi hermes,
Nice graphic image. Thanks for posting your info. A far as load balancing deployments, we have to leave that issue up to customers.
That being said, if customers are using NLB with LanScape SIP and Media proxies, then the deployment scenario you point out should function properly if the NLB node is truly transparent to the SIP proxies (which should be the case). So if NLB is transparent, then you can configure the LanScape SIP and media proxies as you show and the SIP proxies will secondarily load balance call media to as many VOIP Media Proxies that you have deployed in whatever shared manner they (media proxies) are deployed. Does that make sense?
What mfitzgerald and gcamp0730 want from the VOIP Media Engine is the ability to configure multiple proxies and have the media engine handle calls from any proxy in the case of a proxy failure. We are in the process of determining what the proper course of action will be and fully see the media engine supporting multiple proxies/registrars. By the way Fitz and Greg, thanks for being patient as we consider the options.
General Notice:
If you are a user of this support forum and would like to post your load balancing solution, please feel free to do so. We will all learn from your knowledge.
All users – continue to add to this thread as needed.
Thanks,
Support
|
| Back to Top |
|
| |
hermes
Junior
Joined: October 27 2006
Posts: 64
|
| Posted: October 20 2008 at 4:26pm | IP Logged
|
|
|
I´m not sure if I´ve understood well you wanted to say. NLB cluster to SIP Proxies is truly transparent because the 'Load Balancer' is a previous step before connection arrives to SIP Proxies, so I think that it wouldn´t be a problem.
Your SIP Centrex Proxy can be configured to manage several Media Proxies across 'Control Port' (doing an internal load balancing between all Media Proxies); my doubt is if two Centrex Proxies can manage the same Media Proxy across the same 'Control Port'.
Perhaps it is better to move this post to 'Proxy Forum', feel free to do so.
Thanks.
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: October 21 2008 at 5:52am | IP Logged
|
|
|
hermes,
As you probably already know, the media proxies are configured to communicate with the SIP proxies. You can “point” any media proxy to any SIP proxy and media load balancing for all calls will function. Maybe we are misunderstanding your concern.
You are right, we can take this issue up in another thread if needed.
Support
|
| Back to Top |
|
| |
gcamp0730
Intermediate
Joined: June 12 2006
Location: United States
Posts: 35
|
| Posted: October 27 2008 at 3:33pm | IP Logged
|
|
|
I know you (Support) stated that option #2 is the LS-preferred option, but would it be quicker to implement option #1?
We're looking at the first week in December as the tentative timeline for testing the redundant SIP proxies.
Thanks,
Greg.
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: October 28 2008 at 9:15am | IP Logged
|
|
|
Hi Greg,
Thanks for posting.
Not sure if option #1 would be quicker to implement and get deployed but it is possible. What we will be doing is closing the loop with Fitz to decide on the full final details. We will probably have to discuss a bit just to be sure we are all on the same page and then simply get it done. We need to fully review multi-proxy support in the media engine and its overall ramifications. We understand what Fitz has purposed. We want to implement a generic multi proxy (domain) capability that will help us all moving forward. We need to make sure the results are clean and not some half baked hack.
We are getting Release 6 of the media engine product ready for the street. We will want to base the new multi-proxy support on the Release 6 product branch. We are going to tackle multi-proxy support as soon as we get Release 6 off our back. We will shoot for week 1 December too.
Support
|
| Back to Top |
|
| |
gcamp0730
Intermediate
Joined: June 12 2006
Location: United States
Posts: 35
|
| Posted: October 28 2008 at 9:23am | IP Logged
|
|
|
Okay. Also, please help me understand when our paid support hours will be used so we can adjust our requests accordingly. If none of the hours will come from October then we may have another request for you to work on instead.
Thanks,
Greg.
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: October 28 2008 at 10:48am | IP Logged
|
|
|
Hi Greg,
The 16 hour block of support hours is still available for October. We have no support time logged for your group this month.
You bet, if we can get something else done before the proxy issue, that's not a problem. We will just cut a v6 engineering release to Fitz with required updates.
Support
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: December 19 2008 at 1:39pm | IP Logged
|
|
|
Hi Greg and Fitz,
December 1 has come and gone. That’s how it is sometimes.
Now that I think about the original post, Scenario #1 will be simpler and it will not require any modifications to the media engine. Greg was correct all along.
I think at this point a conference call is in order. Primarily to make up for lost time. Greg, Fitz and I should discuss the actual details and talk about a possible solution. Once we agree on the solution, I will post that info back to this thread to document our approach.
Scenario #1 can be accomplished completely at the application level (within your agent station code) using all the canned functionality of the media engine. There are however details to discuss.
Let me know when you guys would like to discuss this further. At the very least, I need to speak with one of you in order to move forward.
If all three of us take part in the conference call, I can give you the number of my VOIP conference server you can call. We can all conference via VOIP and save a buck.
Fitz:
You already have a VOIP account here. You can use that.
Greg:
Fitz has the general VOIP account info for the LanScape VOIP system here. I will send via email your extension and authentication password for your new VOIP account.
I bet we can still get this done before the end of this month.
I am assuming that Greg still wants to accomplish this work yet this month. If for some reason this work cannot be done right at this time, just let me know.
Thanks,
Randal
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: January 06 2009 at 8:24am | IP Logged
|
|
|
Hi Greg, Fitz,
Anytime you guys want to pursue the multi proxy support, just post to this thread again and we can decide on a time to set up a teleconference. I can set up a VOIP teleconference at my end so we can all discuss the possible options that exist.
Also, let’s plan on upgrading your software to Release 6 VOIP Media Engine in January. I need to know if you guys want to stay with your current number of lines or add a few more to give yourself additional flexibility.
Thanks,
Randal
|
| Back to Top |
|
| |
gcamp0730
Intermediate
Joined: June 12 2006
Location: United States
Posts: 35
|
| Posted: January 23 2009 at 1:41pm | IP Logged
|
|
|
Hi Randal,
Yes, we would like to continue pursuing multi-proxy support. We're still okay with pursuing option #1 and handling all the details of the multiple proxies inside our custom application.
Please email me the VoIP setup info and we'll schedule a time to discuss.
Thanks!
Greg.
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: January 26 2009 at 11:49am | IP Logged
|
|
|
Hi Greg,
Will do...
Randal
|
| Back to Top |
|
| |
gcamp0730
Intermediate
Joined: June 12 2006
Location: United States
Posts: 35
|
| Posted: February 04 2009 at 12:25pm | IP Logged
|
|
|
Hi Randal,
We have just learned some important information regarding the dual SIP proxy servers. While one server is active and the other is standby, both servers will respond with OK to REGISTER commands. However, incoming calls will only occur via the active proxy server.
Since we have a 2-line media engine, I've been asked if it is possible to register line 1 to one proxy and line two to a separate proxy. I've looked over the documentation and it appears that all lines use the same proxy server. I hope I'm mistaken!
Please let me know if this is possible.
Thanks,
Greg.
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: February 04 2009 at 4:11pm | IP Logged
|
|
|
Hi Greg,
Internal multi registrar support is something we need to add to the media engine – it has been on the list of new features for a while. It is required if VOIP apps must register to multiple registrars simultaneously (i.e. for supporting multiple VOIP service providers for example or in your case, server failover). From our teleconference the other day, we discussed you using a REGISTER timeout detection scheme to provide serialized REGISTER failover from one server to the other - which could be handled pretty easily in app code using current media engine functionality. If you now want to register with multiple registrars at the same time, it can be done but the secondary (or more) registrations would have to be handled by the app (it’s a bit clunky but not too bad)… more on this in a bit.
Unless I have forgotten something, configuring multiple default SIP proxies does not matter in this case. Your app should work as expected as long as the SIP server uses “Record-route:” headers when your app receives its calls. Even though your app does not yet initiate calls, if you eventually want to initiate calls, you can override the default SIP server setting when calling the MakeCall() and MakeCallUri() API procs to specify that the default SIP server not be used and that the INVITE requests be sent directly to some other SIP server on the network. Again, make sure that the SIP servers are configured to use “Record-route:” headers. This way the media engine will send responses based on the specified SIP server’s route info.
Duplicating REGISTER requests:
This can be accomplished in application code but it is too clunky for my liking.
The basic principle is to simply mirror REISTER requests to whatever secondary registrars you have to support. For example:
1)
Have your app code initiate a primary REGISTER requests using the EnableSipRegisterServer() API procedure.
2)
Your app needs to be able to process the SipModifySipMessage immediate event so that it can detect when the media engine sends a SIP REGISTER request to the primary registrar.
3)
When a REGISTER request is sent, your app code should mirror it (send it out) alternate SIP registrars as needed. It can send out the mirrored SIP REGISTER messages using the SendUdpDatagramUsingSipPort() API procedure. Use this API to ensure symmetrical SIP signaling.
4)
You must have code in place in your SipModifySipMessage immediate event handler that will filter received REGISTER responses from all the registrars. Your app must not interfere with the primary register response (the media engine must process it). Your app on the other hand will however be responsible for handling REGISTER responses from the mirrored registrars as appropriate (detecting “200 OK” responses, 4xx errors or possible timeouts).
Duplicating REGISTER requests – Alternate approach:
Because this is a required feature on our “todo” list, this may be the time to finally implement the feature. I will have to think….
This approach will make multiple registrations for the app very simple. The logic would be completely integrated into the media engine.
What we would like to do is to allow the VOIP app to simply call the EnableSipRegisterServer() API procedure as many time as required. Each call would represent a specific register cycle to a different registration server (server address:port). The media engine would then “magically handle” the rest of the work. The API would require no changes.
When the app decides that it needs to terminate further register cycles or simply wants to un-register from a registrar, it would have to call the existing DisableSipRegisterServer() API procedure passing the same registrar server address and port (server:port) that was used in the original call to the EnableSipRegisterServer() API procedure. So this API would need two additional parameters.
Just off the top of my head, the above description seems reasonable and technically accurate. Let me know what alternative you would like. We can then discuss further.
Thanks Greg,
Randal
|
| Back to Top |
|
| |
gcamp0730
Intermediate
Joined: June 12 2006
Location: United States
Posts: 35
|
| Posted: February 04 2009 at 5:18pm | IP Logged
|
|
|
Hi Randal,
The new information I received this morning (confirmed by testing) indicates we will only receive a SipRegistrarTimeout when one of the proxy servers is down hard (i.e. offline). If both primary and backup proxy servers are functioning normally, each will return a 200 OK response to a REGISTER request.
So, while we would like to implement the solution discussed the other day in the teleconference, it is not an option since our information about how the proxy servers respond was incorrect.
Ideally, we'd like to implement the feature as you described in your "alternate approach". However, depending on how long you believe that might take, we may need to implement the first option. But I'd prefer to let the media engine handle the details!
If you could give me an idea of how long you anticipate it might take to add multiple registration functionality, it will help me decide which approach we take.
Thanks!
Greg.
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: February 05 2009 at 9:52am | IP Logged
|
|
|
Hi Greg,
Definitely option 2 (the alternate approach) is cleaner in the long run. I will look into what changes are needed and repost with some form of time estimate.
Randal
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: February 11 2009 at 12:32pm | IP Logged
|
|
|
Hi Greg,
Thanks for your patience. It took longer to investigate this than I originally expected. I will send you the info via direct email instead of posting the info to this support forum thread.
The good news is: this capability can be added with moderate code redesign. It will take some work but not impossible.
Randal
|
| Back to Top |
|
| |
Active Topics 
Member List 
Search 
Help 
Register 
Login
LanScape Support Forum -> LanScape VOIP Media Engine™ - Technical Support
Topic: Redundant SIP Registrar
