Strange Behaviours:

ccentrale · October 12, 2021, 7:28pm

I have the following situation:
Italian E1/ISDN —>Patton SmartNode 4980A VoIP Gateway Router —> FreePBX (15.0.17.55)

Pattone <—> FreePBX = SIP Trunk

I noticed the following situations:

I made a call from my Cell/Mobile to the ISDN number;
The “Set Destination” in the FreePBX “Inbound Routes” configuration, routes that call to an IVR Service;
After the “Welcome Message”, I close immediately the call.
With the command “core show channels” the calls is still active and is closed after 30 sec. (about - more or less)

I receive the same result if I set a “Queue” as destination in the “Inbound Routes”. I hang up the call immediately when start the MOH, but the call continues in the Telephony System and is disconnected 30 sec. later.

Instead:

If i set an “Extension” as destination in the “Inbound Routes”;
place the call to the ISDN number and the exten. start to ring (but I don’t answer);
I hang up the call, the same is correctly closed (I see with “core show channels”). It doesn’t remain active in background for more 30 sec. as the others scenario.

Is anyone that could help me?

dicko · October 12, 2021, 7:32pm

pastebin a log of a failed call

ccentrale · October 12, 2021, 7:56pm

Hi,
this is a call placed to an IVR Service:

[2021-10-12 21:52:15] VERBOSE[16771][C-00000039] pbx.c: Executing [645775926@from-trunk-sip-uco_p1:1] Set(“SIP/uco_p1-00000054”, “GROUP()=OUT_1”) in new stack
[2021-10-12 21:52:15] VERBOSE[16771][C-00000039] pbx.c: Executing [645775926@from-trunk-sip-uco_p1:2] Goto(“SIP/uco_p1-00000054”, “from-trunk,645775926,1”) in new stack
[2021-10-12 21:52:15] VERBOSE[16771][C-00000039] pbx_builtins.c: Goto (from-trunk,645775926,1)
[2021-10-12 21:52:15] VERBOSE[16771][C-00000039] pbx.c: Executing [645775926@from-trunk:1] Set(“SIP/uco_p1-00000054”, “__DIRECTION=INBOUND”) in new stack
[2021-10-12 21:52:15] VERBOSE[16771][C-00000039] pbx.c: Executing [645775926@from-trunk:2] Set(“SIP/uco_p1-00000054”, “CHANNEL(language)=it”) in new stack
[2021-10-12 21:52:15] VERBOSE[16771][C-00000039] pbx.c: Executing [645775926@from-trunk:3] Gosub(“SIP/uco_p1-00000054”, “sub-record-check,s,1(in,645775926,dontcare)”) in new stack
[2021-10-12 21:52:15] VERBOSE[16771][C-00000039] pbx.c: Executing [s@sub-record-check:1] GotoIf(“SIP/uco_p1-00000054”, “0?initialized”) in new stack
[2021-10-12 21:52:15] VERBOSE[16771][C-00000039] pbx.c: Executing [s@sub-record-check:2] Set(“SIP/uco_p1-00000054”, “__REC_STATUS=INITIALIZED”) in new stack
[2021-10-12 21:52:15] VERBOSE[16771][C-00000039] pbx.c: Executing [s@sub-record-check:3] Set(“SIP/uco_p1-00000054”, “NOW=1634068335”) in new stack
[2021-10-12 21:52:15] VERBOSE[16771][C-00000039] pbx.c: Executing [s@sub-record-check:4] Set(“SIP/uco_p1-00000054”, “__DAY=12”) in new stack
[2021-10-12 21:52:15] VERBOSE[16771][C-00000039] pbx.c: Executing [s@sub-record-check:5] Set(“SIP/uco_p1-00000054”, “__MONTH=10”) in new stack
[2021-10-12 21:52:15] VERBOSE[16771][C-00000039] pbx.c: Executing [s@sub-record-check:6] Set(“SIP/uco_p1-00000054”, “__YEAR=2021”) in new stack
[2021-10-12 21:52:15] VERBOSE[16771][C-00000039] pbx.c: Executing [s@sub-record-check:7] Set(“SIP/uco_p1-00000054”, “__TIMESTR=20211012-215215”) in new stack
[2021-10-12 21:52:15] VERBOSE[16771][C-00000039] pbx.c: Executing [s@sub-record-check:8] Set(“SIP/uco_p1-00000054”, “__FROMEXTEN=unknown”) in new stack
[2021-10-12 21:52:15] VERBOSE[16771][C-00000039] pbx.c: Executing [s@sub-record-check:9] Set(“SIP/uco_p1-00000054”, “__MON_FMT=wav”) in new stack
[2021-10-12 21:52:15] VERBOSE[16771][C-00000039] pbx.c: Executing [s@sub-record-check:10] NoOp(“SIP/uco_p1-00000054”, “Recordings initialized”) in new stack
[2021-10-12 21:52:15] VERBOSE[16771][C-00000039] pbx.c: Executing [s@sub-record-check:11] ExecIf(“SIP/uco_p1-00000054”, “0?Set(ARG3=dontcare)”) in new stack
[2021-10-12 21:52:15] VERBOSE[16771][C-00000039] pbx.c: Executing [s@sub-record-check:12] Set(“SIP/uco_p1-00000054”, “REC_POLICY_MODE_SAVE=”) in new stack
[2021-10-12 21:52:15] VERBOSE[16771][C-00000039] pbx.c: Executing [s@sub-record-check:13] ExecIf(“SIP/uco_p1-00000054”, “0?Set(REC_STATUS=NO)”) in new stack
[2021-10-12 21:52:15] VERBOSE[16771][C-00000039] pbx.c: Executing [s@sub-record-check:14] GotoIf(“SIP/uco_p1-00000054”, “2?checkaction”) in new stack
[2021-10-12 21:52:15] VERBOSE[16771][C-00000039] pbx_builtins.c: Goto (sub-record-check,s,17)
[2021-10-12 21:52:15] VERBOSE[16771][C-00000039] pbx.c: Executing [s@sub-record-check:17] GotoIf(“SIP/uco_p1-00000054”, “1?sub-record-check,in,1”) in new stack
[2021-10-12 21:52:15] VERBOSE[16771][C-00000039] pbx_builtins.c: Goto (sub-record-check,in,1)
[2021-10-12 21:52:15] VERBOSE[16771][C-00000039] pbx.c: Executing [in@sub-record-check:1] NoOp(“SIP/uco_p1-00000054”, “Inbound Recording Check to 645775926”) in new stack
[2021-10-12 21:52:15] VERBOSE[16771][C-00000039] pbx.c: Executing [in@sub-record-check:2] Set(“SIP/uco_p1-00000054”, “FROMEXTEN=unknown”) in new stack
[2021-10-12 21:52:15] VERBOSE[16771][C-00000039] pbx.c: Executing [in@sub-record-check:3] ExecIf(“SIP/uco_p1-00000054”, “10?Set(FROMEXTEN=3408004705)”) in new stack
[2021-10-12 21:52:15] VERBOSE[16771][C-00000039] pbx.c: Executing [in@sub-record-check:4] Gosub(“SIP/uco_p1-00000054”, “recordcheck,1(dontcare,in,645775926)”) in new stack
[2021-10-12 21:52:15] VERBOSE[16771][C-00000039] pbx.c: Executing [recordcheck@sub-record-check:1] NoOp(“SIP/uco_p1-00000054”, “Starting recording check against dontcare”) in new stack
[2021-10-12 21:52:15] VERBOSE[16771][C-00000039] pbx.c: Executing [recordcheck@sub-record-check:2] Goto(“SIP/uco_p1-00000054”, “dontcare”) in new stack
[2021-10-12 21:52:15] VERBOSE[16771][C-00000039] pbx_builtins.c: Goto (sub-record-check,recordcheck,3)
[2021-10-12 21:52:15] VERBOSE[16771][C-00000039] pbx.c: Executing [recordcheck@sub-record-check:3] Return(“SIP/uco_p1-00000054”, “”) in new stack
[2021-10-12 21:52:15] VERBOSE[16771][C-00000039] pbx.c: Executing [in@sub-record-check:5] Return(“SIP/uco_p1-00000054”, “”) in new stack
[2021-10-12 21:52:15] VERBOSE[16771][C-00000039] pbx.c: Executing [645775926@from-trunk:4] Set(“SIP/uco_p1-00000054”, “CHANNEL(tonezone)=it”) in new stack
[2021-10-12 21:52:15] VERBOSE[16771][C-00000039] pbx.c: Executing [645775926@from-trunk:5] Set(“SIP/uco_p1-00000054”, “__FROM_DID=645775926”) in new stack
[2021-10-12 21:52:15] VERBOSE[16771][C-00000039] pbx.c: Executing [645775926@from-trunk:6] Set(“SIP/uco_p1-00000054”, “returnhere=1”) in new stack
[2021-10-12 21:52:15] VERBOSE[16771][C-00000039] pbx.c: Executing [645775926@from-trunk:7] Gosub(“SIP/uco_p1-00000054”, “app-blacklist-check,s,1()”) in new stack
[2021-10-12 21:52:15] VERBOSE[16771][C-00000039] pbx.c: Executing [s@app-blacklist-check:1] GotoIf(“SIP/uco_p1-00000054”, “0?blacklisted”) in new stack
[2021-10-12 21:52:15] VERBOSE[16771][C-00000039] pbx.c: Executing [s@app-blacklist-check:2] Set(“SIP/uco_p1-00000054”, “CALLED_BLACKLIST=1”) in new stack
[2021-10-12 21:52:15] VERBOSE[16771][C-00000039] pbx.c: Executing [s@app-blacklist-check:3] Return(“SIP/uco_p1-00000054”, “”) in new stack
[2021-10-12 21:52:15] VERBOSE[16771][C-00000039] pbx.c: Executing [645775926@from-trunk:8] Set(“SIP/uco_p1-00000054”, “CDR(did)=645775926”) in new stack
[2021-10-12 21:52:15] VERBOSE[16771][C-00000039] pbx.c: Executing [645775926@from-trunk:9] GotoIf(“SIP/uco_p1-00000054”, “0?”) in new stack
[2021-10-12 21:52:15] VERBOSE[16771][C-00000039] pbx.c: Executing [645775926@from-trunk:10] ExecIf(“SIP/uco_p1-00000054”, “0 ?Set(CALLERID(name)=3408004705)”) in new stack
[2021-10-12 21:52:15] VERBOSE[16771][C-00000039] pbx.c: Executing [645775926@from-trunk:11] Set(“SIP/uco_p1-00000054”, “__MOHCLASS=”) in new stack
[2021-10-12 21:52:15] VERBOSE[16771][C-00000039] pbx.c: Executing [645775926@from-trunk:12] Set(“SIP/uco_p1-00000054”, “__REVERSAL_REJECT=FALSE”) in new stack
[2021-10-12 21:52:15] VERBOSE[16771][C-00000039] pbx.c: Executing [645775926@from-trunk:13] GotoIf(“SIP/uco_p1-00000054”, “1?post-reverse-charge”) in new stack
[2021-10-12 21:52:15] VERBOSE[16771][C-00000039] pbx_builtins.c: Goto (from-trunk,645775926,15)
[2021-10-12 21:52:15] VERBOSE[16771][C-00000039] pbx.c: Executing [645775926@from-trunk:15] NoOp(“SIP/uco_p1-00000054”, “”) in new stack
[2021-10-12 21:52:15] VERBOSE[16771][C-00000039] pbx.c: Executing [645775926@from-trunk:16] Set(“SIP/uco_p1-00000054”, “__CALLINGNAMEPRES_SV=allowed_not_screened”) in new stack
[2021-10-12 21:52:15] VERBOSE[16771][C-00000039] pbx.c: Executing [645775926@from-trunk:17] Set(“SIP/uco_p1-00000054”, “__CALLINGNUMPRES_SV=allowed_not_screened”) in new stack
[2021-10-12 21:52:15] VERBOSE[16771][C-00000039] pbx.c: Executing [645775926@from-trunk:18] Set(“SIP/uco_p1-00000054”, “CALLERID(name-pres)=allowed_not_screened”) in new stack
[2021-10-12 21:52:15] VERBOSE[16771][C-00000039] pbx.c: Executing [645775926@from-trunk:19] Set(“SIP/uco_p1-00000054”, “CALLERID(num-pres)=allowed_not_screened”) in new stack
[2021-10-12 21:52:15] VERBOSE[16771][C-00000039] pbx.c: Executing [645775926@from-trunk:20] NoOp(“SIP/uco_p1-00000054”, “CallerID Entry Point”) in new stack
[2021-10-12 21:52:15] VERBOSE[16771][C-00000039] pbx.c: Executing [645775926@from-trunk:21] Set(“SIP/uco_p1-00000054”, “__CRM_DIRECTION=INBOUND”) in new stack
[2021-10-12 21:52:15] VERBOSE[16771][C-00000039] pbx.c: Executing [645775926@from-trunk:22] Set(“SIP/uco_p1-00000054”, “__CRM_SOURCE=3408004705”) in new stack
[2021-10-12 21:52:15] VERBOSE[16771][C-00000039] pbx.c: Executing [645775926@from-trunk:23] Set(“SIP/uco_p1-00000054”, “__CRM_LINKEDID=1634068335.84”) in new stack
[2021-10-12 21:52:15] VERBOSE[16771][C-00000039] pbx.c: Executing [645775926@from-trunk:24] AGI(“SIP/uco_p1-00000054”, “agi://127.0.0.1/sangomacrm.agi,true”) in new stack
[2021-10-12 21:52:15] VERBOSE[16771][C-00000039] res_agi.c: <SIP/uco_p1-00000054>AGI Script agi://127.0.0.1/sangomacrm.agi completed, returning 0
[2021-10-12 21:52:15] VERBOSE[16771][C-00000039] pbx.c: Executing [645775926@from-trunk:25] ExecIf(“SIP/uco_p1-00000054”, “1?Set(CHANNEL(hangup_handler_push)=crm-hangup,s,1)”) in new stack
[2021-10-12 21:52:15] VERBOSE[16771][C-00000039] pbx.c: Executing [645775926@from-trunk:26] Goto(“SIP/uco_p1-00000054”, “ivr-4,s,1”) in new stack
[2021-10-12 21:52:15] VERBOSE[16771][C-00000039] pbx_builtins.c: Goto (ivr-4,s,1)
[2021-10-12 21:52:15] VERBOSE[16771][C-00000039] pbx.c: Executing [s@ivr-4:1] Set(“SIP/uco_p1-00000054”, “TIMEOUT_LOOPCOUNT=0”) in new stack
[2021-10-12 21:52:15] VERBOSE[16771][C-00000039] pbx.c: Executing [s@ivr-4:2] Set(“SIP/uco_p1-00000054”, “INVALID_LOOPCOUNT=0”) in new stack
[2021-10-12 21:52:15] VERBOSE[16771][C-00000039] pbx.c: Executing [s@ivr-4:3] Set(“SIP/uco_p1-00000054”, “_IVR_CONTEXT_ivr-4=”) in new stack
[2021-10-12 21:52:15] VERBOSE[16771][C-00000039] pbx.c: Executing [s@ivr-4:4] Set(“SIP/uco_p1-00000054”, “_IVR_CONTEXT=ivr-4”) in new stack
[2021-10-12 21:52:15] VERBOSE[16771][C-00000039] pbx.c: Executing [s@ivr-4:5] Set(“SIP/uco_p1-00000054”, “__IVR_RETVM=”) in new stack
[2021-10-12 21:52:15] VERBOSE[16771][C-00000039] pbx.c: Executing [s@ivr-4:6] GotoIf(“SIP/uco_p1-00000054”, “0?skip”) in new stack
[2021-10-12 21:52:15] VERBOSE[16771][C-00000039] pbx.c: Executing [s@ivr-4:7] Answer(“SIP/uco_p1-00000054”, “”) in new stack
[2021-10-12 21:52:16] VERBOSE[16771][C-00000039] res_rtp_asterisk.c: 0x7fabe0060530 – Strict RTP switching to RTP target address 10.139.156.1:6092 as source
[2021-10-12 21:52:16] VERBOSE[16771][C-00000039] pbx.c: Executing [s@ivr-4:8] Set(“SIP/uco_p1-00000054”, “IVR_MSG=custom/UCO_FuoriOrarioHoliday”) in new stack
[2021-10-12 21:52:16] VERBOSE[16771][C-00000039] pbx.c: Executing [s@ivr-4:9] Set(“SIP/uco_p1-00000054”, “TIMEOUT(digit)=3”) in new stack
[2021-10-12 21:52:16] VERBOSE[16771][C-00000039] func_timeout.c: Digit timeout set to 3.000
[2021-10-12 21:52:16] VERBOSE[16771][C-00000039] pbx.c: Executing [s@ivr-4:10] ExecIf(“SIP/uco_p1-00000054”, “1?Background(custom/UCO_FuoriOrarioHoliday)”) in new stack
[2021-10-12 21:52:16] VERBOSE[16771][C-00000039] file.c: <SIP/uco_p1-00000054> Playing ‘custom/UCO_FuoriOrarioHoliday.ulaw’ (language ‘it’)
[2021-10-12 21:52:20] VERBOSE[16771][C-00000039] res_rtp_asterisk.c: 0x7fabe0060530 – Strict RTP learning complete - Locking on source address 10.139.156.1:6092
[2021-10-12 21:52:30] VERBOSE[16771][C-00000039] pbx.c: Executing [s@ivr-4:11] WaitExten(“SIP/uco_p1-00000054”, “10,”) in new stack
[2021-10-12 21:52:40] VERBOSE[16771][C-00000039] pbx_builtins.c: Timeout on SIP/uco_p1-00000054, going to ‘t’
[2021-10-12 21:52:40] VERBOSE[16771][C-00000039] pbx.c: Executing [t@ivr-4:1] Set(“SIP/uco_p1-00000054”, “TIMEOUT_LOOPCOUNT=1”) in new stack
[2021-10-12 21:52:40] VERBOSE[16771][C-00000039] pbx.c: Executing [t@ivr-4:2] GotoIf(“SIP/uco_p1-00000054”, “0?final”) in new stack
[2021-10-12 21:52:40] VERBOSE[16771][C-00000039] pbx.c: Executing [t@ivr-4:3] Set(“SIP/uco_p1-00000054”, “IVR_MSG=no-valid-responce-pls-try-again”) in new stack
[2021-10-12 21:52:40] VERBOSE[16771][C-00000039] pbx.c: Executing [t@ivr-4:4] Goto(“SIP/uco_p1-00000054”, “s,start”) in new stack
[2021-10-12 21:52:40] VERBOSE[16771][C-00000039] pbx_builtins.c: Goto (ivr-4,s,9)
[2021-10-12 21:52:40] VERBOSE[16771][C-00000039] pbx.c: Executing [s@ivr-4:9] Set(“SIP/uco_p1-00000054”, “TIMEOUT(digit)=3”) in new stack
[2021-10-12 21:52:40] VERBOSE[16771][C-00000039] func_timeout.c: Digit timeout set to 3.000
[2021-10-12 21:52:40] VERBOSE[16771][C-00000039] pbx.c: Executing [s@ivr-4:10] ExecIf(“SIP/uco_p1-00000054”, “1?Background(no-valid-responce-pls-try-again)”) in new stack
[2021-10-12 21:52:40] VERBOSE[16771][C-00000039] file.c: <SIP/uco_p1-00000054> Playing ‘no-valid-responce-pls-try-again.ulaw’ (language ‘it’)
[2021-10-12 21:52:44] VERBOSE[16771][C-00000039] pbx.c: Executing [s@ivr-4:11] WaitExten(“SIP/uco_p1-00000054”, “10,”) in new stack
[2021-10-12 21:52:48] VERBOSE[16771][C-00000039] pbx.c: Spawn extension (ivr-4, s, 11) exited non-zero on ‘SIP/uco_p1-00000054’
[2021-10-12 21:52:48] VERBOSE[16771][C-00000039] pbx.c: Executing [h@ivr-4:1] Hangup(“SIP/uco_p1-00000054”, “”) in new stack
[2021-10-12 21:52:48] VERBOSE[16771][C-00000039] pbx.c: Spawn extension (ivr-4, h, 1) exited non-zero on ‘SIP/uco_p1-00000054’
[2021-10-12 21:52:48] VERBOSE[16771][C-00000039] app_stack.c: SIP/uco_p1-00000054 Internal Gosub(crm-hangup,s,1) start
[2021-10-12 21:52:48] VERBOSE[16771][C-00000039] pbx.c: Executing [s@crm-hangup:1] NoOp(“SIP/uco_p1-00000054”, “Sending Hangup to CRM”) in new stack
[2021-10-12 21:52:48] VERBOSE[16771][C-00000039] pbx.c: Executing [s@crm-hangup:2] NoOp(“SIP/uco_p1-00000054”, “HANGUP CAUSE: 16”) in new stack
[2021-10-12 21:52:48] VERBOSE[16771][C-00000039] pbx.c: Executing [s@crm-hangup:3] ExecIf(“SIP/uco_p1-00000054”, “0?Set(__CRM_VOICEMAIL=)”) in new stack
[2021-10-12 21:52:48] VERBOSE[16771][C-00000039] pbx.c: Executing [s@crm-hangup:4] NoOp(“SIP/uco_p1-00000054”, “MASTER CHANNEL: 1634068335.84 = 1634068335.84”) in new stack
[2021-10-12 21:52:48] VERBOSE[16771][C-00000039] pbx.c: Executing [s@crm-hangup:5] GotoIf(“SIP/uco_p1-00000054”, “0?return”) in new stack
[2021-10-12 21:52:48] VERBOSE[16771][C-00000039] pbx.c: Executing [s@crm-hangup:6] Set(“SIP/uco_p1-00000054”, “__CRM_HANGUP=1”) in new stack
[2021-10-12 21:52:48] VERBOSE[16771][C-00000039] pbx.c: Executing [s@crm-hangup:7] AGI(“SIP/uco_p1-00000054”, “agi://127.0.0.1/sangomacrm.agi”) in new stack
[2021-10-12 21:52:48] VERBOSE[16771][C-00000039] res_agi.c: <SIP/uco_p1-00000054>AGI Script agi://127.0.0.1/sangomacrm.agi completed, returning 0
[2021-10-12 21:52:48] VERBOSE[16771][C-00000039] pbx.c: Executing [s@crm-hangup:8] Return(“SIP/uco_p1-00000054”, “”) in new stack
[2021-10-12 21:52:48] VERBOSE[16771][C-00000039] app_stack.c: Spawn extension (ivr-4, h, 1) exited non-zero on ‘SIP/uco_p1-00000054’
[2021-10-12 21:52:48] VERBOSE[16771][C-00000039] app_stack.c: SIP/uco_p1-00000054 Internal Gosub(crm-hangup,s,1) complete GOSUB_RETVAL=

ccentrale · October 12, 2021, 8:02pm

Total Duration “00:32” visible in the “CDR Reports”

But I close the call afte 2 sec. from the Answer received by the IVR with the Announcement configured.

dicko · October 12, 2021, 8:39pm

Please use pastebin.

That call shows your PBX answering, playing the greeting but not getting a response, total time about 32 seconds. I don’t understand

. . . But I close the call afte 2 sec. from the Answer received by the IVR with the Announcement configured. . . .

Stewart1 · October 12, 2021, 8:56pm

Assuming that the Patton and FreePBX are on the same LAN subnet:
In Asterisk SIP settings, confirm that External Address and Local Networks are correctly set.
If you change these, after Submit and Apply Config, you must restart Asterisk.
Also, confirm that no NAT-related settings are enabled on the Patton.

Otherwise, or if you still have trouble, please provide details.

ccentrale · October 12, 2021, 9:01pm

Hi Dicko,
here the link requested: https://pastebin.freepbx.org/view/6cad4125

If you notice the call start at “21:52:15 - Italy Time” d finished at “21(09:52:15 PM) an:52:48”. In total “00:33” sec.

But in fact (in the reality) I ended the call in the same time I received the first second of the playing greeting. The call continued alone in the System for other 30 sec.

In a “Queue” condition, for example, If I abandon the call but the System hang up it after more 30 sec…the risk is that SLA (Service Level Agreement) based on Waiting Time will be totally wrong.

I’m sorry for my little English and I want to say thanks for your patient and for supporting me in this strange case.

Grazie

dicko · October 12, 2021, 9:04pm

I suggest your problem is probably with your Patton not honoring your hangup request, perhaps take this to them.

Stewart1 · October 12, 2021, 9:07pm

The PBX is not seeing a BYE from the Patton, presumably because of a configuration at one end or the other.

At the Asterisk command prompt, type
sip set debug on
make another call in and paste another log.

`

ccentrale · October 12, 2021, 9:36pm

Hi Stewart1,
here is the URL: https://pastebin.freepbx.org/view/88757e6e

The Caller is: 3408004705
The Number Called is: 645775926 (The is configured an IVR Service with a simple test announcement).

Naturally I closed the call immediately after the answer but the call in the system continues for other 30 sec. +/-

Other Numbes that you see in the trace like 200, 201, 2xx are SIP ext. that are connected in LAN. Not involved by the test.

Grazie Mille

dicko · October 12, 2021, 9:43pm

You say

Naturally I closed the call immediately after the answer but the call in the system continues for other 30 sec. +/-

But the Patton didn’t “close the call” , take that to Patton.

ccentrale · October 12, 2021, 9:55pm

Hi Dicko,
yes…you are right but I tested also the following situation where the Hang Up is correctly managed by Patton.

Scenario:

If i set an “Extension” as destination in the “Inbound Routes”;
place the call to the ISDN number and the exten. start to ring (but I don’t answer);
I hang up the call, the same is correctly closed (I see with “core show channels”). It doesn’t remain active in background for more 30 sec. as the others scenario

This is the reason why I suspect in somethings different.
Grazie

dicko · October 12, 2021, 10:50pm

Calls to extensions are ‘answered’ , calls to IVR’s not necessarily. Check with Patton about their ‘far end disconnect’ handling .

Stewart1 · October 12, 2021, 11:34pm

In the SIP protocol, abandoning a call not yet established is done with a CANCEL request. Ending a call in progress is done with a BYE request. The rules for sending these are somewhat different.

With default settings, FreePBX ‘answers’ the call before playing an IVR announcement (and it did in your log), but does not answer a call routed to an extension until the extension is picked up. So the equivalent test would be to answer the ringing extension, wait one or two seconds, then hang up the calling mobile. If things were working properly, the answered extension should immediately show the disconnect. My bet is that it won’t.

I looked at your log fairly carefully and believe that on line 153:
Contact: <sip:[email protected]:5060>
Asterisk correctly told the Patton where to send BYE, but the Patton never sent one.

Most likely, the Patton is misconfigured and is not passing the disconnect from the carrier to Asterisk. Conceivably, the carrier is not sending the disconnect properly.
I don’t know the details, but the logging features in the Patton should allow you to see what is going wrong, or whether it is receiving the disconnect from the carrier at all.

ccentrale · October 13, 2021, 6:24am

Hi Stewart1, Dicko,
in the Patton configuration I inserted the command “early-disconnect” and the problem seems to be resolved. Now, If I close the call immediately also FreePBX do the same. For your information I put here the Interface Configuration in the Patton:

interface sip IF_SIP
bind context sip-gateway GW_SIP
route call dest-service SRV_HG
remote 10.139.156.115 5060
early-disconnect
use profile tone-set IT
trust remote

I hope I have solved it completely and I appreciate a lot your support.

Grazie a tutti.

system · November 13, 2021, 6:24am

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