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
