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

reply to Nick3CX

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

reply to Iscream
Can someone from Call centric contact me and explain to me what the problem is? This is a long thread and contains many attempts.

nb@3cx.com

Best thing to do is to send me a new account with new credentials and we will conduct a test to see.

Also if a change was made in callcentric servers, then of course the 3CX template must be updated and rechecked and callcentric must now be retested again against the latest version of 3CX and callcentric. Lets start on that first before blaming DNS resolution problems in 3CX...

Now I have checked the srv records of callcentric and they have the same weight.

Reading 3CX sources I see that if all weights in SRV response are 0 - 3CX selects first record always, otherwise it selects random record with probability corresponidng to weight (ie. if you have two records, first has weight 80 and second has weight 20 - than it selects first with probability 80%, or second with probability 20%).

This is correct behavior.
So I am not exactly sure what / where the problem is.

Also in my opinion, we should delete this post and come up with a document that works across all platforms - Just like we have with all the other providers we support. Because this post is full or trial and errors.

3CX Phone system has a configuration template in the installation which is selectable and should populate all options automatically. Options that at the time that the introp was made between 3CX and Callcentric, both callcentric and 3CX had approved. All these options were working with callcentric until Mid October / beginning of November.

Now of course, if things have changed, we need to retest this. To be honest, we have not attempted to retest with callcentric after the problems that occurred during the past month.

Let me know how you guys with to proceed.

reply to DBOD
I've replied to your PM. Please check yours )

reply to Iscream
Iscream, Check your IM. 3CX has expressed an interest in the non-zero weight SRV problem.

reply to PX Eliezer
True, I think it is odd that they are not aware of the issue from other avenues. 3CX has a lot of users. I wouldn't think this is the first voip provider to implement SRV records that brings 3CX down. Maybe Callcentric is ahead of the curve? It is not an imminent problem at this point but it does hamper a voip provider's strategy if it is indeed a 3CX issue. At this point 3CX is not acknowledging a problem. Hope they can resolve it soon. I'd feel better if Callcentric implemented a more robust SRV system and 3CX could follow it.

reply to DBOD

reply to Iscream
I just lost registration on the bypass domain. Going back to what is working for now. I am going to run the condition that fails to process the weighted SRVs send the wireshark logs to 3CX

reply to VexorgTR
From the 3CX response you get the impression that callcentric and 3CX haven't been talking.

reply to VexorgTR
Here is the 3CX response on the general forum

Hi - thanks for the detailed explanation. We are not aware of this issue.
Probably if something has changed in call centric, we need to be updated in order to make the changes to the template.
3CX DNS resolution also changes in case it is a registration based authentication account or a non registration based trunk.
This is interesting.

"pulls the DNS A record for the second random server and sends the REGISTER response with the first nonce to the second server instead of the first server that issued the 407. Needless to say the registration never completes. "

What server are you using and what outbound proxy do you have specified in the account configuration?
Is it a registration based provider or a trunk?
Can you make a wireshark capture and send this to ...

reply to VexorgTR
Thanks DBOD for looking into this... I have not the time to do so.

reply to Iscream
Finally today they have looked at my concern in the user forum and are request wirehark logs. I'll sign on srv.callcentric.com and give it to them.

reply to Iscream
I can't ask 3CX since I don't pay for support. They are ignoring my query in the user forums.

reply to Iscream
We've stopped announcing "bypass0." as of this moment.
Thanks a lot for your time testing!

reply to DBOD
That's the question to 3CX, not us.

We're just a messenger (providing SRV records) )

I'll ask our techs whether they have this issue on control with 3CX guys.

reply to Iscream
Any estimated time for the 3CX SRV fix?

reply to Iscream
I am getting off the bypass0. Will leave one running on bypass. Don't see much value or harm in it for now.

reply to DBOD
Ouch, you've caught me here (thanks to your log!). I tried to create this test bed for you, to check 3CX's stickiness to particular SBC, last night, while was thinking about going to my own bed )

The "bypass0." was created as DN SRV RR within our DN servers, but wasn't actually provisioned within SBC layer allocated to support this new domain.

Considering the fact that 3CX's "stickiness" issue was not resolved - it keeps sticking to the same SBC - I now withdraw this test setup (related to "bypass0.") completely. If you want or see any reason in continuing doing so - you may keep playing with older "bypass." (non zero weights). Thanks for your time!

reply to DBOD
I make the presumption that 3CX and Callcentric can handle multiple SIP trunks from the same voip provider and the same PBX. I haven't seen any indication of a problem in that area but it may be an odd situation that you do not see often and worth mentioning. We run two business in this office with separate accounts. When I ran the other 3 tests earlier I shut off the second account just to make the logs easier to read. These three errors have occurred while both sip trunks are registered with CC but one using bypass0 and the other one just callcentric.com

reply to VexorgTR
Well I have to say that the Network error 500 is a once in a year occurrence around here. It has now happened a second time on bypass0 this morning. I have also now another error on bypass0 that I have never seen.

14-Nov-2012 10:08:43.656 Call to T:Line:10001>>18006383120@[Dev:sip:1777XXXXXXXX@bypass0.callcentric.com] from L:373.1[Extn:606] failed, cause: Cause: 483 Too Many Hops/INVITE from 204.11.192.135:10123
14-Nov-2012 10:08:43.656 [CM503003]: Call(C:373): Call to has failed; Cause: 483 Too Many Hops/INVITE from 204.11.192.135:10123

Given that I am simultaneously running another Callcentric sip trunk through the same PBX without errors on the callcentric.com port 0 SIP server and now I have three weird errors in a short period, I would say this is not a spurious correlation. Something odd is happening with this setup. The question is what? I will let it run awhile longer. I'll take a look at the wireshark logs in a few hours and see if there are any clues in there.

reply to DBOD
I don't think those lines [you mentioned above] are relevant somehow to the setup in question - this is just a "regular" 500 Network Failure, could happen due to many different reasons (this event isn't good by itself, but happens - could be network connectivity issue or even something on our side which prevented the call from progressing properly).

For me it was important to see whether or not 3CX will register to different SBCs or keep sticking to the same one. Seems like the latter. Just tried to find "something" for 3CX that could cause it to move onto another SBC when it's time to re-register.

Well, seems like no luck (one of my hopes was that when only a few records returned - it may behave itself) until 3CX will actually fix their SRV related behavior.