[Serusers] Portal for forking call to preferredenddevice-sequential ringing

[Samuel Osorio Calvo]

>> 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...
I think the current usrloc fifo commands provide enough flexibility to modify the q value, I don't know now the exact spelling but womething like:

serctl ul add location user at domain user at ip  {expires} {q} {replicate} 

I recall that there where a few values representing expiration, replicate, q value and maybe something else. From the source code, it seems that if the contact already exists, serctl ul add will update the record.
If you don't have the user's record values you can use serctl ul show.

I'm not 100% sure, but if you use sipsack, you should be carefull to not modifying other parameters just as received, User-Agent...am I right?

Samuel.


Unclassified.
>>> "Greger V. Teigre" <greger at teigre.com> 06/22/05 06:42AM >>>
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 at tutpro.com 
>> To: greger at 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.