Hangup not propagating to caller

Hi, I am quite new to the world of VoIP and FreePBX so forgive me if my understanding of some topics is a bit lacking. My objective was to set up FreePBX such that it would dynamically route incoming calls under a new CallerId to a new destination. I achieved this with the following setup:

Inbound Route (Catch all)->Dynamic Route (Requests API with CallerId and Destination to retrieve new CallerId and new Destination)->Dynamic Route (Sets new CallerId and new Destination as Asterisk variables by using the API response from previous Dynamic Route)->Set CallerId (Sets CallerId to the value of the New CallerId variable)->Custom Destination (from-internal,${NewDID},1)->Outbound Route

This works and the calls get through but a problem arises when the callee terminates the call without accepting it. The hangup response is sent to FreePBX and it’s as if part of the call terminates but the inbound part doesn’t get the message. The caller does get the message “The number is not answering” but after that a quick beeping tone continues and after a while the call just starts again if the caller hasn’t hung up himself. I also noticed that the redial problem goes away if I force accept the call on the inbound route but there is still a pretty long delay (15-20 seconds) between the callee hanging up and the caller getting the message. I don’t really like the idea of instantly accepting every call either.

Any help pointing me in the right direction is much appreciated.

I am using FreePBX V16.0.40.11

Which channel technology is the inbound side using? (E.g. DAHDI/Analogue, DAHDI/ISDN, SIP/chan_SIP, SIP/chan_PJSIP, etc.)

Which channel technology is the outbound side using?

What does terminates the call without accepting mean in terms of the signalling received? “Terminates” in telephony generally means answer, so think you either mean rejects, or answers then immediately hangs up.

Please provide the Asterisk full log, with enough verbosity to show dialplan execution, and with the appropriate command issued, to show the channel protocol exchanges. This depends on the channel technology. The preferred way of doing this is to upload it to a pastebin server, and post the URL, or the final component of the URL.

Also, how is the call arriving at your site (Analogue, ISDN, SIP) and how was it originated?

Hi David, thanks for taking an interest.

I am using a PJSIP trunk which routes through an SBC to a SIP trunk provider. The same trunk is used for both directions. Yeah, sorry about the unclear terminology. I meant “the callee rejects without answering”.

I added the asterisk logs to pastebin under the address: t442LcEx. In this example the call went like this:

+37256277002->+37259999912->(new callerid)+37255611771->(new destination)+37253685425

I turned “Force accept” option on the inbound route off for this one. The callee didn’t reject the call directly but let it ring out. As you can see the call started making progress twice and the callee got two calls. The second time the call ended for good.

I also saved PJSIP logs for this call, they are under the pastebin address: i97rTtRU.

For context - the freepbx ip is 10.1.6.4 and the sbc ip is 10.1.3.4.

You haven’t enabled pjsip protocol logging, and you seem to have screen scraped, so there are no time stamps, but it seems to me as though you have two different incoming calls, so I think your problem is upstream of Asterisk:

1. == Spawn extension (macro-hangupcall, s, 6) exited non-zero on 'PJSIP/LibreSBC-0000009b' in macro 'hangupcall'

2. == Spawn extension (from-internal, h, 1) exited non-zero on 'PJSIP/LibreSBC-0000009b'

3. -- Executing [+37259999912@from-pstn:1] NoOp("PJSIP/LibreSBC-0000009d", "Catch-All DID Match - Found +37259999912 - You probably want a DID for this.") in new stack

4. -- Executing [+37259999912@from-pstn:2] Set("PJSIP/LibreSBC-0000009d", "__FROM_DID=+37259999912") in new stack

This is the transition. The first call is …009b, and the second call is …009d.

Also note that you are allowing anonymous calls, which is not, normally, a good thing. It was sometimes necessary on chan_sip, but chan_pjsip avoids the main reason.

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