[asterisk-bugs] [JIRA] (ASTERISK-26787) Received incoming SIP connection from unknown peer" from registered sip provider
Joshua Colp (JIRA)
noreply at issues.asterisk.org
Sun Feb 12 05:35:10 CST 2017
[ https://issues.asterisk.org/jira/browse/ASTERISK-26787?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Joshua Colp closed ASTERISK-26787.
----------------------------------
Resolution: Not A Bug
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.
> Received incoming SIP connection from unknown peer" from registered sip provider
> --------------------------------------------------------------------------------
>
> Key: ASTERISK-26787
> URL: https://issues.asterisk.org/jira/browse/ASTERISK-26787
> Project: Asterisk
> Issue Type: Bug
> Security Level: None
> Components: Channels/chan_sip/General, Channels/chan_sip/Registration
> Affects Versions: 11.24.1
> Environment: FreePBX Distro 10.13.66-17 / (Centos)
> Reporter: Andy Woolford
>
> 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
More information about the asterisk-bugs
mailing list