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(a)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(a)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:
>>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(a)tutpro.com
>>Cc: samuel.osorio(a)nl.thalesgroup.com; ashling.odriscoll(a)cit.ie;
>>serusers(a)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(?)
>>>
>>>1. 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(a)tutpro.com
>>>>To: greger(a)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.
