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" skuehner@veraza.com; 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" lists@ohlmeier.org To: serusers@lists.iptel.org Cc: "Sebastian Kühner" skuehner@veraza.com Sent: Tuesday, July 19, 2005 3:58 PM Subject: Re: [Serusers] ACK
Hi,
On Tuesday 19 July 2005 20:53, Sebastian Kühner
wrote:
I have two phones behind a Port Restricted Cone
NAT (both in the same
private area) and ser is running with another
public IP.
I want to call from one of those phone to the
other. The call is set
up and I can talk, but one Softphone shows me
the message: "Waiting
acknowledgement..."... and all followed SIP
messages don't reach the
other phone. I'm using a STUN server.
Call from 14@xxx.xxx.xxx.xxx:5060 to
13@xxx.xxx.xxx.xxx:1024:
14 -> ser:
IVITE 13@ip.of.ser.xxx@5060 (Contact:
14@192.168.1.101:5060)
ser -> 13:
INVITE 13@xxx.xxx.xxx.xxx:1024 (Contact:
14@xxx.xxx.xxx.xxx:5060)
sorry but what do you use STUN for if the UAs
still use their private
IPs and your SER is re-writting the Contact? If you
allready fixing the IP it
should be easy to fix the port as well.
Conclusion: throw away STUN. In case of
symmetric NATs you have to
find another solution anyway. And you really do
not want to try to
determine the NAT type with STUN.
Nils
13 -> ser
Trying and ringing (Contact:
13@xxx.xxx.xxx.xxx:5060)
(!!!!!!!!!!! <-- wrong port !!!!!!!)
13 -> ser
OK (Contact: 13@xxx.xxx.xxx.xxx:5060) (!!!!!!!!!!! <-- wrong port !!!!!!!)
ser -> 14
OK (Contact: 13@xxx.xxx.xxx.xxx:5060) (!!!!!!!!!!! <-- wrong port !!!!!!!)
14 -> ser
ACK 13@xxx.xxx.xxx.xxx:5060
ser -> 14
ACK 13@xxx.xxx.xxx.xxx:5060
14 -> ser
ACK 13@xxx.xxx.xxx.xxx:5060
... and so on... until timeout.
Does anybody know what is the problem... or
better: the solution?
Thanks!
Sebastian
=== 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
-
Sebastian Kühner