Re: [Serusers] Intermittent Audio

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: http://lists.iptel.org/pipermail/serusers/2005-January/014620.html http://www.linksysinfo.org/modules.php?name=Forums&file=viewtopic&p… > > > 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, > >>> >>> I have a strange problem. I have two grandstream > >>> budgetone clients on the same subnet behind nat > >>> registering with ser on a public address. > >> Obviously > >>> their public addresses would be the same but > they > >>> listen on different ports. When they initially > >>> register, I can the call,audio is transmitted > and > >>> everything is successful. > >>> >>> However sometimes theres only one way audio, > other > >>> times theres no audio and then other times it > >>> works....I am guessing that this is because the > >> nat > >>> router is forgetting the nat mapping so after a > >> while > >>> when the nat mapping is "forgotten" and a packet > >>> arrives destined for a client, the router drops > >> it.... > >>> >>> Could someone verify this for me??...Am I on the > >> right > >>> track?? I have the following settings in ser.cfg > >> which > >>> I thought would keep the nat settings alive. > >>> >>> modparam("registrar", "nat_flag", 6) > >>> modparam("nathelper", "natping_interval", 30) # > >> Ping > >>> interval 30 s > >>> modparam("nathelper", "ping_nated_only", 1) # > >> Ping > >>> only clients behind NAT > >>> >>> I also increased the nat keep alives "pings" > sent > >> in > >>> the configuration settings of the grandstream > >>> phone....Any further ideas?? > >>> >>> Regards, > >>> Pat. > >>> >>> Send instant messages to your online friends > >>> http://uk.messenger.yahoo.com > >>> >>> _______________________________________________ > >>> Serusers mailing list > >>> serusers(a)lists.iptel.org > >>> http://lists.iptel.org/mailman/listinfo/serusers > >> >> > > Send instant messages to your online friends > > http://uk.messenger.yahoo.com > > Send instant messages to your online friends http://uk.messenger.yahoo.com