Re: [Serusers] ACK

Just curious: Have you used the ONsip.org Getting Started guide, configs

getting started source package!? Rtpproxy is included, while mediaproxy

a standalone package where everything is prepared. Getting this far, you can try to the udp mode: # We set up requests over udp modparam("nathelper", "rtpproxy_sock", "udp:10.56.0.5:22222") Start rtpproxy this way: rtpproxy -l your_up -s udp:* g-) Sebastian Kühner wrote: > Hi, > > I don't have a rtpproxy.pid file. You mean the *.sock file? > > Here is the permission: > srwxr-xr-x 1 root root 0 2005-07-20 18:18 rtpproxy.sock= > > The rtpproxy has to create a pid-file? > > Thanks! > > > ----- Original Message ----- > From: "harry gaillac" &lt;gaillacharry(a)yahoo.fr&gt; > To: "Sebastian Kühner" &lt;skuehner(a)veraza.com&gt; > Sent: Wednesday, July 20, 2005 5:22 PM > Subject: Re: [Serusers] ACK > > >> did you check /var/run/*/rtpproxy.pid >> >> --- Sebastian Kühner &lt;skuehner(a)veraza.com&gt; a écrit : >> >>> Hi! >>> >>> Thanks for your question ;-) >>> >>> I'm using Slackware... >>> >>> ----- Original Message ----- >>> From: "harry gaillac" &lt;gaillacharry(a)yahoo.fr&gt; >>> To: "Sebastian Kühner" &lt;skuehner(a)veraza.com&gt; >>> Sent: Wednesday, July 20, 2005 5:07 PM >>> Subject: Re: [Serusers] ACK >>> >>> >>>> What's your distro Debian, .. ? >>>> >>>> --- Sebastian Kühner &lt;skuehner(a)veraza.com&gt; a écrit >>>> >>>> >>>>> It should... but it doesn't. I have ser 0.9.0 >>> and >>>>> the latest rtpproxy >>>>> version. >>>>> >>>>> WARNING: rtpp_test: can't get version of the RTP >>>>> proxy >>>>> >>>>> >>>>> >>>>> >>>>> ----- Original Message ----- >>>>> From: "harry gaillac" &lt;gaillacharry(a)yahoo.fr&gt; >>>>> To: "Sebastian Kühner" &lt;skuehner(a)veraza.com&gt; >>>>> Sent: Wednesday, July 20, 2005 1:44 PM >>>>> Subject: Re: [Serusers] ACK >>>>> >>>>> >>>>>> your rtpproxy should work ! >>>>>> >>>>>> --- Sebastian Kühner &lt;skuehner(a)veraza.com&gt; a >>> écrit >>>>>> >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> Ok, my rtpproxy doesn't work, so I try it with STUN. >>>>>>> When I look at my >>>>>>> SIP-messages I get the information, that the >>>>> audio >>>>>>> stream has to go through >>>>>>> my public IP... but I don't hear anything (I >>>>> have >>>>>>> the volume on maximum). >>>>>>> >>>>>>> The Invite comes with this message: >>>>>>> >>>>>>> v=0. >>>>>>> o=- 3330865830 3330865830 IN IP4 >>>>> xxx.xxx.xxx.xxx. >>>>>>> <-- Public IP >>>>>>> s=SJphone. >>>>>>> c=IN IP4 xxx.xxx.xxx.xxx >>> <-- >>>>>>> Public IP >>>>>>> t=0 0. >>>>>>> a=direction:active. >>>>>>> m=audio 16482 RTP/AVP 3 8 0 101. >>>>>>> a=rtpmap:3 GSM/8000. >>>>>>> a=rtpmap:8 PCMA/8000. >>>>>>> a=rtpmap:0 PCMU/8000. >>>>>>> a=rtpmap:101 telephone-event/8000. >>>>>>> a=fmtp:101 0-11,16. >>>>>>> >>>>>>> Doesn't that mean, that the audio-stream has to go >>>>>>> through my public IP now? >>>>>>> Both sides doesn't hear anything... >>>>>>> >>>>>>> What's wrong? >>>>>>> >>>>>>> Sebastian >>>>>>> >>>>>>> >>>>>>> >>>>>>> ----- Original Message ----- >>>>>>> From: "Greger V. Teigre" &lt;greger(a)teigre.com&gt; >>>>>>> To: "Sebastian Kühner" >>> &lt;skuehner(a)veraza.com&gt;om>; >>>>>>> &lt;serusers(a)lists.iptel.org&gt; >>>>>>> Sent: Wednesday, July 20, 2005 2:24 AM >>>>>>> Subject: Re: [Serusers] ACK >>>>>>> >>>>>>> >>>>>>>> Sebastian, >>>>>>>> I know many people don't like STUN. However, I have good >>>>>>>> experiences with STUN and prefer to use STUN as a "first layer >>>>>>>> defence." For many NATs I then avoid the proxying. However, >>>>>>>> there >>> are >>>>> some >>>>>>> things that can go wrong: >>>>>>>> For one, you need to make sure that the >>> STUN >>>>>>> server is running correctly >>>>>>> on >>>>>>>> two ports and two IP addresses. If you for >>>>> example >>>>>>> have a firewall >>>>>>> blocking >>>>>>>> one port, STUN will give the wrong result. >>> But >>>>> the >>>>>>> biggest problem can be >>>>>>>> faulty STUN implementations in the EUCs. They normally behave >>>>>>>> ok for the most standard NATs, but there are some >>>>>>> non-standard NATs and the EUC's >>>>>>>> behavior can be unpredictable. Also, some EUCs try to rewrite >>>>>>>> the IP:port even if they are behind a symmetric NAT >>> (or if >>>>> the >>>>>>> STUN server is not >>>>>>>> correctly set up, the EUC will conclude >>> with >>>>> the >>>>>>> wrong result). >>>>>>>> If you know the clients you are going >>> to >>>>> use, >>>>>>> you can test and limit >>>>>>> the >>>>>>>> problems and STUN can be a great cost >>> saver! >>>>> If >>>>>>> your gateway supports >>>>>>>> active media (direction=active), then you only have IP-2-IP >>>>>>>> phone calls to proxy. >>>>>>>> >>>>>>>> To your question: Sipura has a good implementation of STUN, >>>>>>>> but has MANY options for NAT. Your problem is that the >>> RTP >>>>> and >>>>>>> RTCP is not traversing >>>>>>> the >>>>>>>> NAT to your Sipura. Either you don't >>> force >>>>>>> proxying in onreply for OKs, >>>>>>> or >>>>>>>> something goes wrong. An ngrep trace of >>> the >>>>> call >>>>>>> setup will reveal what >>>>>>> the >>>>>>>> problem can be. >>>>>>>> g-) >>>>>>>> >>>>>>>> Sebastian Kühner wrote: >>>>>>>>> Thank you Nils, >>>>>>>>> >>>>>>>>> Now it's working better! >>>>>>>>> >>>>>>>>> The problem that I have now is that I >>> don't >>>>> hear >>>>>>> anything if I call >>>>>>>>> from the SIPURA to a Gateway, but the >>> callee >>>>> is >>>>>>> hearing me. >>>>>>>>> >>>>>>>>> What could be the problem of that one-way conversation? Had >>>>>>>>> anyone of you the same problem using a Restricted Cone NAT? >>>>>>>>> >>>>>>>>> Thanks! >>>>>>>>> >>>>>>>>> Sebastian >>>>>>>>> >>>>>>>>> >>>>>>>>> ----- Original Message ----- >>>>>>>>> From: "Nils Ohlmeier" >>> &lt;lists(a)ohlmeier.org&gt; >>>>>>>>> To: &lt;serusers(a)lists.iptel.org&gt; >>>>>>>>> Cc: "Sebastian Kühner" >>> &lt;skuehner(a)veraza.com&gt; >>>>>>>>> Sent: Tuesday, July 19, 2005 3:58 PM >>> >> === message truncated === >> >> >> >> >> >> >> >> >