Call hangsup as after 1st ring

Hi,

Let me first explain my network, i have two interfaces on server
1 for local LAN, ip 192.168.1.221
2 for SIP PRI, ip 10.24.33.126

SIP trunk ip: 43.242.100.1 which is registered via 2nd interface.

now when i make an inbound call, it lands fine, plays IVR, when i press any extension (3 digit) or press 0 (as defined in IVR to ring operator) it takes DTMF fine. and start ringing device (D-Link IP phone which are connect over local LAN IP)
when it sends ring to device, it gives below error:

Retransmission timeout reached on transmission 2b2271971aade8d6739cb5467610da1b@10.24.33.126:5060 for seqno 104 (Critical Request) – See https://wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions

here is sip trace of extension:

Audio is at 14626
Adding codec 0x4 (ulaw) to SDP
Adding codec 0x2 (gsm) to SDP
Adding non-codec 0x1 (telephone-event) to SDP
Reliably Transmitting (NAT) to 192.168.1.212:5060:
INVITE sip:129@192.168.1.212:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.221:5060;branch=z9hG4bK591e4e9b;rport
Max-Forwards: 70
From: “asterisk” sip:asterisk@192.168.1.221;tag=as4ec9fb03
To: sip:129@192.168.1.212:5060
Contact: sip:asterisk@192.168.1.221:5060
Call-ID: 564c12f80f72fabe042093591b566c70@192.168.1.221:5060
Seq: 102 INVITE
User-Agent: Asterisk PBX 1.8.24.0
Date: Thu, 13 Sep 2018 17:19:20 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Content-Type: application/sdp
Content-Length: 262

v=0
o=root 1340143399 1340143399 IN IP4 192.168.1.221
s=Asterisk PBX 1.8.24.0
c=IN IP4 192.168.1.221
t=0 0
m=audio 14626 RTP/AVP 0 3 101
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=sendrecv


-- Called SIP/129

<— SIP read from UDP:192.168.1.212:5060 —>
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 192.168.1.221:5060;branch=z9hG4bK591e4e9b;rport=5060
From: “asterisk” sip:asterisk@192.168.1.221;tag=as4ec9fb03
To: sip:129@192.168.1.212:5060
Call-ID: 564c12f80f72fabe042093591b566c70@192.168.1.221:5060
CSeq: 102 INVITE
Allow: INVITE, ACK, OPTIONS, BYE, CANCEL, REFER, NOTIFY, INFO, PRACK, UPDATE, MESSAGE
Content-Length: 0

<------------->
— (8 headers 0 lines) —

<— SIP read from UDP:192.168.1.212:5060 —>
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 192.168.1.221:5060;branch=z9hG4bK591e4e9b;rport=5060
From: “asterisk” sip:asterisk@192.168.1.221;tag=as4ec9fb03
To: sip:129@192.168.1.212:5060;tag=2739831761
Call-ID: 564c12f80f72fabe042093591b566c70@192.168.1.221:5060
CSeq: 102 INVITE
Contact: sip:129@192.168.1.212:5060
User-Agent: DLINK DPH-150SE FRU2.2.1328.545
Allow: INVITE, ACK, OPTIONS, BYE, CANCEL, REFER, NOTIFY, INFO, PRACK, UPDATE, MESSAGE
Content-Length: 0

<------------->
— (10 headers 0 lines) —
list_route: hop: sip:129@192.168.1.212:5060
– SIP/129-00000005 is ringing
Reliably Transmitting (NAT) to 192.168.1.212:5060:
CANCEL sip:129@192.168.1.212:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.221:5060;branch=z9hG4bK591e4e9b;rport
Max-Forwards: 70
From: “asterisk” sip:asterisk@192.168.1.221;tag=as4ec9fb03
To: sip:129@192.168.1.212:5060
Call-ID: 564c12f80f72fabe042093591b566c70@192.168.1.221:5060
CSeq: 102 CANCEL
User-Agent: Asterisk PBX 1.8.24.0
Content-Length: 0


<— SIP read from UDP:192.168.1.212:5060 —>
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.1.221:5060;branch=z9hG4bK591e4e9b;rport=5060
From: “asterisk” sip:asterisk@192.168.1.221;tag=as4ec9fb03
To: sip:129@192.168.1.212:5060;tag=2739831761
Call-ID: 564c12f80f72fabe042093591b566c70@192.168.1.221:5060
CSeq: 102 CANCEL
User-Agent: DLINK DPH-150SE FRU2.2.1328.545
Content-Length: 0

<------------->
— (8 headers 0 lines) —

<— SIP read from UDP:192.168.1.212:5060 —>
SIP/2.0 487 Request Terminated
Via: SIP/2.0/UDP 192.168.1.221:5060;branch=z9hG4bK591e4e9b;rport=5060
From: “asterisk” sip:asterisk@192.168.1.221;tag=as4ec9fb03
To: sip:129@192.168.1.212:5060;tag=2739831761
Call-ID: 564c12f80f72fabe042093591b566c70@192.168.1.221:5060
CSeq: 102 INVITE
User-Agent: DLINK DPH-150SE FRU2.2.1328.545
Allow: INVITE, ACK, OPTIONS, BYE, CANCEL, REFER, NOTIFY, INFO, PRACK, UPDATE, MESSAGE
Content-Length: 0

<------------->
— (9 headers 0 lines) —
Transmitting (NAT) to 192.168.1.212:5060:
ACK sip:129@192.168.1.212:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.221:5060;branch=z9hG4bK591e4e9b;rport
Max-Forwards: 70
From: “asterisk” sip:asterisk@192.168.1.221;tag=as4ec9fb03
To: sip:129@192.168.1.212:5060;tag=2739831761
Contact: sip:asterisk@192.168.1.221:5060
Call-ID: 564c12f80f72fabe042093591b566c70@192.168.1.221:5060
CSeq: 102 ACK
User-Agent: Asterisk PBX 1.8.24.0
Content-Length: 0

Scheduling destruction of SIP dialog ‘564c12f80f72fabe042093591b566c70@192.168.1.221:5060’ in 6400 ms (Method: INVITE)
– <SIP/cyber-00000004>AGI Script agi://127.0.0.1:4577/call_log–HVcauses–PRI-----NODEBUG-----18-----CANCEL---------- completed, returning 0
[Sep 13 22:19:26] NOTICE[53476]: pbx_spool.c:385 attempt_thread: Call completed to SIP/cyber/03318676062

<— SIP read from UDP:192.168.1.212:5060 —>
OPTIONS sip:192.168.1.221:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.212:5060;branch=z9hG4bK26884218801408323915
From: “Qundeel Ahmed” sip:129@192.168.1.221:5060;tag=274027953
To: sip:192.168.1.221:5060
Call-ID: 98011376722495-110801078332341@192.168.1.212
CSeq: 1 OPTIONS
Max-Forwards: 70
User-Agent: DLINK DPH-150SE FRU2.2.1328.545
Accept: application/sdp
Content-Length: 0

<------------->
— (10 headers 0 lines) —
Looking for s in trunkinbound (domain 192.168.1.221)

<— Transmitting (NAT) to 192.168.1.212:5060 —>
SIP/2.0 404 Not Found
Via: SIP/2.0/UDP 192.168.1.212:5060;branch=z9hG4bK26884218801408323915;received=192.168.1.212;rport=5060
From: “Qundeel Ahmed” sip:129@192.168.1.221:5060;tag=274027953
To: sip:192.168.1.221:5060;tag=as78d7f0f6
Call-ID: 98011376722495-110801078332341@192.168.1.212
CSeq: 1 OPTIONS
Server: Asterisk PBX 1.8.24.0
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Accept: application/sdp
Content-Length: 0

<------------>
Scheduling destruction of SIP dialog ‘98011376722495-110801078332341@192.168.1.212’ in 32000 ms (Method: OPTIONS)
Reliably Transmitting (NAT) to 192.168.1.212:5060:
OPTIONS sip:129@192.168.1.212:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.221:5060;branch=z9hG4bK6b9d0bce;rport
Max-Forwards: 70
From: “asterisk” sip:asterisk@192.168.1.221;tag=as3628c805
To: sip:129@192.168.1.212:5060
Contact: sip:asterisk@192.168.1.221:5060
Call-ID: 7758a1266e6e7d471eab921f16f85bae@192.168.1.221:5060
CSeq: 102 OPTIONS
User-Agent: Asterisk PBX 1.8.24.0
Date: Thu, 13 Sep 2018 17:19:27 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Content-Length: 0


<— SIP read from UDP:192.168.1.212:5060 —>
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.1.221:5060;branch=z9hG4bK6b9d0bce;rport=5060
From: “asterisk” sip:asterisk@192.168.1.221;tag=as3628c805
To: sip:129@192.168.1.212:5060;tag=10561730
Call-ID: 7758a1266e6e7d471eab921f16f85bae@192.168.1.221:5060
CSeq: 102 OPTIONS
Contact: sip:129@192.168.1.212:5060
Supported: 100rel, replaces, timer
Allow: INVITE, ACK, OPTIONS, BYE, CANCEL, REFER, NOTIFY, INFO, PRACK, UPDATE, MESSAGE
Accept: application/sdp, message/sipfrag, application/dtmf-relay
Content-Length: 0

<------------->
— (11 headers 0 lines) —
Really destroying SIP dialog ‘7758a1266e6e7d471eab921f16f85bae@192.168.1.221:5060’ Method: OPTIONS
Really destroying SIP dialog ‘564c12f80f72fabe042093591b566c70@192.168.1.221:5060’ Method: INVITE

I have set nat=force_rport in sip trunk settings.

asterisk version is 11.22-vici

Sometimes , i’ve the same problem and i resolve that with rebooting the network and the server. I think that the problem is the trafic in your network and your will must create a vlan to isolate the sip trafic.

I have already restarted things, but didn’t work anything. it was working fine, suddenly it started making this issue.

do you have vlan for your voice trafic?

Le jeu. 13 sept. 2018 à 20:07, s.khan asterisk@discoursemail.com a écrit :

no, server has lan ip and all the phones are connected directly to the server

The log shows that your end aborted the call, but doesn’t have enough information to indicate why it should have decided to do that.

should i share any other logs?

Update:

I tested the case with my SIP provider, and as per him, my system send INVITE packet again when it rings any extension, which is creating issue.
how can i limit invite packet? Also i am using this on Hyper-V and my physical interface is connected with SIP interface.

Re-INVITEs are perfectly valid and should not cause a problem with a valid peer (retransmitted ones certainly shouldn’t).

However your log shows a call being cancelled, before the final response. Asterisk will never send INVITE whilst an inbound one is incomplete.

A Re-INVITE, after the final response to the initial INVITE could be the result of:

Direct media: drectmedia=yes (or the obsolete form, canreinvite=yes).

Connected line update (sendrpid anything other than no).

Session timer refreshes or initialisation (the peer tries to negotiate them and Asterisk is not set to refuse them).