Ankush,
You're missing an ACK from your phone toward your SIP Server. Please examine your PortGo for iOS phone client for remedy. Please see below.
I see your carrier, Twilio, responding to your INVITE here:
11:45:02.572: SIPTR: Received [0,UDP] 945 bytes from 54.172.60.2:5060 <<<<<
SIP/2.0 200 OK
CSeq: 1 INVITE
Via: SIP/2.0/UDP 172.31.17.148:5060;rport=5060;received=35.178.84.153;branch=z9hG4bK20A69B2C-9BAF-4B89-8861-8E1AD853E2FF-1
Record-Route: <sip:54.172.60.2:5060;lr;twnat=sip:35.178.84.153:5060>
Server: Twilio
Contact: <sip:172.18.60.51:5060>
Allow: INVITE,ACK,CANCEL,OPTIONS,BYE,REFER,NOTIFY
Content-Type: application/sdp
X-Twilio-CallSid: CAa5f37e3af3dd34b851a287d62e45e9db
Content-Length: 256
v=0
o=root 1899655235 1899655235 IN IP4 172.18.130.230
s=Twilio Media Gateway
c=IN IP4 34.203.251.140
t=0 0
m=audio 18666 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=maxptime:150
a=sendrecv
This in turn tells your SIP Server that the call is being answered. Your SIP Server sends a 200 OK to your phone here:
11:45:02.572: Sending [0,UDP] 902 bytes to 115.110.104.225:60192 >>>>>
SIP/2.0 200 OK
Via: SIP/2.0/UDP 115.110.104.225:60192;branch=z9hG4bK-524287-1---6665aa2034905e47;rport;received=115.110.104.225
Call-ID: y0H86GReq7ybmHXK3d7gjw..
CSeq: 1 INVITE
Contact: <sip:172.31.17.148:5060>
X-Genesys-CallUUID: 9DROR7JN756ERF8R3F0Q2TH5OS000001
Allow: INVITE, ACK, PRACK, CANCEL, BYE, REFER, INFO, MESSAGE, NOTIFY, OPTIONS
Server: Twilio
X-Twilio-CallSid: CAa5f37e3af3dd34b851a287d62e45e9db
Session-Expires: 1800;refresher=uas
Supported: uui,replaces,timer
Content-Type: application/sdp
Content-Length: 233
v=0
o=root 1580125486 1 IN IP4 34.203.251.140
s=Twilio
c=IN IP4 34.203.251.140
t=0 0
m=audio 18666 RTP/AVP 0 101
a=ptime:20
a=maxptime:150
a=sendrecv
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
After this, your phone should send an ACK to let the SIP Server know that the answer was acknowledged. I don't see an ACK, and so the INVITE timer of 32 seconds is used to terminate the call since it isn't properly being processed by your phone. The phone leg is Call-ID: y0H86GReq7ybmHXK3d7gjw.. See here:
11:45:34.572: SipDialog: event CONNECTED_TIMEOUT_ST, t=5, s=7, r=5, m=0000000003735968 port=60192
11:45:34.572: CID:CUUID>y0H86GReq7ybmHXK3d7gjw..:9DROR7JN756ERF8R3F0Q2TH5OS000001:
Your SIP Server is generating an EventReleased event:
11:45:34.572 +++ CIFace::Event +++
+++ Pre-event +++
Type EventReleased
Devices: <9001/9001> <-/00919168635523> <-/->
Calls: 16777217/008c02f286c2c001/16777217.374a210/c:2/r:0 0/none
Parties: D9001/9001.375b060-374a210:1/l:1/r:0/Dialing,Active,Origination
X00919168635523/00919168635523.375b2b0-374a210:1/l:2/r:0/Alerting,Destination
none
Flags: divert=0 hook=1 postCall=0 active=1 moveAll=1 callType=1 hideOtherPi=0 InternalOther=0
--- Pre-event ---
+++ Released +++
-- XAction: start 9001.375b060-374a210:1
SetReleased: party 9001.375b060-374a210:1, cause Null
-- party_info 9001.26f7080 state change: from <Connected,Dialing> to <Null>
-- G7 release
@11:45:34.5720 [0] 8.1.103.72 distribute_event: message EventReleased
AttributeEventSequenceNumber 0000000000000010
AttributeTimeinuSecs 572000
AttributeTimeinSecs 1580125534 (11:45:34)
AttributeExtensions [60] 00 02 00 00..
'OtherTrunkName' 'SIP_Outbound_Trunk'
'BusinessCall' 0
AttributeOtherDNRole 2
AttributeOtherDN '00919168635523'
AttributePartyUUID 'HLD8F4UK7T4KPD3SGDM4IBJ5E0000002'
AttributeThisDNRole 1
AttributeThisDN '9001'
AttributeDNIS '00919168635523'
AttributeCallUUID '9DROR7JN756ERF8R3F0Q2TH5OS000001'
AttributeConnID 008c02f286c2c001
AttributeCallID 16777217
AttributePropagatedCallType 3
AttributeCallType 3
AttributeCallState 0
11:45:34.572 Int 04544 Interaction message "EventReleased" generated
-- TellReleased
-- XAction: commit 9001.375b060-374a210:1
This is in turn telling your SIP server to generate a BYE message toward your phone:
11:45:34.572: Sending [0,UDP] 349 bytes to 115.110.104.225:60192 >>>>>
Call-ID: y0H86GReq7ybmHXK3d7gjw..
CSeq: 1 BYE
Content-Length: 0
Via: SIP/2.0/UDP 172.31.17.148:5060;branch=z9hG4bK20A69B2C-9BAF-4B89-8861-8E1AD853E2FF-2
Max-Forwards: 70
Once this BYE message is generated, your SIP Server is sending an ACK toward your carrier, so that it can subsequently send it a BYE.
11:45:34.573: Sending [0,UDP] 476 bytes to 54.172.60.2:5060 >>>>>
ACK sip:172.18.60.51:5060 SIP/2.0
CSeq: 1 ACK
Content-Length: 0
Via: SIP/2.0/UDP 172.31.17.148:5060;branch=z9hG4bK20A69B2C-9BAF-4B89-8861-8E1AD853E2FF-3
Route: <sip:54.172.60.2:5060;lr;twnat=sip:35.178.84.153:5060>
...
11:45:34.573: Sending [0,UDP] 494 bytes to 54.172.60.2:5060 >>>>>
BYE sip:172.18.60.51:5060 SIP/2.0
CSeq: 2 BYE
Content-Length: 0
Via: SIP/2.0/UDP 172.31.17.148:5060;branch=z9hG4bK20A69B2C-9BAF-4B89-8861-8E1AD853E2FF-4
Max-Forwards: 69
Route: <sip:54.172.60.2:5060;lr;twnat=sip:35.178.84.153:5060>
You then receive 200 OK messages responding to the BYE's your sip server sent to the phone and carrier legs.
11:45:34.675: SIPTR: Received [0,UDP] 498 bytes from 54.172.60.2:5060 <<<<<
SIP/2.0 200 OK
CSeq: 2 BYE
Via: SIP/2.0/UDP 172.31.17.148:5060;rport=5060;received=35.178.84.153;branch=z9hG4bK20A69B2C-9BAF-4B89-8861-8E1AD853E2FF-4
Server: Twilio
X-Twilio-CallSid: CAa5f37e3af3dd34b851a287d62e45e9db
Content-Length: 0
...
11:45:34.987: SIPTR: Received [0,UDP] 461 bytes from 115.110.104.225:60192 <<<<<
SIP/2.0 200 OK
Via: SIP/2.0/UDP 172.31.17.148:5060;branch=z9hG4bK20A69B2C-9BAF-4B89-8861-8E1AD853E2FF-2;received=35.178.84.153
Contact: <sip:
9001@115.110.104.225:60192>;+sip.instance="<urn:uuid:071DBAB7-A605-4555-ADB5-078E9252D85F>"
Call-ID: y0H86GReq7ybmHXK3d7gjw..
CSeq: 1 BYE
User-Agent: PortGo for iOS
Content-Length: 0
------------------------------
Ivan Ullmann
Eventus Solutions Group
------------------------------
Original Message:
Sent: 01-27-2020 06:48
From: Ankush Khare
Subject: Call disconnects in 32 sec.
Hi All,
I have a scenario where SIP server is directly integrated with Twilio provider. The outbound call is always disconnected in 32 seconds.
When i checked the SIP server logs I can see I am getting 200OK message and after that ACK is sent from SIP server and then immediate BYE.
The provider says that they are not receiving ACK message from my SIP Server. I checked all the ports and firewall and everything seems to be open.
my ACK message is sent to contact address of 200OK , still it's not reaching provider.
I have attached a log a log snippet:
Call-ID: 69F0631D-3245-4D28-8028-865B773B9A6A-5
Please advise.
#SIP/VolP
#Telephony
------------------------------
[Ankush] [Khare]
------------------------------