Asterisk 15 + Linphone Derps

Asterisk Asterisk SIP
1

Hello! I’m quite new to SIP, but while I may be a noob to it I don’t think I’m THAT much of a noob as far as basic networks goes. Here’s the fun thing I’m going through right now:

If I call from my test extension 1000 (conveniently named “God”) to my smartphone at 1003, the call drops are 32 seconds. Apparently I get a repeated flood of 401s in the debug. If I call from 1003 to 1000, the call goes on forever. The codec negotiation and quality are great, and I love how Linphone gives me opus and speex so readily.

Some notes: the smartphone is an LG V20 Android smartphone, and the test extension right now is on a MacBook Pro running High Sierra; both are running Linphone and are updated. I tried calling an iOS device last night and it worked just beautifully, no problem. The server is an Ubuntu VirtualBox system with an adapter in bridging mode.

Logs:

1000 to 1003, Fail

https://pastebin.com/NzzDAcPi

1003 to 1000, Success

https://pastebin.com/7qXGKWNM

NAT isn’t being used in either case at this point, and yet this is happening. I’m so lost x.x. To make this even more interesting, 1003 can’t call 1005, it also fails in a similar manner. 1005 is a One Plus One, so it’s an Android smartphone. The same problem occurs when 1005 calls 1003, it still drops at 32 seconds.

I was initially only referencing to my Asterisk box via its private IP address, but then I figured “what the heck, might as well try to do it all in one go.” The problem is still the same =. Zoiper coincidentally doesn’t have as many issues but I don’t want to pay 8 dollars to use a codec that’s otherwise free per phone.

I’m using a Sophos UTM 9 firewall, I’ve enabled SIP mode, I’ve added the DNAT rule, I’ve enabled all SIP relevant communications to go through. Some firewall specific rules:

1000 is on a laptop with full access and all ports opened and on the same WAN as the Asterisk server
1003 is on a smartphone with all ports opened but on a different WAN (AND THIS ONE WORKS!)
1005 is a standard smartphone with ports closed on the same WAN as 1003

2

Ok so I’m getting somewhere; I enabled the RTP ports and also allowed an exception rule for the Asterisk server under web filtering. Sadly there’s not THAT much materials on the interwebz for Sophos and VoIP setups. Can anyone lend a hand here please?

3

So my big mistake, I should’ve cleared out my IP address. Wonderful to see so many unsolicited connections. Jerks.

4

32 seconds is the timeout for failing to get a SIP response and is normally NAT or firewall related.

The normal dialogue is INVITE; 401; ACK INVITE with authentication; 200; ACK.

It looks as though the ACK is never arriving, and that is why the call is falling.

Being connected to the internet is sufficient to be found and attacked. I think that is more likely than that someone picked up your log that quickly.

5

Thanks for the response david. I’ve disabled the external NAT route for now, will probably switch to TLS and a custom port eventually.

The server is on a separate VLAN from the clients, and I’m guessing that that’s why the firewall is active in the middle. What bothers me is why this is happening for only one of the devices instead of both. In fact, the device that I think SHOULD be working, the MBP, isn’t, and the V20 is working fine. Got any insights?

I’ve tried adding the SIP server as an exception under web filtering policies, but still no dice. I AM using TCP to make sure it’s not packet reconstruction issues.

8

Hi David

You’re right, I misread the first post (I am not a native english speaker). So I removed my posts.

Sorry again for wasting your time. And btw thanks for the time you spend helping the others.

Regards,

9

Please don’t hijack an old existing thread with what is a different problem. You are not receiving any 401s at all.

Generally if you have exactly the same problem, you should use exactly the same solution, and if none was provided, you should assume there is none. However, most people claiming exactly the same problem do not have the same problem.

Scheduled destruction is normal, not a fault.

It looks like the B side has truncated your huge To header. I don’t think that Asterisk will create such a header itself, so I assume the peer created an own goal by registering with such a large callback URI.