New system, calls hanging up after some seconds

General Help
1

Calls are hanging up after something like 8 to 15 seconds. I’m guessing its something stupid.

<— SIP read from UDP:199.244.96.39:5060 —>
SIP/2.0 200 OK
Via: SIP/2.0/UDP 54.78.121.36:5060;branch=z9hG4bK57e838d0;rport=5060;received=54.78.121.35
Contact: sip:[email protected]:5070
To: sip:[email protected];tag=lydguangwrrgenl4.o
From: sip:[email protected];tag=as52c1281f
Call-ID: dfd2f62034b7bc9813c4380895dae186cbc8287e479c30d100-0100-5870~1o
CSeq: 102 INVITE
Allow: INVITE, ACK, BYE, CANCEL, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS, UPDATE
Content-Type: application/sdp
Server: PortaSIP
Content-Length: 318

v=0
o=PortaSIP 2915983984105223251 1 IN IP4 199.244.96.46
s=-
t=0 0
m=audio 47788 RTP/AVP 18 0 8 101
c=IN IP4 199.244.96.46
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
a=sqn: 0
a=cdsc:1 image udptl t38
<------------->
— (11 headers 15 lines) —
Comparing SDP version 1 -> 1 and unique parts [PortaSIP 2915983984105223251 IN IP4 199.244.96.46] -> [PortaSIP 2915983984105223251 IN IP4 199.244.96.46]
set_destination: Parsing sip:199.244.96.39;lr;ep for address/port to send to
set_destination: set destination to 199.244.96.39:5060
Transmitting (no NAT) to 199.244.96.39:5060:
ACK sip:[email protected]:5070 SIP/2.0
Via: SIP/2.0/UDP 54.78.121.36:5060;branch=z9hG4bK0962556b;rport
Route: sip:199.244.96.39;lr;ep
Max-Forwards: 70
From: sip:[email protected];tag=as52c1281f
To: sip:[email protected];tag=lydguangwrrgenl4.o
Contact: sip:[email protected]:5060
Call-ID: dfd2f62034b7bc9813c4380895dae186cbc8287e479c30d100-0100-5870~1o
CSeq: 102 ACK
User-Agent: Asterisk PBX 16.17.0
Content-Length: 0

set_destination: Parsing sip:199.244.96.39;lr;ep for address/port to send to
set_destination: set destination to 199.244.96.39:5060
Reliably Transmitting (no NAT) to 199.244.96.39:5060:
BYE sip:[email protected]:5070 SIP/2.0
Via: SIP/2.0/UDP 54.78.121.36:5060;branch=z9hG4bK0b074417;rport
Route: sip:199.244.96.39;lr;ep
Max-Forwards: 70
From: sip:[email protected];tag=as52c1281f
To: sip:[email protected];tag=lydguangwrrgenl4.o
Call-ID: dfd2f62034b7bc9813c4380895dae186cbc8287e479c30d100-0100-5870~1o
CSeq: 103 BYE
User-Agent: Asterisk PBX 16.17.0
X-Asterisk-HangupCause: No user responding
X-Asterisk-HangupCauseCode: 18
Content-Length: 0

Scheduling destruction of SIP dialog ‘dfd2f62034b7bc9813c4380895dae186cbc8287e479c30d100-0100-5870~1o’ in 32000 ms (Method: INVITE)

<— SIP read from UDP:199.244.96.39:5060 —>
SIP/2.0 200 OK
Via: SIP/2.0/UDP 54.78.121.36:5060;branch=z9hG4bK0b074417;rport=5060;received=54.78.121.35
To: sip:[email protected];tag=lydguangwrrgenl4.o
From: sip:[email protected];tag=as52c1281f
Call-ID: dfd2f62034b7bc9813c4380895dae186cbc8287e479c30d100-0100-5870~1o
CSeq: 103 BYE
Allow: INVITE, ACK, BYE, CANCEL, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS, UPDATE
Server: PortaSIP
Content-Length: 0

<------------->
— (9 headers 0 lines) —
Really destroying SIP dialog ‘dfd2f62034b7bc9813c4380895dae186cbc8287e479c30d100-0100-5870~1o’ Method: INVITE
Reliably Transmitting (no NAT) to 10.123.193.18:5060:
OPTIONS sip:10.123.193.18 SIP/2.0
Via: SIP/2.0/UDP 10.123.192.141:5060;branch=z9hG4bK7e85465e
Max-Forwards: 70
From: “asterisk” sip:[email protected];tag=as11f3cfea
To: sip:10.123.193.18
Contact: sip:[email protected]:5060
Call-ID: [email protected]:5060
CSeq: 102 OPTIONS
User-Agent: Asterisk PBX 16.17.0
Date: Fri, 11 Jun 2021 20:51:09 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Content-Length: 0

2

Most likely guess: You didn’t run the firewall wizard, so it did not automatically set your public and local IP information in the SIP settings section.

3

Instead of giving us a few leaves to look at, why don’t you tell us about the forest?

For starters, this is a FreePBX forum. I see no evidence of FreePBX being involved in this system.

Why are you running a call from Kansas City to Sacramento via a US provider through an AWS server in Ireland?

Why are you using chan_sip? Why is chan_sip on port 5060?

The provider (Avoxi ?) is offering G.729 as first preferred codec. Are you intentionally trying to use g729? If so, why? If not, is it disabled on the Asterisk end? (If not, the problem could be related to codec translations.)

What’s up with the OPTIONS request to another AWS instance? Is that relevant to this system or to the problem at hand?

If you still have trouble, please paste the complete Asterisk log for a failing call at pastebin.freepbx.org and post the link here.

2 Likes
4

It was nat typo on a sbc. so that is fixed. now comes the next.

5

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