Intesting answered call

yellowpostit · October 14, 2022, 9:27am

Hello all,

There is a something about my calls. Interesting is call answered but not any thing for in 900 seconds then it get hangup. I will share my call logs line by line.

Infact, if this call when answered, it must go to queue but didn’t. I don’t understand this situation and i need help to understand.

Thanks…


[2022-10-13 10:47:36] VERBOSE[12482] dial.c: Called CALLEDPHONE@dialplan
[2022-10-13 10:47:36] VERBOSE[12483][C-0068642c] pbx.c: Executing [CALLEDPHONE@dialplan:1] Verbose("Local/CALLEDPHONE@dialplan-0060ae4d;2", "3,--------------------------------------> AMD BEGIN local dialer") in new stack
[2022-10-13 10:47:36] VERBOSE[12483][C-0068642c] pbx.c: Executing [CALLEDPHONE@dialplan:2] Set("Local/CALLEDPHONE@dialplan-0060ae4d;2", "CALLERID(all)=CIDNUMBER") in new stack
[2022-10-13 10:47:36] VERBOSE[12483][C-0068642c] pbx.c: Executing [CALLEDPHONE@dialplan:3] Set("Local/CALLEDPHONE@dialplan-0060ae4d;2", "TIMEOUT(absolute)=1800") in new stack
[2022-10-13 10:47:36] VERBOSE[12483][C-0068642c] pbx.c: Executing [CALLEDPHONE@dialplan:4] Set("Local/CALLEDPHONE@dialplan-0060ae4d;2", "CHANNEL(hangup_handler_push)=hangup_handler,s,1") in new stack
[2022-10-13 10:47:36] VERBOSE[12483][C-0068642c] pbx.c: Executing [CALLEDPHONE@dialplan:5] Dial("Local/CALLEDPHONE@dialplan-0060ae4d;2", "PJSIP/CALLEDPHONE@vendor,0,M(amd-detect)") in new stack
[2022-10-13 10:47:36] VERBOSE[12483][C-0068642c] app_dial.c: Called PJSIP/CALLEDPHONE@vendor
INVITE sip:CALLEDPHONE@sip.vendor.com:8000 SIP/2.0
To: <sip:CALLEDPHONE@sip.vendor.com>
To: <sip:CALLEDPHONE@sip.vendor.com>;tag=z9hG4bKPjfb631715-276d-4fc1-b3e2-b51356298343
ACK sip:CALLEDPHONE@sip.vendor.com:8000 SIP/2.0
To: <sip:CALLEDPHONE@sip.vendor.com>;tag=z9hG4bKPjfb631715-276d-4fc1-b3e2-b51356298343
INVITE sip:CALLEDPHONE@sip.vendor.com:8000 SIP/2.0
To: <sip:CALLEDPHONE@sip.vendor.com>
Authorization: Digest username="101", realm="asterisk", nonce="1665647256/a9cb14883234e89e166d37808b91b8ab", uri="sip:CALLEDPHONE@sip.vendor.com:8000", response="0dbc9866b92bdbffc60d2c90bbef68bb", algorithm=md5, cnonce="6fc1aa6f93e84f59929cdd7d8154a5f6", opaque="4de596d76d8041cf", qop=auth, nc=00000001
To: <sip:CALLEDPHONE@sip.vendor.com>
To: <sip:CALLEDPHONE@sip.vendor.com>;tag=0f0a6a42-8299-4b77-b3fb-3df22ce1f482
P-Asserted-Identity: <sip:CALLEDPHONE@sip.vendor.com>
To: <sip:CALLEDPHONE@sip.vendor.com>;tag=0f0a6a42-8299-4b77-b3fb-3df22ce1f482
P-Asserted-Identity: <sip:CALLEDPHONE@sip.vendor.com>
[2022-10-13 10:47:36] VERBOSE[12483][C-0068642c] app_dial.c: PJSIP/vendor-00627d8c is making progress passing it to Local/CALLEDPHONE@dialplan-0060ae4d;2
[2022-10-13 10:47:36] VERBOSE[12483][C-0068642c] app_dial.c: PJSIP/vendor-00627d8c is making progress passing it to Local/CALLEDPHONE@dialplan-0060ae4d;2
[2022-10-13 10:47:36] VERBOSE[12482] dial.c: Local/CALLEDPHONE@dialplan-0060ae4d;1 is making progress
[2022-10-13 10:47:36] VERBOSE[12482] dial.c: Local/CALLEDPHONE@dialplan-0060ae4d;1 is making progress
To: <sip:CALLEDPHONE@sip.vendor.com>;tag=0f0a6a42-8299-4b77-b3fb-3df22ce1f482
P-Asserted-Identity: <sip:CALLEDPHONE@sip.vendor.com>
To: <sip:CALLEDPHONE@sip.vendor.com>;tag=0f0a6a42-8299-4b77-b3fb-3df22ce1f482
[2022-10-13 10:47:57] VERBOSE[12483][C-0068642c] app_dial.c: PJSIP/vendor-00627d8c answered Local/CALLEDPHONE@dialplan-0060ae4d;2
To: <sip:CALLEDPHONE@sip.vendor.com>;tag=0f0a6a42-8299-4b77-b3fb-3df22ce1f482
To: <sip:CALLEDPHONE@sip.vendor.com>;tag=0f0a6a42-8299-4b77-b3fb-3df22ce1f482


**-- Then there is no anything -- 2022-10-13 10:47:57 < - > 2022-10-13 11:02:57**


[2022-10-13 11:02:57] VERBOSE[12483][C-0068642c] pbx.c: Spawn extension (dialplan, CALLEDPHONE, 5) exited non-zero on 'Local/CALLEDPHONE@dialplan-0060ae4d;2'
[2022-10-13 11:02:57] VERBOSE[12483][C-0068642c] app_stack.c: Local/CALLEDPHONE@dialplan-0060ae4d;2 Internal Gosub(hangup_handler,s,1) start
[2022-10-13 11:02:57] VERBOSE[12483][C-0068642c] pbx.c: Executing [s@hangup_handler:1] Verbose("Local/CALLEDPHONE@dialplan-0060ae4d;2", "0, Executing Hangup Handler") in new stack
[2022-10-13 11:02:57] VERBOSE[12483][C-0068642c] pbx.c: Executing [s@hangup_handler:2] Verbose("Local/CALLEDPHONE@dialplan-0060ae4d;2", "0, ========================== # QUEUESTATUSC: 0") in new stack
[2022-10-13 11:02:57] VERBOSE[12483][C-0068642c] pbx.c: Executing [s@hangup_handler:3] Set("Local/CALLEDPHONE@dialplan-0060ae4d;2", "CHANNEL_ID=PJSIP/vendor-00627d8c") in new stack
[2022-10-13 11:02:57] VERBOSE[12483][C-0068642c] pbx.c: Executing [s@hangup_handler:4] Set("Local/CALLEDPHONE@dialplan-0060ae4d;2", "ANSWERINGMACHINE=SIP 708 Answering Machine") in new stack
[2022-10-13 11:02:57] VERBOSE[12483][C-0068642c] pbx.c: Executing [s@hangup_handler:5] Set("Local/CALLEDPHONE@dialplan-0060ae4d;2", "ReasonTech=SIP 200 OK") in new stack
[2022-10-13 11:02:57] VERBOSE[12483][C-0068642c] pbx.c: Executing [s@hangup_handler:6] ExecIf("Local/CALLEDPHONE@dialplan-0060ae4d;2", "0?Set(ReasonTech=SIP 715 Queue Hangup)") in new stack
[2022-10-13 11:02:57] VERBOSE[12483][C-0068642c] pbx.c: Executing [s@hangup_handler:7] Set("Local/CALLEDPHONE@dialplan-0060ae4d;2", "SIP_CAUSE=SIP 200 OK") in new stack
[2022-10-13 11:02:57] VERBOSE[12483][C-0068642c] pbx.c: Executing [s@hangup_handler:8] Set("Local/CALLEDPHONE@dialplan-0060ae4d;2", "GLOBAL(QUEUESTATUSC)=0") in new stack
To: <sip:CALLEDPHONE@sip.vendor.com>;tag=0f0a6a42-8299-4b77-b3fb-3df22ce1f482
[2022-10-13 11:02:57] VERBOSE[12483][C-0068642c] pbx.c: Executing [s@hangup_handler:9] Return("Local/CALLEDPHONE@dialplan-0060ae4d;2", "SIP 200 OK") in new stack
[2022-10-13 11:02:57] VERBOSE[12483][C-0068642c] app_stack.c: Spawn extension (dialplan, CALLEDPHONE, 5) exited non-zero on 'Local/CALLEDPHONE@dialplan-0060ae4d;2'
[2022-10-13 11:02:57] VERBOSE[12483][C-0068642c] app_stack.c: Local/CALLEDPHONE@dialplan-0060ae4d;2 Internal Gosub(hangup_handler,s,1) complete GOSUB_RETVAL=SIP 200 OK
To: <sip:CALLEDPHONE@sip.vendor.com>;tag=0f0a6a42-8299-4b77-b3fb-3df22ce1f482

david551 · October 14, 2022, 9:46am

You appear to have filtered this on CALLEDPHONE, which has removed most of the SIP protocol trace.

I would guess this is a failed session timer.

yellowpostit · October 14, 2022, 9:57am

Please help me to understand more.

So, Which side belongs to have this problem? provider/vendor or our server?
What can i do in this point to fix?

david551 · October 14, 2022, 10:07am

Most likely your router. You can disable session timers, but if they are successfully negotiated then fail, other subsequent operations, like ending the call, may also fail.

Whilst I cannot see anything arriving from the other side, that would cause the call to terminate, having the full SIP trace for the call would help confirm that, and also indicate if, and how, session timers were set up.

There might also be a message about session timers that you have lost, as a result of filtering your log.

My working hypothesis is that the provider was responsible for refreshing the session, and that you have a dynamic NAT or firewall rule that timed out, before the refresh, so that the refresh never reached your Asterisk daemon.

This appears to have been an outbound call, so, at least initially, the asterisk daemon was the client, not the server.

yellowpostit · October 14, 2022, 11:38am

Okay, thanks for your explanation now i have more opinion about that.

system · November 13, 2022, 11:39am

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