[OpenSIPS-Users] Question about mediaproxy relay preference

[Henk Hesselink]

Hi Dan,

The clean way would seem to be to have different selection algorithms in
the dispatcher that can be chosen through modparam and/or an avp.  Maybe
the time and motivation will become available at some point :-)

Our situation is this:

- we don't know to which datacenter a UA will send its traffic: we're
   BGP multi-homed so this can also change randomly.  And for the same
   reason we usually can't say anything about how 'far away' a UA is
- we do know where the servers (media/conf./PSTN gw./etc.) are, because
   they're in our datacenters (we provide hosted VOIP)
- we don't have idle relays: front-end SIP dispatchers do loadbalancing
   across the datacenters, and the media dispatchers' random selection
   means that all media relays have about equal load

What we're trying to achieve is to minimize the media path by preferring
a relay that is close to (i.e. in the same datacenter as) the server for
a particular call leg, and to only choose a relay that is farther away
when all the local ones are unavailable (down/high load/whatever).

As it is now, about 20-30% of our calls would be completely local to
one datacenter except that the dispatcher assigns a relay in another
one.

Any suggestions how to improve that?

Henk


Dan Pascu wrote:
> On 7 Apr 2010, at 10:45, Saúl Ibarra Corretgé wrote:
>
>> Hi,
>>
>> On 5/4/10 10:13 PM, Henk Hesselink wrote:
>>> Hi Adrian,
>>>
>>> The way I read the code I can indicate one preferred relay, but not a
>>> set.  So I can't say "prefer this set of relays (i.e. the ones in
>>> this
>>> particular datacenter) over the rest".  That's less flexible than the
>>> SRV style.
>>>
>>> What would be great would be a dispatcher option to say "based on the
>>> media streams in the SDP, prefer 'local' relays" for some
>>> definition of
>>> local - for instance relays that are on the same subnet as one or
>>> more
>>> of the media endpoints.  I might be able to code up a patch for
>>> that if
>>> you can give me a hint where to start (looks like that would be the
>>> send_command method in the RelayFactory class).
>>>
>>
>> Having that said, here is my proposal: modify both OpenSIPS module and
>> MdediaProxy to accept a list of space separated relays. The way of
>> building that list should be decoupled from the whole process IMHO, so
>> you could do it by having the DNS query results cached somewhere. This
>> would prevent the delay that DNS query may cause.
>
>
> I'm pretty much opposed to such hacks in mediaproxy. They do not add
> any value only increase the complexity. This would be just a hack on
> top of another hack (the ability to specify the media relay from
> OpenSIPS's configuration was a hack to fill the lack of a better relay
> selection algorithm than the 'choose a random relay').
>
> What mediaproxy needs to solve such issues is configurable relay
> selection algorithms. We planned that from the start, we just didn't
> have the time and motivation to implement anything more elaborate than
> the random selection yet.
>
> One such algorithm would be to prefer a relay that is closer to the
> proxy. Or one that is closer to the PSTN gateway.
>
> Another one would be for the dispatcher to determine the relay that is
> closest to the UA and prefer that (this is what we had in mind from
> the beginning).
>
> Also this has to keep in mind how much a relay is loaded. A relay
> should be able to inform the dispatchers when it cannot accept anymore
> sessions (by monitoring the CPU/network load) so a relay is not
> overloaded. The proposed solution cannot guarantee this as in the
> OpenSIPS configuration there is no way of knowing it.
>
> Besides the original feature proposal only tries to emulate the old
> model where some mediaproxies were idle waiting for the main ones to
> fail in order to enter the scene. This is no longer the model for
> mediaproxy-2. If you always prefer relays close to the proxy, then
> when are the ones which are farther away be used? Also what if the
> ones close to the proxy are not close to the endpoints and only add
> lag to the conversation. What if the ones close to the proxy are
> overloaded while the others are completely idle. Such a solution will
> not address any of these issues.
>
> --
> Dan
>
>
>
>
>
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>