[Serusers] ACK

[Greger V. Teigre]

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 at ohlmeier.org>
> To: <serusers at lists.iptel.org>
> Cc: "Sebastian Kühner" <skuehner at 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 at xxx.xxx.xxx.xxx:5060 to 13 at xxx.xxx.xxx.xxx:1024:
>>
>> 14 -> ser:
>> ----------
>> IVITE 13 at ip.of.ser.xxx@5060  (Contact: 14 at 192.168.1.101:5060)
>>
>> ser -> 13:
>> ----------
>> INVITE 13 at xxx.xxx.xxx.xxx:1024 (Contact: 14 at 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 at xxx.xxx.xxx.xxx:5060)
>> (!!!!!!!!!!! <-- wrong port !!!!!!!)
>>
>> 13 -> ser
>> ---------
>> OK (Contact: 13 at xxx.xxx.xxx.xxx:5060)
>> (!!!!!!!!!!! <-- wrong port !!!!!!!)
>>
>> ser -> 14
>> ----------
>> OK (Contact: 13 at xxx.xxx.xxx.xxx:5060)
>> (!!!!!!!!!!! <-- wrong port !!!!!!!)
>>
>> 14 -> ser
>> ----------
>> ACK 13 at xxx.xxx.xxx.xxx:5060
>>
>> ser -> 14
>> ---------
>> ACK 13 at xxx.xxx.xxx.xxx:5060
>>
>> 14 -> ser
>> ----------
>> ACK 13 at 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 at lists.iptel.org
>> http://lists.iptel.org/mailman/listinfo/serusers
>
>
>
> _______________________________________________
> Serusers mailing list
> serusers at lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serusers