[Home]

Summary:ASTERISK-22720: devstate incorrectly cached on transfer of a DAHDI to SIP call.
Reporter:Tzafrir Cohen (tzafrir)Labels:
Date Opened:2013-10-16 10:10:03Date Closed:2013-10-20 12:54:36
Priority:MinorRegression?Yes
Status:Closed/CompleteComponents:Channels/chan_dahdi
Versions:1.8.23.1 11.5.1 Frequency of
Occurrence
Related
Issues:
duplicatesASTERISK-22718 Devstate caching mangled after local channel optimization
Environment:Attachments:( 0) dahdi-devstate-cachbility-workaround.patch
Description:To reproduce:

Setup: A DAHDI extension that can call to a SIP extension and to at least any other exteension (may be anything).

To reproduce:

1. Run 'event dump cache DeviceState' to see DAHDI device is not there.

2. From the DAHDI extension dial to the SIP extension.

3. In the DAHDI extension press flash for an attended transfer.

4. Dial the other extension number and hang up.

5. In the CLI, run 'event dump cache DeviceState'. You'll see the DADHI device listed as 2 (in use).

Expected results: in stage 5, the state of the DAHDI device should not have appeared in the cache, or listed as "unknown".

See also the similar ASTERISK-22718

A workaround patch is attached, to forcefully disable caching of DAHDI devices.

Marked as regression as it has worked OK up until 1.8.19. Broken in 1.8.20.
Comments:By: Rusty Newton (rnewton) 2013-10-18 18:34:48.756-0500

Thanks Tzafrir!

By: Richard Mudgett (rmudgett) 2013-10-18 18:49:29.097-0500

@Tzafrir
Could you retest on the latest SVN version now that ASTERISK-22718 is committed to see if that actually fixed the problem.

By: Tzafrir Cohen (tzafrir) 2013-10-20 12:51:30.025-0500

Upgraded to r401182 and issue seem to be resolved (probably due to r401179.

As an a side note: while I'm at it: I noticed the following warning in that scenario, just as I'm hanging up the original phone. I don't remember seeing it earlier, but maybe I just don't remember it.

[Oct 20 19:46:45] WARNING[12940][C-00000004]: chan_dahdi.c:3865 _dahdi_get_index: Unable to get index for 'DAHDI/45-2' on channel 45 (dahdi_indicate(), line 9676)

   -- Starting simple switch on 'DAHDI/45-1'
   -- Executing [501@from-internal:1] Answer("DAHDI/45-1", "") in new stack
   -- Executing [501@from-internal:2] Dial("DAHDI/45-1", "SIP/501") in new stack
 == Using SIP RTP CoS mark 5
   -- Called SIP/501
   -- SIP/501-00000002 is ringing
   -- SIP/501-00000002 answered DAHDI/45-1
   -- Started three way call on channel 45
   -- Starting simple switch on 'DAHDI/45-2'
   -- Started music on hold, class 'default', on SIP/501-00000002
   -- Executing [441@from-internal:1] Answer("DAHDI/45-2", "") in new stack
   -- Executing [441@from-internal:2] Set("DAHDI/45-2", "phone=DAHDI/41") in new stack
   -- Executing [441@from-internal:3] NoOp("DAHDI/45-2", "State for DAHDI/41 is UNKNOWN") in new stack
   -- Executing [441@from-internal:4] Dial("DAHDI/45-2", "DAHDI/41") in new stack
   -- Called DAHDI/41
   -- DAHDI/41-1 is ringing
   -- DAHDI/41-1 is ringing
   -- DAHDI/41-1 answered DAHDI/45-2
   -- TRANSFERRING DAHDI/45-1 to DAHDI/45-2
[Oct 20 19:46:45] WARNING[12940][C-00000004]: chan_dahdi.c:3865 _dahdi_get_index: Unable to get index for 'DAHDI/45-2' on channel 45 (dahdi_indicate(), line 9676)
   -- Stopped music on hold on SIP/501-00000002
   -- Hanging up on 'DAHDI/45-2<ZOMBIE>'
   -- Hungup 'DAHDI/45-2<ZOMBIE>'
 == Spawn extension (from-internal, 501, 2) exited non-zero on 'DAHDI/45-1'
   -- Hanging up on 'DAHDI/45-1'
   -- Hungup 'DAHDI/45-1'
   -- Hanging up on 'DAHDI/41-1'
   -- Hungup 'DAHDI/41-1'
 == Spawn extension (from-internal, 441, 4) exited non-zero on 'SIP/501-00000002'

By: Tzafrir Cohen (tzafrir) 2013-10-20 12:53:54.647-0500

Fixed