Ok, just to recap - cos Im getting a little bit confused ;)
I have two choices(?)
1. Somehow invoke sipsak to configure permanent addresses with a particular q value. 2. Develop a FIFO method to change q value.
Am I correct in thinking directly modifying the usrloc table in the database is out of the question because the changes cant be updated except by SER itself in which case a reboot would required - Correct? Also lcr module (load_contacts() etc) isnt suitable for per user configurable sequential forking?
Have others tried to implement similar functionality or is it usually a generic site wide sequential forking policy?
Many thanks for the opinions and help so far. Aisling.
---- Original Message ---- From: jh@tutpro.com To: greger@teigre.com Subject: Re: [Serusers] Portal for forking call to preferredenddevice-sequential ringing Date: Tue, 21 Jun 2005 21:41:54 +0300
Greger V. Teigre writes:
:-D Yes, that is true. But I didn't know that you could change
q-value in
FIFO?
if that is not possible, then you can always use sipsak to install "permanent" registrations with a given q value. sipsak has an additional advantage over fifo in that you can apply permissions
check
to sipsak registration, but not to fifo registration.
-- juha
-------------------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.
You could definitely query the current bindings with sipsak, check the q value in some script language and the re-insert the binding with the fixed q value (if required). But that really sounds cumbersome to me...
Nils
On Tuesday 21 June 2005 23:00, Aisling O'Driscoll wrote:
Ok, just to recap - cos Im getting a little bit confused ;)
I have two choices(?)
- Somehow invoke sipsak to configure permanent addresses with a
particular q value. 2. Develop a FIFO method to change q value.
Am I correct in thinking directly modifying the usrloc table in the database is out of the question because the changes cant be updated except by SER itself in which case a reboot would required - Correct? Also lcr module (load_contacts() etc) isnt suitable for per user configurable sequential forking?
Have others tried to implement similar functionality or is it usually a generic site wide sequential forking policy?
Many thanks for the opinions and help so far. Aisling.
---- Original Message ---- From: jh@tutpro.com To: greger@teigre.com Subject: Re: [Serusers] Portal for forking call to preferredenddevice-sequential ringing Date: Tue, 21 Jun 2005 21:41:54 +0300
Greger V. Teigre writes:
:-D Yes, that is true. But I didn't know that you could change
q-value in
FIFO?
if that is not possible, then you can always use sipsak to install "permanent" registrations with a given q value. sipsak has an additional advantage over fifo in that you can apply permissions
check
to sipsak registration, but not to fifo registration.
-- juha
-------------------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.
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Aisling O'Driscoll wrote:
Ok, just to recap - cos Im getting a little bit confused ;)
I have two choices(?)
- Somehow invoke sipsak to configure permanent addresses with a
particular q value. 2. Develop a FIFO method to change q value.
Yes. Except that I don't know if anybody verified that q value cannot be changed with today's FIFO. I just asked the question...
Am I correct in thinking directly modifying the usrloc table in the database is out of the question because the changes cant be updated except by SER itself in which case a reboot would required - Correct?
Correct. "SER itself" is here either serctl, sipsak or FIFO.
Also lcr module (load_contacts() etc) isnt suitable for per user configurable sequential forking?
I don't know about that. There is definitely a q-value based functionality there.
Have others tried to implement similar functionality or is it usually a generic site wide sequential forking policy?
I think using CPL could be an option. Have you looked at CPL and the cpl module? g-)
Many thanks for the opinions and help so far. Aisling.
---- Original Message ---- From: jh@tutpro.com To: greger@teigre.com Subject: Re: [Serusers] Portal for forking call to preferredenddevice-sequential ringing Date: Tue, 21 Jun 2005 21:41:54 +0300
Greger V. Teigre writes:
:-D Yes, that is true. But I didn't know that you could change
q-value in
FIFO?
if that is not possible, then you can always use sipsak to install "permanent" registrations with a given q value. sipsak has an additional advantage over fifo in that you can apply permissions
check
to sipsak registration, but not to fifo registration.
-- juha
-------------------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.
Hello,
Many thanks for the ideas so far. I looked at CPL Greger and I think that provides a very simple solution to this - a simple Call forward on no answer script.
I have an included an example that I came across below. If a user wants to modify the order of the devices a call should be sent to, then I simply have to retrieve the information from the user via the web interface and provision a new cpl script. I think this solves the problem - Does anyone foresee any problems with this or think it has disadvantages?
I do have two minor questions if I am to go ahead with this direction though: 1) If a particular user already has a cpl script e.g. a call screening script uploaded to the database and they then upload this forward on no answer script, will it overwrite the original script? i.e. can there only be one cpl script per user?
2)How can a cpl script be "undone" or deleted? Must it be overwritten or is there a way of simply removing it(without using mysql commands)?
Example CPL: Call Forward on No Answer
<?xml version="1.0">
<cpl> <subaction id="phone2"> <location url="sip:2000@phone2"> <proxy /> </location> </subaction>
<incoming> <location url="sip:2000@phone1"> <proxy timeout="8"> <noanswer> <sub ref="phone2"/> </noanswer> </proxy> </location> </incoming> </cpl>
Many Thanks, Aisling.
-----Original Message----- From: Greger V. Teigre [mailto:greger@teigre.com] Sent: 22 June 2005 05:42 To: Aisling O'Driscoll; jh@tutpro.com Cc: samuel.osorio@nl.thalesgroup.com; ashling.odriscoll@cit.ie; serusers@lists.iptel.org Subject: Re: [Serusers] Portal for forking call to preferredenddevice-sequential ringing
Aisling O'Driscoll wrote:
Ok, just to recap - cos Im getting a little bit confused ;)
I have two choices(?)
- Somehow invoke sipsak to configure permanent addresses with a
particular q value. 2. Develop a FIFO method to change q value.
Yes. Except that I don't know if anybody verified that q value cannot be
changed with today's FIFO. I just asked the question...
Am I correct in thinking directly modifying the usrloc table in the database is out of the question because the changes cant be updated except by SER itself in which case a reboot would required - Correct?
Correct. "SER itself" is here either serctl, sipsak or FIFO.
Also lcr module (load_contacts() etc) isnt suitable for per user configurable sequential forking?
I don't know about that. There is definitely a q-value based functionality there.
Have others tried to implement similar functionality or is it usually a generic site wide sequential forking policy?
I think using CPL could be an option. Have you looked at CPL and the cpl
module? g-)
Many thanks for the opinions and help so far. Aisling.
---- Original Message ---- From: jh@tutpro.com To: greger@teigre.com Subject: Re: [Serusers] Portal for forking call to preferredenddevice-sequential ringing Date: Tue, 21 Jun 2005 21:41:54 +0300
Greger V. Teigre writes:
:-D Yes, that is true. But I didn't know that you could change
q-value in
FIFO?
if that is not possible, then you can always use sipsak to install "permanent" registrations with a given q value. sipsak has an additional advantage over fifo in that you can apply permissions
check
to sipsak registration, but not to fifo registration.
-- juha
-------------------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.
-------------------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 O'Driscoll writes:
Also lcr module (load_contacts() etc) isnt suitable for per user configurable sequential forking?
it is suitable, once you have first somehow got the contacts into destination set. sipsak is one possibility for doing so.
-- juha
-
Aisling -
Aisling O'Driscoll
-
Greger V. Teigre -
Juha Heinanen -
Nils Ohlmeier