[Serusers] Portal for forking call to preferred end device-sequential ringing

[Greger V. Teigre]

You get into even worse problems as SER does not really have a model for 
usrloc changes outside itself. Thus, dependent on your db mode (memory-only, 
flush, write-through etc) SER will potentially overwrite your externally set 
q-value before stopping. If you use write-through, you probably don't get 
that problem, and yes, you could probably theoretically restart SER to 
reload the usrloc with new q-values (never validated that, though). 
However, with a lot of locations, it's not really feasible due to SER's 
start-up loading of locations (and being unavailable while doing so).  Also, 
you will probably restart in the middle of a transaction and calls may fail 
(unless you use the restart safe parameter).
g-)

Aisling wrote:
> Thank you for the replys. I will look up the post you suggested for
> further info on the lcr module. One thing I just want to clarify:
>
> " DB-based changes is the way to go  - Updating the usrloc table
> outside
> SER does not work as SER loads usrloc info into memory."......
>
> Does this mean I must modify the database and then restart SER,
> thereby
> disrupting the service for other users?
>
> Thanks,
> Aisling.
>
> -----Original Message-----
> From: Greger V. Teigre [mailto:greger at teigre.com]
> Sent: 21 June 2005 13:33
> To: Samuel Osorio Calvo; ashling.odriscoll at cit.ie; serusers at lists.iptel.org
> Subject: Re: [Serusers] Portal for forking call to preferred end
> device-sequential ringing
>
> I believe the lcr module will do q-value based sequential forking.
> There
> was a thread on that a while back. Search for q-value and Juha.  LCR
> can
> be
> found in head and as a backported 0.9.x module.
> DB-based changes is the way to go! Doing dynamic ser.cfg changes is
> not
> feasible as long you have to restart ser (and thus reload contacts,
> which
> may take a long time).  Updating the usrloc table outside SER does not
> work
> as SER loads usrloc info into memory.
> g-)
>
> Samuel Osorio Calvo wrote:
>> I guess a sequential forking ordered with the q value of the contact
>> header field value would do what you are asking for. The user has
>> just to configure the appropriate value in his/her UA to the
>> preferred ringing sequence. This method is fully SIP compliant but
>> what I am not sure is if SER does sequential forking in the q order
>> (it wasn't a few months ago but some modifications might have added
>> it...someone can tell you better than me).
>> If you still want users to modify SER's database with a web
>> interface, you might try to modify the q value in the usrloc
>> database, of course if SER does q-ordered sequential forking, but I
>> just think it adds lots of complexity to a feature which SER is
>> supposed to provide together with minum user configuration in the
>> endpoints.
>>
>> Hope it helps,
>>
>> Samuel.
>>
>>
>> Unclassified.
>>>>> "Aisling" <ashling.odriscoll at cit.ie> 06/21/05 12:54PM >>>
>> Hello all,
>>
>> I'm hoping someone will offer an opinion as to how I should approach
>> the
>> following and if I am thinking along the correct lines:
>>
>> I am creating a web application where a user can dictate which device
>> they want a call delivered to. So if I have a user with sip url
>> "sip:2000 at server" and they have registered with the SER server from a
>> pda, pc and laptop, SER will currently parallel fork a call to all
>> these
>> destinations causing all softphones to ring (correct?). However I
>> want a
>> user to choose from a drop down menu in their browser (which I'm
>> developing with servlets and JSP's) their preferred phone e.g. pda
>> and then SER will fork the call to the softphone on the pda first.
>>
>> So basically my current plan is to retrieve the information from the
>> user about their preferred phone (which will be associated with a
>> particular IP address) and then dynamically modify the ser.cfg for a
>> sequential forking rule for that user. I would appreciate opinions as
>> to
>> whether I am approaching this correctly or if there's an alternative
>> method for such functionality (perhaps such as forking the call to
>> the device which last registered or something)?
>>
>> Many Thanks,
>> Aisling.
>>
>>
>>
>>
>> -------------------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
>
>
> -------------------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.