18 Mar
2005
18 Mar
'05
12:38 p.m.
In the ser.cfg file i have:
modparam("nathelper", "rtpproxy_sock",
"/var/run/rtpproxy.sock")
When I go to the /var/run directory and do "ls" I can
see rtpproxy.sock along with a directory called
"rtpproxy" containing c files/readme files etc. I ran
"ls -l rtpproxy.sock" and got the following results:
srwxr-xr-x 1root root [date]rtpproxy.sock
I also checked pstree and can see rtpproxy running.
Is it correct for rtpproxy.sock to be in a different
directory to all the rtpproxy c files etc?
When I run the following:
localhost:/var/run# cvs
-d:pserver:anonymous@cvs.ser.berlios.de:/cvsroot/ser
co rtpproxy
I get: ? rtpproxy/127.0.0.1
cvs server: Updating rtpproxy.
Am I running this command in the correct directory?
I again stopped rtpproxy and ser (killall rtpproxy and
killall ser) and restarted rtpproxy ("rtpproxy" from
the command line...does this have to be started in a
particular directory?) and then restarted
ser(/etc/init.d/ser restart). I still have the errors
described below.
Am I doing something ridiculously stupid or missing
something very obvious or is all the above correct?
Regards,
Pat.
--- "Greger V. Teigre" <greger(a)teigre.com> wrote:
http://www.linksysinfo.org/modules.php?name=Forums&file=viewtopic&p…
=== message truncated ===
Send instant messages to your online friends http://uk.messenger.yahoo.com
Yes, an update could be of help. There was a
protocol change (between
rtpproxy and ser/nathelper) at one point. I don't
remember when.
I would agree that getting rid of the error messages
would be priority 1.
As the warning says, rtpproxy is disabled and
force_rtp_proxy will not help
you...
An updated version of the Getting Started
document with NAT (both
mediaproxy and rtpproxy) is in the works and will be
released within the
next couple of weeks (probably). Until then I
suggest that you make sure
that rtpproxy is really updated and running
correctly and that they are able
to communicate (permissions) through the
/var/run/rtpproxy.sock socket.
g-)
pat newham wrote:
http://lists.iptel.org/pipermail/serusers/2005-January/014620.html
Thank you for the explanation...perhaps my view
of
the
nat issues are too simplified!! I realise now
that
there is no point in invoking rtpproxy when the
user
agents are behind the same nat on the same
subnet.
I
do not think the linksys router has any sip alg
settings. However while I acknowledge this is bad
design practice, I suspect now that the problem is
that my rtpproxy isnt working correctly anyway.
I found the following messages in
/var/log/messages:
localhost /usr/sbin/ser: ERROR: send rtpp_test:
cant
read reply from a rtp proxy
localhost /usr/sbin/ser: WARNING: rtpp_test: cant
get
version of the RTP proxy
localhost /usr/sbin/ser: WARNING: support for the
rtpproxy has been temporarily disabled
I searched the archives and determined that I am
probably running the wrong version of RTPProxy so
from
the /usr/sbin directory I ran the following
command:
cvs
-d:pserver:anonymous@cvs.ser.berlios.de:/cvsroot/ser
co rtpproxy.
However this seems not to have made any
difference.
Any further ideas? Do you think this is the
source
of
the problem?
Regards,
Pat.
--- "Greger V. Teigre" <greger(a)teigre.com> wrote:
Pat,
The system is currently being tested by someone
else
but I believe they are behind a Linksys VPN
router.
Have a look at these:
>
>> Are you suggesting it could simply be the
settings
> in
>> this?
> Yes.
>
>> I "think" I understand the nat issues associated
> with
>> sip and sdp fairly ok so would I be correct in
> saying
>> that if my two clients are behind nat(the same
> nat)on
>> the same subnet the rtpproxy should be invoked?
> This
>> would be my understanding of the situation but
> then I
>> saw a recent email (see message header
below)which
>> suggests an external script should be
used.
>
> I'm afraid it's not that simple. ;-) If the
clients
> are directly routable on
> your LAN, you would be best off not doing any
> nathelper/rtpproxy. The rtp
> will then flow directly between the clients.
> However, if you use nathelper,
> it depends on your knowledge of the clients. If
you
> send the SIP messages
> through an ALG, the ALG will change the SDP IP
> addresses (probably), unless
> it detects that both are on it's own LAN. This is
> dependent on the
> implementation. Anyway, an ALG rewriting to send
> rtp in a hairpin (turn in
> the NAT) will probably support hairpin. The
problem
> is that you get all
> sorts of problems if the ALG is rewriting and you
> make some assumptions
> about the SDP payload.
> You should probably dump the SIP messages on the
> outside of the NAT (I
> believe you said ser is on a public address
> outside?)
>
> External scripts should never be used. If a
script
> blocks, you block the ser
> ser process. If the same error is triggered in
> several processes, ser will
> stop responding.
>
>> Re: FW: [Serusers] calls between UA´s b ehind
same
> NAT
>> us ing nathelper/rtpproxy
>>
>> Also what confuses me is that the scenario works
>> sometimes and yet other times it doesnt.
>
> :-) Welcome to the club...
>
> g-)
>
>> I will
>> attempt to get a full message dump (of both the
>> working and non working scenario)from the tester
> if
>> that will help.
>>
>> Kindest Regards,
>> Pat.
>>
>> --- "Greger V. Teigre" <greger(a)teigre.com>
wrote:
>>> Pat,
>>> You haven't said anything of the type of NAT
you
> are
>>> behind. To me it sounds
>>> like an ALG (Application layer gateway)
problem.
> Try
>>> to turn of the SIP ALG
>>> in your router. If not, please post a full SIP
>>> message exchange. You need
>>> to find out if they communicate through the NAT
>>> (hairpin media) or directly.
>>> That depends on the SDP payload in the INVITE
and
> OK
>>> messages.
>>> The new Getting Started document on
>>> http://onsip.org/ (you need to
>>> register) has a thorough review of NAT issues
and
>>> rewriting. Recommend! (I
>>> wrote it ;-) )
>>> g-)
>>>
>>> pat newham wrote:
>>>> Following on from my below email, I can now
>>> definately
>>>> say the problem is not nat pings. Just to
recap I am
>>>> experiencing intermittent audio.
It works when
> the
>>>> phones have very recently registered, then
>>> sometimes
>>>> theres one way audio and then sometimes no
audio. Does
>>>> anyone have any ideas what the
problem could
be
> or
>>>> where I could begin to troubleshoot this?
>>>>
>>>> Hi,