Aisling O'Driscoll wrote:
Ok, just to recap - cos Im getting a little bit
confused ;)
I have two choices(?)
1. Somehow invoke sipsak to configure permanent addresses with a
particular q value.
2. Develop a FIFO method to change q value.
Yes. Except that I don't know if anybody verified that q value cannot be
changed with today's FIFO. I just asked the question...
Am I correct in thinking directly modifying the usrloc
table in the
database is out of the question because the changes cant be updated
except by SER itself in which case a reboot would required - Correct?
Correct. "SER itself" is here either serctl, sipsak or FIFO.
Also lcr module (load_contacts() etc) isnt suitable
for per user
configurable sequential forking?
I don't know about that. There is definitely a q-value based functionality
there.
Have others tried to implement similar functionality
or is it usually
a generic site wide sequential forking policy?
I think using CPL could be an option. Have you looked at CPL and the cpl
module?
g-)
Many thanks for the opinions and help so far.
Aisling.
---- Original Message ----
From: jh(a)tutpro.com
To: greger(a)teigre.com
Subject: Re: [Serusers] Portal for forking call to
preferredenddevice-sequential ringing
Date: Tue, 21 Jun 2005 21:41:54 +0300
Greger V. Teigre writes:
> :-D Yes, that is true. But I didn't know that you could change
q-value in
FIFO?
if that is not possible, then you can always use sipsak to install
"permanent" registrations with a given q value. sipsak has an
additional advantage over fifo in that you can apply permissions
check
to sipsak registration, but not to fifo
registration.
-- juha
-------------------Legal
Disclaimer---------------------------------------
The above electronic mail transmission is confidential and intended
only for the
person to whom it is addressed. Its contents may be
protected by legal and/or professional privilege. Should it be
received by you in error please contact the sender at the above
quoted email address. Any unauthorised form of reproduction of this
message is strictly prohibited. The Institute does not guarantee the
security of any information electronically transmitted and is not
liable if the information contained in this communication is not a
proper and complete record of the message as transmitted by the
sender nor for any delay in its receipt.
>
>
-------------------Legal
Disclaimer---------------------------------------
The above electronic mail transmission is confidential and intended
only for the person to whom it is addressed. Its contents may be
protected by legal and/or professional privilege. Should it be
received by you in error please contact the sender at the above
quoted email address. Any unauthorised form of reproduction of this
message is strictly prohibited. The Institute does not guarantee the
security of any information electronically transmitted and is not
liable if the information contained in this communication is not a
proper and complete record of the message as transmitted by the
sender nor for any delay in its receipt.