Problem with incomming call via VOIP provider

[adza]

Hi,

I have our system setup to use a number of VOIP providers. Amongst which - i have setup an option for incomming VOIP calls to be directed / routed to the 3CX server.

I'm finding a problem in that I can have this setup, and it works fine - but then after a few minutes, it will not receive any calls. Anyone trying to call through just gets silence on there phone.

According to both 3CX, and the end VOIP provider, I am still registered, but the calls won't come through. If I restart the 3CX server, the calls will come back through again for a period of time.

I am behind a NAT firewall to have access to the internet. I have opened up port 5060 from the outside to go to my 3CX server. There are no restrictions on outbound packets.

Can anyone suggest what might be causing this?

Thanks & Regards

Adam.

 

[adza]

Aah - I think I may be onto something...

When 3CX registers with my VOIP provider, apparently it gives the provider a 'rinstance' ID.

ie... sip:[email protected]:5060;rinstance=a139c126a2692449

I'm thinking that when 3CX re-registers, it changes this ID, but my VOIP providers ID doesn't seem to change unless I initiate something within 3CX. I'm therefore guessing that when the call is passed through to 3CX, it's passing the wrong "rinstance" id, and therefore the call is 'dropped'.

I'm now guessing (providing my guess above is accurate), I want to make a change somewhere in the "Source Identification" to match my "line number" instead of the rinstance id.

Is anyone able to confirm whether or not this is what I should be looking at, or whether I'm way off?

Thanks & Regards

Adam.

 

[adza]

Interestingly enough - no log entries appear (even in verbose mode) when I try calling myself when this error occurs.

When I first start the server, everything works fine, but if I wait about 5 mins, no incomming calls will get through to me.

Is there a way to open up 3CX so it will receive calls on a particular port regardless of what tags are included in the call?

Thanks & Regards

Adam

 

[adza]

I'm not sure if this helps - but this is the information in the log that comes through IF the call gets in. (Normally only within the first few minutes of registration with the provider)

21:13:28.312 Call::Terminate [CM503008]: Call(11): Call is terminated
21:13:28.296 LineCfg::getInboundTarget [CM503011]: Inbound office hours' rule for LN:10003 forwards to DN:800
21:13:08.375 CallCtrl:nAnsweredCall [CM503002]: Call(11): Alerting sip:[email protected]:18032;transport=udp
21:13:08.234 CallCtrl:nAnsweredCall [CM503002]: Call(11): Alerting sip:[email protected]:28526;transport=udp
21:13:07.953 CallCtrl:nSelectRouteReq [CM503004]: Call(11): Calling: RingAll:800@[Dev:sip:[email protected]:28526;transport=udp, Dev:sip:[email protected], Dev:sip:[email protected]:18032;transport=udp]
21:13:07.953 CallCtrl:nSelectRouteReq [CM503010]: Making route(s) to [sip:[email protected]:5060]
21:13:07.953 Line:rintEndpointInfo [CM505003]: Provider:[Pennytel2] Device info: Device Not Identified: User Agent not matched; Capabilities:[reinvite, replaces, able-no-sdp, recvonly] UserAgent: [Sippy] Transport: [sip:192.168.0.1:5060]
21:13:07.953 LineCfg::getInboundTarget [CM503011]: Inbound office hours' rule for LN:10003 forwards to DN:800
21:13:07.937 CallCtrl:nIncomingCall [CM503001]: Call(11): Incoming call from 888012@(Ln.10003@Pennytel2) to [sip:[email protected]:5060]
21:13:07.687 LineCfg::getInboundTarget [CM503011]: Inbound office hours' rule for LN:10003 forwards to DN:800

 

[jits04]

1) These are the ports to open on your router: 5060-5062 tcp/up 9000-9015 udp

Please check your windows firewall too. If you are behind NAT you could disable the service. Otherwise open the same ports.

William

 

[adza]

Hi William,

And thanks for your reply!!!

We have no firewall running on Windows, and the machine with 3CX has full outbound access to the internet.

As for incomming ports, we have routed via NAT port 5060 through to the 3CX machine.

When we do the 3CX firewall tests - they all come back green.

Should we be rouding ports 9000 thru 9015 back IN to the server also, or do these only need to be outbound?

I also notice that you mentioned 5060 to 5062. Were you talking outbound, or creating a NAT rule of these ports inbound?

Thanks & Regards

Adam.

 

[aguilar]

hello have you tried DMZ just for test?

regards

 

[adza]

Hi,

Thanks for your reply. It looks as though my problem is the same as the one posted in this thread:

http://www.3cx.com/forums/incoming-calls-fail-3902.html

However, since then, I've found if I open up ports 5060 through 5070 it appears to be behaving itself now.

I'm waiting to hear back from the other in the other thread to see if this made a difference for them too.

Best Regards

Adam.

 

[wzaatar]

Hi,

Change the registration time from the default (Which is 60 minutes) to 2 minutes (120 seconds).

That will fix your problem.

Cheers,

Wadih

 

[adza]

Hi Wadih,

Thanks for your reply. I have tried reducing the time to 2 mins (and even 60 seconds) but that didn't fix the problem. The only way so far I have found to fix the problem was by opening up ports 5060 through to 5070.

Best Regards

Adam

 

[wzaatar]

Hi Wadih,

Thanks for your reply. I have tried reducing the time to 2 mins (and even 60 seconds) but that didn't fix the problem. The only way so far I have found to fix the problem was by opening up ports 5060 through to 5070.

Best Regards

Adam

That's not good. It's a security breach.

Listen, I don't mind helping you debugging it. Send me an email to wzaatar at mail dot com and we'll exchange AIMs.

Cheers,

Wadih