Genesys Engage on-premises

 View Only
Discussion Thread View
Expand all | Collapse all

Call disconnects in 32 sec.

  • 1.  Call disconnects in 32 sec.

    Posted 01-27-2020 06:49
    Edited by Ankush Khare 01-27-2020 06:51
      |   view attached
    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]
    ------------------------------

    Attachment(s)

    txt
    SIPlogs.txt   69 KB 1 version


  • 2.  RE: Call disconnects in 32 sec.

    Posted 01-27-2020 09:20
    Edited by Ivan Ullmann 01-27-2020 09:27
    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
    From: <sip:+17162355059@172.31.17.148:5060>;tag=6936CFC3-D045-48AE-A7AB-1EB7B1344817-6
    To: <sip:+919168635523@172.31.17.148:5060>;tag=83083917_6772d868_e74b4453-34b3-4d93-8953-810c85586431
    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
    To: <sip:00919168635523@35.178.84.153>;tag=6936CFC3-D045-48AE-A7AB-1EB7B1344817-5
    From: <sip:9001@35.178.84.153>;tag=974d431b
    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 >>>>>
    BYE sip:9001@115.110.104.225:60192 SIP/2.0
    From: <sip:00919168635523@35.178.84.153>;tag=6936CFC3-D045-48AE-A7AB-1EB7B1344817-5
    To: <sip:9001@35.178.84.153>;tag=974d431b
    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
    From: <sip:+17162355059@172.31.17.148:5060>;tag=6936CFC3-D045-48AE-A7AB-1EB7B1344817-6
    To: <sip:+919168635523@172.31.17.148:5060>;tag=83083917_6772d868_e74b4453-34b3-4d93-8953-810c85586431
    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
    From: <sip:+17162355059@172.31.17.148:5060>;tag=6936CFC3-D045-48AE-A7AB-1EB7B1344817-6
    To: <sip:+919168635523@172.31.17.148:5060>;tag=83083917_6772d868_e74b4453-34b3-4d93-8953-810c85586431
    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
    From: <sip:+17162355059@172.31.17.148:5060>;tag=6936CFC3-D045-48AE-A7AB-1EB7B1344817-6
    To: <sip:+919168635523@172.31.17.148:5060>;tag=83083917_6772d868_e74b4453-34b3-4d93-8953-810c85586431
    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>"
    To: <sip:9001@35.178.84.153>;tag=974d431b
    From: <sip:00919168635523@35.178.84.153>;tag=6936CFC3-D045-48AE-A7AB-1EB7B1344817-5
    Call-ID: y0H86GReq7ybmHXK3d7gjw..
    CSeq: 1 BYE
    User-Agent: PortGo for iOS
    Content-Length: 0


    ------------------------------
    Ivan Ullmann
    Eventus Solutions Group
    ------------------------------



  • 3.  RE: Call disconnects in 32 sec.

    Posted 01-27-2020 15:33
    As Ivan mentioned the lack of an ACK is the root, maybe your Phone can't communicate directly with Twilio? If that is the case check the possibility to free firewall rules, or use a SBC to handle the communication path in a better way

    ------------------------------
    Jorge Cornejo
    VS Telecom LTDA.
    ------------------------------



  • 4.  RE: Call disconnects in 32 sec.

    Posted 01-27-2020 23:32
      |   view attached
    Thank you for the reply guys.
    I have tried with 4 different soft phone and every time it's same. I am not sure how to troubleshoot a problem where Soft phone is not sending ACK.
    See attached traces wireshark and SIP logs.

    ------------------------------
    [Ankush] [Khare]
    ------------------------------

    Attachment(s)

    zip
    Call-Disconnect.zip   487 KB 1 version


  • 5.  RE: Call disconnects in 32 sec.

    Posted 01-27-2020 23:36
    Are these logs from the softphone or the SIP Server? Interesting is to see the Softphone SIP logs for that call.

    ------------------------------
    Jorge Cornejo
    VS Telecom LTDA.
    ------------------------------



  • 6.  RE: Call disconnects in 32 sec.

    Posted 01-27-2020 23:58
    The log is from SIP server and Wirshark traces are from the host where softphone is running.
    I will try to find out matching Softphone logs.

    ------------------------------
    [Ankush] [Khare]
    ------------------------------



  • 7.  RE: Call disconnects in 32 sec.

    Posted 01-28-2020 02:32
    Softphone logs attached:

    Call-ID: FCCEA55C-DCBD-4B0D-BEE1-8A619D4FD5F6-3@O1fW

    ------------------------------
    [Ankush] [Khare]
    ------------------------------



  • 8.  RE: Call disconnects in 32 sec.

    Posted 01-28-2020 02:34
      |   view attached
    Softphone logs :

    Call-ID: FCCEA55C-DCBD-4B0D-BEE1-8A619D4FD5F6-3@O1fW

    ------------------------------
    [Ankush] [Khare]
    ------------------------------

    Attachment(s)

    zip
    Call-Disconnect.zip   498 KB 1 version


  • 9.  RE: Call disconnects in 32 sec.

    Posted 01-28-2020 09:11
    Ankush,

    I don't know how your environment is built, so I can't say why you're not getting your ACK, but I can see what is happening.

    You receive a 200 OK from 3.8.78.209:5060 at your softphone.
    00:16:01.927| 7224|-i- SIPport[1260,UDP:5061] 972 bytes from 3.8.78.209:5060 <<<<<
    SIP/2.0 200 OK
    From: "Genesys Softphone" <sip:9001@3.8.78.209:5060>;tag=42B62466-9EBF-402F-BA59-A46159C84EA6-3
    To: <sip:00918605110351@3.8.78.209:5060>;tag=E040053C-9368-4B3C-965C-2D69914D5C7E-4
    Call-ID: FCCEA55C-DCBD-4B0D-BEE1-8A619D4FD5F6-3@O1fW
    CSeq: 1 INVITE
    Via: SIP/2.0/UDP 192.168.1.6:5061;branch=z9hG4bK042ABB63-876E-4A99-AAA8-ECA76BAF9F26-3;received=122.169.7.210
    Contact: <sip:172.31.17.148:5060>
    X-Genesys-CallUUID: M299PRJDDT04HCAMH9EJVLETI4000001
    Allow: INVITE, ACK, PRACK, CANCEL, BYE, REFER, INFO, MESSAGE, NOTIFY, OPTIONS
    Server: Twilio
    X-Twilio-CallSid: CA6b4c1a82d33a6b801f6409349e353d38
    Session-Expires: 1800;refresher=uas
    Supported: uui,replaces,timer
    Content-Type: application/sdp
    Content-Length: 233
    v=0
    o=root 1580150757 1 IN IP4 34.203.250.178
    s=Twilio
    c=IN IP4 34.203.250.178
    t=0 0
    m=audio 11150 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

    Your softphone client then sends an ACK to an entirely different address.  This address is in the "Contact" header that is in the 200 OK.  It appears that the SIP Server is sending that IP address with your initial INVITE for "Contact".  When your phone is processing the ACK, it's sending it there, and that's why your SIP Server isn't getting it to pass along back to Twilio.


    00:16:01.931| 7224|-i- SIPconn[1260,UDP] 475 bytes to 172.31.17.148:5060 >>>>>
    ACK sip:172.31.17.148:5060 SIP/2.0
    From: "Genesys Softphone" <sip:9001@3.8.78.209:5060>;tag=42B62466-9EBF-402F-BA59-A46159C84EA6-3
    To: <sip:00918605110351@3.8.78.209:5060>;tag=E040053C-9368-4B3C-965C-2D69914D5C7E-4
    Call-ID: FCCEA55C-DCBD-4B0D-BEE1-8A619D4FD5F6-3@O1fW
    CSeq: 1 ACK
    Content-Length: 0
    Via: SIP/2.0/UDP 192.168.1.6:5061;branch=z9hG4bK042ABB63-876E-4A99-AAA8-ECA76BAF9F26-4
    User-Agent: Genesys-Softphone/9.0.009.03 (Windows 10.0.17134)
    Max-Forwards: 70

    Since this breaks your transaction pathing, it's going to continue to produce this behavior because that's what the SIP messaging is telling the respondents to do.


    ------------------------------
    Ivan Ullmann
    Eventus Solutions Group
    ------------------------------



  • 10.  RE: Call disconnects in 32 sec.

    Posted 01-28-2020 12:26
    Hi Ivan,

    Thanks for the explanation :) . But as I understand the ACK is sent directly to the Contact Address in 200OK. This is how ACK is formed right?
    Isn't the same thing happening. Can it be because I don't have SBC in between and I am talking directly to SIP trunk provider.

    I am just trying to understand to which IP ACK should be sent ?

    Thanks
    Ankush

    ------------------------------
    [Ankush] [Khare]
    ------------------------------



  • 11.  RE: Call disconnects in 32 sec.

    Posted 01-28-2020 12:28
    Ankush,

    Since the SIP Server is the one brokering the communication path between Twilio and the softphone, the ACK should be going back to SIP Server.  I don't know what device 172.31.17.148 is in your communication path, but I can tell you that none of the other messaging appears to be trying to talk to that address.

    -Ivan

    ------------------------------
    Ivan Ullmann
    Eventus Solutions Group
    ------------------------------



  • 12.  RE: Call disconnects in 32 sec.

    Posted 01-28-2020 12:36
    18:46:00.960: SIPTR: Received [0,UDP] 938 bytes from 54.172.60.3:5060 <<<<<    (This 200OK is from provider and this is the IP of SIP trunk)T 
    SIP/2.0 200 OK
    CSeq: 1 INVITE
    Call-ID: 12AF137D-3F38-4E10-9CBC-643F84F4D2F1-1@172.31.17.148
    From: <sip:+17162355059@172.31.17.148:5060>;tag=E040053C-9368-4B3C-965C-2D69914D5C7E-5
    To: <sip:+918605110351@172.31.17.148:5060>;tag=78445343_6772d868_eacf0ee7-dce3-4709-99db-d4eb36610640
    Via: SIP/2.0/UDP 172.31.17.148:5060;rport=5060;received=3.8.78.209;branch=z9hG4bK43B6382A-405F-43DE-B940-30EF404971AC-1
    Record-Route: <sip:54.172.60.3:5060;lr;twnat=sip:3.8.78.209:5060>
    Server: Twilio
    Contact: <sip:172.18.61.163:5060>    (This IP is sent by provider in it's contact header under 200OK)
    Allow: INVITE,ACK,CANCEL,OPTIONS,BYE,REFER,NOTIFY
    Content-Type: application/sdp
    X-Twilio-CallSid: CA6b4c1a82d33a6b801f6409349e353d38
    Content-Length: 254

    v=0
    o=root 1276362974 1276362974 IN IP4 172.18.141.7
    s=Twilio Media Gateway
    c=IN IP4 34.203.250.178
    t=0 0
    m=audio 11150 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


    can it be because softphone is trying to send the ACK directly to this IP 172.18.61.163 which seems to be a Private IP .

    Is  there any option in SIP server by which I can make Softphone to send ACK back to SIP server instead of directly sending to Contact IP?


    ------------------------------
    [Ankush] [Khare]
    ------------------------------



  • 13.  RE: Call disconnects in 32 sec.

    Posted 01-28-2020 12:47
    Ankush,

    The problem is specifically in your configuration of your SIP Server.

    The initial INVITE received by your SIP Server to start an outbound communication is this:
    18:45:55.045: SIPTR: Received [0,UDP] 946 bytes from 122.169.7.210:5061 <<<<<
    INVITE sip:00918605110351@3.8.78.209:5060;transport=udp SIP/2.0
    From: "Genesys Softphone" <sip:9001@3.8.78.209:5060>;tag=42B62466-9EBF-402F-BA59-A46159C84EA6-3
    Call-ID: FCCEA55C-DCBD-4B0D-BEE1-8A619D4FD5F6-3@O1fW
    CSeq: 1 INVITE
    Content-Length: 407
    Content-Type: application/sdp
    Via: SIP/2.0/UDP 122.169.7.210:5061;branch=z9hG4bK042ABB63-876E-4A99-AAA8-ECA76BAF9F26-3
    Contact: <sip:9001@122.169.7.210:5061>
    User-Agent: Genesys-Softphone/9.0.009.03 (Windows 10.0.17134)
    Max-Forwards: 70
    v=0
    o=Genesys 1 1 IN IP4 122.169.7.210
    s=GSept-9.0.017.05
    c=IN IP4 122.169.7.210
    t=0 0
    m=audio 8000 RTP/AVP 0 8 9 102 103 104 18 120 101
    a=rtpmap:0 pcmu/8000
    a=rtpmap:8 pcma/8000
    a=rtpmap:9 g722/8000
    a=rtpmap:102 iLBC/8000
    a=rtpmap:103 iSAC/16000
    a=rtpmap:104 iSAC/32000
    a=rtpmap:18 g729/8000
    a=fmtp:18 annexb=yes
    a=rtpmap:120 opus/48000/2
    a=rtpmap:101 telephone-event/8000
    a=fmtp:101 0-15

    After your SIP Server receives this, it selects your SIP_Outbound_Trunk for service:
    18:45:55.045: DialPlan: No dialplan defined for 9001.
    18:45:55.045: GetRegistration::Unable to resolve number for DN:00918605110351
    18:45:55.045: DialPlan: No rule applied, using original destination '00918605110351'.
    18:45:55.045: DialPlan: clear flag 0x100, callId 16777217
    18:45:55.045: Number:[00918605110351] is not internal, looking for service
    18:45:55.045: Selected for Dn 00918605110351(geo-loc[]:partitionId[]:cpdCapability[]): Service SIP_Outbound_Trunk (geo-loc[], priority[0], capacity 0 (0% of 0))
    18:45:55.045: Dialed number was 00918605110351, will replace prefix '00' with '+'
    18:45:55.046: ProcessDialPlanResult: Connecting to DEVICE(5,00918605110351).

    Your SIP Server then begins a dialog with Twilio where there's already a contact address defined.
    18:45:55.060: Sending [0,UDP] 1227 bytes to 54.172.60.3:5060 >>>>>
    From: <sip:+17162355059@172.31.17.148:5060>;tag=E040053C-9368-4B3C-965C-2D69914D5C7E-5
    CSeq: 1 INVITE
    Content-Length: 416
    Content-Type: application/sdp
    Via: SIP/2.0/UDP 172.31.17.148:5060;branch=z9hG4bK43B6382A-405F-43DE-B940-30EF404971AC-1
    Contact: <sip:9001@172.31.17.148:5060>
    Allow: ACK, BYE, CANCEL, INFO, INVITE, MESSAGE, NOTIFY, OPTIONS, PRACK, REFER, UPDATE
    User-Agent: Genesys-Softphone/9.0.009.03 (Windows 10.0.17134)
    Max-Forwards: 69
    X-Genesys-CallUUID: M299PRJDDT04HCAMH9EJVLETI4000001
    X-ISCC-CofId: location=SIP_Callback;cofid=16777218
    Session-Expires: 1800;refresher=uac
    Min-SE: 90
    Supported: uui,replaces,timer
    v=0
    o=Genesys 1580150765 1 IN IP4 122.169.7.210
    s=GSept-9.0.017.05
    c=IN IP4 122.169.7.210
    t=0 0
    m=audio 8000 RTP/AVP 0 8 9 102 103 104 18 120 101
    a=rtpmap:0 pcmu/8000
    a=rtpmap:8 pcma/8000
    a=rtpmap:9 g722/8000
    a=rtpmap:102 iLBC/8000
    a=rtpmap:103 iSAC/16000
    a=rtpmap:104 iSAC/32000
    a=rtpmap:18 g729/8000
    a=fmtp:18 annexb=yes
    a=rtpmap:120 opus/48000/2
    a=rtpmap:101 telephone-event/8000
    a=fmtp:101 0-15

    I suspect you have a setting on your trunk that's forcing SIP Server to set this:
    18:45:55.047 SIPCONN(00918605110351): Local contact: '<sip:9001@172.31.17.148:5060>'

    I suggest you review your trunk configuration for the IP address 172.31.17.148 as soon as you are able to do so.

    -Ivan

    ------------------------------
    Ivan Ullmann
    Eventus Solutions Group
    ------------------------------



  • 14.  RE: Call disconnects in 32 sec.

    Posted 01-28-2020 13:35
    Below is the config on my TRUNK:

    [TServer]
    contact=vf-test.pstn.us1.twilio.com
    cpn=+17162355059
    dual-dialog-enabled=true
    make-call-rfc3725-flow=1
    prefix=00
    refer-enabled=false
    replace-prefix=+
    sip-enable-100rel=false


    ------------------------------
    [Ankush] [Khare]
    ------------------------------



  • 15.  RE: Call disconnects in 32 sec.

    Posted 01-28-2020 14:47
    Ankush,

    You should contact customer care to determine where the setting is being generated.  I don't have access to your DN, Trunk, or Application configurations to troubleshoot this further.

    -Ivan

    ------------------------------
    Ivan Ullmann
    Eventus Solutions Group
    ------------------------------



  • 16.  RE: Call disconnects in 32 sec.

    Posted 01-28-2020 22:26
    Yeah I have opened the ticket :)

    Thanks for all your help

    ------------------------------
    [Ankush] [Khare]
    ------------------------------



  • 17.  RE: Call disconnects in 32 sec.

    Posted 01-29-2020 03:14
    Edited by Sivakumar B 01-29-2020 03:14
    Hi Ankush,

    I guess the issue is related to NAT, please check with your firewall team. 



    ------------------------------
    SIvakumar 
    ------------------------------



  • 18.  RE: Call disconnects in 32 sec.

    Posted 01-29-2020 01:54
    Edited by Sivakumar B 01-29-2020 03:18
    Just an observation, from the log I can see ACK from SIP server to 54.172.60.3 (Call-ID: 12AF137D-3F38-4E10-9CBC-643F84F4D2F1-1@172.31.17.148)

    18:46:32.949: Sending [0,UDP] 474 bytes to 54.172.60.3:5060 >>>>>
    ACK sip:172.18.61.163:5060 SIP/2.0
    From: <sip:+17162355059@172.31.17.148:5060>;tag=E040053C-9368-4B3C-965C-2D69914D5C7E-5
    To: <sip:+918605110351@172.31.17.148:5060>;tag=78445343_6772d868_eacf0ee7-dce3-4709-99db-d4eb36610640
    Call-ID: 12AF137D-3F38-4E10-9CBC-643F84F4D2F1-1@172.31.17.148
    CSeq: 1 ACK
    Content-Length: 0
    Via: SIP/2.0/UDP 172.31.17.148:5060;branch=z9hG4bK43B6382A-405F-43DE-B940-30EF404971AC-3
    Route: <sip:54.172.60.3:5060;lr;twnat=sip:3.8.78.209:5060>

    ------------------------------
    SIvakumar 



  • 19.  RE: Call disconnects in 32 sec.

    Posted 01-29-2020 04:55
    Hi Siva,

    Thanks for the response.
    Yes the problem is ACK is being sent to private IP of SIP server i.e. 172.31.17.148 instead of sending it to Public IP of SIP server which is on AWS.
    I am just trying to understand if there is a possibility to force SIP server to insert the Record-Route header with Public IP in 200OK message where ACK can reply on.


    ------------------------------
    [Ankush] [Khare]
    ------------------------------



  • 20.  RE: Call disconnects in 32 sec.

    Posted 01-29-2020 07:06
    As said, better go with an SBC. This is one of many scenarios you will face




    On Wed, Jan 29, 2020 at 6:56 AM -0300, "Ankush Khare via Genesys"





  • 21.  RE: Call disconnects in 32 sec.

    Posted 01-29-2020 09:02
    Ankush,

    There are a couple of ways you can do this.
    1. You can change the [TServer]\sip-address field to your public IP.
    2. You can adjust the [TServer]\override-domain-<oosp/from/refer-to/etc> on your trunk.

    There are other options you could be using situationally, but I think these would be the easiest to implement.

    -Ivan

    ------------------------------
    Ivan Ullmann
    Eventus Solutions Group
    ------------------------------



  • 22.  RE: Call disconnects in 32 sec.

    Posted 01-30-2020 07:00

    Hi

     

    I suggest give a ringback to the gateway while u investiage the delay by making ringing on routepoint as true....

     

    This is a mitigation so that call does not drop

     

    Cheers

     

    Santosh Sundaram

    Talk:   +91 981 955 4265

    Skype: santoshs5

    image002.jpg@01D4D8DB.531F1390

     






  • 23.  RE: Call disconnects in 32 sec.

    Posted 01-30-2020 23:28
    Hi Santosh,

    Thanks will try the same. :)

    ------------------------------
    [Ankush] [Khare]
    ------------------------------



Need Help finding something?

Check out the Genesys Knowledge Network - your all-in-one access point for Genesys resources