Re: [OpenSIPS-Users] Question about mediaproxy relay preference

2010-04-13 Thread Dan Pascu

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

2010-04-10 Thread Dan Pascu

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

2010-04-10 Thread Henk Hesselink
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

2010-04-08 Thread Henk Hesselink
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

2010-04-07 Thread Saúl Ibarra Corretgé
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

2010-04-07 Thread Dan Pascu
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

2010-04-07 Thread Brett Nemeroff
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

2010-04-07 Thread Saúl Ibarra Corretgé
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

2010-04-07 Thread Brett Nemeroff
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

2010-04-05 Thread Henk Hesselink
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

2010-04-02 Thread Brett Nemeroff
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

2010-04-01 Thread Henk Hesselink
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