[Devel] rtpproxy: rtpproxy_sock as an avp

[Ovidiu Sas]

Hi Bogdan,


The proposed solution would work great.  Since the nathelper module
already has LB support built in (there is support to reconnect to an
rtpproxy), it would be interesting to load the set of rtpproxy from
the database.  Like this, we would be able to add/remove rtpproxy
servers on the fly (no need to restart openser), change the rtpproxy
sets on the fly, remap the rtpproxy sets on the fly.  I was thinking
about caching the rtpproxy servers in memory and reload them from the
db via a fifo command after a db reconfig.


Regards,
Ovidiu Sas

On 4/3/07, Bogdan-Andrei Iancu <bogdan at voice-system.ro> wrote:
> Hi Ovidiu, Hi Daryl,
>
> this functionality was discussed for a long time and I agree with you it
> is useful - I also felt the need for it couple of times ;).
>
> what I suggest is the following:
>     - via configuration you can define sets of rtpproxys (multiple sets)
>     - from script, you can specify the set to be used; nathelper will
> perform LB inside that set.
>
> by this, we preserve the LB functionality and achieve more control also.
>
>
> does this sounds reasonable to you?
>
> regards,
> bogdan
>
> Ovidiu Sas wrote:
> > Hi Daryl,
> >
> > That would be nice.  If you do it, make sure that you don't restrict
> > to one rtpproxy server.
> > Allow the script to use a list of rtpproxy servers (good for
> > redundancy/failover).
> >
> >
> > Regards,
> > Ovidiu Sas
> >
> > On 3/23/07, Daryl Sanders <daryl.sanders at gmail.com> wrote:
> >> When I get some time I may try to modify the OpenSER nathelper module
> >> to support this. It think it is important to have the ability to
> >> choose the the rtpproxy server you wish to use (on the fly) with info
> >> from an avp.
> >>
> >> That way you can let your users choose the rtpproxy nearest to them. I
> >> understand the SER version of nathelper already has this
> >> functionality.
> >>
> >> - Daryl
> >>
> >> On 3/23/07, Ovidiu Sas <sip.nslu at gmail.com> wrote:
> >> > No, there weren't any more discussion on this.
> >> > As Bogdan pointed out, the nathelper module is able to manage multiple
> >> > instances of rtpproxy and provide failover.  It works quite nicely.
> >> >
> >> > But any enhancements would be welcomed :)
> >> >
> >> >
> >> > Regards,
> >> > Ovidiu Sas
> >> >
> >> > On 3/23/07, Daryl Sanders <daryl.sanders at gmail.com> wrote:
> >> > > Has there been any more discussion on this? If we could store
> >> > > rtpproxy_sock param as an avp wouldn't we then be able to change the
> >> > > value on the fly?
> >> > >
> >> > > This would be a tremendously useful feature as we'd be able to
> >> select
> >> > > the specific rtpproxy we want to use.
> >> > >
> >> > > - Daryl
> >> > >
> >> > >
> >> > > On 2/8/07, Ovidiu Sas <sip.nslu at gmail.com> wrote:
> >> > > > Hi Bogdan,
> >> > > >
> >> > > > Thx for pointing me out.
> >> > > > I guess I should re-read the doc from time to time before
> >> asking :-)
> >> > > >
> >> > > >
> >> > > > Cheers,
> >> > > > Ovidiu
> >> > > >
> >> > > > On 2/8/07, Bogdan-Andrei Iancu <bogdan at voice-system.ro> wrote:
> >> > > > > Hi Ovidiu,
> >> > > > >
> >> > > > > afaik, nathelper already has support for multiple rtpproxy and
> >> > > > > balancing. You cannot control the selection algorithm, but
> >> you can
> >> > > > > distribute the load to several rtpproxy-s.
> >> > > > >
> >> > > > > regards,
> >> > > > > bogdan
> >> > > > >
> >> > > > > Ovidiu Sas wrote:
> >> > > > > > Hi all,
> >> > > > > >
> >> > > > > > I think it would be nice to have the ability to store the
> >> > > > > > rtpproxy_sock param as an avp (just like the
> >> fr_inv_timer_avp).  This
> >> > > > > > will allow one to loadbalance rtp streams via several rtpproxy
> >> > > > > > servers.
> >> > > > > >
> >> > > > > >
> >> > > > > > Regards,
> >> > > > > > Ovidiu Sas
> >> > > > > >
> >> > > > > > _______________________________________________
> >> > > > > > Devel mailing list
> >> > > > > > Devel at openser.org
> >> > > > > > http://openser.org/cgi-bin/mailman/listinfo/devel
> >> > > > > >
> >> > > > >
> >> > > > >
> >> > > >
> >> > > > _______________________________________________
> >> > > > Devel mailing list
> >> > > > Devel at openser.org
> >> > > > http://openser.org/cgi-bin/mailman/listinfo/devel
> >> > > >
> >> > >
> >> >
> >>
> >
>
>