[OpenSIPS-Users] Question about mediaproxy relay preference

[Dan Pascu]

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? :-)

>
> 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