Heheh. Elegant, I might even grant you. But I'm still thinking utilising DNS
to handle call groups doesn't fall into the category of easy... or
user-friendly. Sure, DNS is easy for DNS, as it should be. But mixing in DNS
to handle calling functions seems... odd somehow.
Just my opinion. I like handy abstractions. I've never found NAPTR records to
be human-readable enough to count as easy. Especially in vi.
Perhaps Asterisk is just spoiling me in that sense. Its callgroups are easy to
spot in a text file and rather easy to manage.... and, of course, don't rely
solely on DNS (which is another point of failure in a production system). I'm
picky that way. I don't like adding overt complexity to achieve a solution. I
like that to be done behind the scenes by someone more motivated and
interested in the 'how things work' side of the code. ;)
This isn't to say I couldn't get used to it. But it's like the equivalent of
piping writes on a unix command line compared to an IM client where all the
details of how the communication is achieved is done behind the scenes. They
both get the job done, but one is clearly easy and the other is clearly a kludge.
N.
On Wed, 09 Aug 2006 11:56:45 -0400, Evan Borgström wrote
My whacked out universe includes a web administration
interface that
uses 'nsupdate' to manage contacts in a cluster of nameservers
running bind. Granted that's not very easy as you now have to run a
cluster of nameservers that allow dynamic updates (key exchanges,
etc).
What I was really referring to is the other dimension of my whacked
out universe that includes vim and some text files on any machine
that is capable of running bind (which would be any unix derivative)
. Take your pick.
If you can manage contacts via the mysql monitor then what's so hard
about managing some text files that bind uses? Here, some made up
nonsense off the top of my head (sip:2612355@domain.com is the original
URI);
$ORIGIN
e164.domain.com.
5.5.3.2.1.6.2 60 IN NAPTR "u" "E2U+sip"
"!^.*!sip:user1@domain.com!"
60 IN NAPTR "u" "E2U+sip"
"!^.*!sip:user2@domain.com!"
60 IN NAPTR "u" "E2U+sip"
"!^.*!sip:user3@domain.com!"
Easy.
-Evan
sip wrote:
> Evan,
>
> I understand where you're coming from in that ENUM seems a possible solution
> for this, but in what whacked out universe is managing multiple NAPTRs to
> handle call groups considered an 'easy' way to do things?
>
> Perhaps this is another definition of the word easy of which I'm unaware. ;)
>
> N.
>
>
> On Wed, 09 Aug 2006 10:44:36 -0400, Evan Borgström wrote
>> So long as the original extension is numeric then there is a much
>> easier way to do this, ENUM. Create a private E164 tree (ie.
>>
e164.yourdomain.com) and add multiple NAPTR's for the single
>> extension all with the same preference and order. When you call
>> enum_lookup() it will cause the request to fork to all the recipients.
>>
>> -Evan
>>
>> P.S. Don't forget to prefix + before calling enum_lookup()
>> P.P.S Don't forget to remove the + if enum_lookup() fails
>>
>> Ricardo Carvalho wrote:
>>> The idea is really that. I want do be able to call one extension and
>>> ring on many phones, each registered to a different user, to be able to
>>> implementing like a help desk or something...
>>> Is it possible in SER?
>>>
>>> Thanks
>>>
>>> Ricardo.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> sip wrote:
>>>> If you gave the same alias to multiple subscribers, that's a bit
like
>>>> giving
>>>> the same username to multiple subscribers, or even having the same URL
>>>> for
>>>> multiple websites. How would the computer know whether someone trying
to
>>>> contact ALIAS is trying to contact USER-A or USER-B ?
>>>>
>>>>
>>>>
>>>> On Mon, 07 Aug 2006 12:16:08 +0100, Ricardo Carvalho wrote
>>>>
>>>>> Hi,
>>>>>
>>>>> Is it possible to give same alias to different subscribers? Trying
to
>>>>> add same alias in serctl isn't well succeeded because it says
that
>>>>> that alias is already in use by other user. Is it any other way to
do
>>>>> it?
>>>>>
>>>>> Regards,
>>>>>
>>>>> Ricardo.
>>>>> _______________________________________________
>>>>> Serusers mailing list
>>>>> Serusers(a)lists.iptel.org
>>>>>
http://lists.iptel.org/mailman/listinfo/serusers
>>>>>
>>>>
>>> _______________________________________________
>>> Serusers mailing list
>>> Serusers(a)lists.iptel.org
>>>
http://lists.iptel.org/mailman/listinfo/serusers
>