[Serusers] Associating a contact address with a location

Greger V. Teigre greger at teigre.com
Fri Jul 1 12:28:27 CEST 2005


How you do this depends on whether you use domains or not. The idea is that 
your main number is 1234 at yourdomain.com (using domains).  Then, you add an 
alias pointing 1234 at yourdomain.com to 1234dt at yourdomain.com, 
1234sp at yourdomain.com etc
1234 at yourdomain.com will not be registered in location, but 
1234dt at yourdomain.com will, so when lookup("location") is executed (you need 
lookup("aliases") first, the actual IP address and port will be found.

Of course, all of this is theory, I haven't tried it and using aliases this 
way is a bit upside down (mapping 1 virtual address to multiple real ones 
instead of multiple virtual ones to one real), so there may be issues I 
overlook.
g-)

Aisling wrote:
> 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 at 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 at teigre.com]
> Sent: 01 July 2005 06:42
> To: Aisling; 'Bogdan-Andrei Iancu'; serusers at 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 at voice-system.ro]
>> Sent: 22 June 2005 12:45
>> To: Aisling
>> Cc: 'Greger V. Teigre'; jh at 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 at 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 at phone2">
>>>      <proxy />
>>>    </location>
>>>  </subaction>
>>>
>>>  <incoming>
>>>    <location url="sip:2000 at phone1">
>>>      <proxy timeout="8">
>>>        <noanswer>
>>>          <sub ref="phone2"/>
>>>        </noanswer>
>>>      </proxy>
>>>    </location>
>>>  </incoming>
>>> </cpl>
>>>
>>> Many Thanks,
>>> Aisling.
>>>
>>> -----Original Message-----
>>> From: Greger V. Teigre [mailto:greger at teigre.com]
>>> Sent: 22 June 2005 05:42
>>> To: Aisling O'Driscoll; jh at tutpro.com
>>> Cc: samuel.osorio at nl.thalesgroup.com; ashling.odriscoll at cit.ie;
>>> serusers at 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 at tutpro.com
>>>>> To: greger at 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 at 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. 




More information about the sr-users mailing list