Meetme causing kernel panic on Asterisk 1.6

Asterisk Asterisk Support
1

I have discovered a situation where asterisk is causing a system crash. Is this the correct forum to discuss this issue?

The test system consists of 2 machines, I am sending SIP calls from the first machine to the second where the calls join a meetme conference. The call lasts about 30 seconds and hangs up, a new call is initiated every 5 seconds or so. The conference contains 6 or 7 calls all playing the test message to each other.

The machine running meetme kernel panics after about 10 minutes, the other stays up forever.

The machine is a Dell PowerEdge SC440 running CentOS 5.0; Asterisk 1.6.0.3-rc1 dahdi 2.1.0.3 libpri 1.4.7. There is one TE405P, quad T1 with a single PRI attached, no calls are present on the PRI. Asterisk 1.6.1-beta4 has the same behavior.

extensions.conf:
[general]
static=yes
writeprotect=no
autofallthrough=yes

[test]
exten => s,1,Answer()
exten => s,2,NoOp(exten:${EXTEN} callerid:${CALLERID(NUMBER)})
exten => s,3,Playback(tt-allbusy)
exten => s,4,Wait(3.0)
exten => s,5,Playback(tt-allbusy)
exten => s,6,Wait(3.0)
exten => s,7,Playback(tt-allbusy)
exten => s,8,Wait(3.0)
exten => s,9,Hangup()

[newcall]
exten => test,1,MeetMe(test,dp(#*)q)

sip.conf:
[ast216]
type=user
context=newcall
host=dynamic
disallow=all
allow=gsm
allow=ulaw
defaultuser=ast216
secret=…
nat=no

2

Hi,

I do not have an identical issue, but what’s about the meetme conference itself. I do have an issue with meetme on that version of Asterisk. The sound to the callers is not stable which means is coming and going - really a pain. I did not suceed in solving that issue.

According to my research, the talk optimization is responsible for that an cannot be switched off in 1.6 and not the timing source (DAHDI). Here’s the link http://bugs.digium.com/view.php?id=13801

3

I also noticed the talker optimization problem. I solved it by a coding change in app_meetme.c Here is a diff:
2452c2452,2453
< careful_write(fd, f->data, f->datalen, 0);

  				if (user->talking)
  					careful_write(fd, f->data, f->datalen, 0);

Similar results could be obtained by changing MEETME_DELAYDETECTTALK its a value in milliseconds.

Obviously I regressed my code to the distributed version to test and report the crash.

4

thx for hint, but …

… very interesting that in my version of app_meetme.c of 1.6.0.3-rc1 the if clause is already there and therefore already compiled in.

Can I somehow switch off this optimization stuff completely?

Thx,
Alex

5

Sorry confused you. I got the diff backwards. The release code says:
if (user->talking)
safe_write(…);

need to change to just
safe_write(…);

6

Thx for your post - the issue is solved and the system still alive! My system is a Debian Lenny on a 2.6.26-am64 kernel, maybe that’s the difference to the CentOS.