[Serusers] ACK

[Sebastian Kühner]

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 at teigre.com>
To: "Sebastian Kühner" <skuehner at veraza.com>; <serusers at 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 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
>
>
>