[OpenSIPS-Users] Question about mediaproxy relay preference

[Henk Hesselink]

Dan Pascu wrote:
>
> On 9 Apr 2010, at 02:14, Henk Hesselink wrote:
>
>> 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 :-)
>
> Are you volunteering to code this? :-)

We might, if we have time.  That's why I asked for a hint where to start
(send_command method in the RelayFactory class?).

Henk


>>
>> 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.
>
> This would be solved by a 'choose the relay that minimizes the voice
> path' algorithm I proposed before.
>
>>
>> Any suggestions how to improve that?
>
> By coding those selection algorithms. As it is now you cannot do much,
> except manually select a specific relay for a call.
>
>>
>> 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
>>>
>>
>
>
> --
> Dan
>
>
>
>
>
>
>