[Home]

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
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/Transfers
Versions:Frequency of
Occurrence
Related
Issues:
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

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

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?

bkw

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.

bkw
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.

Thanks

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
192.168.1.113    204         4d3ae07929e  00104/1682859725   ULAW
1 active SIP channel(s)


imaging*CLI> sip show history 4d3ae07929e
imaging*CLI>
 * SIP Call
1. TxReqRel        INVITE sip:204@192.168.1.113 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@192.168.1.113 SIP/2.0 / 102 ACK
9. Rx              INVITE sip:207@192.168.1.102 SIP/2.0 / 1682859724 INVITE
10. CancelDestroy
11. TxRespRel       SIP/2.0 200 OK / 1682859724 INVITE
12. Rx              ACK sip:207@192.168.1.102 SIP/2.0 / 1682859724 ACK
13. Rx              REFER sip:207@192.168.1.102 SIP/2.0 / 1682859725 REFER
14. TxResp          SIP/2.0 202 Accepted / 1682859725 REFER
15. TxReqRel        NOTIFY sip:204@192.168.1.113 SIP/2.0 / 103 NOTIFY
16. TxReqRel        BYE sip:204@192.168.1.113 SIP/2.0 / 104 BYE
17. Rx              SIP/2.0 200 OK / 103 NOTIFY
18. Rx              SIP/2.0 200 OK / 104 BYE
imaging*CLI>
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.
bkw
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
192.168.1.4      427         1c6641d9025  00104/501630   ULAW
1 active SIP channel(s)


pbx*CLI> sip show history 1c6641d9025
pbx*CLI>
 * SIP Call
1. TxReqRel        INVITE sip:427@192.168.1.4:5060 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@192.168.1.4:5060 SIP/2.0 / 102 ACK
9. Rx              INVITE sip:301@192.168.1.3 SIP/2.0 / 501629 INVITE
10. CancelDestroy
11. TxRespRel       SIP/2.0 200 OK / 501629 INVITE
12. Rx              ACK sip:301@192.168.1.3 SIP/2.0 / 501629 ACK
13. Rx              REFER sip:301@192.168.1.3 SIP/2.0 / 501630 REFER
14. TxResp          SIP/2.0 202 Accepted / 501630 REFER
15. TxReqRel        NOTIFY sip:427@192.168.1.4:5060 SIP/2.0 / 103 NOTIFY
16. TxReqRel        BYE sip:427@192.168.1.4:5060 SIP/2.0 / 104 BYE
17. Rx              SIP/2.0 200 OK / 103 NOTIFY
18. Rx              SIP/2.0 200 OK / 104 BYE
pbx*CLI>
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.

Thanks

(now running Asterisk CVS-v1-0-11/24/04)
By: Ryan Courtnage (rcourtna) 2004-11-26 09:42:59.000-0600

Hi,

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

Ryan.


---snip---
I see the same

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

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

The ZOMBIE Remains......

Jason
---snip---
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
anthmct@yahoo.com
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?

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

yes it should go 1.0 also ;P

bkw
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

Mark,

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

Mark,

Will this also make the stable branch?

Thanks
Ryan
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)

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

http://svn.digium.com/view/asterisk?view=rev&revision=4627
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)

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

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