Yes, it blows away the DNS SRV concept. The new model where media relays automatically connect to one or more dispatchers using TLS is much more secure and has more self-organizing properties then statically configured DNS that can hold a limited amount of records. Still you have full control to promote a chosen relay on top of the list if you want to. You just need to work out a bit your configuration for achieving this.
Adrian On Apr 2, 2010, at 2:46 PM, Brett Nemeroff wrote: > Adrian, > I do this in a few configurations. However, it kinda blows away the > whole DNS SRV features, doesn't it? Anyway to indicate a mediaproxy > preference without nailing to a specific one? > > -Brett > > > On Fri, Apr 2, 2010 at 2:30 AM, Adrian Georgescu <a...@ag- > projects.com> wrote: >> You have control over which MP is selected by setting an AVP in the >> proxy routing logic. So you can make some checks about your topology >> and then fetch the relay address from a database. >> >> Adrian >> >> On Apr 2, 2010, at 1:46 AM, Henk Hesselink wrote: >> >>> We're moving our mediaproxies to 2.0 and have run into the >>> following: in >>> the old setup we used the priority value in the mediaproxy SRV >>> records >>> to prefer local (same datacenter) relays but to failover to a >>> different >>> datacenter if all local relays were unavailable. We then used the >>> SRV >>> weight value to load balance between different capacity relays >>> within >>> the datacenter. >>> >>> With 2.0 using conntrack we don't need to load balance anymore, but >>> we'd >>> still like to be able to prefer a local relay. Right now a call can >>> be >>> completely in one datacenter and yet have the relay in a different >>> one, >>> causing unnecessary latency. >>> >>> Ideally when a dispatcher sees that an endpoint of a call is on the >>> same subnet as any of its relays, then it should prefer those >>> relays. >>> Is something like that possible? >>> >>> Regards, >>> >>> Henk Hesselink >>> >>> _______________________________________________ >>> Users mailing list >>> [email protected] >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>> >> >> >> _______________________________________________ >> Users mailing list >> [email protected] >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> > > _______________________________________________ > Users mailing list > [email protected] > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > _______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
