VOIP etc > Voice Over IP - VOIP > VOIP Tech Chat > [CallCentric] Recommended settings for 3CX can be problematic.

reply to Iscream

Re: [CallCentric] Recommended settings for 3CX can be problemati

The only reason to consider replacing "zero" weights by non zero ones for "callcentric.com" - was in an attempt to solve your problem. If you say that you prefer to stay with "0s" there - no problem, no one would ever mess with that )

B/w - there is no worry about 3CX server sticking to some particular SBC when weight "0" is used - the moment our system detects any issue with any SBC - it's literally milliseconds to remove (in case of complete failure or maintenance) or to change the announced SRV's weights (in case of overload); a TTL for those SRV records is set to 60 seconds thus within this interval all DN servers and/or DN resolvers will have updated SRV settings for domain in question.

Of course - mistakes do happen as well as mis-configurations, therefore it's better to have a fully operational SRV based "round-robin" setup, but until 3CX fixed their issue - it's okay to let the 3CX server to "stick" to a particular SBCs while the DN SRV records return back (resolve to) that SBC as one of "announced" addresses and until an announced weight is still "0".

Also, worth mentioning, I do hope that it's clear that whatever is called "port 0" is not actually a UDP "port 0" at all. It's simply a configuration "switch" which tells the program to get the port value from the SRV record instead of using a preconfigured one.

I recognize that it is not literally Port 0. Designating port 0 seems to be the method of forcing 3CX to look up SRV records. Not necessarily use them or use them correctly. The 3CX administrator manual for version level 11 has no discussion of SRV records at all. So I can only deduce based on observation with wireshark what is happening.

3CX is broken when using srv.callcentric.com port 0 on both SIP and OBP servers. It is my belief that it is a 3CX problem with the non zero weights. I'd like 3CX to chime in on that issue. Please don't use non zero weights on callcentric.com to help us 3CX users. I can understand why you would choose to implement non zero weights however for all users. Non compliant user agents need to change. If you need to implement it, leave another domain with non zero weights for us problem children.

I was searching for a way to avoid problems with sticking to a particular SBC in the rare event that a automatic mechanism failed to remove the SBC.

Setting both of my server options to port 5080 forces A records but randomizes the servers. I recognize that it will still break if you decide to start port hopping. Since 3CX appears to me non-compliant, I have to pick my poison. I don't like it but I am sticking with the SRV records.

Outbound proxy hostname or IP = callcentric.com
Outbound proxy port (default is 5060) = 0

When I set it like this... In the event that it "falls off" it can't get back on by itself... 3CX just starts with this error....

01-11-2012 10:44:45.937 [CM504007]: Next attempt to register Lc:10000(@Callcentric[]) is scheduled in 120 seconds
01-11-2012 10:44:45.906 [CM504005]: Registration failed for: Lc:10000(@Callcentric[]); Cause: Cause: 408 Request Timeout/REGISTER from local

But I also want to know what are your SIP server and port settings when you are expericencing this??

both are callcentric.com

5060 for the sip port....

straight from CC tech support.

I am not having any problem registering with those settings. Are you saying it is just a re-registering problem after you have lost registration? How often are you losing registration? Can you simulate it without having to wait for the problem?

Here is my concern with your set up. And I think we get into trouble here because CC isn't fully aware of the defects in 3CX.

With the setup you describe, 3CX is pulling the SRV records from callcentric.com and as we know it is defaulting to alpha10. But it is only using the SRV record for server selection not port selection. So registration is happening on alpha10 port 5060 with your set up. I don't know how stable that is or why 3CX loses and can not reconnect under that situation. If CC loses alpha10 you should be able to get back on another server. One question I have is while callcentric can change both servers and ports in SRV records, will they still listen to 5060?

reply to DBOD
At this time we don't have immediate plans to replace 0s with non 0 weights - the consideration was only to help you and customers having their configurations like yours. Because you asked - no more needs to immediately change this behavior.

The same is about about using dynamic port hoping - in a long run I'd not recommend to use SRV mechanism to choose a name of SBC while still using some fixed port (be it 5060 or 5080) because it may happen, at some time in future, that all ports which are not _currently_ being announced, the same as all SBC names which are not being currently announced by DN SRV or A records - will be explicitly closed and blocked by our dynamic firewall (with exception of currently registered or with active calls devices). That is the whole principle of using load balancers and resource protection mechanisms to allow access only to those devices which are currently available with adequate processing power.

The mechanism outlined above is within 2-4 months down the road, may take even longer if more non-compliant devices discovered or there is a significant demand from active (read - reasonable) customers, but earlier of later this mechanism must be deployed because with the current age of Internet, its threats and ability to "hunt different service providers" just for sports - this is the only way to go; any single, the most powerful, SBC has always a finite amount of processing power therefore it always may be "suppressed" by a matching fire from malicious/zombie devices while having ability to quickly add more SBCs with dynamically changing ports - gives us an ability to remove devices from fire which were attacked _before_ their resource had been exhausted while adding another device{s} with new resources available to serve more requests.