How to avoid caller hangup when callee busy over ARI

Asterisk Asterisk APIs
1

Hello.

Asterisk 16.6.1 (same in other versions.)
ARI

I wrote the Python code with reference to the “early bridging”.
(https://blogs.asterisk.org/2016/08/24/asterisk-14-ari-create-bridge-dial/
By Joshua C. Colp)

Check the dialstatus on out_channel.on_event(‘Dial’,).

I need that the callee busy status will don’t hang up on caller as in the answer status.

Could someone help me?
Thank you!

Below is the test result.
1. When dialstatus==“ANSWER” of 300(callee),
Even if the 300(callee) hangs up, the 100(caller) remains connected.

  1. Dial from 100(caller) to 300(callee).
  2. Answer 300(callee).
  3. Hangup 300(callee).
  4. Now 100(caller) stay connected until 100(caller) hangs up.

2. But dialstatus==“BUSY” of 300(callee),
After the busy tone is heard, the 100(caller) hangs up.

  1. Dial from 100(caller) to 300(callee).
  2. Busy 300(callee).
  3. Listen busy tone.
  4. And 100(caller) hangs up by asterisk. >>>> I want to stay connected(don’t hang up on 100(caller)).
2

Have you determined whether it is actually Asterisk hanging up on the caller? What events do you receive? Or do you mean how do you modify the code?

3

Yes, it is actually Asterisk hanging up on the caller.

Because, the following events occur.
Set on event

  1. in_channel.on_event(‘ChannelHangupRequest’, self.on_hangup)
  2. out_channel.on_event(‘StasisEnd’, self.oo_stop)
  3. out_channel.on_event(‘Dial’, self.oo_dial)
    this Dial event print dialstatus only, nothing else.

Run this command
1)out_channel.dial(caller=in_channel.id)

Then the following events occur in order when callee busy.
And caller heard busy tone and off-hook tone.

<SIP/100-00000019> 5.Add the channels to the bridge.
stasis_start_cb
<SIP/100-00000019> 7.Now the dialing begin.

Dial event: self.oo_dial()
dialstatus =

Dial event: self.oo_dial()
dialstatus = [RINGING]

Dial event: self.oo_dial()
dialstatus = [BUSY]

stasis_end_cb
<SIP/100-00000019> on_hangup

stasis_end_cb
<SIP/300-00000019> oo_stop

localhostCLI>
== Using SIP RTP CoS mark 5
localhostCLI>
– Channel SIP/100-0000001d joined ‘holding_bridge’ stasis-bridge <8caff83f-66aa-42bf-92e1-7f4721bf2589>
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [SIP/100-0000001d]
– Channel SIP/100-0000001d left ‘holding_bridge’ stasis-bridge <8caff83f-66aa-42bf-92e1-7f4721bf2589>
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [SIP/100-0000001d]
– Channel SIP/100-0000001d joined ‘simple_bridge’ stasis-bridge <1f270170-1440-41f2-b0d0-635c11114cc9>
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [SIP/100-0000001d]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [SIP/100-0000001d]
– Channel SIP/300-0000001e joined ‘simple_bridge’ stasis-bridge <1f270170-1440-41f2-b0d0-635c11114cc9>
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [SIP/300-0000001e]
– Got SIP response 486 “Busy Here” back from 192.168.0.137:14550
<< [ TYPE: Control (4) SUBCLASS: Unknown control ‘33’ (33) ] [SIP/300-0000001e]
<< [ TYPE: Control (4) SUBCLASS: Busy (5) ] [SIP/300-0000001e]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [SIP/100-0000001d]
<< [ HANGUP (NULL) ] [SIP/100-0000001d]
– Channel SIP/100-0000001d left ‘simple_bridge’ stasis-bridge <1f270170-1440-41f2-b0d0-635c11114cc9>
– Channel SIP/300-0000001e left ‘simple_bridge’ stasis-bridge <1f270170-1440-41f2-b0d0-635c11114cc9>
– Channel SIP/300-0000001e joined ‘holding_bridge’ stasis-bridge <11aab1b8-5328-40d8-b707-92d0111bc1a3>
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [SIP/300-0000001e]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [SIP/300-0000001e]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [SIP/300-0000001e]
<< [ HANGUP (NULL) ] [SIP/300-0000001e]
– Channel SIP/300-0000001e left ‘holding_bridge’ stasis-bridge <11aab1b8-5328-40d8-b707-92d0111bc1a3>
localhost*CLI>

4

I found the reason.
Run in_channel.answer() before dialing.
Then caller heard busy tone and stay connected.

But there is a problem.
I want to send an answer on the caller only when the callee answered.
If the call is busy, it should not be charged.

What should I do?

5

I don’t think the API using /create, /dial, and bridging will meet your requirements or needs. The normal originate route would be the only other mechanism I can think of.

6

Thank you so much for quick reply!

Early bridge was considered because of the ring-back tone or early media(sounds).
It cannot be solved with the regular originate operation.

I am troubled.
There seems to be no solution at this time.

7

I think this issue must update in new asterisk ARI.
We are outbound call business.
Our Client want to listen CRBT(Color Ring back tone) of callee.
But We can’t use ARI if ARI’s /dial can’t support control inbound call without “Answer” signal.
We want redirect new callee if old callee is “busy”.
We will send “Answer” signal to caller if callee answer the call.
Please check update this issue.

8

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