dslreports logo
 
    All Forums Hot Topics Gallery
spc
Search similar:


uniqs
8829

VexorgTR
join:2012-08-27
Sheffield Lake, OH

VexorgTR

Member

[CallCentric] Recommended settings for 3CX can be problematic.

By setting the outbound proxy port to '0' it makes 3CX go SRV.... it seems to work.

However, in the event that CallCentric becomes unregistered in my 3CX for whatever reason, it won't hop back on unless I restart the services. It gives a bunch of DNS resolution errors.

This doesn't happen when using 5060 as the outbound proxy port.

Anyone find a solution to this? Since CallCentric is working ok, I'm not to frazzed, but it's inconvenient.
DBOD
join:2012-10-17

DBOD

Member

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

I'm beginning to think it is useless to discuss 3CX Outbound proxy settings separate from the SIP server settings. Pulling SRV records and using them and using them properly are three different things. Can you be more explicit in your description? That is list all four items for the two conditions you are describing.

SIP server host name
SIP server port
Outbound proxyserver host name
Outbound proxy port

Also the behaviour between callcentric.com and srv.callcentric.com is different so please be specific. I assume you are not using the srv.callcentric.com since you have also discovered it does not work for 3CX right now.

To answer your question though, I have never seen 3CX fail to continue to attempt to register and eventually succeed on its own. I have never had to restart services to get it to register. And I have tried a lot of permutations of those four settings above.
nitzan
Premium Member
join:2008-02-27

nitzan to VexorgTR

Premium Member

to VexorgTR
Try setting it directly to one of the alpha servers, i.e. alpha8.callcentric.com port 5080, and see if that works. If yes then you can probably just leave it that way and forget about SRV.
DBOD
join:2012-10-17

DBOD to VexorgTR

Member

to VexorgTR
Right now I have two callcentric SIP trunks on one 3CX system. I have been experimenting with two different configurations. One has both servers set to callcentric.com port 0 and the second has both servers set to callcentric.com port 5080.

The first one is pulling the SRV records which only contain alpha10 thru alpha20 and all on port 5080. 3CX dutifully selects alpha10 each time. This is a weakness in 3CX but I think it meets the RFC standard since all the weights are 0. So all registration ends uo going to alpha10 port 5080. This stickiness could mean 3CX loses registration if on the rare occasion CC fails to automatically detect a fault/overload with alpha10.

My second sip trunk pulls the A records which right now looks like it is the ip addresses for alpha9 throught alpha20. 3CX seems to pull the first record in the list to register at. Because CC changes the order with each DNS query this trunk registers with another server every 60 seconds. Hence no stickiness. Because I specified port 5080 it uses 5080. I don't know if getting away from 5060 is even useful anymore since CC improved things last week.

I can tell you that both trunks have performed equally well in the last three days that I have run this setup. I lost registration only once for a few minutes yesterday afternoon on both trunks. May not even have been a CC issues but I had my wireshark off and couldn't see the event. Since I am still forwarding my DIDs to SIP URL and I have backup outbound voip providers my staff did not report the registration loss. A few more weeks and maybe there will be a perfomance difference during a peak DDOS attack. We'll see.
Iscream
Premium Member
join:2009-02-17
New York, NY

1 recommendation

Iscream to nitzan

Premium Member

to nitzan
? _forget_about_SRV_ ?
Well, and if, for whatever reason, the alpha8 is removed from service (died and/or under maintenance, etc)?

What if current ports have been changed there (via DNS SRV mechanism) by a load balancer or manually?

We have already more than enough customers who "hard-configured" even IP addresses/port combinations to say the least.

Any time, whenever anything happened - those customers are first to cry and curse that "everything just plain worked before then/that and then all of a sudden - it stopped and now nothing works; this is going to be CC who had destroyed my whole life, etc..." - all, accompanied by "whole package of things" related to a frustrated customer who posts to this site.

The OP clearly (!!!) and in multiple posts specified that their 3CX has NO problems working with "A" records - so why would they need to "test" some particular host-name/IP address which had NEVER been publicly announced to be used?

I suggest you to stay closer to your own system, customers and their configurations and stay away from providing "support" to posters who asked for help related to Callcentric and other providers' settings.

You have NO idea about how Callcentric (or any other provider's) system works, network topology and parameters (as well as - about 1000s other things in their network).

Please consider this seriously.
Iscream

Iscream to DBOD

Premium Member

to DBOD
To DBOD:

I'm very thankful for your continued support of Callcentric!

I have just one observation, to express though:

A port 5060 is a standard (default) UDP port per RFC for "A" record resolution - therefore manually configuring it is okay.

On another hand - I'd not recommend "sticking" to port 5080 or any other "intelligently" gathered port number from our network because doing so may and will (at some time) explicitly reduce reliability whenever our personnel or automated monitoring systems may need to change the currently announced port.

I don't have a documentary proof in front of me now, but I do believe that it's a violation of RFC (for UA) to use any preconfigured UDP port in combination with SRV record resolution. Sure, it will work for now because we do have a tendency to "stick" to some parameters, but when or if it's needed to change that parameter for whatever reason - it may be a cause of problem with one's service.

B/w - we're also looking into possible replacement of "0" weights by non-zero ones, but there were a few legitimate cases in past which actually forced us to use zeros there. We're checking on whether we can "move" those zero weights to another domain (like "srv.callcentric.com" or "bypass.callcentric.com") while replacing those zeros by non-zeroes in "callcentric.com" - unless 3CX may resolve this issue in a near future.

Thanks again for your support.
DBOD
join:2012-10-17

DBOD

Member

I posted the 3CX SRV issues in their forums 3 days ago with no response yet. I don't subscribe to their paid support and so I haven't discussed this with anyone at 3CX. Do you know if they are aware of it? Since Callcentric is on the list of 3CX recommended voip providers, have you guys at Callcentric floated this problem up to them?

It is still looking like callcentric.com port 0 is the best setting for both SIP and OBP servers on the 3CX systems for now. If you move the non zero weights to another domain it will bring us down. Can you email your 3CX users using SRV records with a 24 hour email notice please when you do that?? I'm going on vacation for a few weeks and would like to have some peace of mind. Thanks.

BTW the service has been great since the change you made last week.
Iscream
Premium Member
join:2009-02-17
New York, NY

Iscream

Premium Member

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.
DBOD
join:2012-10-17

DBOD

Member

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.

VexorgTR
join:2012-08-27
Sheffield Lake, OH

VexorgTR

Member

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
DBOD
join:2012-10-17

DBOD

Member

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

VexorgTR
join:2012-08-27
Sheffield Lake, OH

VexorgTR

Member

both are callcentric.com

5060 for the sip port....

straight from CC tech support.
DBOD
join:2012-10-17

DBOD

Member

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?
DBOD

DBOD to VexorgTR

Member

to VexorgTR
By setting both SIP and Outbound Proxy servers to callcentric.com port 0 in 3CX, my registration follows the SRV RR server and port specified which is the purpose of the SRV implemention.
Iscream
Premium Member
join:2009-02-17
New York, NY

Iscream to DBOD

Premium Member

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.
gweidenh
join:2002-05-18
Houston, TX

gweidenh to DBOD

Member

to DBOD
Sounds like VX needs to change his sip port to 0
DBOD
join:2012-10-17

DBOD to VexorgTR

Member

to VexorgTR
I'm not making 3CX setting recommendations. Just observations. I realize that the my supposition that 3CX will be more secure using the dumbed down callcentric.com SRV records is untested by me. What we do know is that 3CX is not working with the srv.callcentric.com SRV records. We also know that 3CX does registers just fine with the callcentric.com SRV resource records albeit it sticks to the same server independent of the order the RRs are sent in the answer to the query ( I don't think that is a standard non-compliance issue BTW because of the 0 weighting). And it only follows the RR port number if the SIP server port is 0 and probably the OBP server port is 0) What I have not actually done is witnessed this in battle. When Callcentric starts adding and dropping SBCs and changing ports, will 3CX follow properly? I hope so but given their performance with the srv.callcentric.com records it is only a hope. I'll leave my wireshark running to see if I can trap that behavior. 3CXs silence on this issue is deafening! Anybody have any connections with 3CX to get attention on this issue?

Has anyone witnessed 3CX following the RRs in the DNS answers as they are supposed to?

VexorgTR
join:2012-08-27
Sheffield Lake, OH

VexorgTR

Member

There were two of us with different ISP's that saw this. If we just use the "A" record, we're ok...

It's not a nightmare, but it will be interesting to see if the 3CX crew comes up with a fix.
DBOD
join:2012-10-17

DBOD

Member

I think you misunderstood the question. I believe there are two of you that saw the problem you have described. Your setup will not follow the the SRV RRs correctly. It doesn't even register with the first one correctly. Yes it registers but not on the port given by the SRV RR. I still don't understand why your problem occurs though.

My question was has anyone has seen 3CX following the SRVs RRs FQDN and port as it was intended on callcentric.com port 0. I don't think 3CX has a chance of doing it unless both SIP and OBP servers are set to callcentric.com port 0. Even then you have to trap the SRV RR change to see it happening. And I don't mean the round robin changes to the RRs.
DBOD

DBOD to VexorgTR

Member

to VexorgTR
Iscream,

I remember reading in a post a while back that Callcentric had some ATAs on hand to simulate different customer problems. Does Callcentric have a 3CX PBX server to run tests on? There is a free version of the software available. Does Callcentric and 3CX collaborate on customer issues that you deem important?
Iscream
Premium Member
join:2009-02-17
New York, NY

Iscream

Premium Member

Callcentric does have lots (and lots and lots - anybody wants to buy some lightly used SIP gear? I'm really kidding, we don't sell any gear) of ATAs on shelves. Yes, we do have 3CX servers installed - our support engineers are in touch with 3CX, but that "touch" is not in a real time and doesn't happen momentarily.

Our support people are frequent lurkers on this forum - they surely read this thread too.

Tomorrow we're closed due to observing Veteran's day holiday, but at Tuesday we may hear something from or post something to, 3CX, but I'm not in charge of those conversations (I'll keep my evil eye on them though ).

VexorgTR
join:2012-08-27
Sheffield Lake, OH

VexorgTR

Member

I got a message from 3CX about it.

Hi

Thanks for your email.

There is a 3CX issue at this point in time with SRV records.

Can you please try to connect to Callcentric WITHOUT using the Outbound Proxy and advise the outcome.

Thanks and regards
Iscream
Premium Member
join:2009-02-17
New York, NY

Iscream

Premium Member

As a matter of fact - that's a good advice! If your side doesn't use some sort of aggressive NAT/Firewall which would be actively hunting against SIP packets - you don't need an outbound proxy while working with Callcentric.

The OBP is used/recommended just as an additional measure helping to penetrate NAT related issues.

Please try it (without OBP) - let's see how it works.
DBOD
join:2012-10-17

DBOD

Member

I'm game. Except what do they mean without outbound proxy? You can set the server field blank but it won't let you leave the port field blank. I am setting both of mine to 0. Under the advanced tab there is a "Require registration for:" that I have set for "In and outgoing calls" . I am leaving that alone.

So far it is pulling the SRV records as expected and sticking to alpha10 port 5080 as expected.
DBOD

DBOD

Member

I should clarify that I am using the callcentric.com port 0 for the SIP server.
DBOD

DBOD to VexorgTR

Member

to VexorgTR
One more setting I have been running. I realized that stun was causing me problems in 3CX with Callcentric registration consistency. I avoided it a long time ago by going to the Voip Provider Advanced tab and setting "Which IP to use in 'Contact' field for registration" to Internal.
Iscream
Premium Member
join:2009-02-17
New York, NY

Iscream

Premium Member

The outbound proxy is not required. The way it's [un]configured differs for each particular device. Having it configured/enabled was advised for simplicity for non technical users.

Yeah, you don't need STUN either, when working with Callcentric (was a first reason for us using NAT penetrating SBCs since very beginning).

Also - we don't require a registration in order to be able to make outbound calls. If you're comfortable making calls without a dial-tone of if/when a device may be configured to provide a dial-tone without being registered - no problem on our side to accept calls.

The registration is only required in order to receive inbound calls toward your device and/or for call-treatments [based on being registered as a condition] to work.

Davesnothere
Change is NOT Necessarily Progress
Premium Member
join:2009-06-15
Canada

4 edits

Davesnothere

Premium Member

said by Iscream:

The outbound proxy is not required. The way it's [un]configured differs for each particular device. Having it configured/enabled was advised for simplicity for non technical users.

Yeah, you don't need STUN either, when working with Callcentric (was a first reason for us using NAT penetrating SBCs since very beginning).

Also - we don't require a registration in order to be able to make outbound calls. If you're comfortable making calls without a dial-tone of if/when a device may be configured to provide a dial-tone without being registered - no problem on our side to accept calls.

The registration is only required in order to receive inbound calls toward your device and/or for call-treatments [based on being registered as a condition] to work.

 
So that's 3 things which we might not need (already did not use STUN).

Are you telling us that certain fancy (above defined as extra/optional) parts of the config for CC are more to make their service more fool/idiot proof, aka more robust ?

Would there be any point in any of us on typical ATAs to try any of the simplification changes mentioned in your most recent post ? (and just keep the SRV stuff enabled)

IIRC, a PAP2T can be set to issue a dialtone without registration, for example.

I suppose you'll say "if it works (as it is)...."
DBOD
join:2012-10-17

1 edit

DBOD to VexorgTR

Member

to VexorgTR
This is like watching the paint dry.

For the last day I have been running my 3CX with

SIP server hostname callcentric.com
SIP server port 0
Outbound proxy hostname "field left blank"
Outbound proxy port 0

I have to report that there seems to be absolutely no difference between how it handles the DNS SRV or how reliable it is versus the following which I have been using for the last month.

SIP server hostname callcentric.com
SIP server port 0
Outbound proxy hostname callcentric.com
Outbound proxy port 0

Both have been rock solid reliable since last Wednesday night when CC made the big changes.
Iscream
Premium Member
join:2009-02-17
New York, NY

Iscream

Premium Member

said by DBOD:

This is like watching the paint dry.

For the last day I have been running my 3CX with

SIP server hostname callcentric.com
SIP server port 0
Outbound proxy hostname "field left blank"
Outbound proxy port 0

I have to report that there seems to be absolutely no difference between how it handles the DNS SRV or how reliable it is versus the following which I have been using for the last month.

SIP server hostname callcentric.com
SIP server port 0
Outbound proxy hostname callcentric.com
Outbound proxy port 0

Both have been rock solid reliable since last Wednesday night when CC made the big changes.

To DBOD:

I have one idea... Please may you make one experiment for me?

Try to configure your 3CX to use server hostname "bypass.callcentric.com" (with our without outbound proxy).

Use SIP server and OBP port 0 (our DN will return port 10123, but if that works for you - we can set other ports - it seems for some reason people tend to like port 5080 more than 10123, which looks racists to me ).

The "bypass.callcentric.com" SRV uses weights of "30" there.

Then you may try also using "bypass0.callcentric.com" - same as above, but SRV is configured with weights "0s" for all records.

Please let me know whether your 3CX worked with some, all or not at all with above config combinations and whether it stopped sticking to a particular SBC (chooses different SBCs at different times) - somehow I believe that if it worked for you - then it also now uses different SBCs vs. sticking to one only.

Please don't stick to this config yet - this is a part of experimental setup and may change on instant. If it works - we'll create some more persistent DN records. Thanks.