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

[Samuel Osorio Calvo]

In fact, SER has a model for usrloc changes outside itself: FIFO interface. Using the ul command of this interface it is possible to add/update/remove users' information during runtime without having to restart SER.
In fact, these commands update SER's cache and this information is immediately used by SER. It will be propagated to the permament DB storage depending on the mode selected.

I would suggest to add a chapter of the FIFO/UNIX/TCP/XMLRPC interface to the famous Getting Started Document ;)

Samuel.


Unclassified.
>>> "Greger V. Teigre" <greger at teigre.com> 06/21/05 04:53PM >>>
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.