[OpenSIPS-Users] OpenSIPS 1.6.3 / Solaris 10 / nathelper problem

Marty Lee marty at maui-systems.co.uk
Sat Dec 11 11:40:34 CET 2010


Hi,

spending time getting my head around OpenSIPS and how to use it as an outbound
proxy for my internal SIP phones.

I'm working on Solaris 10, and am seeing some strange things with the nathelper
module. So much so, even though I've helped out in numerous open source projects
before, I've not seen this error previously, so while I'm spending more time
googling it, I thought I'd ask here, in case someone else knows either what I've
done wrong, or can explain further...

Output from opensips indicates the initial test for the proxy are fine:
Dec 11 10:23:45 [17646] INFO:nathelper:rtpp_test: rtp proxy <Dec 11 10:23:45udp:127.0.0.1:9000> found, support for it enabled
(looks like one of these per thread)

however, when OpenSIPS tries to use the proxy, I get the messages:
Dec 11 10:25:06 [17656] ERROR:nathelper:send_rtpp_command: can't send command to a RTP proxy(2): 22/Invalid argument
Dec 11 10:25:06 [17656] ERROR:nathelper:send_rtpp_command: proxy <udp:127.0.0.1:9000> does not respond, disable it
Dec 11 10:25:06 [17656] ERROR:nathelper:force_rtp_proxy_body: no available proxies


The first line is a doctored error message, as you have two points in the code that
return the same error - I needed to find out which one was generating the error - as
it turns out, it's the one that uses 'writev'; the
suffix is the value of 'errno' and the strerror() message.

It's a bit weird - send_rtpp_command works fine when it runs to start with, testing
the proxy is valid. When called later on, nathelper doesn't even get to send the
message to the proxy.

I've checked the man pages for writev and EINVAL is returned when the size to write
is too great (it isn't in this case, I've checked); the iovcnt value is too high -
again, it isn't; or

"The STREAM or multiplexer referenced by fildes  is
              linked  (directly or indirectly) downstream from a
              multiplexer."

Is it the last case? Don't really know what this means (so I'll google it some)
but I've no idea what is likely to have changed from when opensips started, to
when it goes to the proxy later on.

BTW, the rtpproxy process is fine; it's running in debug mode and doesn't get
anything on it's socket when the error occurs. If I stop & restart opensips, the
proxy is checked ok, so as far as rtpproxy is concerned, opensips isn't even trying
to connect to it.

Also tried it with unix:/var/run/rtpproxy.sock as the conduit, and I still get
the error (albeit in the earlier section of code in the send_rtpp_command function);
yes, I did update the rtpproxy config when I tested it :-)

OpenSIPS 1.6.3-tls
RTPproxy 1.2.1

Any clues?

m
-----
Marty Lee                         e: marty at maui-systems.co.uk
Technical Director                v: +44 845 869 2661
Maui Systems Ltd                  f: +44 871 433 8922
Scotland, UK                      w: http://www.maui-systems.co.uk




More information about the Users mailing list