[Serusers] Intermittent Audio

[pat newham]

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 at 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 at teigre.com> wrote: 
> 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:
> > 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 at 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 at 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:
> >>
> >
>
http://lists.iptel.org/pipermail/serusers/2005-January/014620.html
> >>
> >
>
http://www.linksysinfo.org/modules.php?name=Forums&file=viewtopic&p=8820
> >>
> >>> 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 at 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,
> 
=== message truncated === 

Send instant messages to your online friends http://uk.messenger.yahoo.com