Re: [OpenSIPS-Users] Question about mediaproxy relay preference
On 10 Apr 2010, at 17:13, Henk Hesselink wrote: 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?). I don't recall the details, but it's where the random choice of a relay is done. I guess it should be somewhere in that function. -- Dan ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Question about mediaproxy relay preference
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@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users -- Dan ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Question about mediaproxy relay preference
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 Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users -- Dan ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Question about mediaproxy relay preference
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 :-) 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. Any suggestions how to improve that? 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@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Question about mediaproxy relay preference
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). Currently only a single preferred relay can be used. The send_command method from the RelayFactory class is responsible for selecting the relay which will be used, currently in a random way if no preferred relay is specified. The preferred relay is specified from the OpenSIPS configuration file through an AVP and the mediaproxy module sends this information to the dispatcher through the 'update' command. So that function would also need modifications. Now the tricky part would be to decide where to do the actual DNS lookup. - If the lookup is done in OpenSIPS, you could pass a space separated list of relays (in the right order) which would be appended at the beginning of the list. - Do the lookup in MediaProxy. I'd rather not do it on MediaProxy, as this would increase the complexity and add delay (due to the DNS lookup) to the setup of the call. 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. Regards, -- Saúl Ibarra Corretgé AG Projects ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Question about mediaproxy relay preference
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@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Question about mediaproxy relay preference
I think this is a really good idea. What about having a mediaproxy modparam for relay_group.. So a relay group could be east_coast or west_coast and you can send that as the preference (and OpenSIPs caches the IPs for the group and sends them pre-looked up to dispatcher) Just my $0.02. Also, with preferred relays specified, will non-prefered relays every be picked? I can think of a handful of circumstances where you'd absolutely not want a non-prefered relay to ever be allowed. -Brett On Wed, Apr 7, 2010 at 2:45 AM, Saúl Ibarra Corretgé s...@ag-projects.com 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). Currently only a single preferred relay can be used. The send_command method from the RelayFactory class is responsible for selecting the relay which will be used, currently in a random way if no preferred relay is specified. The preferred relay is specified from the OpenSIPS configuration file through an AVP and the mediaproxy module sends this information to the dispatcher through the 'update' command. So that function would also need modifications. Now the tricky part would be to decide where to do the actual DNS lookup. - If the lookup is done in OpenSIPS, you could pass a space separated list of relays (in the right order) which would be appended at the beginning of the list. - Do the lookup in MediaProxy. I'd rather not do it on MediaProxy, as this would increase the complexity and add delay (due to the DNS lookup) to the setup of the call. 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. Regards, -- Saúl Ibarra Corretgé AG Projects ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Question about mediaproxy relay preference
Hi Brett, On 7/4/10 4:38 PM, Brett Nemeroff wrote: I think this is a really good idea. What about having a mediaproxy modparam for relay_group.. So a relay group could be east_coast or west_coast and you can send that as the preference (and OpenSIPs caches the IPs for the group and sends them pre-looked up to dispatcher) Just my $0.02. Also, with preferred relays specified, will non-prefered relays every be picked? I can think of a handful of circumstances where you'd absolutely not want a non-prefered relay to ever be allowed. Dan is right, as the solution I proposed doesn't fit any possible scenario that could come up in the future. Implementing a set of strategies for distributing the load among the relays is the way to go. Regards, -- Saúl Ibarra Corretgé AG Projects ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Question about mediaproxy relay preference
I do agree with Dan as well.. However, I urge you to consider situations where mediaproxy selection is based on business logic and not just IP statistics. This may not be the best example, but I have situations where I have a certain proxies that are reserved for traffic going to/from certain providers (over VPNs) and it's important that I can specify what proxies to use based on the provider chosen for a call.. Now that being said, if the relay can tell if it has IP connectivity to both endpoints, perhaps it's smart enough to figure this out on it's own (yes, I can reach both ends of the call and here's my latency to both sides) On Wed, Apr 7, 2010 at 10:36 AM, Saúl Ibarra Corretgé s...@ag-projects.com wrote: Hi Brett, On 7/4/10 4:38 PM, Brett Nemeroff wrote: I think this is a really good idea. What about having a mediaproxy modparam for relay_group.. So a relay group could be east_coast or west_coast and you can send that as the preference (and OpenSIPs caches the IPs for the group and sends them pre-looked up to dispatcher) Just my $0.02. Also, with preferred relays specified, will non-prefered relays every be picked? I can think of a handful of circumstances where you'd absolutely not want a non-prefered relay to ever be allowed. Dan is right, as the solution I proposed doesn't fit any possible scenario that could come up in the future. Implementing a set of strategies for distributing the load among the relays is the way to go. Regards, -- Saúl Ibarra Corretgé AG Projects ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Question about mediaproxy relay preference
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). Henk Adrian Georgescu wrote: 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 Georgescua...@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 Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Question about mediaproxy relay preference
New model? Which model. Maybe I missed something. :) On Fri, Apr 2, 2010 at 7:57 AM, Adrian Georgescu a...@ag-projects.com wrote: 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 Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] Question about mediaproxy relay preference
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 Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users