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

[Aisling]

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.