[Users] LCR in cache mode

Papadopoulos Georgios geop at altectelecoms.gr
Wed Apr 25 15:54:53 CEST 2007


In my humble opinion this was a pretty useful relic from the past and it
pretty much means I cannot upgrade to 1.2 :-(
Are you suggesting that ip should be a primary key in the gw table? It
doesn't make sense to me.

Do you have any other suggestions to achieve what I am trying to do? 

thank you

George
 

> -----Original Message-----
> From: Juha Heinanen [mailto:jh at tutpro.com] 
> Sent: Wednesday, April 25, 2007 12:54 PM
> To: Papadopoulos Georgios
> Cc: users at openser.org
> Subject: RE: [Users] LCR in cache mode
> 
> Papadopoulos Georgios writes:
> 
>  > Well, in my case the IP belongs to an asterisk server 
> which then sends  > the call to 5 PSTN gateways. I use this 
> trick with the 5 different  > prefixes to make asterisk 
> choose between the 5 PSTN gateways. It works  > fine in db 
> mode but not in cache mode. Shouldn't lcr behave the same in  
> > both modes?
> 
> db_mode does not exist anymore in 1.2.  it was relic from the past.
> 
>  > I tried working around this by puting the 5 entries into 5 
> different gw  > groups (this sounds like a bigger hack to me 
> than what I am currently  > doing). Still, in cache mode the 
> same entry is always picked.
> 
> that is because according to the current design of lcr module 
> a gateway prefix is gateway specific gateways being 
> identified by their ip addresses.  if request matches more 
> than one gateway, only one of them is left on the list and 
> the rest are pruned.
> 
> -- juha
> 

Disclaimer
The information in this e-mail and any attachments is confidential. It is intended solely for the attention and use of the named addressee(s). If you are not the intended recipient, or person responsible for delivering this information to the intended recipient, please notify the sender immediately. Unless you are the intended recipient or his/her representative you are not authorized to, and must not, read, copy, distribute, use or retain this message or any part of it. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses.





More information about the sr-users mailing list