21 Jul
2005
21 Jul
'05
7:20 a.m.
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(a)yahoo.fr>
To: "Sebastian Kühner" <skuehner(a)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(a)veraza.com> a écrit :
___________________________________________________________________________
Hi!
Thanks for your question ;-)
I'm using Slackware...
----- Original Message -----
From: "harry gaillac" <gaillacharry(a)yahoo.fr>
To: "Sebastian Kühner" <skuehner(a)veraza.com>
Sent: Wednesday, July 20, 2005 5:07 PM
Subject: Re: [Serusers] ACK
=== message truncated ===
What's your distro Debian, .. ?
--- Sebastian Kühner <skuehner(a)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(a)yahoo.fr>
> To: "Sebastian Kühner" <skuehner(a)veraza.com>
> Sent: Wednesday, July 20, 2005 1:44 PM
> Subject: Re: [Serusers] ACK
>
>
>> your rtpproxy should work !
>>
>> --- Sebastian Kühner <skuehner(a)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(a)teigre.com>
>>> To: "Sebastian Kühner"
<skuehner(a)veraza.com>om>;
>>> <serusers(a)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"
<lists(a)ohlmeier.org>
>>>>> To:
<serusers(a)lists.iptel.org>
>>>>> Cc: "Sebastian Kühner"
<skuehner(a)veraza.com>
>>>>> Sent: Tuesday, July 19, 2005
3:58 PM
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(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers