Summary:	ASTERISK-26787: Received incoming SIP connection from unknown peer" from registered sip provider
Reporter:	Andy Woolford (andy_woolford)	Labels:
Date Opened:	2017-02-12 02:05:49.000-0600	Date Closed:	2017-02-12 05:34:06.000-0600
Priority:	Major	Regression?
Status:	Closed/Complete	Components:	Channels/chan_sip/General Channels/chan_sip/Registration
Versions:	11.24.1	Frequency of Occurrence	Constant
Related Issues:
Environment:	FreePBX Distro 10.13.66-17 / (Centos)	Attachments:
Description:	We started to notice that inbound calls from one sip provider (internetcalls.com) were being rejected as follows: {code:java} [2017-02-01 09:33:10] VERBOSE[23991][C-00000b80] pbx.c: -- Executing [44XXXXXXXXXX@from-sip-external:1] NoOp("SIP/sip.internetcalls.com-00000bbc", "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/sip.internetcalls.com-00000bbc", "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/sip.internetcalls.com-00000bbc", "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/sip.internetcalls.com-00000bbc", "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/sip.internetcalls.com-00000bbc", "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/sip.internetcalls.com-00000bbc", "WARNING,"Rejecting unknown SIP connection from 77.72.169.134"") in new stack [2017-02-01 09:33:10] WARNING[23991][C-00000b80] Ext. s: "Rejecting unknown SIP connection from 77.72.169.134" [2017-02-01 09:33:10] VERBOSE[23991][C-00000b80] pbx.c: -- Executing [s@from-sip-external:7] Answer("SIP/sip.internetcalls.com-00000bbc", "") in new stack [2017-02-01 09:33:11] VERBOSE[23991][C-00000b80] pbx.c: -- Executing [s@from-sip-external:8] Wait("SIP/sip.internetcalls.com-00000bbc", "2") in new stack [2017-02-01 09:33:13] VERBOSE[23991][C-00000b80] pbx.c: -- Executing [s@from-sip-external:9] Playback("SIP/sip.internetcalls.com-00000bbc", "ss-noservice") in new stack [2017-02-01 09:33:13] VERBOSE[23991][C-00000b80] file.c: -- <SIP/sip.internetcalls.com-00000bbc> 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/sip.internetcalls.com-00000bbc", "congestion") in new stack [2017-02-01 09:33:18] VERBOSE[23991][C-00000b80] pbx.c: -- Executing [s@from-sip-external:11] Congestion("SIP/sip.internetcalls.com-00000bbc", "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/sip.internetcalls.com-00000bbc' [2017-02-01 09:33:19] VERBOSE[23991][C-00000b80] pbx.c: -- Executing [h@from-sip-external:1] Hangup("SIP/sip.internetcalls.com-00000bbc", "") 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/sip.internetcalls.com-00000bbc' {code} The trunk configuration for this provider looks like this (sip_additional.conf): {code:java} [Andy_ICalls_Out] username=xxx type=peer sendrpid=yes secret=xxx qualify=yes nat=no insecure=port,invite host=sip.internetcalls.com fromuser=xxx fromdomain=internetcalls.com dtmfmode=rfc2833 canreinvite=yes authuser=xxx context=from-trunk-sip-Andy_ICalls_Out {code} The registration string also uses sip.internetcalls.com as the host url. # dig sip.internetcalls.com returns: {code:java} ;; ANSWER SECTION: sip.internetcalls.com.  1121    IN      A       77.72.169.134 sip.internetcalls.com.  1121    IN      A       77.72.169.129 {code} asterisk sip show peers: {code:java} Andy_ICalls_Out/[username] 77.72.169.129                               No         No             5060     OK (17 ms) {code} I have noticed that incoming calls to the registered IP address 77.72.169.129 are accepted, but incoming calls from the alternative IP address 77.72.169.134 are rejected. The temporary workaround is to replace the URL in the host=sip.internetcalls.com statement with one IP address and to create a duplicate trunk using the other IP address.  In this case, both IP addresses will register and then both will be accepted. It seems to me that the purpose of using a URL in the "host=internetcalls.com" statement of the trunk configuration should avoid having to do this.  It is not a huge problem where only 2 IP addresses are expected, but may be a bigger problem for other providers. There is an asterisk blog as follows which addresses this issue: https://blogs.asterisk.org/2016/01/27/the-pjsip-outbound-registration-line-option/ This proposes that under chan_sip the following example configuration should be used: {{[inbound-configuration] type=peer context=incoming-itsp disallow=all allow=ulaw insecure=host,port [inbound1](inbound-configuration) host=94.100.23.82 [inbound2](inbound-configuration) host=94.100.23.83 [inbound3](inbound-configuration) host=94.100.23.84 [inbound4](inbound-configuration) host=94.100.23.85 [inbound5](inbound-configuration) host=94.100.23.86}} I am not familiar with the use of "insecure=host, port".  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. Accordingly, can you clarify if the use of a URL in the "host=internetcalls.com" field with type=peer is allowed and, if so, if it is a bug that incoming calls are being rejected from one or other of the IP addresses which are resolved.
Comments:	By: Asterisk Team (asteriskteam) 2017-02-12 02:05:50.152-0600 Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution. A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report. Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process]. By: Joshua C. Colp (jcolp) 2017-02-12 05:34:06.609-0600 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.