1 Jul
2005
1 Jul
'05
12:02 p.m.
Hi Greger,
If I am to create an alias for every phone i.e. an alias for 1234 to
1234dt and an alias for 134 to 1234pda etc, wouldn't this mean that I
would have to issue:
Serctl alias add 1234 sip:1234dt@CONTACTADDRESS.
Doesn't this limit mobility in that if the user changes IP address(i.e.
their contact address), the alias no longer applies and the sequential
forking mechanism wont work?
Many thanks for ideas,
Aisling.
-----Original Message-----
From: Greger V. Teigre [mailto:greger@teigre.com]
Sent: 01 July 2005 06:42
To: Aisling; 'Bogdan-Andrei Iancu'; serusers(a)lists.iptel.org
Subject: Re: [Serusers] Associating a contact address with a location
Aisling,
After pondering this for some time now, I think your best bet would be
to
register each phone with a different username with predefined suffixes:
1234dt
1234sp
1234whatever
You could have one account 1234 with password used for all accounts and
then
you add the other usernames to the uri table (to pass check_from. Each
phone
will thus use 1234 as auth user and 1234dt or whatever as username.
1234dt will be registered as the location and in order to route calls,
you
will either have to use your serial forking with CPL or register fixed
aliases in the alias table from 1234 (probably the number called) to
each of
1234dt, 1234sp etc. lookup("aliases") should then fork the call to all.
g-)
Aisling wrote:
Hi,
Sorry to resubmit on much the same topic as before (Portal for forking
call to preferred end device-sequential ringing) but I was wondering
if
anyone had any further ideas on how to associate a particular contact
address with a location. i.e. a user can choose that their preferred
location is their desktop phone and I need to devise some way to know
that a particular contact address is associated with the desktop
phone.
I was 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....Which
is
why I was wondering if anyone had any better ideas?
Many Thanks,
Aisling.
p.s. I currently retrieve the users contact address and q value via a
web interface using the serctl fifo interface.
-----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:
-------------------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(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:
be
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
changed with today's FIFO. I just asked the question...
cpl
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
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.
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers