7 Apr
2005
7 Apr
'05
10:48 p.m.
> > > > > > Make sure you are not
behind a Symmetric NAT. If so, you're
> > > > > > dead. STUN does not work with Symmetric NAT.
> > > > >
> > > > > If a UA is behind Symmetric NAT, and
> > > > > UA use STUN, and
> > > > > SER have [RTP/Media]Proxy to handle Symmetric NAT,
> > > > > this UA should be fine, right?
> > > >
> > > > Yes, but, if UA is behind symmetric NAT, I would not
> > > > configure STUN to it. I'd just led mediaproxy solve the problem.
> > >
> > > But if you have 100 clients,
> > > it would be hard to put all clients in one group.
> >
> > LA> Good point !
> >
> > LA> Yes, it is true. If stun can not solve the nat problem,
> > media proxy
> > LA> should fix it with no trouble at all.
> >
> If there is no symmetric NAT and I have installed
STUN and
> Mediaproxy on my server. Which one will have higher priority
> to handle this call session? Is it always STUN? Of course if
> I don't need to pass the call to PSTN gateway. Just IP-phone
> to IP-phone. Can you set the priority in ser.cfg? and how?
LA> It is not a matter of priorities. It depends on how you get your
LA> mediaproxy configured. You need to be aware that nated clients should
LA> use the media proxy, because of the nat problem. But, if your client can
LA> find ( using stun for example ) his public ip/port, then, from
LA> mediaproxy point of view, this client is not nated, and so, it needs not
LA> treatment ( no fixing from part of media proxy ).
LA> You can always do this: Get every traffic proxied along mediaproxy. But,
LA> if clients can talk to each other being able to bypass mediaproxy, why
LA> should you proxy your communications ???
LA> Hope to be clear
LA> Regards,
LA> Lucas
Thank you, it makes sence.
It would be the best solution I'd say, but it reminds me JavaRocks
statement that STUN makes problems in some circumstances.. Just wondering what problems?
Maybe some UA's not supporting STUN?
Lada