No Voice on incoming calls after 60sec and hangup after 120sec

[TobyL]

Hi all,

I'm new to 3cx and this forum and would really appreciate your help.

Following problem with 3cx Linux V.15 (all updates applied):
On incoming calls there is voice for 60 seconds after 60s voice is gone and after another 60s the call gets hanged up.
Outgoing can be called for more than 15 Minutes (just not tested much more)

> Logs don't really show anything abnormal. Saying "Terminated... Reason localBye"

Details on environment:
- 3cx Linux Distro V15

- > Running on XenServer 7.1​

- Fibre Internet with 1 Public IP
- currently MikroTik Router for INET access

- Using Generic SIP Trunk UDP
- rest of PBX pretty much on default settings​

I know this question has been asks in that and other forums more than 100 times, and the answer is always regarding to an NAT issue or SIP Helper.

I don't think it is an NAT or SIP Helper problem because the environment has been tested with different Routers/Firewalls always the same behaviour. Firewalls/Routers taken for test : Huawei USG6000, (old) Zywall 2, Mikrotik Routerboard (V6.39) those always with a media converter for FTTH, Fritzbox 5490 with its own fibre GBIC.

And another point : SIP Provider shouldn't be the source of the problem. Because running the TRUNK directly on the FritzBox itself works for incoming calls for more then 1 minute.

- SNOM phones and 3CX clients tested, same behaviour.

Any ideas, hints? Would really appreciate the forums help, cause I'm kind of stuck here...

at the moment I’m going to try the windows version and see if it’s the same behaviour.

best regards

 

[TobyL]

Additional Information:

I can now definitely say it has nothing to to with my network or NAT. I did a Cloud Setup of PBX Express with 3cx OVH trial service and connected the client on my cell phone via 4G to it. Same behaviour.

So I’m at the point to say it must have something to do with the 3cx PBX or the way of communication between SIP provider and 3CX PBX.

 

[leejor]

I would first check the 3CX Activity log set to provide the most detail. That should show what is causing the call to drop. Using Wireshark would pinpoint which IP was sending the "BYE" message.

Is this happening on only one VoIP provider?
Have you tested calls over another provider?
Have you contacted the provider to ?

It may be that 3CX is expecting a message, and not receiving it, times out and drops that call. This happens after about 30 seconds when no "ACK" message is received, but I don't recall 60 seconds being a common time-out period previously. Since you have made a number of changes, the remaining "suspect" would seem to be your provider and possibly a setting. Which provider are you using, another member may be familiar with them.

 

[TobyL]

Hi Leejor,

Thank you for reading the post and trying to help! Really appreciated here!

First important update to the issue. I’ve now installed a Asterisk server and did the basic configuration for a test. >> Working can make incoming calls more than 10 minutes. So it must definitely be on the 3cx PBX.

I’ll secondly answer your questions:
Is this happening on only one VoIP provider? <<< Yes, unfortunately I got no second Trunk to test.
Have you tested calls over another provider? <<< No, same cause. Only got one provider and could not find a usable “Test” provider on the net.
Have you contacted the provider to ? <<< Not yet. I first thought it must have been on our site.
Provider name is nexphone.ch (green).

Regarding the 60 seconds, I’ve been going thru all parameters of the PBX and couldn’t find anything with 60s or 60000ms or close to that. And I didn’t change the settings/values of the parameters, I left all parameters on default values and only changed one by one and back to find the cause.

I’ve set the log levels of the 3CX to max (CMLOG_VERBOSITY 6 and ANALYSEVOIPPACKETS to 1).

Out of the log it say the IP 0.0.0.0 sent the “BYE” message. Which looks strange to me.
Also out of the log the PBX sent an INVITE to the number and looks like received an ACK.

My “problem” now is that I need to setup a working PBX anyhow. Cause the numbers are in use for the business L. So I’ve to stop with the 3CX box for now and go ahead with the Asterisk solution. That’s a shame I really liked that simple and also powerful UI of 3CX. Really a good solution and I’m sure it’s just a small “parameter” value to adjust...

Shall I provide you a extract of the log? Chances might be there to solve that out for the future or other users.

Many thanks and best regards

 

[lneblett]

Simply because one system seemingly works whereas another does not, does not in and of itself rule out anything. The issue as described appears to be NAT or firewall related. When making the outbound call, the messaging path is initiated by 3CX which then also initiates the RTP path which may be responsible for keeping the firewall holes open. Hence; this may explain why outbound calls work fine.

On an inbound path from the provider, the firewall sounds like it is closing the RTP path and then, 3CX, no longer getting the stream assumes after some period of time that the call has been dropped and subsequently breaks down the call. The message to the phone is a BYE which is a normal disconnect as 3CX only knows that the stream was no longer seen, not why, and that the reason is not pertinent to the phone and a BYE is a correct response to end of the call. How the stream made it thru in the first place is unknown as more detail about how the setup is was lacking. It was most a comparison of what did work relative to 3CX not.

Was the firewall checker run and did it pass? If not, then see what you can do to correct this issue.
In the trunk settings for the SIP provider, try putting in the external IP of the system into the "select which IP to use in the contact....." and disable all settings other than PBX delivers audio.
In the network settings under firewall, enable keep alive and set to a value of 30.

A wireshark capture will show much more and allow a more precise determination as we will be able to see if a message caused something to change (re-invite?) which may have caused the issue.

 

[TobyL]

Hi Inblett,

Thanks for posting here.

I don't fully agree with your statement :"Simply because one system seemingly works whereas another does not, does not in and of itself rule out anything".
To me it does. I wrote that I've done a setup of the 3CX in the 3CX(OVH) Cloud with a client not over the (local) network to the inet. Which means, "only" the provider and 3CX (cloud presetup) have been involved and it did not work. So it definitely "rules" something about the software or system.

But anyway I'm interested to find the cause of the problem and solve it. As I stated, it was not my intention to run the PBX on an Asterisk "self grown" solution. I initially decided to run it on 3CX and would be willing to switch back if it works and wan't to solve. I invested so much time the last day's into that problem that I can't accept to "loose" against the problem...

Back to your post:
I ran the firewall checker various times and was also able the have it "green" and okay. And it was behaving the same. Also the checker does not need to be all green. I setup up an every router/firewall the fitting parameters which allowed me to phone. And once again, I have no possibilities to impact the "cloud" setup, which did not work as well.

Regarding the settings. I tried probably everthing you mentioned above like that. Set the IP not the DNS of the provider and set my public ip into the "which IP to use field", played with the keep alive settings in the firewall and the "PBX delivers audio" setting. But I can not guarantee that I've set everything totally that way so I will try your suggestions on Wednesday night (when I can make another test). As stated, the Trunk is needed for business during the day.

The wireshark thing might an idea as well but is hard to interpret. And here once again >>> the cloud solution behaved the same. So I guess it will just tell me that the PBX terminated the session...

Thanks so far, I'll post again after the tests

best regards

 

[N_G]

This is not a 3CX problem, but a problem with the provider you are using. Use a supported provider or else tell your provider to test against 3CX.

 

[lneblett]

Sorry, but you took my statement the wrong way. The point was that I do not disagree that there may be a setting issue or other with 3CX; hence why I suggested some possible changes, but using another system by which to compare/assess the validity of the 3CX system does not, in my opinion, lead us to knowing what the issue is that prevents 3CX from working as desired. Had the situation been reversed, the same thing could have been said about the IAX box.

Similarly, while the firewall checker may not need to be all green in a given instance, I do know for a fact that in other instances it does.

I only explained what the log post indicated. There are a number of us on the forum that can and do read Wireshark captures and while it may not be conclusive, it may be. I understand the need about staying on-line with what you have, but if you want to and have the opportunity to post one over the weekend, I would be happy to take a look. As Nick pointed out, it could be the provider and perhaps getting them involved may be of benefit too. If as I suspect, the RTP stream stopped or was altered in some manner, then we at least know that much and can rule out some of the guesswork. It would also be of benefit to get a capture of a working call with the IAX box for comparison with a 3CX capture.

 

[TobyL]

Hi Nick,
Sounds like you could now the provider settings. I thought that I can use the "Generic Provider" settings and the 3CX "certification" is just a benefit for the provider. I thought VOIP/SIP is standardized communication and should behave pretty similar on IAX and 3CX.
Can you provide the settings/features/codecs which the providers system should provide to work with 3CX. Then I could try to get the right person on the provider

This is not a 3CX problem, but a problem with the provider you are using. Use a supported provider or else tell your provider to test against 3CX.

Hi Nick,
Sounds like you could now the provider settings. I thought that I can use the "Generic Provider" settings and the 3CX "certification" is just a benefit for the provider. I thought VOIP/SIP is standardized communication and should behave pretty similar on IAX and 3CX.
Can you provide the settings/features/codecs which the providers system should provide to work with 3CX? Then I could try to get the right person on the provider site to double check there system.
Thanks

 

[TobyL]

Sorry, but you took my statement the wrong way. The point was that I do not disagree that there may be a setting issue or other with 3CX; hence why I suggested some possible changes, but using another system by which to compare/assess the validity of the 3CX system does not, in my opinion, lead us to knowing what the issue is that prevents 3CX from working as desired. Had the situation been reversed, the same thing could have been said about the IAX box.

Similarly, while the firewall checker may not need to be all green in a given instance, I do know for a fact that in other instances it does.

I only explained what the log post indicated. There are a number of us on the forum that can and do read Wireshark captures and while it may not be conclusive, it may be. I understand the need about staying on-line with what you have, but if you want to and have the opportunity to post one over the weekend, I would be happy to take a look. As Nick pointed out, it could be the provider and perhaps getting them involved may be of benefit too. If as I suspect, the RTP stream stopped or was altered in some manner, then we at least know that much and can rule out some of the guesswork. It would also be of benefit to get a capture of a working call with the IAX box for comparison with a 3CX capture.

Hi Inblett,
everything okay, agree so far and it was not my intention to compare the 3CX against the IAX I just thought that the information and fact that it's working on the IAX might isolates the problem a bit.
I'll try to test the settings and capture a call on IAX and another on 3CX to compare them.
regards Toby

 

[N_G]

Hi Nick,
Sounds like you could now the provider settings. I thought that I can use the "Generic Provider" settings and the 3CX "certification" is just a benefit for the provider. I thought VOIP/SIP is standardized communication and should behave pretty similar on IAX and 3CX.
Can you provide the settings/features/codecs which the providers system should provide to work with 3CX. Then I could try to get the right person on the provider

Hi Nick,
Sounds like you could now the provider settings. I thought that I can use the "Generic Provider" settings and the 3CX "certification" is just a benefit for the provider. I thought VOIP/SIP is standardized communication and should behave pretty similar on IAX and 3CX.
Can you provide the settings/features/codecs which the providers system should provide to work with 3CX? Then I could try to get the right person on the provider site to double check there system.
Thanks

Hi Toby, Yes SIP is a standard but open to interpretation. Providers do things differently and not always correctly. Certification is first and foremost a benefit for the customer/user - as all interop has been tested and any issues ironed out already. The provider has also made a commitment to test against 3CX and support the interop. Now you mention IAX - which is a special type of trunk used only by Asterisk, so you must get a SIP trunk and it must not be IAX. Why not get a 30 day free trial at sipgate which is a supported provider by 3CX. I am afraid we can not help you in connecting an unsupported voip provider - though you are free to call them of course.

If you want to use an unsupported provider at the very least ensure it is SIPconnect 2.0 compliant - this is a standard we fully support and this will avoid most issues as well.

 

[TobyL]

Hi Toby, Yes SIP is a standard but open to interpretation. Providers do things differently and not always correctly. Certification is first and foremost a benefit for the customer/user - as all interop has been tested and any issues ironed out already. The provider has also made a commitment to test against 3CX and support the interop. Now you mention IAX - which is a special type of trunk used only by Asterisk, so you must get a SIP trunk and it must not be IAX. Why not get a 30 day free trial at sipgate which is a supported provider by 3CX. I am afraid we can not help you in connecting an unsupported voip provider - though you are free to call them of course.

If you want to use an unsupported provider at the very least ensure it is SIPconnect 2.0 compliant - this is a standard we fully support and this will avoid most issues as well.

Hi Nick, Hi all,

Sorry for not getting back so long. Thanks for all the help!

I thought about Nick's feedback and therefore decided not to take a wireshark capture of the calls on both PBX's. What would the benefit be? Only knowing for sure that the provider does not support 3CX... Not worth the work, sorry.
Btw. : It's not the idea to change the SIP provider, we're quite happy with the services of the provider. So looks like only one option is left, change the PBX.

I still like the 3CX solution so far and will keep an eye on it. Maybe one day my provider supports this nice PBX.

Again Thanks!

 

[leejor]

There are a number of providers that will allow you a free trial (as mentioned), Some even offer ongoing, free, incoming calls. If you do some searches, you can find a number of providers that allow free calls to North American Toll free numbers without registration, SIPbroker being one. This would allow you to test with a second (hopefully, a 3CX supported) provider.

 

[TobyL]

There are a number of providers that will allow you a free trial (as mentioned), Some even offer ongoing, free, incoming calls. If you do some searches, you can find a number of providers that allow free calls to North American Toll free numbers without registration, SIPbroker being one. This would allow you to test with a second (hopefully, a 3CX supported) provider.

Hi Leejor,
I don't want to test it, sure it works. I need it working with my provider. But this information is surely helpful for others.
thanks for the help

 

[leejor]

I would however, give you more information, with which to confront your provider, when pointing out that there is something "not-quite-right" with their service.