[Asterisk-bugs] [Asterisk 0009042]: DUNDi ignoring incoming replies when system is busy
noreply at bugs.digium.com
noreply at bugs.digium.com
Fri Jul 13 08:59:59 CDT 2007
A NOTE has been added to this issue.
======================================================================
http://bugs.digium.com/view.php?id=9042
======================================================================
Reported By: gdhgdh
Assigned To:
======================================================================
Project: Asterisk
Issue ID: 9042
Category: PBX/pbx_dundi
Reproducibility: sometimes
Severity: major
Priority: normal
Status: new
Asterisk Version: 1.2.14
SVN Branch (only for SVN checkouts, not tarball releases): N/A
SVN Revision (number only!):
Disclaimer on File?: No
Request Review:
======================================================================
Date Submitted: 02-12-2007 05:59 CST
Last Modified: 07-13-2007 08:59 CDT
======================================================================
Summary: DUNDi ignoring incoming replies when system is busy
Description:
I have two machines, star (10.0.0.239) and hash (10.0.0.235), both with one
E1 telco uplink. star is almost idle, whilst hash is quite busy
(http://bugs.digium.com/view.php?id=14#25 Zap
channels + MixMonitor + 30 SIP clients). I do DUNDi lookups between them to
find an available Zap channel.
Lookups originating from star complete almost instantly ( < 10ms).
Lookups originating from hash may take several seconds or fail completely.
tcpdump shows star is responding to the request immediately, but hash is
not processing the incoming reply. star then retries once per second for up
to 4 seconds before giving up.
I've annotated the tcpdump output (as run on hash!) for completeness:
ENCRYPT + DPDISCOVER request to star:
10:22:58.768384 IP 10.0.0.235.4520 > 10.0.0.239.4520: UDP, length 88
ACK to hash
10:22:58.768773 IP 10.0.0.239.4520 > 10.0.0.235.4520: UDP, length 8
ENCRYPT to hash:
10:22:58.769921 IP 10.0.0.239.4520 > 10.0.0.235.4520: UDP, length 90
ENCRYPT to hash:
10:22:59.769966 IP 10.0.0.239.4520 > 10.0.0.235.4520: UDP, length 90
ENCRYPT to hash:
10:23:00.770025 IP 10.0.0.239.4520 > 10.0.0.235.4520: UDP, length 90
(then finally after 3 seconds) ACK to star:
10:23:01.651028 IP 10.0.0.235.4520 > 10.0.0.239.4520: UDP, length 8
10:23:01.651446 IP 10.0.0.235.4520 > 10.0.0.239.4520: UDP, length 8
10:23:01.651518 IP 10.0.0.235.4520 > 10.0.0.239.4520: UDP, length 8
10:23:01.651593 IP 10.0.0.235.4520 > 10.0.0.239.4520: UDP, length 8
10:23:01.651716 IP 10.0.0.239.4520 > 10.0.0.235.4520: UDP, length 8
10:23:01.651783 IP 10.0.0.239.4520 > 10.0.0.235.4520: UDP, length 8
10:23:01.651808 IP 10.0.0.235.4520 > 10.0.0.239.4520: UDP, length 8
10:23:01.651841 IP 10.0.0.239.4520 > 10.0.0.235.4520: UDP, length 8
10:23:01.651868 IP 10.0.0.235.4520 > 10.0.0.239.4520: UDP, length 8
10:23:01.652041 IP 10.0.0.239.4520 > 10.0.0.235.4520: UDP, length 8
10:23:01.652074 IP 10.0.0.239.4520 > 10.0.0.235.4520: UDP, length 8
The rest are an assortment of ACKs, NULLs, INVALIDs and ENCREJ presumably
as hash is processing the backlog (possibly out of order ?)
The problem is, /why/ is hash waiting so long? Are other asterisk threads
too busy with other work? How can I determine this? I'm using 1.2.14 on
both machines. Load average on hash is typically only 0.2.
On hash, I notice other small indications like typing 'show chan' and
pressing TAB... the commandline may wait for several seconds before
completing 'show channel'.
Neither machine is doing anything exotic like MeetMe, queueing/agents or
IVR. hash is new - an HP DL145 G2 (Opteron 246 with HyperTransport) and is
dedicated to Asterisk. There is a single Sangoma A104 installed.
======================================================================
----------------------------------------------------------------------
malaiwah - 07-13-07 08:59
----------------------------------------------------------------------
I had some issues today, in my particular setup I'm using
DUNDi-over-OpenVPN which switches calls using IAX2 over two servers, I get
this message quite often in the debug log of one server (snippet):
Jul 13 08:16:08 DEBUG[31661] devicestate.c: Changing state for
IAX2/192.168.10.62:4569 - state 4 (Invalid)
Jul 13 08:16:18 DEBUG[31661] devicestate.c: Changing state for
IAX2/192.168.10.62:4569 - state 4 (Invalid)
Jul 13 08:16:29 DEBUG[31661] devicestate.c: Changing state for
IAX2/192.168.10.62:4569 - state 4 (Invalid)
Jul 13 08:16:39 DEBUG[31661] devicestate.c: Changing state for
IAX2/192.168.10.62:4569 - state 4 (Invalid)
Jul 13 08:16:46 DEBUG[31661] devicestate.c: Changing state for
IAX2/192.168.10.62:4569 - state 4 (Invalid)
Jul 13 08:16:55 DEBUG[31661] devicestate.c: Changing state for
IAX2/192.168.10.62:4569 - state 4 (Invalid)
Jul 13 08:17:00 DEBUG[31661] devicestate.c: Changing state for
IAX2/192.168.10.62:4569 - state 4 (Invalid)
Jul 13 08:17:10 DEBUG[31661] devicestate.c: Changing state for
IAX2/192.168.10.62:4569 - state 4 (Invalid)
Jul 13 08:18:32 DEBUG[31661] devicestate.c: Changing state for
IAX2/192.168.10.62:4569 - state 4 (Invalid)
Jul 13 08:18:42 DEBUG[31661] devicestate.c: Changing state for
IAX2/192.168.10.62:4569 - state 4 (Invalid)
Jul 13 08:19:56 DEBUG[31661] devicestate.c: Changing state for
IAX2/192.168.10.62:4569 - state 4 (Invalid)
Jul 13 08:20:06 DEBUG[31661] devicestate.c: Changing state for
IAX2/192.168.10.62:4569 - state 4 (Invalid)
Jul 13 08:21:34 DEBUG[31661] devicestate.c: Changing state for
IAX2/192.168.10.62:4569 - state 4 (Invalid)
Jul 13 08:21:44 DEBUG[31661] devicestate.c: Changing state for
IAX2/192.168.10.62:4569 - state 4 (Invalid)
Jul 13 08:21:48 DEBUG[31661] devicestate.c: Changing state for
IAX2/192.168.10.62:4569 - state 4 (Invalid)
Jul 13 08:21:58 DEBUG[31661] devicestate.c: Changing state for
IAX2/192.168.10.62:4569 - state 4 (Invalid)
Jul 13 08:22:20 DEBUG[31661] devicestate.c: Changing state for
IAX2/192.168.10.62:4569 - state 4 (Invalid)
Jul 13 08:22:30 DEBUG[31661] devicestate.c: Changing state for
IAX2/192.168.10.62:4569 - state 4 (Invalid)
Jul 13 08:22:44 DEBUG[31661] devicestate.c: Changing state for
IAX2/192.168.10.62:4569 - state 4 (Invalid)
Jul 13 08:22:54 DEBUG[31661] devicestate.c: Changing state for
IAX2/192.168.10.62:4569 - state 4 (Invalid)
Jul 13 08:22:56 DEBUG[31661] devicestate.c: Changing state for
IAX2/192.168.10.62:4569 - state 4 (Invalid)
Jul 13 08:23:06 DEBUG[31661] devicestate.c: Changing state for
IAX2/192.168.10.62:4569 - state 4 (Invalid)
Jul 13 08:23:20 DEBUG[31661] devicestate.c: Changing state for
IAX2/192.168.10.62:4569 - state 4 (Invalid)
Jul 13 08:23:30 DEBUG[31661] devicestate.c: Changing state for
IAX2/192.168.10.62:4569 - state 4 (Invalid)
And the other server:
Jul 11 09:56:45 DEBUG[23149] devicestate.c: Changing state for IAX2/dundi
- state 4 (Invalid)
Jul 11 09:56:50 DEBUG[23149] devicestate.c: Changing state for IAX2/dundi
- state 4 (Invalid)
Jul 11 09:59:21 DEBUG[23149] devicestate.c: Changing state for IAX2/dundi
- state 4 (Invalid)
Jul 11 10:01:16 DEBUG[23149] devicestate.c: Changing state for IAX2/dundi
- state 4 (Invalid)
Jul 11 10:01:21 DEBUG[23149] devicestate.c: Changing state for IAX2/dundi
- state 4 (Invalid)
Jul 11 10:04:08 DEBUG[23149] devicestate.c: Changing state for IAX2/dundi
- state 4 (Invalid)
Jul 11 10:04:12 DEBUG[23149] devicestate.c: Changing state for IAX2/dundi
- state 4 (Invalid)
Jul 11 10:04:29 DEBUG[23149] devicestate.c: Changing state for IAX2/dundi
- state 4 (Invalid)
Jul 11 10:06:11 DEBUG[23149] devicestate.c: Changing state for IAX2/dundi
- state 4 (Invalid)
Jul 11 10:06:54 DEBUG[23149] devicestate.c: Changing state for IAX2/dundi
- state 4 (Invalid)
Jul 11 10:06:55 DEBUG[23149] devicestate.c: Changing state for IAX2/dundi
- state 4 (Invalid)
Jul 11 10:09:13 DEBUG[23149] devicestate.c: Changing state for IAX2/dundi
- state 4 (Invalid)
Jul 11 10:09:19 DEBUG[23149] devicestate.c: Changing state for IAX2/dundi
- state 4 (Invalid)
Issue History
Date Modified Username Field Change
======================================================================
07-13-07 08:59 malaiwah Note Added: 0067342
======================================================================
More information about the asterisk-bugs
mailing list