On 21/04/15 10:40 PM, GG GG wrote:
> By port closed, I mean that ports are normally closed, but when
> rtpengine send the first rtp packets to the client, it opens a pinhole
> in the firewall, and the matching incoming packets from the client will
> make the connection established,related in iptabl
You might want to read up on ICE (STUN & TURN) and SRTP / DTLS which
broadly resolve your issues.
On 21 April 2015 at 23:40, GG GG wrote:
> By port closed, I mean that ports are normally closed, but when rtpengine
> send the first rtp packets to the client, it opens a pinhole in the
> firewall,
By port closed, I mean that ports are normally closed, but when rtpengine
send the first rtp packets to the client, it opens a pinhole in the
firewall, and the matching incoming packets from the client will make the
connection established,related in iptables. I think symmetric nat permits
that.
Bu
On 21/04/15 11:04 AM, GG GG wrote:
> Hello,
>
> what do you think about opening all RTP ports for rtpengine on Internet,
> is it a bad practice ?
>
> I wonder if it's possible to use rtpengine with all ports closed.
Not sure what you mean with "ports closed." How would rtpengine, or any
other RT
Hello,
what do you think about opening all RTP ports for rtpengine on Internet, is
it a bad practice ?
I wonder if it's possible to use rtpengine with all ports closed.
Maybe someone could explain how rtpengine learn the source address when the
SDP contains a local address.
If your rtpengine se
