21 Jun
2005
21 Jun
'05
8:45 p.m.
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(a)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@teigre.com]
Sent: 21 June 2005 13:33
To: Samuel Osorio Calvo; ashling.odriscoll(a)cit.ie; serusers(a)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.
-------------------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. >> "Aisling"
<ashling.odriscoll(a)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@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(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers