Hi,
My mind has changed about how I'm going to approach this a million times!! ;) Ok following on from the below email, CPL doesn't seem such a good option particularly if NAT is coming into the equation(which in my case it will be). So the approach I think might work at the moment is:
1) Using some language (java servlet in the web interface probably) every 20/30 seconds issue the "serctl ul show 2000" to read the contact addresses for user 2000.This loop will hopefully keep a recent enough record of the contact addresses so devices can register whenever.
2) This is the tricky step which I need advise on. I must somehow know which contact address to associate with the device the user has chosen as the preferred device (e.g. desktop sip phone). At the moment I'm thinking the user must either enter the device ip addresses manually so I can search the contact based on IP address (This sucks in terms of NAT, scalability and losing mobility over networks) OR I could perhaps stipulate that a user cannot have two of the same device e.g. cant have two BT100 hardphones and I could search the location table based on model. I think either of these options aren't great....Any better ideas?
3) Then once I (somehow) know the devices contact address, I'll get my interface to issues the "serctl fifo ul_add 2000@AOR 2000@contact address 3600 qvalue 0 0" command and set that preferred contact address to the highest q value.
Bar the obvious big hole that is step 2, does that all sound feasible?....Or in yere opinions is the CPL route the best way to approach...I'm try to figure out which one leads to the least amount of problems in terms of nat, scalability, mobility etc......All options seem to have down-sides but its difficult to evaluate which option is the most "doable"
Thanks again, Aisling
-----Original Message----- From: Bogdan-Andrei Iancu [mailto:bogdan@voice-system.ro] Sent: 24 June 2005 08:36 To: Aisling Cc: 'Greger V. Teigre'; jh@tutpro.com Subject: Re: [Serusers]CPL - Portal for forking call to preferred end device-sequential ringing
Hi Aisling,
Aisling wrote:
Hi Bogdon,
"even if you use CPL, you need to place in each location node the contacts (and not the AOR) of the user, contacts which are dynamically
stored only in user location.
what you are describing below can be possible only if you a user (as person) has different sip accounts (SIP users) for each of his
devices.
Other way I don't see how you can place in the CPL script the "phone1"
and "phone2" addresses."
I was thinking that the user would first need to manage their contact addresses via the web interface. So they would have to enter the IP address for each device.
e.g.
pda xxx.xxx.xxx.150 pc xxx.xxx.xxx.151 laptop xxx.xxx.xxx.152
Then when a user wants a particular sequential ring order of perhaps pc->laptop->pda, I would provision the cpl script and retrieve the addresses from the above manageContacts to provide the "phone1", "phone2" addresses. i.e. "phone1" could be sip:2000@xxx.xxx.xxx.xxx151 for the pc and "phone2" could be sip:2000@xxx.xxx.xxx.152 for the laptop.
Is this scenario possible?
yes, the scenario is possible, but there are couple of drawback: - you will give up the SIP-like registration mechanism (users have to upload by hand the IPs), so loose the mobility part - if user moved the laptop in a different network, he will have to update manually the contact on server (update which is normally done transparently via registration). - choosing CPL sometime proves to be a real act of bravery :) - first the scripts are difficult to provisions, second to integrate cpl-c
with nat traversal is quite tricky (or with other services).
Also (and forgive me if this question is ignorant) couldn't I just retrieve the contact address (not AOR) from the user location?
via CPL? yes you can do it - use the lookup("registration") node. Then you can proxy what you got in a sequential way (see the "ordering" parameter of proxy node).
regards, bogdan
Thanks, Aisling.
-----Original Message----- From: Bogdan-Andrei Iancu [mailto:bogdan@voice-system.ro] Sent: 22 June 2005 12:45 To: Aisling Cc: 'Greger V. Teigre'; jh@tutpro.com Subject: Re: [Serusers]CPL - Portal for forking call to preferredenddevice-sequential ringing
Hi Aisling,
There are many ways to implement serial forking - like using CPL, LCR
or
AVPOPS. But the main idea (if I getting right from your initial email) is to allow the user to order his contacts for the same account (like account
userx that have contact_pda_x, contact_PC_x, contact_office_x, etc). So
you have all this contacts in user location, you have several mechanism
for serial forking, but you are missing the link - to get the contacts from user location and to feed any of the serial forking mechanism.
This
is the big problem.
even if you use CPL, you need to place in each location node the contacts (and not the AOR) of the user, contacts which are dynamically stored only in user location.
what you are describing below can be possible only if you a user (as person) has different sip accounts (SIP users) for each of his devices.
Other way I don't see how you can place in the CPL script the "phone1" and "phone2" addresses.
and just to answer you to the CPL- related questions (from implementation point of view):
- each user can have only one script - if you load a new script, the
previous one will be lost (overwritten). If you can different services via CPL (like screening and no-answer), you need to mix them in the
same
script during provisioning.
- if you want to delete a CPL script via FIFO, use the REMOVE_CPL
command: serctl fifo REMOVE_CPL user@domain
regards, bogdan
Aisling wrote:
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:
- 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.