[Serusers] ACK

Sebastian Kühner skuehner at veraza.com
Wed Jul 20 18:53:49 CEST 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" <gaillacharry at yahoo.fr>
To: "Sebastian Kühner" <skuehner at veraza.com>
Sent: Wednesday, July 20, 2005 1:44 PM
Subject: Re: [Serusers] ACK


> your rtpproxy should work !
>
> --- Sebastian Kühner <skuehner at veraza.com> 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" <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
> >
> === 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
>
>





More information about the sr-users mailing list