Summary:ASTERISK-02886: [patch] SIP channel goes ZOMBIE when transfering call on IAX to MeetMe
Reporter:Ryan Courtnage (rcourtna)Labels:
Date Opened:2004-11-24 16:36:14.000-0600Date Closed:2008-01-15 15:19:41.000-0600
Versions:Frequency of
Environment:Attachments:( 0) mydiff.txt
( 1) sipxfer.diff
( 2) zombie.tar.gz
Description:I have reproduced this problem on 2 servers..

It's really pretty simple to duplicate, so long as you have a SIP client that supports attended transfer, and IAXe client, and a timer for meetme (ie: tdm400p)

A SIP channel goes ZOMBIE afer transfering a call from an IAX2 extension to a MeetMe room.

The SIP client must support attended transfers (ie: Sayson 480i, Uniden uip200):

1) Make a call from an IAX2 extension to a SIP extension
2) On the SIP phone, use locally supported attended transfer (not #) to transfer the call from IAX2 to a meetme room  
3) Execute 'show channels' at the * CLI

The SIP channel will be <ZOMBIE>:

SIP/427-e8b0  (from-internal 1)  Up Bridged Call SIP/427-4a87<ZOMBIE>
SIP/427-4a87<ZOMBIE>  (macro-dial s 1) Up Dial SIP/427


This problem is only reproducible if you use the combination of technologies I describe (SIP, IAX2, MeetMe).

Please find the following attached:

asterisk_config.txt : contains relevant bits from asterisk config

sip_zombie_1.txt : Server1 - SIP debug output on * console.  SIP client is a Uniden uip200

sip_zombie_2.txt : Server2 - SIP debug output on * console.  SIP client is a Sayson 480i

Comments:By: Brian West (bkw918) 2004-11-24 16:56:03.000-0600

This isn't a bug... thats how it works.  Do the channels go away? or do they stick around?


edited on: 11-24-04 16:57

By: Ryan Courtnage (rcourtna) 2004-11-24 17:01:26.000-0600

The channels just stick around - I guess that's the bug.

They will remain indefinitely (or until I issue a 'soft hangup' to them).

edited on: 11-24-04 18:11

By: Brian West (bkw918) 2004-11-24 18:11:46.000-0600

but they do go away when you soft hangup.. now if they dont go away when you do that we have problems.. hrm.. turn on sip history please.


By: Ryan Courtnage (rcourtna) 2004-11-24 18:14:23.000-0600

SIP history is in zombie.tar.gz, which is attached to the bugdoc.

By: Ryan Courtnage (rcourtna) 2004-11-24 18:23:13.000-0600

my bad - that's 'sip debug' output in the attachement.  I've never used sip history .. i'll give it a shot.

By: Ryan Courtnage (rcourtna) 2004-11-24 18:35:11.000-0600

ok, here it is using the Sayson 480i and the step outlined in the bugnote.

207 is the IAX2 extension
204 is SIP.
207 called 204, 204 transferred call into meetme (x8200).

Sayson's a little odd (imho) in that it uses another of it's freely available lines to complete the transfer (in this case x200).  If you feel that throws off the results, I can also get the history when using a uniden phone.


imaging*CLI> show channels
       Channel  (Context    Extension    Pri )   State Appl.         Data
  SIP/204-a8f0  (from-internal              1   )      Up Bridged Call  SIP/200-1c4d<ZOMBIE>
SIP/200-1c4d<ZOMBIE>  (macro-dial s            1   )      Up Dial          SIP/204|15|tr
2 active channel(s)

imaging*CLI> sip show channels
Peer             User/ANR    Call ID      Seq (Tx/Rx)   Format    204         4d3ae07929e  00104/1682859725   ULAW
1 active SIP channel(s)

imaging*CLI> sip show history 4d3ae07929e
 * SIP Call
1. TxReqRel        INVITE sip:204@ SIP/2.0 / 102 INVITE
2. Rx              SIP/2.0 100 Trying / 102 INVITE
3. CancelDestroy
4. Rx              SIP/2.0 180 Ringing / 102 INVITE
5. CancelDestroy
6. Rx              SIP/2.0 200 OK / 102 INVITE
7. CancelDestroy
8. TxReq           ACK sip:204@ SIP/2.0 / 102 ACK
9. Rx              INVITE sip:207@ SIP/2.0 / 1682859724 INVITE
10. CancelDestroy
11. TxRespRel       SIP/2.0 200 OK / 1682859724 INVITE
12. Rx              ACK sip:207@ SIP/2.0 / 1682859724 ACK
13. Rx              REFER sip:207@ SIP/2.0 / 1682859725 REFER
14. TxResp          SIP/2.0 202 Accepted / 1682859725 REFER
15. TxReqRel        NOTIFY sip:204@ SIP/2.0 / 103 NOTIFY
16. TxReqRel        BYE sip:204@ SIP/2.0 / 104 BYE
17. Rx              SIP/2.0 200 OK / 103 NOTIFY
18. Rx              SIP/2.0 200 OK / 104 BYE

By: Brian West (bkw918) 2004-11-24 19:06:29.000-0600

ya post the sip history of zombie channels in as many ways you can make it happen.

By: Ryan Courtnage (rcourtna) 2004-11-24 19:57:07.000-0600

On a different server (Asterisk CVS-v1-0-11/13/04), using uip200 as sip phone.

301 is IAX2
427 is SIP (uip200)
8427 is meetme

301 called 427.  427 XFERed call to meetme.  Zombies result:

Let me know if there is anything else I can provide.  Thx, again.

pbx*CLI> show channels
       Channel  (Context    Extension    Pri )   State Appl.         Data
  SIP/427-83bb  (from-internal              1   )      Up Bridged Call  SIP/427-b348<ZOMBIE>
SIP/427-b348<ZOMBIE>  (macro-dial s            1   )      Up Dial          SIP/427|15|tr
2 active channel(s)

pbx*CLI> sip show channels
Peer             User/ANR    Call ID      Seq (Tx/Rx)   Format      427         1c6641d9025  00104/501630   ULAW
1 active SIP channel(s)

pbx*CLI> sip show history 1c6641d9025
 * SIP Call
1. TxReqRel        INVITE sip:427@ SIP/2.0 / 102 INVITE
2. Rx              SIP/2.0 100 Trying / 102 INVITE
3. CancelDestroy
4. Rx              SIP/2.0 180 Ringing / 102 INVITE
5. CancelDestroy
6. Rx              SIP/2.0 200 OK / 102 INVITE
7. CancelDestroy
8. TxReq           ACK sip:427@ SIP/2.0 / 102 ACK
9. Rx              INVITE sip:301@ SIP/2.0 / 501629 INVITE
10. CancelDestroy
11. TxRespRel       SIP/2.0 200 OK / 501629 INVITE
12. Rx              ACK sip:301@ SIP/2.0 / 501629 ACK
13. Rx              REFER sip:301@ SIP/2.0 / 501630 REFER
14. TxResp          SIP/2.0 202 Accepted / 501630 REFER
15. TxReqRel        NOTIFY sip:427@ SIP/2.0 / 103 NOTIFY
16. TxReqRel        BYE sip:427@ SIP/2.0 / 104 BYE
17. Rx              SIP/2.0 200 OK / 103 NOTIFY
18. Rx              SIP/2.0 200 OK / 104 BYE

By: Ryan Courtnage (rcourtna) 2004-11-25 01:39:13.000-0600

I see in the bugnote for ASTERISK-2764 that these changes were committed to v1-0 on Nov 9.

So I installed the latest v1-0 and verified that the changes outlined in the chan_sip.c patch where there.

Unfortunately it didn't help.  The problem can still be duplicated using the steps I've outlined.


(now running Asterisk CVS-v1-0-11/24/04)

By: Ryan Courtnage (rcourtna) 2004-11-26 09:42:59.000-0600


Someone on *-users also duplicated the problem using a CISCO 7960 (+IAX, +meetme)"


I see the same

Shuttle*CLI> show channels
       Channel  (Context    Extension    Pri )   State Appl.         Data
Zap/pseudo-400601102  (from-330377 s            1   )   Rsrvd (None)  
IAX2/1111@1111/2  (office     8600         1   )      Up MeetMe        8600
 SIP/1234-e529  (office                  1   )      Up Bridged Call
SIP/1234-9ceb<ZOMBIE>  (macro-stdexten s            7   )      Up Dial
4 active channel(s)

This is with IAX and a Cisco 7960 following the same steps.

The ZOMBIE Remains......


By: ewieling (ewieling) 2004-11-26 13:24:02.000-0600

My experience with zomies involved transfering from Polycom to Polycom, using reinvites.  I think the zombies whent away when I turned off reinvites, but I can't test that now.  The office got rid of Asterisk a few weeks ago.  The zombie channels NEVER EVER go away until I restart Asterisk.  I didn't try softhangup.

By: Ryan Courtnage (rcourtna) 2004-11-26 15:01:38.000-0600

Interesting.  I can confirm that for my tests, my SIP clients have "canreinvite=no".  (SIP -> SIp works fine here, it's just when transfering and IAX call, and only when transfering it to meetme .. at least as far as I can tell)

By: Anthony Minessale (anthm) 2004-11-27 10:17:29.000-0600

Try sipxfer.diff

disclaimer on file

By: Ryan Courtnage (rcourtna) 2004-11-27 19:07:53.000-0600

sipxfer.diff _does_ correct the problem.

I've tested this patch on the latest cvs of -HEAD and -v1-0.  The patch corrects issue for each.

Will this patch make the -v1-0 branch?


By: Brian West (bkw918) 2004-11-27 19:52:29.000-0600

yes it should go 1.0 also ;P


By: Anthony Minessale (anthm) 2004-11-27 21:56:20.000-0600

<shaggy> Like...Scoob! loooks like we got the spooky zombies! </shaggy>

By: twisted (twisted) 2004-11-29 12:46:36.000-0600

I've noticed this issue on one of our customers boxes, only because they complain about calls not going through - because the zombies are each holding a g729 license, and they customer ONLY wants g729.  I'll apply this patch and report back here shortly.

By: twisted (twisted) 2004-11-29 12:47:52.000-0600

Actually, that customer's issue was solved with cvs stable from last week.  If it happens AGAIN, i'll try the patch, but for now, all is well.

By: christian (christian) 2004-12-07 13:12:24.000-0600

Follow-up from twisted's note. The ZOMBIEs reappeared while running CVS stable. I have applied the patch and will report back if the ZOMBIE/SIP/IAX2 problem persists.

edited on: 12-07-04 13:13

By: Ryan Courtnage (rcourtna) 2004-12-09 14:27:57.000-0600

The patch (sipxfer.diff) _does_ fix the specific issue that was reported in this bug's description.  I've been running it in production since Nov 28.  Is anything else required before it is committed?

By: Mark Spencer (markster) 2004-12-09 14:43:02.000-0600

The patch shouldn't be necessary, I think there's something more fundamentally incorrect.  Can you please try the attached patch and see if this fixes it for you?

By: Ryan Courtnage (rcourtna) 2004-12-09 16:46:51.000-0600


I'm currently running -v1-0:

I backed out sipxfer.diff and ensured the the zombie problem re-appeared.

I then hacked your changes into -v1-0's channel.c.  The only difference from mydiff.txt being on line 2392:

   "clone->zombie=1;" instead of "ast_set_flag(clone, AST_FLAG_ZOMBIE);"

Recompiled, tested, and can verify that your patch _does_ correct the issue in CVS-v1-0-11/27/04.... awesome!

By: Brian West (bkw918) 2004-12-26 17:20:55.000-0600

Please respond if this is still a problem.

By: Ryan Courtnage (rcourtna) 2004-12-26 23:34:55.000-0600

mydiff.txt corrects the problem with my build.  Will the patch be committed to cvs?

By: Clod Patry (junky) 2005-01-01 02:50:34.000-0600

If it fix the problem for everyone, i don't see why it shouldn't go into CVS. Personally, i don't have that trouble, so i can't tell if it's okay or not.

By: Mark Spencer (markster) 2005-01-01 14:12:00.000-0600

Fixed in CVS head.

By: Ryan Courtnage (rcourtna) 2005-01-01 15:34:34.000-0600

Reminder sent to markster


Will this also make the stable branch?


By: Russell Bryant (russell) 2005-01-03 23:55:19.000-0600

fixed in 1.0

By: Digium Subversion (svnbot) 2008-01-15 15:19:17.000-0600

Repository: asterisk
Revision: 4627

U   trunk/channel.c

r4627 | markster | 2008-01-15 15:19:17 -0600 (Tue, 15 Jan 2008) | 2 lines

Make sure to wake up sleeper on sip transfer issue (bug ASTERISK-2886)



By: Digium Subversion (svnbot) 2008-01-15 15:19:41.000-0600

Repository: asterisk
Revision: 4654

U   branches/v1-0/channel.c

r4654 | russell | 2008-01-15 15:19:41 -0600 (Tue, 15 Jan 2008) | 2 lines

Make sure to wake up sleeper on sip transfer issue (bug ASTERISK-2886)