<div><div>Hi Muhammed,</div></div>
<br><br><div class="gmail_quote">On Fri, Feb 8, 2013 at 3:19 PM, Muhammad Shahzad <span dir="ltr"><<a href="mailto:shaheryarkh@gmail.com" target="_blank">shaheryarkh@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div>In my previous experience, i see this error due to one of following reasons.</div><div><br></div><div>1. The media ports you have specified in media proxy configuration overlaps some other service port range, e.g. in case you are running media proxy and asterisk on same machine and RTP port range of asterisk overlaps media proxy port range.</div>
</div></blockquote><div><br></div><div>Asterisk is running on the same machine.</div><div><br></div><div>/etc/asterisk/rtp.conf contains:</div><div><div> rtpstart=16384</div><div> rtpend=20480</div></div><div><br></div>
<div><div>/etc/mediaproxy/config.ini contains:</div><div> port_range = 20482:32768</div></div><div><br></div><div>Having said that, one relay machine does see more Asterisk activity than the other. Still it's activity is in the calls-per-minute range, not calls-per-second.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div>2. Check dmesg, do you see this message or any relevant message from network stack or ethernet driver there?</div>
</div></blockquote><div><br></div><div>No. The last relevant line is:</div><div> [ 44.905812] ctnetlink v0.93: registering with nfnetlink.</div><div><br></div><div>Most "irrelevant" lines are promiscuous mode reports from my tshark testing. Otherwise,</div>
<div> [40380457.905028] Machine check events logged</div><div> </div><div>The machine's uptime is just over 500 days.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div>3. Check syslog and see if you get following message or something similar from nf_conntrack.</div>
<div><br></div><div><div>nf_conntrack: table full, dropping packet</div></div></div></blockquote><div><br></div><div>Nothing of the sort.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div>4. Check ulimit and selinux, but seems from your previous posts on this issue that they are fine.</div></div></blockquote><div><br></div><div>ulimit is handled by the application itself I believe. selinux has never been configured. </div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div>
5. Do you have any SNAT or Multicast related rule in iptables?</div></div></blockquote><div><br></div><div>No. There is no *nat table defined at all, only *mangle (to remark DSCP EF) and *filter (basic INPUT security). No mention of multicast anywhere. There is IPv6 but it's not used for this application.</div>
<div><br></div><div><br></div><div>Saśl,</div><div><br></div><div>I'd be happy to add a logging line, but I'm not familiar enough with Python to know what to add where. Guidance is welcome!</div><div><br></div><div>
<br></div><div><br></div><div>- Jeff</div><div><br></div></div>