Hi!
I tried to use the "modparam("nathelper", "rtpproxy_sock", "udp:10.56.0.5:22222")"... but without result.
I downloaded the ONsip-package (without using it... postgres is implemented there?), but I didn't find the Getting Started guide...
----- Original Message ----- From: "Greger V. Teigre" greger@teigre.com To: "Sebastian Kühner" skuehner@veraza.com; serusers@lists.iptel.org Sent: Thursday, July 21, 2005 2:20 AM Subject: Re: [Serusers] ACK
Just curious: Have you used the ONsip.org Getting Started guide, configs
and
getting started source package!? Rtpproxy is included, while mediaproxy
is
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" gaillacharry@yahoo.fr To: "Sebastian Kühner" skuehner@veraza.com Sent: Wednesday, July 20, 2005 5:22 PM Subject: Re: [Serusers] ACK
did you check /var/run/*/rtpproxy.pid
--- Sebastian Kühner skuehner@veraza.com a écrit :
Hi!
Thanks for your question ;-)
I'm using Slackware...
----- Original Message ----- From: "harry gaillac" gaillacharry@yahoo.fr To: "Sebastian Kühner" skuehner@veraza.com Sent: Wednesday, July 20, 2005 5:07 PM Subject: Re: [Serusers] ACK
What's your distro Debian, .. ?
--- Sebastian Kühner skuehner@veraza.com 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" gaillacharry@yahoo.fr To: "Sebastian Kühner" skuehner@veraza.com Sent: Wednesday, July 20, 2005 1:44 PM Subject: Re: [Serusers] ACK
> your rtpproxy should work ! > > --- Sebastian Kühner skuehner@veraza.com 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" greger@teigre.com >> To: "Sebastian Kühner"
>> serusers@lists.iptel.org >> 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"
>>>> To: serusers@lists.iptel.org >>>> Cc: "Sebastian Kühner"
>>>> Sent: Tuesday, July 19, 2005 3:58 PM
=== message truncated ===
___________________________________________________________________________
Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo! Messenger Téléchargez cette version sur http://fr.messenger.yahoo.com
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers