[SR-Users] Rtpengine vs. TURN?

[Peter Villeneuve]

Hi,

On my server, I have the option of using either Rtpengine for NAT traversal
or pure TURN without rtpengine.
Rtpengine has the obvious plus that it only needs 1 public IP, while TURN
(with STUN) will need 2 public IPs, although that's not a problem in my
case.

Having said that, I'd like to take advantage of the huge experience that
users of this list have in real world deployments. in your experience,
which option is more reliable in a real world deployment?

Cheers,
Peter

[Daniel-Constantin Mierla]

Hello,

Post by Peter Villeneuve
Hi,
On my server, I have the option of using either Rtpengine for NAT
traversal or pure TURN without rtpengine.
Rtpengine has the obvious plus that it only needs 1 public IP, while
TURN (with STUN) will need 2 public IPs, although that's not a problem
in my case.
Having said that, I'd like to take advantage of the huge experience
that users of this list have in real world deployments. in your
experience, which option is more reliable in a real world deployment?

TURN is a more standard way, but it requires support in the client
implementation and not many of the (rather old) sip hardphones don't
support that.

A RTP relay (like rtpengine, rtpproxy) is server only solution, not
requiring anything in the client side. On the other hand is an exposure
to less privacy if you don't encrypt the rtp (just because the server
controls where to send media).

Cheers,
Daniel

[Peter Villeneuve]

Hi Daniel,

Thanks for your input. Since I couldn't decide which one to use, I've been
experimenting with using both.
The problem with my mixed approach is that there are too many ICE
candidates created (I counted 10 in the last logs I looked at for one
call), real relay candidates (turn), and fake host candidates (rtpengine)
with different priorities which leads to all kinds of problems.

I think I'll stick to TURN since my clients have support for it. Still, I'd
like to keep using the NAT traversal (or more accurately NAT detection)
support of Kamailio, but I don't want rtpproxy-ng to add any ICE candidates
at all. The reason I need some NAT support in Kamailio is that although
most of my clients support ICE/STUN/TURN, others use Jitsi which has no
support for these protocols, and I need a way to connect to Jitsi clients
that register from behind NAT.

What's the best way to do this?

Cheers,
Peter

Post by Daniel-Constantin Mierla
Hello,

Post by Peter Villeneuve
Hi,
On my server, I have the option of using either Rtpengine for NAT
traversal or pure TURN without rtpengine.
Rtpengine has the obvious plus that it only needs 1 public IP, while TURN
(with STUN) will need 2 public IPs, although that's not a problem in my
case.
Having said that, I'd like to take advantage of the huge experience that
users of this list have in real world deployments. in your experience,
which option is more reliable in a real world deployment?
TURN is a more standard way, but it requires support in the client

implementation and not many of the (rather old) sip hardphones don't
support that.
A RTP relay (like rtpengine, rtpproxy) is server only solution, not
requiring anything in the client side. On the other hand is an exposure to
less privacy if you don't encrypt the rtp (just because the server controls
where to send media).
Cheers,
Daniel
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

[Daniel-Constantin Mierla]

Hello,

Post by Peter Villeneuve
Hi Daniel,
Thanks for your input. Since I couldn't decide which one to use, I've
been experimenting with using both.
The problem with my mixed approach is that there are too many ICE
candidates created (I counted 10 in the last logs I looked at for one
call), real relay candidates (turn), and fake host candidates
(rtpengine) with different priorities which leads to all kinds of
problems.
I think I'll stick to TURN since my clients have support for it.
Still, I'd like to keep using the NAT traversal (or more accurately
NAT detection) support of Kamailio, but I don't want rtpproxy-ng to
add any ICE candidates at all. The reason I need some NAT support in
Kamailio is that although most of my clients support ICE/STUN/TURN,
others use Jitsi which has no support for these protocols, and I need
a way to connect to Jitsi clients that register from behind NAT.
What's the best way to do this?

you can keep rtpproxy in kamailio.cfg. If there is a turn server, the
SDP should come with a public IP in sdp and then you don't engage the
rtpproxy -- iirc, the rtpproxy or nathelper module has a test to check
if the media ip in sdp is a private address. you can use that for
deciding to do rtp relaying on server or not.

Cheers,
Daniel

Post by Peter Villeneuve
Cheers,
Peter
On Mon, Jul 14, 2014 at 2:18 PM, Daniel-Constantin Mierla
Hello,
Hi,
On my server, I have the option of using either Rtpengine for
NAT traversal or pure TURN without rtpengine.
Rtpengine has the obvious plus that it only needs 1 public IP,
while TURN (with STUN) will need 2 public IPs, although that's
not a problem in my case.
Having said that, I'd like to take advantage of the huge
experience that users of this list have in real world
deployments. in your experience, which option is more reliable
in a real world deployment?
TURN is a more standard way, but it requires support in the client
implementation and not many of the (rather old) sip hardphones
don't support that.
A RTP relay (like rtpengine, rtpproxy) is server only solution,
not requiring anything in the client side. On the other hand is an
exposure to less privacy if you don't encrypt the rtp (just
because the server controls where to send media).
Cheers,
Daniel
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda <http://twitter.com/#%21/miconda> -
http://www.linkedin.com/in/miconda
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users