[Home]

Summary:ASTERISK-13111: SIP Channels Hang - Last Message: Rx BYE - Need Destroy: 2
Reporter:Geoff Mina (geoff2010)Labels:
Date Opened:2008-11-23 18:38:38.000-0600Date Closed:2011-06-07 14:08:21
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:I have a bunch of servers running 1.4.21.2.  They are all, on occassion, getting stuck SIP channels.  Nothing shows up in "core show channels", but the lingering culprits continue to show up in "sip show channels" until a restart of asterisk.  The thing they all have in common is that the last message received was a BYE, and they all have their "Need Destroy" flag set to 2.  Here are some basic outputs, nothing is crashing so I have no core dumps, it's a production system so I don't have SIP debugging enabled.  It seems to only happen in roughly 1 in 5000 calls (estimate)

atl-asterisk5*CLI> core show channels
Channel              Location             State   Application(Data)
0 active channels
0 active calls

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

atl-asterisk5*CLI> sip show channels
Peer             User/ANR    Call ID      Seq (Tx/Rx)  Format           Hold     Last Message
216.82.XXX.XXX   +17066XXX  6b25419936b  00102/00001  0x0 (nothing)    No  (d)  Rx: BYE
216.82.XXX.XXX   +14042XXX  3955ba5d7c2  00102/00001  0x0 (nothing)    No  (d)  Rx: BYE
2 active SIP channels

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

atl-asterisk5*CLI> sip show channel 6b25419936b
atl-asterisk5*CLI>
 * SIP Call5*CLI>
 Curr. trans. direction:  Outgoing
 Call-ID:                6b25419936bd5cac4b4dbe6568042787@blah.com
 Owner channel ID:       <none>
 Our Codec Capability:   260
 Non-Codec Capability (DTMF):   1
 Their Codec Capability:   256
 Joint Codec Capability:   256
 Format:                 0x0 (nothing)
 MaxCallBR:              384 kbps
 Theoretical Address:    216.82.XXX.XXX:5060
 Received Address:       216.82.XXX.XXX:5060
 SIP Transfer mode:      open
 NAT Support:            Always
 Audio IP:               67.220.101.185 (local)
 Our Tag:                as1f608769
 Their Tag:              VPST506071629460
 SIP User agent:
 Username:               +1706687XXXX
 Peername:               bw_g729
 Original uri:           sip:+170668XXXX@216.82.XXX.XXX
 Need Destroy:           2
 Last Message:           Rx: BYE
 Promiscuous Redir:      No
 Route:                  N/A
 DTMF Mode:              rfc2833
 SIP Options:            (none)


If there is anything else I can provide, please let me know.

Thanks,
Geoff
Comments:By: Leif Madsen (lmadsen) 2008-11-24 09:18:34.000-0600

Per the bug guidelines, we will need sip debugging output:

"6. SIP Problem?
Include debug output! Please include output from "sip debug" if you have a SIP problem. This seems obvious, but apparently is not. Set debug to 4, verbose to 4, turn on sip history and dumphistory in sip.conf and capture all output. A packet trace from ethereal will not tell us what is happening inside your Asterisk server, so that is not a replacement."
By: Geoff Mina (geoff2010) 2008-11-24 09:35:47.000-0600

As I said in my original post, these are production machines which process a high volume of calls.  Only about 1 in 5000 calls get stuck.  As we all know, trying to log all SIP messages will eventually crash the server.

If the fact that the last message Rx was a BYE, combined with the Need Destroy flag set to 2 isn't enough to investigate further then feel free to close this bug because I won't be able to easily provide further information.

Thanks,
Geoff
By: ivankolev (ivankolev) 2008-12-16 11:50:15.000-0600

I have almost exactly the same issue, again on production servers so hard to provide sip debug output. I'll try to set-up test machine and use Sipp to generate calls but whether the bug will creep up remains to be seen.
Machine in question takes heavy load of calls, after clean restart and one day of work I have close to 70 zombie channels. By the way, the *version is different - 1.4.13 in my case.
Here's what sip show channel says:
astappsrv1*CLI> sip show channel 124ad3c3e19f1c3d13e0f45da5925acddff8cdb6@XX.XX.XX.XX
astappsrv1*CLI>
 * SIP Call
 Curr. trans. direction:  Incoming
 Call-ID:                124ad3c3e19f1c3d13e0f45da5925acddff8cdb6@XX.XX.XX.XX
 Owner channel ID:       <none>
 Our Codec Capability:   262
 Non-Codec Capability (DTMF):   1
 Their Codec Capability:   2308
 Joint Codec Capability:   260
 Format:                 0x0 (nothing)
 MaxCallBR:              384 kbps
 Theoretical Address:    XX.XX.XX.XX:5060
 Received Address:       XX.XX.XX.XX:5060
 SIP Transfer mode:      open
 NAT Support:            RFC3581
 Audio IP:               XX.XX.XX.XX (local)
 Our Tag:                as76340350
 Their Tag:              1c1223205522
 SIP User agent:         Audiocodes-Sip-Gateway-Mediant 2000/v.4.40.254.482
 Peername:               pritrunkdomain
 Original uri:           sip:XX.XX.XX.XX@XX.XX.XX.XX:5060
 Caller-ID:              XX.XX.XX.XX
 Need Destroy:           2
 Last Message:           Tx: BYE
 Promiscuous Redir:      No
 Route:                  sip:XX.XX.XX.XX@XX.XX.XX.XX:5060;nt_end_pt=YM0+~Kn25r6_4t67~QQiE_q25X861aQ5~LKrM2HXoSvi8Q~MA2N03cK1ek_ihlDdkuZXoH1iatPoS10lWUktb-488~Xn7ZQzN~L1tq3U0z3ofW0JQiktq0UJpy~D4190Ius0brUJpvii;nt_server_host=XX.XX.XX.XX  DTMF Mode:              rfc2833
 SIP Options:            replaces replace 100rel timer join path


By: Joshua C. Colp (jcolp) 2009-02-13 08:40:06.000-0600

Closed as this issue has already been resolved.
By: gb_delti (gb_delti) 2011-10-12 04:03:00.056-0500

I'm also experiencing this bug since Version 1.4. Now I'm on Version 1.8.7 and it still occurs. I can't provide SIP traffic logs because it occurs so infrequently. Please reopen this bug, it's still not fixed.