[asterisk-bugs] [JIRA] (ASTERISK-28802) ari: /dial function disconnect Inbound call automatically if Outbound is "busy" or "discard" in case delay "Answer" message.

[Lee Yun Seok (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-28802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=250527#comment-250527 ] 

Lee Yun Seok edited comment on ASTERISK-28802 at 4/23/20 9:12 PM:
------------------------------------------------------------------

Attached the files.
Please read "ReadMe.txt" first.


was (Author: abcd0950):
Please read "ReadMe.txt" first.

> ari: /dial function disconnect Inbound call automatically if Outbound is "busy" or "discard"  in case delay "Answer" message.
> -----------------------------------------------------------------------------------------------------------------------------
>
>                 Key: ASTERISK-28802
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-28802
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Resources/res_ari_bridges, Resources/res_ari_channels
>    Affects Versions: 16.6.0
>         Environment: asterisk 16
>            Reporter: Lee Yun Seok
>            Assignee: Unassigned
>            Severity: Minor
>         Attachments: CLI.log, dial-early.py, ReadMe.txt
>
>
> We use ARI /dial function to connect outbound in Bridge.
> We don't send "Answer" message until outbound answer.
> ARI /dial function disconnect Inbound call automatically if Outbound is "busy" or "discard" 
> In case we don't send "Answer" message.
> But ARI /dial function don't disconnect Inbound call if outbound is "busy" or "discard". 
> In casessage first. we send "Answer" me
> We must use delay send "Answer" message until outbound answer call because of "Billing Issue"(We can't bill Inbound user in case outbound don't answer call) 
> ARI /originate function don't disconnect Inbound call if outbound is "busy" or "discard". 
> Even if In case we don't send "Answer" message.
> We think "/ originate" and "/ dial" are same operate in case of "No Answer"
> We can't understand why the two functions operate separately.
> Please update "/ dial" function to do not disconnect Inbound call if outbound is "busy" or "discard". 
> Even if In case we don't send "Answer" message.
> Below is the test result.
> 1. When dialstatus==“ANSWER” of 300(callee),
> Even if the 300(callee) hangs up, the 100(caller) remains connected.
> Dial from 100(caller) to 300(callee).
> Answer 300(callee).
> Hangup 300(callee).
> 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.
> Dial from 100(caller) to 300(callee).
> Busy 300(callee).
> Listen busy tone.
> And 100(caller) hangs up by asterisk. >>>> I want to stay connected(don’t hang up on 100(caller)).
> in_channel.on_event(‘ChannelHangupRequest’, self.on_hangup)
> out_channel.on_event(‘StasisEnd’, self.oo_stop)
> 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>
> This is a very serious issue.
> Please check it Thanks~~~



--
This message was sent by Atlassian JIRA
(v6.2#6252)