<div dir="ltr"><div><div>Hey Bogdan, thanks for sharing your ideas for us. In fact all of those items that you have listed are already on drawing board for the next 2-3 months development here:<br><br><tt>  - Send timeout notifications to different OpenSIPS servers
        (more than one)<br>
          - Different timeout values for early media and established
        calls
        (longer for early, shorter for established)<br>
          - Play music on hold in early media state
        <br>
          - Detect on-hold and disable timeouts (search different
        solution here)
        <br>
          - Do not send media timeout if other sessions are active
        (video and audio)
        <br>
          - In bridge mode asymmetric should not be always assumed
        <br>
          - Cache played files instead of reading them from the disk all
        the time
        <br>
        </tt><br></div>I am particularly interested in the timeout notifications and cache for playing files, so maybe you can start with forking out main branch in the github and pushing your patches there? For playing cache, I have been planning to use mmap() and refcounting, so I am particularly curious which path did you take. We need this in order so that we can use rtpproxy to generate test streams for other rtpproxy, or maybe even to itself. I have started some automated regression testing suite here we will be pushing it our pretty soon.<br>
<br><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Jun 20, 2014 at 2:22 AM, Bogdan-Andrei Iancu <span dir="ltr">&lt;<a href="mailto:bogdan@opensips.org" target="_blank">bogdan@opensips.org</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF" text="#000000">
    <div><tt>Hello Maxim, Hello Jev,<br>
        <br>
        Sorry for taking so long to answer to these emails.<br>
        <br>
        I&#39;m really glad to find out that the rtpproxy project is
        actually moving along and even more, evolving - it is a critical
        component in our platforms (and for most OpenSIPS deployments)
        and we got a bit concerned about what is going on with rtpp. To
        be honest, we had on the table the possibility to fork it and
        continue by ourselves - but I do not want to re-invent the wheel
        or to pollute the environment with yet another relay relaying
        tool (anyhow, there is this rtpengine stuff popping around
        lately )<br>
        <br>
        We will be more than happy to get involved - as ideas,
        experience and work - in the rtpproxy evolution ; of course, if
        you guys are willing to accept it :).  One again , rtpproxy is
        too important to us to stay neutral and lately there are more
        and more features touching both SIP and RTP ....so there is a
        strong need for a better integration between OpenSIPS and
        RTPProxy, IMHO.<br>
        <br>
        Now, technically speaking, the kind of problems we mainly faced
        are (a) scaling with HW (especially with the old single threaded
        model), (b) redundancy and (c) controlling streams (multiple
        streams audio/video in the same SIP session, on-hold, etc).<br>
        <br>
        What we did (and have as patches):</tt><tt><br>
          - Send timeout notifications to different OpenSIPS servers
        (more than one)<br>
          - Different timeout values for early media and established
        calls
        (longer for early, shorter for established)<br>
          - Play music on hold in early media state
        <br>
          - Detect on-hold and disable timeouts (search different
        solution here)
        <br>
          - Do not send media timeout if other sessions are active
        (video and audio)
        <br>
          - In bridge mode asymmetric should not be always assumed
        <br>
          - Cache played files instead of reading them from the disk all
        the time
        <br>
        <br>
        <br>
        Also we are looking into new features (things that we can work
        together) :
        <br>
          - better structuring between sessions and streams <br>
          - Send timeout notifications over UDP
        <br>
          - Force specific ports in reply, if possible
        <br>
          - Failover support
        <br>
          - Provide statistics per session (even ended)
        back to OpenSIPS<br>
          - Restart persistent
        <br>
          - Change learning period (possibly linked with on-hold media
        disable)
        <br>
          - ICE support
        <br>
          - SRTP to RTP conversion
        <br>
        <br>
        Definitly we can look into transcoding part too - what we did is
        for Sangoma cards (so HW transcoding, not SW).<br>
        <br>
        <br>
        <br>
        So, we will look into the new work you guys did on rtpproxy - to
        have a starting point for the future planning. After that, if
        you agree on having us contributing to the rtpproxy, we can get
        involved in planning and actual development.<br>
        <br>
        Best regards,<br>
      </tt><div class="">
      <pre cols="72">Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
<a href="http://www.opensips-solutions.com" target="_blank">http://www.opensips-solutions.com</a></pre></div><div><div class="h5">
      On 20.06.2014 02:16, Jev Björsell wrote:<br>
    </div></div></div><div><div class="h5">
    <blockquote type="cite">
      <div dir="ltr">Hi Guys,
        <div><br>
        </div>
        <div>Some updates on the rtpproxy project;</div>
        <div><br>
        </div>
        <div>We have now moved the rtpproxy project from sourceforge to
          github <a href="http://github.com/sippy/rtpproxy" target="_blank">http://github.com/sippy/rtpproxy</a></div>
        <div><br>
        </div>
        <div>This change should make the project more visibility &amp;
          and transparency. Please feel free to create Issues for
          feature requests and bugs, and of course Pull Requests are
          appreciated! :)</div>
        <div><br>
        </div>
        <div>We have also moved the mailing list over to Google Groups: <a href="https://groups.google.com/forum/#%21forum/rtpproxy" target="_blank">https://groups.google.com/forum/#!forum/rtpproxy</a> </div>
        <div><br>
        </div>
        <div>We will do a maintenance release - version 1.3, and  Max is
          busy working on a 2.0 release, which has some significant
          improvements to jitter characteristics,  and performance.</div>
        <div><br>
        </div>
        <div>Best Regards,</div>
        <div>-Jev</div>
        <div><br>
        </div>
        <div class="gmail_extra"><br>
          <br>
          <div class="gmail_quote">On Mon, Jun 9, 2014 at 8:25 AM, Maxim
            Sobolev <span dir="ltr">&lt;<a href="mailto:sobomax@sippysoft.com" target="_blank">sobomax@sippysoft.com</a>&gt;</span>
            wrote:<br>
            <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
              <div dir="ltr">
                <div>
                  <div>
                    <div>
                      <div>Hey Bogdan, sorry for missing your message.
                        The mail traffic these days is insane, so it&#39;s
                        hard to keep atop of all issues. <br>
                        <br>
                      </div>
                      We are working behind the scene on what would
                      become rtpproxy 2.0, the code is pretty stable and
                      we have it deployed in like 30-40 places. The main
                      changes are in the timing loop, which improves the
                      jitter significantly and recently we&#39;ve also split
                      UDP sending code into its own thread(s). That code
                      is available here: <a href="https://bitbucket.org/sippysoft/rtpproxy" target="_blank">https://bitbucket.org/sippysoft/rtpproxy</a>.
                      It&#39;s only tested to compile on FreeBSD, but it
                      should not be difficult to compile it on Linux.
                      This basically pushes it to the limits of what&#39;s
                      possible to achieve with the standard POSIX
                      facilities. We&#39;ve been able to push 16-core
                      machine up to 400KPPS in and 400KPPS out with it,
                      all the way up to 90% CPU, while the older version
                      started choking at about 30%. Our plan is to tie
                      few loose ends and push it out to the official
                      repo as a basis for 2.0. <br>
                      <br>
                    </div>
                    Beyond 2.0, there is another project in progress
                    that is using novel netmap framework to overcome
                    performance issues of the traditional kernel-based
                    socket API. This potentially would allow us to
                    increase capacity at least 5 times on the comparable
                    hardware. The framework itself is pretty low-level,
                    so I am working on a library that would allow it to
                    be more easily integrated into an app. The WiP code
                    is here. <a href="https://bitbucket.org/sobomax/libsinet" target="_blank">https://bitbucket.org/sobomax/libsinet</a>.
                    <br>
                    <br>
                  </div>
                  Another direction that we are going to explore is to
                  add transcoding support. We have 2 cards in our lab
                  now and setting up the devtesting system just today.
                  I&#39;ve heard that you have done some work in this
                  direction, so if you want to share something with us,
                  we would be very interested to look at those patches.<br>
                  <br>
                </div>
                <div>On the open-source side we plan to move the project
                  into some modern project management facility, the
                  favorite being github. My colleague Jev is driving
                  this change.<br>
                  <br>
                </div>
                In general I don&#39;t mind giving you or anyone else from
                the OpenSIPS team read-write access to repository if you
                feel like integrating some of your patches.<br>
                <div class="gmail_extra"><br>
                  <br>
                  <div class="gmail_quote">On Mon, Apr 14, 2014 at 5:03
                    AM, Bogdan-Andrei Iancu <span dir="ltr">&lt;<a href="mailto:bogdan@opensips.org" target="_blank">bogdan@opensips.org</a>&gt;</span>
                    wrote:<br>
                    <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello
                      Maxim,<br>
                      <br>
                      Long time, no talks, but I hope everything is fine
                      on your side.<br>
                      <br>
                      I&#39;m reaching you in order to ask about your future
                      plans in regards to the rtpproxy project? We see
                      no much activity around it and other media relays
                      are popping around.<br>
                      <br>
                      RTPP is an essential component for us, we invested
                      a lot of work, we have many patches (extensions)
                      for it (which we want to push to the public tree,
                      but there is no answer on this) and we are also
                      looking for investing a lot into big future plans
                      (as adding more functionalities).<br>
                      <br>
                      Now, my question is - what is your commitment and
                      disponibility for the RTPP project ? depending on
                      that we what to re-position ourselves, as we do
                      not want to waste time and work on things which
                      are out of control.<br>
                      <br>
                      Best regards,<span><font color="#888888"><span><font color="#888888"><br>
                              <br>
                              -- <br>
                              Bogdan-Andrei Iancu<br>
                              OpenSIPS Founder and Developer<br>
                              <a href="http://www.opensips-solutions.com" target="_blank">http://www.opensips-solutions.com</a><br>
                              <br>
                            </font></span></font></span></blockquote>
                  </div>
                  <span><font color="#888888"><br>
                      <br clear="all">
                      <br>
                      -- <br>
                      <div dir="ltr">Maksym Sobolyev<br>
                        Sippy Software, Inc.<br>
                        Internet Telephony (VoIP) Experts<br>
                        Tel (Canada): <a href="tel:%2B1-778-783-0474" value="+17787830474" target="_blank">+1-778-783-0474</a><br>
                        Tel (Toll-Free): <a href="tel:%2B1-855-747-7779" value="+18557477779" target="_blank">+1-855-747-7779</a><br>
                        Fax: <a href="tel:%2B1-866-857-6942" value="+18668576942" target="_blank">+1-866-857-6942</a><br>
                        Web: <a href="http://www.sippysoft.com" target="_blank">http://www.sippysoft.com</a><br>
                        MSN: <a href="mailto:sales@sippysoft.com" target="_blank">sales@sippysoft.com</a><br>
                        Skype: SippySoft<br>
                      </div>
                    </font></span></div>
              </div>
            </blockquote>
          </div>
          <br>
        </div>
      </div>
    </blockquote>
    <br>
  </div></div></div>

</blockquote></div><br><br clear="all"><br>-- <br><div dir="ltr">Maksym Sobolyev<br>Sippy Software, Inc.<br>Internet Telephony (VoIP) Experts<br>Tel (Canada): +1-778-783-0474<br>Tel (Toll-Free): +1-855-747-7779<br>Fax: +1-866-857-6942<br>
Web: <a href="http://www.sippysoft.com" target="_blank">http://www.sippysoft.com</a><br>MSN: <a href="mailto:sales@sippysoft.com" target="_blank">sales@sippysoft.com</a><br>Skype: SippySoft<br></div>
</div>