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

Nils Ohlmeier lists at ohlmeier.org
Tue Jun 21 23:30:25 CEST 2005


You could definitely query the current bindings with sipsak, check the q value 
in some script language and the re-insert the binding with the fixed q value 
(if required). But that really sounds cumbersome to me...

  Nils

On Tuesday 21 June 2005 23:00, 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.
>
> 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?
> Also lcr module (load_contacts() etc) isnt suitable for per user
> configurable sequential forking?
>
> Have others tried to implement similar functionality or is it usually
> a generic site wide sequential forking policy?
>
> 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.
>
> _______________________________________________
> Serusers mailing list
> serusers at lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serusers




More information about the sr-users mailing list