Samuel Osorio Calvo wrote:

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.

:-D Yes, that is true. But I didn't know that you could change q-value in FIFO? Never really thought about that, it's logical, though :-) Kind of double work to build something that uses FIFO for 0.9.x, when head (hopefully) will get the xmlrpc. It looks like Jan plans to remove the fifo code when replacing with xmlrpc.

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

Good idea :-) However, it's sort of a moving target so far, it's quite an effort to keep the document updated, and we would rather suffer in coverage/depth than suffer from outdated info... g-)

Samuel.

Unclassified.

...

...

...

"Greger V. Teigre" greger@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@cit.ie; serusers@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@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@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.