TIPS inbound call problems "type: 11, dn: directSIP"

Rick Byrne

New Member
Joined
Jun 15, 2017
Messages
9
Reaction score
0
Gentlefolk,

I want to get your thoughts on a problem I'm having.

I'm trying to set up my voip.ms account with PIAF 5 / 3CX. I'm having trouble receiving inbound calls.

Last night I was able to receive inbound calls. I'm posting screen shots of the successful and unsuccessful calls' logs

However, this morning, without having made any changes in my configuration, when I attempt to call the PBX, the call is routed to my failover cell phone. I do, however, see the call in the log.

3CX shows the trunk as being online, and VoIP.ms' portal also reports that the device is registered.

The only documentation I can find about this type: 11 message is here: https://www.3cx.com/community/threads/inbound-direct-sip-is-rejected.1785/ . However this person is attempting to receive direct sip calls, whereas I'm trying to receive calls over my SIP trunk.

I noticed that the problem cleared up if I restarted the services through dashboard > services.

Any thoughts?
 
Joined
Nov 14, 2008
Messages
1,398
Reaction score
320
An inbound call problem after a lack of usage is usually a router issue. You mentioned registration...most providers can do registration or they send calls to your static ip if you have one. The registration initially prods the router to open the proper ports and then things will work for awhile but the router eventually drops that configuration. Whether you do registration or IP authentication you'll still need the proper forwarding of ports on the router or a low enough value for 'qualify' to keep the adhoc router config open. IP configuration requires precise router configuration, registration is prone to the type of problem you mention


 

Rick Byrne

New Member
Joined
Jun 15, 2017
Messages
9
Reaction score
0
Brian,

Thank you for your response, especially on a Saturday.

I understand your point about the proper configuration of the router.

Correct me if I'm wrong, but wouldn't the fact that 3CX sees the inbound call mean that my firewall is not at issue?

Although I'm confident my firewall is configured correctly, I'm pursuing the idea that the connection needs to be regularly prodded to stay open. In 3CX I've enabled keep alives in settings > network settings > firewall.

Now that I think about it, I may have faced the issue previously.

I recently switched over from an Endian firewall to PFSense. While I get 3CX sorted out I'm having my phones register concurrently with VoIP.ms as sub accounts. The phones are using uPnP to get through the firewall. I could see that the phones opened ports via uPNP, and the accounts would appear to be registered, but they would not ring on inbound calls. Per this page: https://doc.pfsense.org/index.php/VoIP_Configuration I enabled keep-alives on the phones lowered the register expiration to 5 minutes. That seems to have done the trick.

My hypothesis was that the PBX server was exempt from this keep-alive business because the port forwarding is permanently encoded in the firewall, whereas uPnP arrangements are more ephemeral. But I could be wrong.

I'll let the forum know how things go.

Rick
 
Joined
Nov 14, 2008
Messages
1,398
Reaction score
320
Hmmmm sorry missed that you saw them in the log. Could be that that destination device is losing registration at times. A call can "come in" on port 5060 but that's only a setup connection. Other issues could prevent the call from completing ie: codecs or no RTP. I'm running Pfsense. Did you configure static ports in Pfsense's NAT?
 

Rick Byrne

New Member
Joined
Jun 15, 2017
Messages
9
Reaction score
0
Yes, I configured static port forwarding on my router. For an image of my firewall configuration, please see the link in my previous post. But I'll summarize the information here as well: I'm forwarding UDP+TCP ports 5060-5080 and UDP ports 9000-9500 to my 3CX device's IP.

I think you may be on to something. If the 3CX thinks it's not registered, but VoIP.ms thinks it is, and VoIP.ms sends a call in, then 3CX will interpret the call as a rogue hacking attempt and refuse the connection. This would explain why the call is then routed to my failover plan: from VoIP.ms' perspective 3CX's rejection of the call means my PBX is offline. The problem with this hypothesis is that when the incoming calls fail, the trunk appears to still be online on 3CX's dashboard, so 3CX should understand the call is from a legitimate source.

If this is the case, a possible solution then would be to decrease the reregistration interval. In VoIP.ms' documentation, they're recommending a register expiration of 5 minutes. I can't seem to find a place in 3CX's configuration to set the trunk's registration interval.

Perhaps the keep-alive will accomplish a similar result.

We'll see how it goes.
 

Rick Byrne

New Member
Joined
Jun 15, 2017
Messages
9
Reaction score
0
No joy.

I'm still having the problem.

To restate the problem: I have an intermittent problem where I cannot receive inbound calls on my voip.ms trunk. The trunk appears to be online both on 3CX's end and on VoIP.ms' end. I see the incoming call in the call log as "type: 11, dn: DirectSIP" with the disposition as being "not answered." VoIP.ms routes the call to my failover plan.

I have done some more testing:

- Enabling keep alives apparently does not fix the problem.
- Forcing the trunk to reregister does not fix the problem.
- I *am*, oddly, able to receive direct SIP calls when I'm not able to receive calls over the trunk. Those calls also appear as "type: 11, dn: DirectSIP."
- Restarting the configuration server service fixes the problem.
- In the call log, when VoIP and 3CX are talking to each other, the call's destination "to" appears as the extension that answered the call. But when it's not working, the destination is "type: 11, dn: DirectSIP."

I'd like to check the registration interval, but I don't see that option anywhere in 3CX.
 

Rick Byrne

New Member
Joined
Jun 15, 2017
Messages
9
Reaction score
0
I post this in case someone else finds this thread useful in the future.

I did some more tinkering with my configuration this evening.

Although I opened the proper ports on my firewall, I noticed that when I ran a firewall check in 3CX, all my ports came back "unmatched mapping."

I dutifully followed the steps for setting up the port preservation as described here: https://www.3cx.com/docs/pfsense-firewall/. (I salute whoever created that page.) However after meticulously setting up the port preservation rule all my ports would still report "unmatched mapping."

The solution was to go to diagnostic menu > states > reset states tab > check mark "reset the firewall state table" and click reset. After doing this, all my ports now show "done" in green.

We'll see if this improves my problem with the trunk not accepting incoming calls.
 

Members online

No members online now.

Forum statistics

Threads
25,782
Messages
167,509
Members
19,202
Latest member
pbxnewguy
Get 3CX - Absolutely Free!

Link up your team and customers Phone System Live Chat Video Conferencing

Hosted or Self-managed. Up to 10 users free forever. No credit card. Try risk free.

3CX
A 3CX Account with that email already exists. You will be redirected to the Customer Portal to sign in or reset your password if you've forgotten it.
Top