SIP Trunk disconnect after 15min, trunk provider no help. Debug and logs attached

FreePBX
1

I have worked with over 20 installs of FreePBX and this is a first.

Current PBX Version:14.0.5.2
Current System Version:12.7.5-1807-1.sng7

SIP Trunk is from a local service provider and we were told, “you don’t set anything up, it just works”. Of course after 4 hours on the phone and trying different SIP trunk configs, we were able to make and receive calls. Here is trunk info:

OUTGOING:
host=XXX.XXX.XXX.XXX
keepalive=20
session-timers=refuse
allow=ulaw
type=peer
fromuser=704#######
dtmfmode=rfc2833
port=5060

INCOMING:
USER Context: 704#######

USER Details:
host=XXX.XXX.XXX.XXX
type=friend
nat=never
disallow=all
canreinvite=yes
allow=ulaw
dtmfmode=auto
context=from-trunk
insecure=port,invite
qualify=yes

NO REGISTRATION STRING

Also, I had to enable Allow Anonymous Inbound in the General SIP settings for the trunk to work. The provider stated it was IP based connection security, so no user/login details were required.

The issue we are seeing, is calls disconnect after 15:00-15:10 min. Of course the trunk provider said it was a PBX issue or firewall issue. So I have tried adjusting TRP timeouts, added session-timers=refuse on SIP, keepalive=20 on trunk, removed all firewall restrictions… all with no change.

SIP debug of trunk below (Phone and IP masked to protect the innocent):

Blockquote
Retransmitting #1 (no NAT) to XXX.XXX.XXX.XXX:5060:
OPTIONS sip:XXX.XXX.XXX.XXX SIP/2.0
Via: SIP/2.0/UDP XXX.XXX.XXX.XXX:5160;branch=z9hG4bK38882347
Max-Forwards: 70
From: “Unknown” sip:[email protected]:5160;tag=as0c6fb61b
To: sip:XXX.XXX.XXX.XXX
Contact: sip:[email protected]:5160
Call-ID: [email protected]:5160
CSeq: 102 OPTIONS
User-Agent: FPBX-14.0.5.2(13.22.0)
Date: Tue, 27 Nov 2018 13:49:08 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces
Content-Length: 0

Retransmitting #2 (no NAT) to XXX.XXX.XXX.XXX:5060:
OPTIONS sip:XXX.XXX.XXX.XXX SIP/2.0
Via: SIP/2.0/UDP XXX.XXX.XXX.XXX:5160;branch=z9hG4bK38882347
Max-Forwards: 70
From: “Unknown” sip:[email protected]:5160;tag=as0c6fb61b
To: sip:XXX.XXX.XXX.XXX
Contact: sip:[email protected]:5160
Call-ID: [email protected]:5160
CSeq: 102 OPTIONS
User-Agent: FPBX-14.0.5.2(13.22.0)
Date: Tue, 27 Nov 2018 13:49:08 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces
Content-Length: 0

[2018-11-27 08:49:10] NOTICE[6665]: chan_sip.c:29618 check_rtp_timeout: Disconnecting call ‘SIP/Spirit-0000000a’ for lack of RTP activity in 31 seconds
– Channel SIP/Spirit-0000000a left ‘simple_bridge’ basic-bridge <7c9fe39d-a3e0-47fe-90bf-c5577a559e7a>
– Channel PJSIP/1014-0000005e left ‘simple_bridge’ basic-bridge <7c9fe39d-a3e0-47fe-90bf-c5577a559e7a>
Scheduling destruction of SIP dialog ‘[email protected]:5160’ in 32000 ms (Method: INVITE)
== Spawn extension (macro-dialout-trunk, s, 25) exited non-zero on ‘PJSIP/1014-0000005e’ in macro ‘dialout-trunk’
Reliably Transmitting (NAT) to XXX.XXX.XXX.XXX:5060:
BYE sip:[email protected]:5060 SIP/2.0
Via: SIP/2.0/UDP XXX.XXX.XXX.XXX:5160;branch=z9hG4bK3899c622;rport
Max-Forwards: 70
From: sip:704#######@XXX.XXX.XXX.XXX:5160;tag=as638afa4f
To: sip:704#######@XXX.XXX.XXX.XXX:5060;tag=sip+1+1178000d+7e508ff0
Call-ID: [email protected]:5160
CSeq: 103 BYE
User-Agent: FPBX-14.0.5.2(13.22.0)
X-Asterisk-HangupCause: Requested channel not available
X-Asterisk-HangupCauseCode: 44
Content-Length: 0

== Spawn extension (restrictedroute-c81e728d9d4c2f636f067f89cc14862c, 704#######, 7) exited non-zero on ‘PJSIP/1014-0000005e’
– Executing [[email protected]:1] Hangup(“PJSIP/1014-0000005e”, “”) in new stack
== Spawn extension (restrictedroute-c81e728d9d4c2f636f067f89cc14862c, h, 1) exited non-zero on ‘PJSIP/1014-0000005e’

<— SIP read from UDP:XXX.XXX.XXX.XXX:5060 —>
SIP/2.0 481 Call/Transaction Does Not Exist
Call-ID: [email protected]:5160
CSeq: 103 BYE
From: sip:704#######@XXX.XXX.XXX.XXX:5160;tag=as638afa4f
To: sip:704#######@XXX.XXX.XXX.XXX:5060;tag=sip+1+1178000d+7e508ff0
Via: SIP/2.0/UDP XXX.XXX.XXX.XXX:5160;received=XXX.XXX.XXX.XXX;rport=5160;branch=z9hG4bK3899c622
Server: SIP/2.0
Warning: 399 sip “There is no matching INVITE session”
Content-Length: 0

<------------->
— (9 headers 0 lines) —
Really destroying SIP dialog ‘[email protected]:5160’ Method: INVITE
Retransmitting #3 (no NAT) to XXX.XXX.XXX.XXX:5060:
OPTIONS sip:XXX.XXX.XXX.XXX SIP/2.0
Via: SIP/2.0/UDP XXX.XXX.XXX.XXX:5160;branch=z9hG4bK38882347
Max-Forwards: 70
From: “Unknown” sip:[email protected]:5160;tag=as0c6fb61b
To: sip:XXX.XXX.XXX.XXX
Contact: sip:[email protected]:5160
Call-ID: [email protected]:5160
CSeq: 102 OPTIONS
User-Agent: FPBX-14.0.5.2(13.22.0)
Date: Tue, 27 Nov 2018 13:49:08 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces
Content-Length: 0

Retransmitting #4 (no NAT) to XXX.XXX.XXX.XXX:5060:
OPTIONS sip:XXX.XXX.XXX.XXX SIP/2.0
Via: SIP/2.0/UDP XXX.XXX.XXX.XXX:5160;branch=z9hG4bK38882347
Max-Forwards: 70
From: “Unknown” sip:[email protected]:5160;tag=as0c6fb61b
To: sip:XXX.XXX.XXX.XXX
Contact: sip:[email protected]:5160
Call-ID: [email protected]:5160
CSeq: 102 OPTIONS
User-Agent: FPBX-14.0.5.2(13.22.0)
Date: Tue, 27 Nov 2018 13:49:08 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces
Content-Length: 0

Really destroying SIP dialog ‘[email protected]:5160’ Method: OPTIONS
Reliably Transmitting (no NAT) to XXX.XXX.XXX.XXX:5060:
OPTIONS sip:XXX.XXX.XXX.XXX SIP/2.0
Via: SIP/2.0/UDP XXX.XXX.XXX.XXX:5160;branch=z9hG4bK5113f37a
Max-Forwards: 70
From: “Unknown” sip:[email protected]:5160;tag=as2e442b1c
To: sip:XXX.XXX.XXX.XXX
Contact: sip:[email protected]:5160
Call-ID: [email protected]:5160
CSeq: 102 OPTIONS
User-Agent: FPBX-14.0.5.2(13.22.0)
Date: Tue, 27 Nov 2018 13:49:22 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces
Content-Length: 0

Blockquote

Any thoughts or recommendations are appreciated!

2

Your provider is correct. This is showing your PBX sending requests to the provider during the call and not getting a response back. That could be one of two things, 1) your provider never got the request or 2) you never got the response back from the provider. The second option could be because of multiple reasons with the main ones being a) your packets were sent with bad information or b) your firewall/NAT caused it to be routed wrong or not routed at all.

Calls are generally “checked” about every 12 to 15 minutes during the call to make sure everything is how it should be and still flowing.

As well this trunk is a mess. This is basically all you need for an IP Auth/Peer trunk with a provider. Get rid of all the crap in the INCOMING section and just use what is below in the OUTGOING.

What kind of firewall are you using?

3

Blaze, thank you so much for your suggestions! I have made changes to the trunk and will test.

On the Firewall question, it is a cisco managed cloud firewall from the service provider.

4

Just my humble opinion, you should not need to allow anonymous incoming requests to make the trunk work. Something is not correctly configured somewhere.

5

Here is a little update…

These two options break the outbound sip trunk completely (all circuits are busy now)

nat=no
disallow=all

And ArielGrin, I would agree, but as soon as we disable the allow anonymous inbound the audio in the call stops working. Calls go thru, but now audio.

6

Sound issues are almost always related to NAT misconfigurations.

7

Regarding disallow=all you need to allow a codec after that, for example
disallow=all
allow=ulaw

Remember that those parameters must be in the correct order, as the last one takes precedence over the previous one, so the disallow should come first and the allow should come after it.

8

No, no they don’t. disallow=all is needed if you have allow=ulaw (or any codec). And the NAT setting is telling the PBX you’re provider is not behind NAT.

You need to show an actual call debug of a failed.

9

hello @gastonchristian,

Your SIP working port is 5160 and the PJSIP port is 5060.
So, your provider sends its answers to the PJSIP stack instead the SIP stack.
Your provider works with port 5060 and that is why you need to allow anonymous access in the SIP settings to get it work.

What you have to do is change your SIP port settings in your provider`s sip trunk to port 5160 or reverse the ports of the SIP and the PJSIP in the Asterisk pbx.

Thank you,

Daniel Friedman
Trixton LTD.

10

Technically, providers send calls where they are told to via the IP and port provided to them. If they use Registration then when the registration happens the IP and port are provided via the REGISTER message. If they are doing SIP URI routing, then they would need to be told where to send it to. If the user only provides that in IP/FQDN format instead of IP:port/FDQN:port the assumption is default 5060.

11

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