Re: [Serusers] ACK - sr-users

20 Jul 2005

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" &lt;gaillacharry(a)yahoo.fr&gt;
To: "Sebastian Kühner" &lt;skuehner(a)veraza.com&gt;
Sent: Wednesday, July 20, 2005 1:44 PM
Subject: Re: [Serusers] ACK

...
  your rtpproxy should work !

 --- Sebastian Kühner &lt;skuehner(a)veraza.com&gt; 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" &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 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" &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 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