Unknown Peer Error After Asterisk 15.4 Upgrade

Currently using 12.7.5-1805-3.sng7 / 14.0.3.6. FreePBX has a trunk connected to a Skype for Business 2015 standard server and has been functioning without difficulty since installation.

After a yum update, which upgraded Asterisk 15 from 15.2.2-1 to 15.4.1-1, call flow has been interrupted because of an unknown peer error. Downgrading Asterisk to 14.4.0-1 gives the same error. Downgrading again to the original 15.2.2-1 resolves the issue (after a fwconsole restart).

Calls from Skype for Business Server -> FreePBX -> SIP Provider are interrupted, but calls from SIP Provider -> FreePBX -> Skype for Business Server continue to work.

The Asterisk full log is below, as is the trunk configuration (which has been in use since before Asterisk 1.8 / FreePBX 5.211.65 without any issues). I’ve reviewed the changes listed at https://www.asterisk.org/downloads/asterisk-news/asterisk-154-now-available-0, but ashamedly cannot figure out which change has caused this issue. Can anyone point me towards a fix? Again, the only change was the Asterisk update from 15…2 to 15.4. Thanks.

[2018-06-26 21:25:31] VERBOSE[14905][C-00000037] netsock2.c: Using SIP RTP TOS bits 184
[2018-06-26 21:25:31] VERBOSE[14905][C-00000037] netsock2.c: Using SIP RTP CoS mark 5
[2018-06-26 21:25:31] VERBOSE[14906][C-00000037] pbx.c: Executing [[email protected]:1] NoOp(“SIP/domain.com-00000006”, “Received incoming SIP connection from unknown peer to +18003210288”) in new stack
[2018-06-26 21:25:31] VERBOSE[14906][C-00000037] pbx.c: Executing [[email protected]:2] Set(“SIP/domain.com-00000006”, “DID=+18003210288”) in new stack
[2018-06-26 21:25:31] VERBOSE[14906][C-00000037] pbx.c: Executing [[email protected]:3] Goto(“SIP/domain.com-00000006”, “s,1”) in new stack
[2018-06-26 21:25:31] VERBOSE[14906][C-00000037] pbx_builtins.c: Goto (from-sip-external,s,1)
[2018-06-26 21:25:31] VERBOSE[14906][C-00000037] pbx.c: Executing [[email protected]:1] GotoIf(“SIP/domain.com-00000006”, “1?setlanguage:checkanon”) in new stack
[2018-06-26 21:25:31] VERBOSE[14906][C-00000037] pbx_builtins.c: Goto (from-sip-external,s,2)
[2018-06-26 21:25:31] VERBOSE[14906][C-00000037] pbx.c: Executing [[email protected]:2] Set(“SIP/domain.com-00000006”, “CHANNEL(language)=en”) in new stack
[2018-06-26 21:25:31] VERBOSE[14906][C-00000037] pbx.c: Executing [[email protected]:3] GotoIf(“SIP/domain.com-00000006”, “1?noanonymous”) in new stack
[2018-06-26 21:25:31] VERBOSE[14906][C-00000037] pbx_builtins.c: Goto (from-sip-external,s,5)
[2018-06-26 21:25:31] VERBOSE[14906][C-00000037] pbx.c: Executing [[email protected]:5] Set(“SIP/domain.com-00000006”, “TIMEOUT(absolute)=15”) in new stack
[2018-06-26 21:25:31] VERBOSE[14906][C-00000037] func_timeout.c: Channel will hangup at 2018-06-26 21:25:46.360 UTC.
[2018-06-26 21:25:31] VERBOSE[14906][C-00000037] pbx.c: Executing [[email protected]:6] Log(“SIP/domain.com-00000006”, "WARNING,“Rejecting unknown SIP connection from 10.10.1.71"”) in new stack
[2018-06-26 21:25:31] WARNING[14906][C-00000037] Ext. s: “Rejecting unknown SIP connection from 10.10.1.71”
[2018-06-26 21:25:31] VERBOSE[14906][C-00000037] pbx.c: Executing [[email protected]:7] Answer(“SIP/domain.com-00000006”, “”) in new stack
[2018-06-26 21:25:31] VERBOSE[14906][C-00000037] pbx.c: Executing [[email protected]:8] Wait(“SIP/domain.com-00000006”, “2”) in new stack
[2018-06-26 21:25:33] VERBOSE[14906][C-00000037] pbx.c: Executing [[email protected]:9] Playback(“SIP/domain.com-00000006”, “ss-noservice”) in new stack
[2018-06-26 21:25:33] VERBOSE[14906][C-00000037] file.c: <SIP/domain.com-00000006> Playing ‘ss-noservice.alaw’ (language ‘en’)
[2018-06-26 21:25:36] VERBOSE[14906][C-00000037] pbx.c: Executing [[email protected]:1] Hangup(“SIP/domain.com-00000006”, “”) in new stack
[2018-06-26 21:25:36] VERBOSE[14906][C-00000037] pbx.c: Spawn extension (from-sip-external, h, 1) exited non-zero on ‘SIP/domain.com-00000006’

Trunk Name: LYNC
PEER Details
host=10.10.1.71
type=friend
insecure=very
transport=tcp
port=5060
canreinvite=yes
context=from-internal
qualify=yes
promiscredir=yes

USER Context: from-trunk-sip-LYNC
USER Details
type=friend
promiscredir=yes
insecure=very
fromdomain=10.10.1.71

A couple of things:

“insecure= very” is deprecated and no longer does what you want it to do. Use “insecure=port,invite” (or just “port” or “invite”) to get this to work correctly.

Since you are using a “type=friend”, there’s no reason to have the “User” config. The only thing you need to do to delete this spurious group of settings is add “fromdomain=10.10.1.71” to your “User” settings. This will accomplish exactly the same thing you are trying to do now, but without the “extra” inbound trunk.

Are you sure you want promiscuous redirects from this trunk? This is an unusual, specific option. Since you’re using S4B, it may well be necessary, but if it isn’t, I’d recommend getting rid of it.

Thanks for the help. Per your instructions, I changed the configs to:

host=10.10.1.71
type=friend
insecure=port,invite
transport=tcp
port=5060
canreinvite=yes
context=from-internal
qualify=yes

fromdomain=10.10.1.71
type=friend

This changes the insecure= statement, removes most of the user config, and removes promiscuous redirects.
I added type=friend to the user config in so that this warning was avoided:
[2018-06-27 16:22:15] WARNING[62822] chan_sip.c: Section ‘from-trunk-sip-LYNC’ lacks type
Let me know if I still need to pull type=friend from the user config.

The changed config works fine with Asterisk 15.2.2-1.

There appears to be a much bigger change, though, with Asterisk between 15.2 and 15.4. After upgrading Asterisk via yum update, calls still fail, and SfB stops communicating altogether with Freepbx. The following is from the Windows Event Viewer, after upgrading Asterisk to 15.4.1-1 and fwconsole stop / start (no changes to /var/log/asterisk/full as SfB doesn’t communicate after the upgrade):

(LS Mediation Server, Event ID 25051)
The Trunk, freepbx.domain.com;trunk=freepbx.domain.com, is not responding to an OPTIONS request sent by the Mediation Server service.
DNS Resolution Failure: False
Exception: Microsoft.Rtc.Signaling.ConnectionFailureException:Unable to establish a connection. —> System.Net.Sockets.SocketException (0x80004005): No connection could be made because the target machine actively refused it 10.10.1.62:5060
at System.Net.Sockets.Socket.EndConnect(IAsyncResult asyncResult)
at Microsoft.Rtc.Internal.Sip.TcpTransport.OnConnected(Object arg)

Last minute edit: This is also in the Windows Event Viewer (LS Outbound Routing, 46047). The 401 may indicate unauthorized?
A PBX gateway has been marked as less-preferred.

Gateway name: freepbx.diamedic.net
Response Code: 401
Consecutive Failure occurrences: 25
Cause: The gateway responded with the same failure response multiple consecutive times and is being marked as less-preferred.
Resolution:
Verify that the gateway is functioning correctly.

Another edit: I’ve tried changing from type=friend to type=peer, and everything works in 15.2, but gets the same behavior (no response to OPTIONS / Response Code 401) with 15.4.

The option “type=friend” is a shorthand for “set up a peer section with ‘type=peer’ and set up a user section with ‘type=user’”. The User section and the Peer section are, for most purposes completely distinct. If you are going to use both, set up both sections as their respective types.

Thanks. I have removed everything from the user section, and I’m still getting the 401 / no response to options issue. As I said, I believe I have tried all combinations. What else can I do?

This is my current config, with Asterisk 15.2 running:
host=10.10.1.71
type=peer
insecure=port,invite
transport=tcp
port=5060
canreinvite=no
context=from-internal
qualify=yes

User context and details are empty.

If you have removed everything from the “User” section, your type needs to be “type=friend” to establish the corresponding user options from the Peer setup. You also still need the “fromdomain=” setting so that your remote provider can authenticate you.

Once you set those back up, you should have a working set on TRUNKS. Note that this is only the first step in a three step process for correct operations.

After you get a working trunk configuration, you will still need to follow the directions and set up appropriate inbound and outbound routes (step 2 and 3, respectively). Even though your trunk configuration is using the “friend” shortcut, the inbound trunking abd outbound trunking are still largely independent.

Troubleshoot one, then the other. Trying to do both at the same time is too many plates in the air at once.

Dave,
Thanks again for the help. The trunk was working fine for years. The routes have been working fine for years. Something has changed between Asterisk 15.2 and 15.4.
I have gone to the configuration you suggested, listed below, and the issue remains the same. If you have any other thoughts, I would appreciate it.

host=10.10.1.71
type=friend
insecure=port,invite
transport=tcp
port=5060
canreinvite=no
context=from-internal
qualify=yes

User Context from-LYNC
User Details
fromdomain=10.10.1.71

What is the server 10.10.1.71? It isn’t a provider’s server, because the network address is not routable.

OK - apparently there’s some disconnect in the way I’m telling you do to this:

In your “PEER Settings”, give the Peer a trunk name.

Use the following settings:

type=friend
host=10.10.1.71
fromdomain=10.10.1.71
insecure=port,invite
port=5060
canreinvite=no
context=from-internal

Do not use a USER section. There are no USER settings. The USER area should be blank. Blank out the USER section of the settings. Remove the USER settings from the config. Do not include any settings in the USER section. You shouldn’t need USER settings since you are not using USER routing for your incoming traffic. The USER settings should be blank.

There are two settings I removed from your PEER settings:
qualify= and transport=

The qualify setting sends “OPTIONS” commands to your trunk provider every 2 seconds to make sure the “phone” at your provider’s end of the connection is there. Since they aren’t a phone, that isn’t probably appropriate.

The transport setting tells your end of the connection to use the TCP protocol for your connection. This would be HIGHLY unusual, since almost all VOIP providers use UDP for their connections. If your provider is using TCP, go ahead and put it back in, but it really would be highly unusual and run counter to all of my experience with SIP (which is usually a SIP protocol unless you are working with Cisco Phones in SIP mode). If this turns out to be the case, you also need to make sure the Advanced SIP settings are configure to pass the TCP protocol (since the default and norm is UDP only). You will also need to adjust the Integrated Firewall to allow traffic to and from TCP port 5060 (since the firewall also blocks TCP by default).

In your log dump, you are processing an inbound call that isn’t processed correctly. Part of that is because the call is coming from outside your system (the context is “from-sip-external”) and is being routed to another number outside your system (+1xxxxxxxxx). This is normally not allowed. For this to work, you need to be processing that incoming call through the “from-internal” context.

Perhaps you missed the earlier part of this thread, where I said (and you acknowledged) that this is a Skype for Business / Lync server?
I’ve tried the exact settings for peer that you have just listed, with no settings in user, with the exception of removing transport. Skype for Business requires TCP transport. Advanced SIP settings and firewall settings have long been in place. This was working for years, and only changed with the move from Asterisk 15.2 to 15.4. In addition, the from-internal context is being processed, as you can see from the settings.

@diamedic

Did you ever manage to resolve this issue?
We are experiencing exactly the same problem after upgrading Asterisk to the latest version.

Trunk from SfB to FreePBX is not being recognized as the peer and the calls are redirected to from-sip-external context, with warning message: Rejecting unknown SIP connection from .

As soon as I revert the version of Asterisk back to 13.18.4, everything seems to be fine.
Thank you.

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.