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
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers