Hi all. I have a customer running 3CX who sometimes has calling problems because the trunk becomes unregistered from our Broadworks platform. When you look at the REGISTERs, there are a couple peculiarities: 1. 3CX sends an un-REGISTER (expires=0) right before it re-REGISTERs rather than just re-registering the session 2. 3CX sometimes, but not always, starts a new session (new Call-ID) for the "new" REGISTER rather than simply refreshing the existing session 3. Not a problem, but something I find odd and worth mentioning is that it sends the User-Agent info when it un-registers but *not *when it registers The problem comes in when we get the un-REGISTER but it is not followed by a new REGISTER and calls begin to fail. The customer is obviously frustrated and is expecting *me *to do something about it, but.... Anyone familiar with 3CX and can give advice? Any idea why it behaves this way? They're running v16.0.5.619 (based on #3 above). Thanks in advance. -Pete
Pete, Does the same behavior happen regardless of how they are registered? Specifically SRV, vs A record, vs IP registration? We have experienced some peculiar behavior of this kind with customers and found that changing the host resolution method to be an effective strategy for "fixing" such problems. Thanks, Kent On Wed, Sep 2, 2020 at 8:47 AM Pete Eisengrein <peeip989 at gmail.com> wrote:
Hi all.
I have a customer running 3CX who sometimes has calling problems because the trunk becomes unregistered from our Broadworks platform. When you look at the REGISTERs, there are a couple peculiarities:
1. 3CX sends an un-REGISTER (expires=0) right before it re-REGISTERs rather than just re-registering the session 2. 3CX sometimes, but not always, starts a new session (new Call-ID) for the "new" REGISTER rather than simply refreshing the existing session 3. Not a problem, but something I find odd and worth mentioning is that it sends the User-Agent info when it un-registers but *not *when it registers
The problem comes in when we get the un-REGISTER but it is not followed by a new REGISTER and calls begin to fail. The customer is obviously frustrated and is expecting *me *to do something about it, but....
Anyone familiar with 3CX and can give advice? Any idea why it behaves this way? They're running v16.0.5.619 (based on #3 above).
Thanks in advance. -Pete
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
Back some time ago, we had a customer using 3CX to our Metaswitch? somewhat similar issues. Every time their 3CX had a hiccup, they too expected us to fix their issue? we could prove via capture it wasn?t us. We tried everything we could come up with? no luck. Finally suggested they engage 3CX? they told us they didn?t have support on the product. While this doesn?t help your situation, it does let you know you?re not alone. From: VoiceOps <voiceops-bounces at voiceops.org> On Behalf Of Pete Eisengrein Sent: Wednesday, September 2, 2020 8:47 AM To: Voiceops.org <voiceops at voiceops.org> Subject: [VoiceOps] 3CX Trunk Unregistering Hi all. I have a customer running 3CX who sometimes has calling problems because the trunk becomes unregistered from our Broadworks platform. When you look at the REGISTERs, there are a couple peculiarities: 1. 3CX sends an un-REGISTER (expires=0) right before it re-REGISTERs rather than just re-registering the session 2. 3CX sometimes, but not always, starts a new session (new Call-ID) for the "new" REGISTER rather than simply refreshing the existing session 3. Not a problem, but something I find odd and worth mentioning is that it sends the User-Agent info when it un-registers but not when it registers The problem comes in when we get the un-REGISTER but it is not followed by a new REGISTER and calls begin to fail. The customer is obviously frustrated and is expecting me to do something about it, but.... Anyone familiar with 3CX and can give advice? Any idea why it behaves this way? They're running v16.0.5.619 (based on #3 above). Thanks in advance. -Pete
We host 3CX for our customers, in our own infrastructure, and manage it for them. I have an advanced certification with them, but this sort of thing was never covered in training, and I've never heard of it before. Our core infrastructure is Asterisk (where all other servers register to). So this all may be very different from your situation. We also have one customer with their own off-net server. In every case, we use IP authentication and not usernames, that may be something to consider trying. 3CX has some semi-hidden features that can deeply modify the SIP behavior. We have not changed any of that, other than how CLID is presented so that calls that forward from the PBX who the original CLID and not the PBX's own CLID. I'd ask if any of that has been changed. The 3CX forums are very good, and very much to the point. It's a resource you should search, at least, and perhaps post there. Their support is also quite good, if maybe slightly slow because most of them are in the EU and the timezones play a factor. If the customer is off support, well, excuse me, but screw them for being idiots. On Wed, Sep 2, 2020 at 5:48 AM Pete Eisengrein <peeip989 at gmail.com> wrote:
Hi all.
I have a customer running 3CX who sometimes has calling problems because the trunk becomes unregistered from our Broadworks platform. When you look at the REGISTERs, there are a couple peculiarities:
1. 3CX sends an un-REGISTER (expires=0) right before it re-REGISTERs rather than just re-registering the session 2. 3CX sometimes, but not always, starts a new session (new Call-ID) for the "new" REGISTER rather than simply refreshing the existing session 3. Not a problem, but something I find odd and worth mentioning is that it sends the User-Agent info when it un-registers but *not *when it registers
The problem comes in when we get the un-REGISTER but it is not followed by a new REGISTER and calls begin to fail. The customer is obviously frustrated and is expecting *me *to do something about it, but....
Anyone familiar with 3CX and can give advice? Any idea why it behaves this way? They're running v16.0.5.619 (based on #3 above).
Thanks in advance. -Pete
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
Thanks Carlos. I did try searching the web, and thus the 3CX forums, before emailing the group but came up blank. We will move to unauthenticated, IP-based trust if necessary, but that's usually a last resort. But I will ask about the low-level settings. Thanks for the advice. On Wed, Sep 2, 2020 at 10:11 AM Carlos Alvarez <caalvarez at gmail.com> wrote:
We host 3CX for our customers, in our own infrastructure, and manage it for them. I have an advanced certification with them, but this sort of thing was never covered in training, and I've never heard of it before. Our core infrastructure is Asterisk (where all other servers register to). So this all may be very different from your situation. We also have one customer with their own off-net server. In every case, we use IP authentication and not usernames, that may be something to consider trying.
3CX has some semi-hidden features that can deeply modify the SIP behavior. We have not changed any of that, other than how CLID is presented so that calls that forward from the PBX who the original CLID and not the PBX's own CLID. I'd ask if any of that has been changed.
The 3CX forums are very good, and very much to the point. It's a resource you should search, at least, and perhaps post there. Their support is also quite good, if maybe slightly slow because most of them are in the EU and the timezones play a factor. If the customer is off support, well, excuse me, but screw them for being idiots.
On Wed, Sep 2, 2020 at 5:48 AM Pete Eisengrein <peeip989 at gmail.com> wrote:
Hi all.
I have a customer running 3CX who sometimes has calling problems because the trunk becomes unregistered from our Broadworks platform. When you look at the REGISTERs, there are a couple peculiarities:
1. 3CX sends an un-REGISTER (expires=0) right before it re-REGISTERs rather than just re-registering the session 2. 3CX sometimes, but not always, starts a new session (new Call-ID) for the "new" REGISTER rather than simply refreshing the existing session 3. Not a problem, but something I find odd and worth mentioning is that it sends the User-Agent info when it un-registers but *not *when it registers
The problem comes in when we get the un-REGISTER but it is not followed by a new REGISTER and calls begin to fail. The customer is obviously frustrated and is expecting *me *to do something about it, but....
Anyone familiar with 3CX and can give advice? Any idea why it behaves this way? They're running v16.0.5.619 (based on #3 above).
Thanks in advance. -Pete
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
On 02/09/2020 13:46, Pete Eisengrein wrote:
The problem comes in when we get the un-REGISTER but it is not followed by a new REGISTER and calls begin to fail. The customer is obviously frustrated and is expecting _me _to do something about it, but...
Sounds like the timer for refreshing the registration is longer than the registration valid time (or the same). I don't know if 3CX works like that.? I've asked out support team at work. As for the 3CX not under support.? You can get quite big systems now - like 8 calls, (maybe bigger) without paying 3CX.? So tempting for people to use the free one. -- Tim Bray Huddersfield, GB tim at kooky.org
participants (5)
-
caalvarez＠gmail.com -
kent＠sip.us -
mwiles＠akabis.com -
peeip989＠gmail.com -
tim＠kooky.org