[prev in list] [next in list] [prev in thread] [next in thread] 

List:       serusers
Subject:    Re: [SR-Users] Rtpengine vs. TURN?
From:       Daniel-Constantin Mierla <miconda () gmail ! com>
Date:       2014-07-25 9:13:05
Message-ID: 53D21FA1.5070007 () gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]


Hello,

On 14/07/14 15:49, Peter Villeneuve wrote:
> 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
>
> Cheers,
> Peter
>
>
> On Mon, Jul 14, 2014 at 2:18 PM, Daniel-Constantin Mierla 
> <miconda@gmail.com <mailto:miconda@gmail.com>> wrote:
>
>     Hello,
>
>
>     On 12/07/14 19:55, Peter Villeneuve wrote:
>
>         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
>     sr-users@lists.sip-router.org <mailto:sr-users@lists.sip-router.org>
>     http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
>

-- 
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda


[Attachment #5 (text/html)]

<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Hello,<br>
    <br>
    <div class="moz-cite-prefix">On 14/07/14 15:49, Peter Villeneuve
      wrote:<br>
    </div>
    <blockquote
cite="mid:CAEiJqQNeT1OEBwmsS00a_oZ97RAEfXhpHQYqJPNNyiJwV72iGQ@mail.gmail.com"
      type="cite">
      <div dir="ltr">Hi Daniel,
        <div><br>
        </div>
        <div>Thanks for your input. Since I couldn't decide which one to
          use, I've been experimenting with using both.</div>
        <div>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.</div>
        <div><br>
        </div>
        <div>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.</div>
        <div><br>
        </div>
        <div>What's the best way to do this?</div>
      </div>
    </blockquote>
    <br>
    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.<br>
    <br>
    Cheers,<br>
    Daniel<br>
    <blockquote
cite="mid:CAEiJqQNeT1OEBwmsS00a_oZ97RAEfXhpHQYqJPNNyiJwV72iGQ@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div><br>
        </div>
        <div>Cheers,</div>
        <div>Peter</div>
      </div>
      <div class="gmail_extra"><br>
        <br>
        <div class="gmail_quote">On Mon, Jul 14, 2014 at 2:18 PM,
          Daniel-Constantin Mierla <span dir="ltr">&lt;<a
              moz-do-not-send="true" href="mailto:miconda@gmail.com"
              target="_blank">miconda@gmail.com</a>&gt;</span> wrote:<br>
          <blockquote class="gmail_quote" style="margin:0 0 0
            .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello,
            <div>
              <div class="h5"><br>
                <br>
                On 12/07/14 19:55, Peter Villeneuve wrote:<br>
                <blockquote class="gmail_quote" style="margin:0 0 0
                  .8ex;border-left:1px #ccc solid;padding-left:1ex">
                  Hi,<br>
                  <br>
                  On my server, I have the option of using either
                  Rtpengine for NAT traversal or pure TURN without
                  rtpengine.<br>
                  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.<br>
                  <br>
                  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?<br>
                  <br>
                </blockquote>
              </div>
            </div>
            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.<br>
            <br>
            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).<br>
            <br>
            Cheers,<br>
            Daniel<span class="HOEnZb"><font color="#888888"><br>
                <br>
                -- <br>
                Daniel-Constantin Mierla - <a moz-do-not-send="true"
                  href="http://www.asipto.com" \
target="_blank">http://www.asipto.com</a><br>  <a moz-do-not-send="true"
                  href="http://twitter.com/#%21/miconda" \
                target="_blank">http://twitter.com/#!/miconda</a>
                - <a moz-do-not-send="true"
                  href="http://www.linkedin.com/in/miconda"
                  target="_blank">http://www.linkedin.com/in/miconda</a><br>
                <br>
                <br>
                _______________________________________________<br>
                SIP Express Router (SER) and Kamailio (OpenSER) -
                sr-users mailing list<br>
                <a moz-do-not-send="true"
                  href="mailto:sr-users@lists.sip-router.org"
                  target="_blank">sr-users@lists.sip-router.org</a><br>
                <a moz-do-not-send="true"
                  href="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users"
                
                  target="_blank">http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users</a><br>
  </font></span></blockquote>
        </div>
        <br>
      </div>
    </blockquote>
    <br>
    <pre class="moz-signature" cols="72">-- 
Daniel-Constantin Mierla - <a class="moz-txt-link-freetext" \
href="http://www.asipto.com">http://www.asipto.com</a> <a \
class="moz-txt-link-freetext" \
href="http://twitter.com/#!/miconda">http://twitter.com/#!/miconda</a> - <a \
class="moz-txt-link-freetext" \
href="http://www.linkedin.com/in/miconda">http://www.linkedin.com/in/miconda</a></pre>
  </body>
</html>



_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users


[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic