No Inbound Calls

Hi All,
I know this issue has popped up before but this newbie was unable to get any resolution.
I have extensions all working and all are able to make outbound calls.
I have disconnected all other phones that were directly connected to my SIP provider and when I try to call in on my mobile I just get the message that the service is not compatible.

Here is a debug output when attempting an inbound call.

[2018-08-05 20:42:41] DEBUG[6109]: threadpool.c:1137 worker_idle: Worker thread idle timeout reached. Dying.
[2018-08-05 20:42:53] DEBUG[1088]: chan_sip.c:9012 __sip_alloc: Allocating new SIP dialog for [email protected]:5060 - INVITE (No RTP)
[2018-08-05 20:42:53] DEBUG[1088][C-00000029]: chan_sip.c:4534 __sip_ack: Stopping retransmission on '[email protected]:5060' of Response 102: Match Found
[2018-08-05 20:42:59] DEBUG[6080]: threadpool.c:1137 worker_idle: Worker thread idle timeout reached. Dying.
[2018-08-05 20:42:59] DEBUG[6079]: threadpool.c:1137 worker_idle: Worker thread idle timeout reached. Dying.
[2018-08-05 20:42:59] DEBUG[6081]: threadpool.c:1137 worker_idle: Worker thread idle timeout reached. Dying.
[2018-08-05 20:42:59] DEBUG[6078]: threadpool.c:1137 worker_idle: Worker thread idle timeout reached. Dying.
[2018-08-05 20:42:59] DEBUG[6077]: threadpool.c:1137 worker_idle: Worker thread idle timeout reached. Dying.
[2018-08-05 20:43:00] DEBUG[6082]: threadpool.c:1137 worker_idle: Worker thread idle timeout reached. Dying.
[2018-08-05 20:43:00] DEBUG[1088]: chan_sip.c:9012 __sip_alloc: Allocating new SIP dialog for [email protected]:5060 - OPTIONS (No RTP)
[2018-08-05 20:43:00] DEBUG[1088]: chan_sip.c:8797 change_callid_pvt: SIP call-id changed from '[email protected]:5060' to '[email protected]:5060'
[2018-08-05 20:43:00] DEBUG[1088]: chan_sip.c:3393 initialize_initreq: Initializing initreq for method OPTIONS - callid [email protected]:5060
[2018-08-05 20:43:00] DEBUG[1088]: chan_sip.c:9012 __sip_alloc: Allocating new SIP dialog for [email protected]:5060 - OPTIONS (No RTP)
[2018-08-05 20:43:00] DEBUG[1088]: chan_sip.c:8797 change_callid_pvt: SIP call-id changed from '[email protected]:5060' to '[email protected]:5060'
[2018-08-05 20:43:00] DEBUG[1088]: chan_sip.c:3393 initialize_initreq: Initializing initreq for method OPTIONS - callid [email protected]:5060
[2018-08-05 20:43:01] DEBUG[1088]: chan_sip.c:9012 __sip_alloc: Allocating new SIP dialog for [email protected]:5060 - OPTIONS (No RTP)
[2018-08-05 20:43:01] DEBUG[1088]: chan_sip.c:8797 change_callid_pvt: SIP call-id changed from '[email protected]:5060' to '[email protected]:5060'
[2018-08-05 20:43:01] DEBUG[1088]: chan_sip.c:3393 initialize_initreq: Initializing initreq for method OPTIONS - callid [email protected]:5060
[2018-08-05 20:43:01] DEBUG[1088]: chan_sip.c:4534 __sip_ack: Stopping retransmission on '[email protected]:5060' of Request 102: Match Found
[2018-08-05 20:43:01] DEBUG[1088]: chan_sip.c:4534 __sip_ack: Stopping retransmission on '[email protected]:5060' of Request 102: Match Found
[2018-08-05 20:43:01] DEBUG[1088]: chan_sip.c:4534 __sip_ack: Stopping retransmission on '[email protected]:5060' of Request 102: Match Found

Hopefully, you are able to help this newbie?

it looks no incoming call routing?

HI James,

Ok, thanks for the reply.

So what do I need to look at in order to resolve it?
I do have incoming rules.

Also inbound route

What am I missing?

Regards Ian

have you set the ring group and added the phone in the group?

Hi James,
Yes and it works. It rings all phones both it I call the group 200 and if I perform a test incoming call 7777.

The SIP Supplier was not helpful as they do not supply it, what a surprise!

Maybe I should mention that this is on at NATTED LAN.
I have other SIP phones which do work so the firewall is not blocking sip traffic.
Thanks.

You have natted phones and FreePBX in the same network, call talking to your main SIP provider?

That sounds like something I would not do.

Hi Cynjut,

Thank you for your response.

In essence yes, however, for testing I have disconnected the other phones (the rinning was getting annoying!).
So I only have the FreePBX connected.

Moving on, I have now managed to get inbound calls but only by turning the Allow Anonymous Inbound SIP Calls to Yes!

So I now need to find out how to be able to turn this back to No and still have it working?

Hi All,

If I set Allow Anonymous Inbound SIP Calls YES
I can get inbound calls fine but as the warnings say this is not secure.

But if I set Allow Anonymous Inbound SIP Calls NO then calls are rejected and the caller gets a message saying the number is not in service!
Below is the trace from such an attempt. What must I do to permit the calls and where di I do it?

Thanks

raspbxCLI>
== Using SIP RTP TOS bits 184
== Using SIP RTP CoS mark 5
> 0xadf33630 – Strict RTP learning after remote address set to: 77.240.61.172:18862
– Executing [s@from-sip-external:1] GotoIf(“SIP/77.240.61.172-00000019”, “1?setlanguage:checkanon”) in new stack
– Goto (from-sip-external,s,2)
– Executing [s@from-sip-external:2] Set(“SIP/77.240.61.172-00000019”, “CHANNEL(language)=en_GB”) in new stack
– Executing [s@from-sip-external:3] GotoIf(“SIP/77.240.61.172-00000019”, “1?noanonymous”) in new stack
– Goto (from-sip-external,s,5)
– Executing [s@from-sip-external:5] Set(“SIP/77.240.61.172-00000019”, “TIMEOUT(absolute)=15”) in new stack
– Channel will hangup at 2018-08-06 16:28:38.742 BST.
– Executing [s@from-sip-external:6] Log(“SIP/77.240.61.172-00000019”, "WARNING,“Rejecting unknown SIP connection from 217.14.138.127"”) in new stack
[2018-08-06 16:28:23] WARNING[9487][C-00000017]: Ext. s:6 @ from-sip-external: “Rejecting unknown SIP connection from 217.14.138.127”
– Executing [s@from-sip-external:7] Answer(“SIP/77.240.61.172-00000019”, “”) in new stack
– Executing [s@from-sip-external:8] Wait(“SIP/77.240.61.172-00000019”, “2”) in new stack
> 0xadf33630 – Strict RTP switching to RTP target address 77.240.61.172:18862 as source
– Executing [s@from-sip-external:9] Playback(“SIP/77.240.61.172-00000019”, “ss-noservice”) in new stack
– <SIP/77.240.61.172-00000019> Playing ‘ss-noservice.ulaw’ (language ‘en_GB’)
> 0xadf33630 – Strict RTP learning complete - Locking on source address 77.240.61.172:18862
– Executing [h@from-sip-external:1] Hangup(“SIP/77.240.61.172-00000019”, “”) in new stack
== Spawn extension (from-sip-external, h, 1) exited non-zero on ‘SIP/77.240.61.172-00000019’
raspbx
CLI>

You need an inbound route. Even is the CID and DID are blank (what we call an ?Any/Any" route) and you need to point it to your extension/ring group/queue/IVR.

The called DID(DDI) is probably in the headers , try the context

from-pstn-toheader

for your trunk with telappliant ( the ip of origination)

Cynjut,

I do have inbound route configured:-

Sorry, Dicko,

I not sure exactly what you mean. Yep I know I’m thick :smile:
Yes I know the IP Addresses are registered to Telappliant

OK, with an any/any inbound route, any call that connects through one of your trunks will be answered. Since you’ve done that, you need to check your trunk configuration. Are you using a “type=friend” setup, or do you have separate “type=peer” and “type=user” sections?

In your “User” section (if you are using “type=user”) or in your Peer section (if you are using “type=friend”) is a setting for “context=something”, That something is your inbound context. @dicko suggested (and I concur) that your context could be set to “from-pstn-toheader” so that, if the “To:” header is used, you will get the Direct In Dial number from that instead of the “regular” SIP way.

Thanks, Cynjut,

The best way for me is to send you screenshots.



My plan was to ring all phones and I have a group 200 setup for this, I still need to set a group Voicemail box but have not looked at that yet so it just goes to one phone’s voicemail for now. This seems to work.

OK - let’s see what we can do:

  • host=draynet.com” isn’t going to work, you end up getting traffic from the one place that DNS resolved that to. You’ll need to set up one trunk per host with the IP address for each server built into the definition. REITERATE - one trunk per server for inbound. We all know and understand that it “should” work, but we also all know that it doesn’t with Chan_SIP, so arguing about it is not going to get you anywhere.
  • “type=friend” means that you don’t set up PEER and USER for this host. You combine the settings into your PEER section and use that as your connection. Important “getting it to work” point. If you can’t send a call to the IP address you set in the “host=” entry, do not try to set up a “type=friend” entry. Entries that are the same in both can be specified once. Anything in one but not the other needs to be copied to the “PEER” settings.

Start with those two and see if you can get closer.