[Home]

Summary:ASTERISK-26448: Channels in Ringing state after PickUpChan of a local channel
Reporter:nappsoft (nappsoft)Labels:
Date Opened:2016-10-07 08:10:38Date Closed:2016-11-03 06:59:48
Priority:MinorRegression?
Status:Closed/CompleteComponents:Applications/app_directed_pickup Core/PBX
Versions:13.11.2 Frequency of
Occurrence
Constant
Related
Issues:
is related toASTERISK-26549 app_dial: When PickupChan() is used some channels may have incorrect device state
Environment:Attachments:( 0) ast_dbug.pcap
( 1) asterisk_debug.txt
Description:When Dialing multiple channels with the Dial application and picking up a local channel the other channels (PJSIP) stay in Ringing state until the call ends.

When trying to hangup one of the stuck channels the following happens:

asterisk> channel request hangup PJSIP/UT123-00000248
PJSIP/UT123-00000248 is not a known channel

However the channel will still be listed with "core show channels concise":

PJSIP/UT123-00000248!default!0xxxxxxx!1!Ringing!AppDial!(Outgoing Line)!0xxxxxxxx!pZNRJ5r8X4dU!pZNRJ5r8X4dU!3!48!!LumiMagic-1475843690.10390

In fact the phone stops ringing after the local channel has been picked up but the problem here is that the hint doesn't change back to idle until the call finishes, so we have wrong extension states.

Some details:

- incoming channel is a pjsip channel
- the call is ringing on several pjsip channels and one local channel (the function of this channel is to send a message to mobile extensions which can in turn pickup the call)
- the call is being picked up with a pjsip channel
Comments:By: Asterisk Team (asteriskteam) 2016-10-07 08:10:39.629-0500

Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution.

A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report.

Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process].

By: Rusty Newton (rnewton) 2016-10-07 17:40:09.072-0500

Thank you for taking the time to report this bug and helping to make Asterisk better. Unfortunately, we cannot work on this bug because your description did not include enough information. Please read over the Asterisk Issue Guidelines [1] which discusses the information necessary for your issue to be resolved and the format that information needs to be in. We would be grateful if you would then provide a more complete description of the problem. At a minimum, we need:

1. The specific steps or actions you took that caused you to encounter the problem.
2. The behavior you expected and the location of documentation that led you to that expectation.
3. The behavior you actually encountered.

To demonstrate the issue in detail, please include Asterisk log files generated per the instructions on the wiki [2]. If applicable, please ensure that protocol-level trace debugging is enabled, e.g., 'sip set debug on' if the issue involves chan_sip, and configuration information such as dialplan and channel configuration.

Thanks!

[1] https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines

[2] https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information



By: nappsoft (nappsoft) 2016-10-08 01:59:30.641-0500

Thanks for the guidelines, I might have time to describe next year again what I've already described in the initial report.

By: nappsoft (nappsoft) 2016-10-14 05:11:29.003-0500

As you can see in the attached scenario (verbose console output and pcap file) it does not have anything to do with picking up a local channel, it also happens when picking up a PJSIP channel.

So here the scenario:

- incoming call
- Dial with several extensions: Dial("PJSIP/A1020srvID2-000003d0", "PJSIP/snom/sip:snom@10.10.10.2:40477&PJSIP/UT123/sip:UT123@10.10.10.3:5060,25,tkwL(86400000:120000:30000)b(predial^headers^1(<sip:0445405045@94.230.216.119>;reason=unconditional^LumiMagic-1476438795.16151^0445405045^0))")
- pickup the call from a different channel with PickupChan: AGI Script Executing Application: (PickupChan) Options: (PJSIP/snom-000003d1)

=> the pickup works and as you can see in the pcap file the two SIP sessions to  UT123 and snom are immediately Cancelled. So on the SIP layer everything works as expected. While asterisk cleans up the picked up channel (PJSIP/snom-000003d1) as well, the other one (PJSIP/UT123-000003d2) gets stuck somehow. (It is still listed as ringing with core show channels and the hint of the extension stays in the wrong state as well). Output of core show channels: PJSIP/UT123-000003d2 0445405045@default:1 Ringing AppDial((Outgoing Line))

Concerning the guidelines: I can't show you exactly the place in the documentation where the behavior that I expect is described but as we all know the behavior here is not as expected and is not how asterisk used to work in the past.

One sidenode: when not using PickupChan but picking up the call by one of the ringing phones all other channels will be closed as expected. So it does nothing have to do with the Dial command with several PJSIP extensions, but with the fact that I use PickupChan in this example.

The behavior can be reproduced in 100% of cases. The only workaround I've found so far is to do a "channel request hangup" on all other channels before using the PickupChan command.

By: nappsoft (nappsoft) 2016-11-03 06:49:24.631-0500

Why has there been created a duplicate of this issue? => ASTERISK-26549

I can confirm that Change-Id: Iea7168e6e82f7d4609ec0366153804e4f55ea64f fixed this issue as well, so the issue can be closed

By: Joshua C. Colp (jcolp) 2016-11-03 06:59:48.167-0500

Sorry, did not know this issue existed. Linked and closed out!