[OpenSIPS-Users] media-relay error - operation not permitted

[Saúl Ibarra Corretgé]

Hi Jeff,

On Feb 8, 2013, at 10:08 PM, Jeff Pyle wrote:

> Hi Muhammed,
> 
> 
> On Fri, Feb 8, 2013 at 3:19 PM, Muhammad Shahzad <shaheryarkh at gmail.com> wrote:
> In my previous experience, i see this error due to one of following reasons.
> 
> 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.
> 
> Asterisk is running on the same machine.
> 
> /etc/asterisk/rtp.conf contains:
>   rtpstart=16384
>   rtpend=20480
> 
> /etc/mediaproxy/config.ini contains:
>   port_range = 20482:32768
> 
> 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.
> 
> 2. Check dmesg, do you see this message or any relevant message from network stack or ethernet driver there?
> 
> No.  The last relevant line is:
>   [   44.905812] ctnetlink v0.93: registering with nfnetlink.
> 
> Most "irrelevant" lines are promiscuous mode reports from my tshark testing.  Otherwise,
>   [40380457.905028] Machine check events logged
>   
> The machine's uptime is just over 500 days.
>  
> 3. Check syslog and see if you get following message or something similar from nf_conntrack.
> 
> nf_conntrack: table full, dropping packet
> 
> Nothing of the sort.
> 
> 4. Check ulimit and selinux, but seems from your previous posts on this issue that they are fine.
> 
> ulimit is handled by the application itself I believe.  selinux has never been configured.  
>  
> 5. Do you have any SNAT or Multicast related rule in iptables?
> 
> 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.
> 
> 
> Saúl,
> 
> 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!
> 

John provided me with some logs which I've inspected. The problem is still not 100% clear to me but I have a couple of suspicions.

I spent some time trying to understand what is going on, since it's really uncommon to get EPERM for a datagram socket.

Please find attached a patch which logs and ignores the error. What I'm interested in seeing is if it would actually work if the error is just ignored. You seem to be running an older MediaProxy release, so the attached patch may not apply cleanly. It should be easy to manually apply though. 

Now, as for the error reason, the only plausible explanation in case no firewall is being used is a problem with traffic pacing. Basically there seems to be a chance of getting EPERM when sending data over a UDP socket in case the sender is too quick and kernel buffers are full. We do have a (undocumented) setting for this: userspace_transmit_every in the [relay] section. The default value is 1, which means every packet would be relayed in user-space until the conntrack rule has been established. Please also test setting that value to 4, which means that only one out of every 4 packets will be sent to the destination. Since bidirectional media is not yet established (otherwise there would be a conntrack rule) this shouldn't be harmful.

Recap: please apply the supplied patch and run these tests:

- Just run the current config, watch for the log lines and see if audio flows regardless
- Set userspace_transmit_every = 4 in the [relay] section of the configuration file

Please let me know how testing goes.


Regards,

--
Saúl Ibarra Corretgé
AG Projects