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 >> [email protected] >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> > -- Dan _______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
