ASTERISK-13162: [patch] DAHDI group dials/members broken with AddQueueMember / queue member add

[Home]

Summary: ASTERISK-13162: [patch] DAHDI group dials/members broken with AddQueueMember / queue member add

Reporter: Matt King, M.A. Oxon. (kebl0155) Labels:

Date Opened: 2008-12-03 09:44:36.000-0600 Date Closed: 2009-07-27 14:26:08

Priority: Major Regression? No

Status: Closed/Complete Components: Applications/app_queue

Versions: Frequency of
Occurrence

Related
Issues:

Environment: Attachments: ( 0) 14014_number2.patch
( 1) 14014.patch

Description: We have Queues, and we dial the agent's phones directly over ZAP (now DAHDI). The agents are dynamic, and we used to add and remove them to/from the queue using:

add queue member ZAP/r2/0008 to CustServ

Having upgraded to DAHDI and Asterisk 1.6.0.1, we now use:

add queue member DAHDI/r2/0008 to CustServ

This does add the member to the queue, but after a single call is placed to the agent, the agent becomes invalid and cannot receive further calls.

Furthermore, the member cannot be removed from the queue without restart.

****** ADDITIONAL INFORMATION ******

I'm posting this after having called tech support and asked on the #asterisk channels. I did look for a dupe bug but couldn't find one. It is possible that this is a DAHDI bug rather than a Queue bug, so apologies if I'm posting this in the wrong place.

When we initially add the member (before any calls), 'queue show CustServ' gives:

CustServ has 0 calls (max unlimited) in 'ringall' strategy (0s holdtime), W:0, C:0, A:0, SL:0.0% within 0s
Members:
DAHDI/r2/0008 (dynamic) (Unknown) has taken no calls yet
No Callers

This is normal. When a call is placed to the queue, the first delivered call causes the phone to ring, and gives the following message in the log:

-- Called DAHDI/r2/0008

This is also normal. However, if this call is not answered, the next (and subsequent) attempts will give:

-- Called DAHDI/r2

This is not normal (it's missing the 0008). The agent's phone does not ring, and the call fails.

If you then try a 'queue show CustServ', the output has changed to

CustServ has 0 calls (max unlimited) in 'ringall' strategy (0s holdtime), W:0, C:0, A:0, SL:0.0% within 0s
Members:
DAHDI/r2/0008 (DAHDI/r2) (dynamic) (Invalid) has taken no calls yet

You also cannot remove the queue member.

*CLI> queue remove member DAHDI/r2/0008 from CustServ
Unable to remove interface 'DAHDI/r2/0008' from queue 'CustServ': Not there
Command 'queue remove member DAHDI/r2/0008 from CustServ' failed.

*CLI> queue remove member DAHDI/r2 from CustServ
Unable to remove interface 'DAHDI/r2' from queue 'CustServ': Not there
Command 'queue remove member DAHDI/r2 from CustServ ' failed.

Asterisk has to be restarted.

I'm working around this using local channels for the time being, but this does seem broken. I haven't been able to reproduce this fault using SIP channels, and the rest of DAHDI is working fine - it just seems to be (DAHDI && Queue) that is affected.

Comments: By: Leif Madsen (lmadsen) 2008-12-17 10:04:55.000-0600

Does this happen with other types of channels as well? Does this only happen when you use the format Tech/Group/Exten?

I wonder if this has something to do with parsing with this type of format? (just a personal guess.)
By: Mark Michelson (mmichelson) 2008-12-17 10:18:07.000-0600

A cursory look makes me think that this entire problem is in app_queue, and is not specific to DAHDI channels. I think I know where the problem is and I'll have a patch written shortly.
By: Matt King, M.A. Oxon. (kebl0155) 2008-12-17 10:59:42.000-0600

We don't see this problem with other channel types.

I'm afraid I'm not able to test the function without groups as this is a production system - sorry!
By: Mark Michelson (mmichelson) 2008-12-17 11:20:09.000-0600

I've uploaded two patches to the issue.

The first patch, 14014.patch contains a fix that will prevent the name of the interface from changing from "DAHDI/r2/0008" to just "DAHDI/r2." That much is certain. Because I'm not 100% sure of the method by which device state reporting is done in chan_dahdi, I also am placing a second patch, 14014_number2.patch, here as well, which should handle the reporting in case 14014.patch is not enough.

In answer to blitzrage's initial question, this would be a problem which would effect any interface with multiple '/' characters in it, such as a DAHDI channel which specified a group and extension. The code in question appears to be there to deal with Local channels that have a /n on the end of them, so that the /n is stripped from the string when comparing to the interface provided.

So in summary, I suggest trying 14014.patch first, and if the problem is not completely solved, then try using 14014_number2.patch.
By: Leif Madsen (lmadsen) 2008-12-17 11:34:29.000-0600

Aha! That makes sense (and sounds like I was somewhat on the right track in my thinking).

Hopefully we can get a test on this shortly and get this issue closed out. Thanks putnopvut!
By: Leif Madsen (lmadsen) 2008-12-22 11:07:30.000-0600

We're looking for a test and feedback on this issue from the original reporter.

kebl0155: were you able to test this yet?
By: Matt King, M.A. Oxon. (kebl0155) 2008-12-22 11:09:31.000-0600

Hi there, I'll see if I can get this tested while they're closed over the Christmas period...
By: Amilcar S Silvestre (amilcar) 2008-12-28 19:42:28.000-0600

Seems that ASTERISK-13166 is exactly the same case, duplicating this.

By: Mark Michelson (mmichelson) 2009-01-13 13:38:24.000-0600

I was just wondering whether this issue is still occurring. Furthermore, if it is not, which of the two patches should be merged in?
By: Mark Michelson (mmichelson) 2009-01-15 16:18:59.000-0600

After taking a look through the device state code more closely, I'm reasonably confident that the second patch is what is necessary to fix this issue. If I don't hear back about this by tomorrow, then I'm just going to get this fix committed since the code is hurting by not having this change in.
By: Leif Madsen (lmadsen) 2009-01-20 13:51:34.000-0600

Is it tomorrow yet?! :)
By: Mark Michelson (mmichelson) 2009-01-20 15:31:08.000-0600

blitzrage: oops! I'll go ahead and commit the number2 patch.
By: Matt King, M.A. Oxon. (kebl0155) 2009-01-20 18:12:15.000-0600

Hi there, sorry it's taken so long to get back to you on this - I've been off sick.

I can confirm that the second patch has resolved this issue.
By: Digium Subversion (svnbot) 2009-01-20 18:33:28.000-0600

Repository: asterisk
Revision: 169611

U trunk/apps/app_queue.c

------------------------------------------------------------------------
r169611 | mmichelson | 2009-01-20 18:33:28 -0600 (Tue, 20 Jan 2009) | 22 lines

Fix device state parsing issues for channel names with multiple slashes

The fix being applied is a bit different for trunk and the 1.6.X branches.
For trunk, we only wish to strip off the characters beyond the second slash
if the channel is a Local channel (i.e. we are removing the /n from the device
name). Other channel technologies with multiple slashes (e.g. DAHDI) need the
information after the second slash in order to get the proper device state
information.

In addition to this fix, the 1.6.X branches are receiving a much more important
fix as well. The problem in 1.6.X is that the member's device name was being directly
changed instead of having a copy changed. This meant that we would strip off the
second slash and trailing characters and then leave the member's device name like
that permanently thereafter.

(closes issue ASTERISK-13162)
Reported by: kebl0155
Patches:
14014_number2.patch uploaded by putnopvut (license 60)
Tested by: kebl0155

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=169611
By: Digium Subversion (svnbot) 2009-01-20 18:34:49.000-0600

Repository: asterisk
Revision: 169612

_U branches/1.6.0/
U branches/1.6.0/apps/app_queue.c

------------------------------------------------------------------------
r169612 | mmichelson | 2009-01-20 18:34:48 -0600 (Tue, 20 Jan 2009) | 30 lines

Merged revisions 169611 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

........
r169611 | mmichelson | 2009-01-20 18:33:32 -0600 (Tue, 20 Jan 2009) | 22 lines

Fix device state parsing issues for channel names with multiple slashes

The fix being applied is a bit different for trunk and the 1.6.X branches.
For trunk, we only wish to strip off the characters beyond the second slash
if the channel is a Local channel (i.e. we are removing the /n from the device
name). Other channel technologies with multiple slashes (e.g. DAHDI) need the
information after the second slash in order to get the proper device state
information.

In addition to this fix, the 1.6.X branches are receiving a much more important
fix as well. The problem in 1.6.X is that the member's device name was being directly
changed instead of having a copy changed. This meant that we would strip off the
second slash and trailing characters and then leave the member's device name like
that permanently thereafter.

(closes issue ASTERISK-13162)
Reported by: kebl0155
Patches:
14014_number2.patch uploaded by putnopvut (license 60)
Tested by: kebl0155

........

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=169612
By: Digium Subversion (svnbot) 2009-01-20 18:35:27.000-0600

Repository: asterisk
Revision: 169613

_U branches/1.6.1/
U branches/1.6.1/apps/app_queue.c

------------------------------------------------------------------------
r169613 | mmichelson | 2009-01-20 18:35:27 -0600 (Tue, 20 Jan 2009) | 30 lines

Merged revisions 169611 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

........
r169611 | mmichelson | 2009-01-20 18:33:32 -0600 (Tue, 20 Jan 2009) | 22 lines

Fix device state parsing issues for channel names with multiple slashes

The fix being applied is a bit different for trunk and the 1.6.X branches.
For trunk, we only wish to strip off the characters beyond the second slash
if the channel is a Local channel (i.e. we are removing the /n from the device
name). Other channel technologies with multiple slashes (e.g. DAHDI) need the
information after the second slash in order to get the proper device state
information.

In addition to this fix, the 1.6.X branches are receiving a much more important
fix as well. The problem in 1.6.X is that the member's device name was being directly
changed instead of having a copy changed. This meant that we would strip off the
second slash and trailing characters and then leave the member's device name like
that permanently thereafter.

(closes issue ASTERISK-13162)
Reported by: kebl0155
Patches:
14014_number2.patch uploaded by putnopvut (license 60)
Tested by: kebl0155

........

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=169613