packet timeout log error

› VitalPBX Community Support › General Discussion › packet timeout log error

  • Post
    • October 23, 2019 at 9:00 pm
    toxicfusion
    Participant

    Unsure what is causing this. Could be issue from client side, as their phones will not stay connected.  Happening same time as the IVR Loop issue (see other post). Scrambling to find fix.

     

    Packet timed out after 6400ms with no response
    [2019-10-23 16:43:13] WARNING[1656] chan_sip.c: Timeout on 2026245064-897691138-1202476321 on non-critical invite transaction.
    [2019-10-23 16:43:21] WARNING[1656] chan_sip.c: Timeout on 1997083236-1707736611-673989703 on non-critical invite transaction.
    [2019-10-23 16:43:26] WARNING[1656] chan_sip.c: Retransmission timeout reached on transmission 1897545996-5060-82@BJC.BGI.D.BGB for seqno 102 (Critical Request) — See https://wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions
    Packet timed out after 6400ms with no response
    [2019-10-23 16:43:28] WARNING[1656] chan_sip.c: Timeout on 356135904-147483397-409121765 on non-critical invite transaction.
    [2019-10-23 16:43:36] WARNING[1656] chan_sip.c: Timeout on 1622140938-1620135275-1996395105 on non-critical invite transaction.
    [2019-10-23 16:43:43] WARNING[1656] chan_sip.c: Timeout on 157997331-1841656359-553199610 on non-critical invite transaction.
    [2019-10-23 16:43:49] WARNING[1656] chan_sip.c: Timeout on 543840414-419285944-31089079 on non-critical invite transaction.
    [2019-10-23 16:43:57] WARNING[1656] chan_sip.c: Timeout on 1157460850-727418388-1287284724 on non-critical invite transaction.
    [2019-10-23 16:43:58] WARNING[1656] chan_sip.c: Retransmission timeout reached on transmission 2016835488-5060-422@BJC.BGI.D.IC for seqno 102 (Critical Request) — See https://wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions
    Packet timed out after 6401ms with no response
    [2019-10-23 16:44:03] WARNING[1656] chan_sip.c: Timeout on 987012759-574671042-972542671 on non-critical invite transaction.
    [2019-10-23 16:44:10] WARNING[1656] chan_sip.c: Timeout on 1021861340-1298807737-1942326983 on non-critical invite transaction.

    0
Viewing 15 replies - 1 through 15 (of 21 total)
1 2
  • Replies
    • October 23, 2019 at 9:05 pm
    toxicfusion
    Participant
    Up
    0
    Down

    Uhh…. did VitalPBX release another patch today? come on…  As I did update earlier ~ 10AM EST.. and been fighting issues all day with a particular install/client.

     

    yum update -y

    vpbx-addons | 2.9 kB 00:00:00
    (1/3): extras/7/x86_64/primary_db | 153 kB 00:00:00
    (2/3): updates/7/x86_64/primary_db | 2.8 MB 00:00:00
    (3/3): vpbx/x86_64/primary_db | 347 kB 00:00:00
    Resolving Dependencies
    –> Running transaction check
    —> Package firewalld.noarch 0:0.6.3-2.el7_7.2 will be updated
    —> Package firewalld.noarch 0:0.6.3-3.el7_7.2 will be an update
    —> Package firewalld-filesystem.noarch 0:0.6.3-2.el7_7.2 will be updated
    —> Package firewalld-filesystem.noarch 0:0.6.3-3.el7_7.2 will be an update
    —> Package microcode_ctl.x86_64 2:2.1-53.el7 will be updated
    —> Package microcode_ctl.x86_64 2:2.1-53.2.el7_7 will be an update
    —> Package patch.x86_64 0:2.7.1-11.el7 will be updated
    —> Package patch.x86_64 0:2.7.1-12.el7_7 will be an update
    —> Package python-firewall.noarch 0:0.6.3-2.el7_7.2 will be updated
    —> Package python-firewall.noarch 0:0.6.3-3.el7_7.2 will be an update
    –> Finished Dependency Resolution

    0
    • October 23, 2019 at 9:15 pm
    Jose Miguel Rivera
    Keymaster
    NI
    Up
    0
    Down

    Yes, we update the firewall-d packages, due to the last update of Centos kernel broke the firewall-d rules, producing that the PBX gets fully blocked.

     

    0
    • October 23, 2019 at 9:18 pm
    Jose Miguel Rivera
    Keymaster
    NI
    Up
    0
    Down

    About your issue, may you share a call trace (from asterisk CLI) of the IVR looping?

    Did you check the DTMF settings on your trunk?

    May you share the settings of the IVR (from the GUI) that is presenting the issue?

    0
    • October 24, 2019 at 1:54 am
    toxicfusion
    Participant
    Up
    0
    Down

    I was familiar with the last centOS update that broke firewall-d packages in conjunction with VitalPBX.  odd as the system was fine and working and then started having issue.  So I performed update, it broke firewall. I knew to delete mDNS. that worked.  Then later yum update ended up pulling down (later in day, first time was no update even after a yum clean all).

    Anyways.  Phones are still disconnected ‘unknown’  but the phones themselves from webUI are saying registered……

     

    I’m going to install a new instance for this customer and reload from backup and test connections.  It nearly appears as a NAT issue!  As my Zoper app on my cell phone connects just fine without issue.

    No firewall or router changes been made.  I’m asking client to have ISP swap modem, as its business class and bridged (spectrum). Issue since monday.

     

    I first thought was amazon route53 (DNS) issue, was known. But no other clients were effected.

    0
    • October 24, 2019 at 3:52 am
    Jose Miguel Rivera
    Keymaster
    NI
    Up
    0
    Down

    When phones are shown as UNREACHABLE on VitalPBX, try changing the qualify frequency setting on the technology profiles module, decrease the value to something like 20 or 10 seconds. This may help with big network latencies.

    0
    • October 24, 2019 at 4:13 am
    Jose Miguel Rivera
    Keymaster
    NI
    Up
    0
    Down

    About this message: “chan_sip.c: Timeout on 356135904-147483397-409121765 on non-critical invite transaction.”

    This may happen for the following reasons:

    • A NAT device in the signaling path. A misconfigured NAT device is in the signaling path and stops SIP messages.
    • A firewall that blocks messages or reroutes them wrongly in an attempt to assist in a too clever way.
    • A SIP middlebox (SBC) that rewrites contact: headers so that we can’t reach the other side with our reply or the ACK.
    • A badly configured SIP proxy that forgets to add record-route headers to make sure that signaling works.
    • Packet loss. IP and UDP are unreliable transports. If you lose too many packets the retransmits don’t help and communication is impossible. If this happens with signaling, media would be unusable anyway.
    • Some routers are configured by default with the “SIP ALG” option. In some cases, this option should be off because the implementation is incomplete.
    • Unauthorized invites. Also, you may get this message when SIP scanners try to vulnerate your server.
    0
    • October 24, 2019 at 12:53 pm
    toxicfusion
    Participant
    Up
    0
    Down

    Update:

    A fresh install at first glance appeared to fix the issue. However, now this morning ALL the phones are back to the same ‘unreachable’ status.  I even moved the hosted instance to my 2nd location.

     

    This is only effecting one client. Makes me question NAT issue. However, no firewall changes have been made AT ALL!  This appears to be stemming from an update??

    I noticed another member posted very similar issue. 

    0
    • October 24, 2019 at 12:56 pm
    toxicfusion
    Participant
    Up
    0
    Down

    @ing-joserivera26

    Qualify frequency is already set to default 60 seconds. Saying I should lower this threshhold?

     

    Settings >>  Technology Settings > Profiles >> Default SIP Profile

    0
    • October 24, 2019 at 1:15 pm
    Jose Miguel Rivera
    Keymaster
    NI
    Up
    0
    Down

    Yes, you must decrease the value as much as possible, try with 30, 20 or 5 seconds.

    0
    • October 24, 2019 at 1:26 pm
    toxicfusion
    Participant
    Up
    0
    Down

    @ing-joserivera26

    Is this a newer default value in the latest VitalPBX Release? Again, I’ve never experienced this ever with clients.  This is only client who’s recently experienced issue and it just cropped up. Spectrum internet – same as quite a few others…

     

    Spectrum coming today to review coax line quality and have them replace modem. 

     

    Odd as after a fresh install of VitalPBX, loaded backup, then migrated DNS A-Records. The phones started to register and were status “OK” and seemed stable.  Checked this morning, and all back to unreachable.  Very busy office client as well!!

    0
    • October 24, 2019 at 1:28 pm
    toxicfusion
    Participant
    Up
    0
    Down

    VitalPBX 2.3.8-1
    Asterisk 16.6.0-1
    DAHDI 2.11.1-7

     

    Latest build/install. Fresh install.   I’m scrambling as may lose customer who i’ve had for 3+ years for phones. I migrated to VitalPBX from AskoziaPBX…

    0
    • October 24, 2019 at 1:29 pm
    Jose Miguel Rivera
    Keymaster
    NI
    Up
    0
    Down

    No, this is no a new default, this something you can do with big network latencies.

    Did you already try?

    0
    • October 24, 2019 at 1:41 pm
    toxicfusion
    Participant
    Up
    0
    Down

    Already tried, lowered to 10seconds…  No change. Phones still unreachable 🙁

     

    CLI: asterisk -r

    shows phones trying but not reachable.  Again feel like NAT.  I’m wondering if their spectrum modem got reprovisioned and not completely bridged and SIP-ALG on??  As monday I had notice their internet went down for few minutes and back online and then shortly after I began getting calls that their phones are not working properly.

    [2019-10-23 17:17:21] WARNING[28408]: chan_sip.c:4178 retrans_pkt: Timeout on 1777994436-823524420-730192873 on non-critical invite transaction.
    [2019-10-23 17:17:25] WARNING[28408]: chan_sip.c:4178 retrans_pkt: Timeout on 146670409-846227674-65996837 on non-critical invite transaction.
    [2019-10-23 17:17:29] WARNING[28408]: chan_sip.c:4178 retrans_pkt: Timeout on 1152714157-1437402208-253856997 on non-critical invite transaction.
    [2019-10-23 17:17:34] WARNING[28408]: chan_sip.c:4178 retrans_pkt: Timeout on 191675425-672009175-1450313016 on non-critical invite transaction.
    [2019-10-23 17:17:35] WARNING[28408]: chan_sip.c:4178 retrans_pkt: Timeout on 682675796-27726949-1930973542 on non-critical invite transaction.
    [2019-10-23 17:17:38] WARNING[28408]: chan_sip.c:4178 retrans_pkt: Timeout on 821745102-488602223-215523759 on non-critical invite transaction.

    [2019-10-24 13:37:26] WARNING[28771][C-00000076]: func_channel.c:463 func_channel_read: Unknown or unavailable item requested: ‘dahdi_channel’
    [2019-10-24 13:37:26] WARNING[28771][C-00000076]: app_dial.c:2578 dial_exec_full: Unable to create channel of type ‘SIP’ (cause 20 – Subscriber absent)
    [2019-10-24 13:37:26] WARNING[28770][C-00000076]: func_channel.c:463 func_channel_read: Unknown or unavailable item requested: ‘dahdi_channel’
    [2019-10-24 13:37:26] WARNING[28773][C-00000076]: func_channel.c:463 func_channel_read: Unknown or unavailable item requested: ‘dahdi_channel’
    [2019-10-24 13:37:26] WARNING[28773][C-00000076]: app_dial.c:2578 dial_exec_full: Unable to create channel of type ‘SIP’ (cause 20 – Subscriber absent)
    [2019-10-24 13:37:26] WARNING[28772][C-00000076]: func_channel.c:463 func_channel_read: Unknown or unavailable item requested: ‘dahdi_channel’
    [2019-10-24 13:37:26] WARNING[28772][C-00000076]: app_dial.c:2578 dial_exec_full: Unable to create channel of type ‘SIP’ (cause 20 – Subscriber absent)
    [2019-10-24 13:37:26] WARNING[28774][C-00000076]: func_channel.c:463 func_channel_read: Unknown or unavailable item requested: ‘dahdi_channel’
    [2019-10-24 13:37:26] WARNING[28774][C-00000076]: app_dial.c:2578 dial_exec_full: Unable to create channel of type ‘SIP’ (cause 20 – Subscriber absent)
    [2019-10-24 13:37:26] WARNING[28770][C-00000076]: app_dial.c:2578 dial_exec_full: Unable to create channel of type ‘SIP’ (cause 20 – Subscriber absent)

     

    0
    • October 24, 2019 at 1:43 pm
    Jose Miguel Rivera
    Keymaster
    NI
    Up
    0
    Down

    I think this something related to your customer network.

    0
    • October 24, 2019 at 1:45 pm
    toxicfusion
    Participant
    Up
    0
    Down

    <————->
    — (17 headers 0 lines) —
    Ignoring this SUBSCRIBE request
    Found peer ‘202’ for ‘202’ from XX.XX.XXX.XX:1051

    <— Transmitting (NAT) to 67.XX.XXX.XX:1051 —>
    SIP/2.0 401 Unauthorized
    Via: SIP/2.0/UDP 192.168.3.161:5060;branch=z9hG4bK1932796332;received=67.78.248.26;rport=1051
    From: <sip:202@sip-sanitizeddomainname.com>;tag=1219705200
    To: <sip:806@sip-sanitizeddomainname.com>;tag=as40207254
    Call-ID: 135776760-5060-1553@BJC.BGI.D.BGB
    CSeq: 35500 SUBSCRIBE
    Server: VitalPBX
    Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
    Supported: replaces, timer
    WWW-Authenticate: Digest algorithm=MD5, realm=”asterisk”, nonce=”66cdc91f”
    Content-Length: 0

    <————>
    Scheduling destruction of SIP dialog ‘135776760-5060-1553@BJC.BGI.D.BGB’ in 6400 ms (Method: SUBSCRIBE)

    <— SIP read from UDP:XX.XX.XXX.XX:1053 —>
    SIP/2.0 200 OK
    Via: SIP/2.0/UDP 149.28.249.167:5060;branch=z9hG4bK505c20f2;rport=5060
    From: “asterisk” <sip:asterisk@149.28.249.167>;tag=as024aa505
    To: <sip:210@192.168.3.82:5060>;tag=2106561804
    Call-ID: 135f3836330580636bcad1373ce239aa@149.28.249.167:5060
    CSeq: 102 OPTIONS
    Supported: replaces, path, timer
    User-Agent: Grandstream GXP1628 1.0.4.105
    Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, SUBSCRIBE, NOTIFY, INFO, REFER, UPDATE, MESSAGE
    Content-Length: 0

    0
Viewing 15 replies - 1 through 15 (of 21 total)
1 2
  • You must be logged in to reply to this topic.