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