Summary:ASTERISK-07555: SIP -> SIP call hangs forever with "Blocking in: ast_waitfor_nandfds"
Reporter:Sergey Tamkovich (sergee)Labels:
Date Opened:2006-08-19 03:19:43Date Closed:2006-11-28 10:11:35.000-0600
Versions:Frequency of
Environment:Attachments:( 0) asterisk-messages.txt
Description:It happenes rarely, but it does. I'm using DIAL(SIP/1199||jL(3600000:60000:30000)) - to make a call from 1 sip friend to another. So, call is limited  to 1 hour. Right now this call is hanging for ~ 23 hours already and i can't perfom neither "restart gracefully" nor "restart when convinient".

Here are some additional data, i hope it will be helpfull:

Regards, Sergey.


babylon*CLI> show channels
Channel              Location             State   Application(Data)
SIP/1199-082264c0    (None)               Ringing AppDial((Outgoing Line))
SIP/1213-b664ea68    1199@internal:2      Ring    Dial(SIP/1199||jL(3600000:6000
2 active channels
1 active call

babylon*CLI> show channel SIP/1213-b664ea68
-- General --
          Name: SIP/1213-b664ea68
          Type: SIP
      UniqueID: 1155890797.977
     Caller ID: 1213
Caller ID Name: 1213
   DNID Digits: 1199
         State: Ring (4)
         Rings: 0
 NativeFormats: 0x4 (ulaw)
   WriteFormat: 0x40 (slin)
    ReadFormat: 0x40 (slin)
WriteTranscode: Yes
 ReadTranscode: Yes
1st File Descriptor: 7
     Frames in: 0
    Frames out: 0
Time to Hangup: 0
  Elapsed Time: 22h57m2s
 Direct Bridge: <none>
Indirect Bridge: <none>
--   PBX   --
       Context: internal
     Extension: 1199
      Priority: 2
    Call Group: 0
  Pickup Group: 0
   Application: Dial
          Data: SIP/1199||jL(3600000:60000:30000)
   Blocking in: ast_waitfor_nandfds
SIPUSERAGENT=Siemens Gigaset C450 IP

 CDR Variables:
level 1: owner=99
level 1: clid="1213" <1213>
level 1: src=1213
level 1: dst=1199
level 1: dcontext=internal
level 1: channel=SIP/1213-b664ea68
level 1: dstchannel=SIP/1199-082264c0
level 1: lastapp=Dial
level 1: lastdata=SIP/1199||jL(3600000:60000:30000)
level 1: start=2006-08-18 10:46:37
level 1: duration=0
level 1: billsec=0
level 1: disposition=NO ANSWER
level 1: amaflags=DOCUMENTATION
level 1: uniqueid=1155890797.977

babylon*CLI> show channel SIP/1199-082264c0
-- General --
          Name: SIP/1199-082264c0
          Type: SIP
      UniqueID: 1155890797.978
     Caller ID: 1199
Caller ID Name: (N/A)
   DNID Digits: (N/A)
         State: Ringing (5)
         Rings: 0
 NativeFormats: 0x2 (gsm)
   WriteFormat: 0x40 (slin)
    ReadFormat: 0x40 (slin)
WriteTranscode: Yes
 ReadTranscode: Yes
1st File Descriptor: 23
     Frames in: 1
    Frames out: 0
Time to Hangup: 0
  Elapsed Time: N/A
 Direct Bridge: <none>
Indirect Bridge: <none>
--   PBX   --
       Context: internal
      Priority: 1
    Call Group: 0
  Pickup Group: 0
   Application: AppDial
          Data: (Outgoing Line)
   Blocking in: ast_waitfor_nandfds
Comments:By: Serge Vecher (serge-v) 2006-08-21 09:17:51

hmm, I think oej will want to see either a sip debug or sip history for this 'friend' to see how things get this way. If you need any help with either of those options, please feel free to find me on either #asterisk-bugs or #asteriskru

By: Joshua C. Colp (jcolp) 2006-08-21 13:14:32

Yes, we need at least a sip debug. There's no console output to indicate that either side hung up. Also if you could grab a core while it is in this state and paste a backtrace that would rock. You can get it by using: gdb asterisk --pid=<PID OF ASTERISK> - note you'll want to have your Asterisk built with no optimizations using make dont-optimize

By: Sergey Tamkovich (sergee) 2006-08-22 01:06:31

i built non-optimised version, and i'm runing it with sip debug. However this bug happenes rarely. As soon as it will happenagain - i'll post bt here.

By: Serge Vecher (serge-v) 2006-09-06 12:51:10

as per sergee on #asteriskru, this is still a problem with r.41241. Working on a SIP debug.

By: Olle Johansson (oej) 2006-10-25 12:59:18

Any updates?

By: Olle Johansson (oej) 2006-11-14 06:04:17.000-0600

sergee: Does it happen with latest trunk or is the problem gone? We've changed quite a lot.

By: Sergey Tamkovich (sergee) 2006-11-14 07:15:30.000-0600

Runing SVN-trunk REvision 46400 for 24 hours now, don't have any "zombie" channels yet,

let's keep this issue open for a couple more days.

By: Sergey Tamkovich (sergee) 2006-11-28 05:21:37.000-0600

5 days of intensive usage, don't have any zombies..
i think that we can close this issue.

By: Joshua C. Colp (jcolp) 2006-11-28 10:11:35.000-0600

Closed per request of reporter, seems to have already been fixed.