Trunk falls call when answering

Hello, I have a problem in one of the trunk when receiving a call, he calls normally. But if I call this trunk, it comes to answer the call but drops in 5 seconds.

Log sngrep:

2021/01/05 17:34:27.899295 10.10.10.201:5060 -> 10.10.10.199:8091
INVITE sip:[email protected]:8091;transport=udp SIP/2.0
Allow: INVITE,BYE,REGISTER,ACK,OPTIONS,CANCEL,INFO,PRACK,SUBSCRIBE,NOTIFY,REFER,UPDATE
Call-ID: [email protected]
Contact: sip:10.10.10.201:5060;transport=udp
Content-Type: application/sdp
CSeq: 23 INVITE
From: sip:10.10.10.201:5060;transport=udp;tag=0-8C0C7A76
Max-Forwards: 70
P-Asserted-Identity: sip:10.10.10.199:8091;transport=udp
Session-Expires: 1800;refresher=uas
Session-ID: 73f2a8ef35a1c513ea3a51fb9be19ac6
Supported: 100rel,timer,replaces,histinfo
To: sip:[email protected]:8091;transport=udp
Via: SIP/2.0/UDP 10.10.10.201:5060;rport;branch=z9hG4bKD4E7F25
Content-Length: 333

v=0
o=- 41 0 IN IP4 10.10.10.201
s=-
c=IN IP4 10.10.10.201
t=0 0
m=audio 10080 RTP/AVP 8 0 18 4 2 100
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:4 G723/8000
a=rtpmap:2 G726-32/8000
a=rtpmap:100 telephone-event/8000
a=fmtp:100 0-15
a=ptime:20
a=sendrecv
a=rtcp:10081

2021/01/05 17:34:27.899624 10.10.10.199:8091 -> 10.10.10.201:5060
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 10.10.10.201:5060;rport=5060;received=10.10.10.201;branch=z9hG4bKD4E7F25
Call-ID: [email protected]
From: sip:10.10.10.201;tag=0-8C0C7A76
To: sip:[email protected]
CSeq: 23 INVITE
Server: FPBX-15.0.16.75(13.36.0)
Content-Length: 0

2021/01/05 17:34:28.474337 10.10.10.199:8091 -> 10.10.10.201:5060
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.10.10.201:5060;rport=5060;received=10.10.10.201;branch=z9hG4bKD4E7F25
Call-ID: [email protected]
From: sip:10.10.10.201;tag=0-8C0C7A76
To: sip:[email protected];tag=d43ba648-589a-425a-bfb9-2b453d451157
CSeq: 23 INVITE
Server: FPBX-15.0.16.75(13.36.0)
Contact: sip:10.10.10.199:8091
Allow: OPTIONS, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, REGISTER, MESSAGE, REFER
Supported: 100rel, timer, replaces, norefersub
Session-Expires: 1800;refresher=uas
Content-Type: application/sdp
Content-Length: 342

v=0
o=- 41 2 IN IP4 10.10.10.199
s=Asterisk
c=IN IP4 10.10.10.199
t=0 0
m=audio 16818 RTP/AVP 18 2 4 0 8 100
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:2 G726-32/8000
a=rtpmap:4 G723/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:100 telephone-event/8000
a=fmtp:100 0-16
a=ptime:20
a=maxptime:150
a=sendrecv

2021/01/05 17:34:28.483748 10.10.10.201:5060 -> 10.10.10.199:8091
ACK sip:10.10.10.199:8091 SIP/2.0
Allow: INVITE,BYE,REGISTER,ACK,OPTIONS,CANCEL,INFO,PRACK,SUBSCRIBE,NOTIFY,REFER,UPDATE
Call-ID: [email protected]
Contact: sip:10.10.10.201:5060;transport=udp
CSeq: 23 ACK
From: sip:10.10.10.201:5060;transport=udp;tag=0-8C0C7A76
Max-Forwards: 70
Session-ID: 73f2a8ef35a1c513ea3a51fb9be19ac6
To: sip:[email protected]:8091;transport=udp;tag=d43ba648-589a-425a-bfb9-2b453d451157
Via: SIP/2.0/UDP 10.10.10.201:5060;rport;branch=z9hG4bK0EA81046
Content-Length: 0

2021/01/05 17:34:51.942809 10.10.10.201:5060 -> 10.10.10.199:8091
BYE sip:10.10.10.199:8091 SIP/2.0
Allow: INVITE,BYE,REGISTER,ACK,OPTIONS,CANCEL,INFO,PRACK,SUBSCRIBE,NOTIFY,REFER,UPDATE
Call-ID: [email protected]
CSeq: 24 BYE
From: sip:10.10.10.201:5060;transport=udp;tag=0-8C0C7A76
Max-Forwards: 70
Reason: Q.850;cause=16;text=“Normal Call Clearing”
Session-ID: 73f2a8ef35a1c513ea3a51fb9be19ac6
Supported: timer,replaces,histinfo
To: sip:[email protected]:8091;transport=udp;tag=d43ba648-589a-425a-bfb9-2b453d451157
Via: SIP/2.0/UDP 10.10.10.201:5060;rport;branch=z9hG4bK9B573FB3
Content-Length: 0

2021/01/05 17:34:51.943012 10.10.10.199:8091 -> 10.10.10.201:5060
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.10.10.201:5060;rport=5060;received=10.10.10.201;branch=z9hG4bK9B573FB3
Call-ID: [email protected]
From: sip:10.10.10.201;tag=0-8C0C7A76
To: sip:[email protected];tag=d43ba648-589a-425a-bfb9-2b453d451157
CSeq: 24 BYE
Server: FPBX-15.0.16.75(13.36.0)
Content-Length: 0

This log is not very useful because it only shows communication between phone and PBX.

To produce a complete log, at the Asterisk command prompt, type
sip set debug on
and/or
pjsip set logger on
according to whether your extension and trunk are using chan_sip or pjsip. Then, make a test call, paste the Asterisk log for the call at pastebin.freepbx.org and post the link here.

I did notice that Asterisk is prioritizing g729. Possibly, that’s not being transcoded correctly. Unless you have some reason for using g729, set the codecs for the extension (and trunk, if relevant) to allow only alaw and ulaw.

Also, the call was apparently ‘answered’ in only 0.6 seconds. If this is an analog trunk (without answer supervision), that’s normal, but post details about how you connect to it (FXO card, gateway, etc.)

I have a media gateway (IP 10.10.10.201) connected to freepbx (IP 10.10.10.199) where there is a trunk (PJSIP) where an authentication is made without registration only the registered did of the gateway ip.

Trunk:


Gateway:


pjsip set logger on:
https://pastebin.freepbx.org/view/15b534bf

The trunk trunk works normal only this one has this problem.

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