Received incoming SIP connection from unknown peer" from registered sip provider

Asterisk Version: 11.24.1
FreePBX Distro 10.13.66-17

We started to notice that inbound calls from one sip provider ( were being rejected as follows:

    [2017-02-01 09:33:10] VERBOSE[23991][C-00000b80] pbx.c: -- Executing [44XXXXXXXXXX@from-sip-external:1] NoOp("SIP/", "Received incoming SIP connection from unknown peer to 44XXXXXXXXXX") in new stack
[2017-02-01 09:33:10] VERBOSE[23991][C-00000b80] pbx.c: -- Executing [44XXXXXXXXXX@from-sip-external:2] Set("SIP/", "DID=44XXXXXXXXXX") in new stack
[2017-02-01 09:33:10] VERBOSE[23991][C-00000b80] pbx.c: -- Executing [44XXXXXXXXXX@from-sip-external:3] Goto("SIP/", "s,1") in new stack
[2017-02-01 09:33:10] VERBOSE[23991][C-00000b80] pbx.c: -- Goto (from-sip-external,s,1)
[2017-02-01 09:33:10] VERBOSE[23991][C-00000b80] pbx.c: -- Executing [s@from-sip-external:1] GotoIf("SIP/", "0?checklang:noanonymous") in new stack
[2017-02-01 09:33:10] VERBOSE[23991][C-00000b80] pbx.c: -- Goto (from-sip-external,s,5)
[2017-02-01 09:33:10] VERBOSE[23991][C-00000b80] pbx.c: -- Executing [s@from-sip-external:5] Set("SIP/", "TIMEOUT(absolute)=15") in new stack
[2017-02-01 09:33:10] VERBOSE[23991][C-00000b80] func_timeout.c: -- Channel will hangup at 2017-02-01 09:33:25.707 UTC.
[2017-02-01 09:33:10] VERBOSE[23991][C-00000b80] pbx.c: -- Executing [s@from-sip-external:6] Log("SIP/", "WARNING,"Rejecting unknown SIP connection from"") in new stack
[2017-02-01 09:33:10] WARNING[23991][C-00000b80] Ext. s: "Rejecting unknown SIP connection from"
[2017-02-01 09:33:10] VERBOSE[23991][C-00000b80] pbx.c: -- Executing [s@from-sip-external:7] Answer("SIP/", "") in new stack
[2017-02-01 09:33:11] VERBOSE[23991][C-00000b80] pbx.c: -- Executing [s@from-sip-external:8] Wait("SIP/", "2") in new stack
[2017-02-01 09:33:13] VERBOSE[23991][C-00000b80] pbx.c: -- Executing [s@from-sip-external:9] Playback("SIP/", "ss-noservice") in new stack
[2017-02-01 09:33:13] VERBOSE[23991][C-00000b80] file.c: -- <SIP/> Playing 'ss-noservice.alaw' (language 'en')
[2017-02-01 09:33:18] VERBOSE[23991][C-00000b80] pbx.c: -- Executing [s@from-sip-external:10] PlayTones("SIP/", "congestion") in new stack
[2017-02-01 09:33:18] VERBOSE[23991][C-00000b80] pbx.c: -- Executing [s@from-sip-external:11] Congestion("SIP/", "5") in new stack
[2017-02-01 09:33:19] VERBOSE[23991][C-00000b80] pbx.c: == Spawn extension (from-sip-external, s, 11) exited non-zero on 'SIP/'
[2017-02-01 09:33:19] VERBOSE[23991][C-00000b80] pbx.c: -- Executing [h@from-sip-external:1] Hangup("SIP/", "") in new stack
[2017-02-01 09:33:19] VERBOSE[23991][C-00000b80] pbx.c: == Spawn extension (from-sip-external, h, 1) exited non-zero on 'SIP/'

The trunk configuration for this provider looks like this (sip_additional.conf):


The registration string also uses as the host url.
dig returns:

;; ANSWER SECTION:  1121    IN      A  1121    IN      A

asterisk sip show peers:

Andy_ICalls_Out/[username] No No 5060 OK (17 ms)

I raised this as a bug on the “Issues” page but was advised by “Joshua Colp” that:

This is not a bug as chan)sip does not allow multiple IP addresses, even when a hostname is provided. It will resolve, and store, only one.

The approach of using multiple peers, one with each IP address, is the way to support this in chan_sip.

I do not doubt this information but it is strange because my configuration above (which uses only a hostname URL in the field “” has worked for a number of years - and has only recently started failing for inbound calls.

There is an asterisk blog which addresses this issue further:

This proposes that under chan_sip the following example configuration should be used:


Now, using this example above, I am not familiar with the use of the setting “insecure=host, port”. (Bearing in mind I am using Asterisk 11.24.1)

I understood that this is normally either “insecure=very” for asterisk version 1.0.9 or earlier, or for later versions:

insecure=port ; Allow matching of peer by IP address without matching port number;
insecure=invite ; Do not require authentication of incoming INVITEs or
insecure=port,invite ; (both)

Typically used to allow incoming calls (e.g. from FWD) while having a type=friend entry defined with username and password.

It is worth mentioning that although my trunk configuration above DOES have a username and password, this most likely is only being used for outgoing calls. I don’t think the provider uses it to authenticate Inbound calls.

Accordingly, I would appreciate some further guidance on what should be entered in the insecure field in conjunction with “type=peer” as should be used for an inbound and outbound trunk.

There are very few cases where type=friend should be used; this is not one of them; use type=peer. However that is not causing your problem.

At a guess insecure=host was a mistake, unless there has been a recent move to deprecate invite in favour of host. You should not use insecure=port, unless you actually need to use it, and using remotesecret, instead of secret, is, in my view, a clearer way of achieving what insecure=invite did.

Asterisk doesn’t have a concept of a trunk, and has no way of specifying that a peer entry should only be used for outbound calls. It will use a random entry that matches the IP address, so, if the peer can originate calls from the address you used for your “outbound trunk”, it may well match that, rather than the “inbound trunk” with the same address, so both should contain the same parameters as far as they relate to inbound calls.

Thanks for this info David.

As you say, I use type=peer.

I was having some difficulty in making sense of the “insecure=” settings and misprints don’t help obviously.

May I ask why you would not use the insecure=port? It seems a very common setting which would apparently go some way towards doing what I want, which is to allow incoming calls from a SIP provider using the host IP address defined in the “host=” field.

Insecure is called that because it disables security check. As such, you should only disable the checks that you absolutely need to disable.

insecure=invite does not, in itself, permit calls from a different IP address from that in the peer entry; you still need a peer entry for every IP address.

What insecure=invite does is to disable password checking on incoming calls.

insecure=port disables checking of the port number. You may need if if incoming calls don’t come from port 5060, but you should only enable it if you actually need it.

Ah, the mist is beginning to lift.

Many thanks. I will do this.