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

> When I look at my > SIP-messages I get the information, that the

> stream has to go through > my public IP... but I don't hear anything (I

> the volume on maximum). > > The Invite comes with this message: > > v=0. > o=- 3330865830 3330865830 IN IP4

> <-- 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

> through my public IP now? > Both sides doesn't hear anything... > > What's wrong? > > Sebastian > > > > ----- Original Message ----- > From: "Greger V. Teigre" &lt;greger(a)teigre.com&gt; > To: "Sebastian Kühner" &lt;skuehner(a)veraza.com&gt;om>; > &lt;serusers(a)lists.iptel.org&gt; > 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

> 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

> have a firewall > blocking > > one port, STUN will give the wrong result. But

> 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

> try to rewrite the IP:port > > even if they are behind a symmetric NAT (or if

> STUN server is not > > correctly set up, the EUC will conclude with

> wrong result). > > If you know the clients you are going to

> you can test and limit > the > > problems and STUN can be a great cost saver!

> 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

> of STUN, but has MANY > > options for NAT. Your problem is that the RTP

> 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

> 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

> anything if I call > > > from the SIPURA to a Gateway, but the callee

> 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" &lt;lists(a)ohlmeier.org&gt; > > > To: &lt;serusers(a)lists.iptel.org&gt; > > > Cc: "Sebastian Kühner" &lt;skuehner(a)veraza.com&gt; > > > Sent: Tuesday, July 19, 2005 3:58 PM > > > Subject: Re: [Serusers] ACK > > > > > > > > > Hi, > > > > > > On Tuesday 19 July 2005 20:53, Sebastian

> wrote: > > >> I have two phones behind a Port Restricted

> NAT (both in the same > > >> private area) and ser is running with

> public IP. > > >> > > >> I want to call from one of those phone to

> other. The call is set > > >> up and I can talk, but one Softphone shows

> 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

> still use their private > > > IPs and > > > your SER is re-writting the Contact? If you > allready fixing the IP it