[Asterisk-Dev] Rendezvous (aka Zeroconf) for Asterisk

[Benjamin on Asterisk Mailing Lists]

On Thu, 11 Nov 2004 14:07:30 -0500, Karl Brose <khb at brose.com> wrote:
> 
> Doesn't this open all kinds of privacy and security issues?

Most definitely not.

First, security by obscurity is one of the most silly ideas of our time.

Second, if you look at the scenarios I described, you will find that
(for now) we are talking about services being advertised on a LAN to
people who are meant to have access to that LAN.

Third, the exercise here is about working out just how much
granularity we need from an Asterisk configuration point of view to
give us the control what exactly is to be advertised.

> As far as SIP is concerned, the standard way to inform a SIP client
> about what features or capabilities are available is via the OPTIONS
> method.

And how does the client know where to even ask? Which DNS name or IP
address? which port number? What service is it? What is it called? How
do I know it is meant for me?

Also, OPTIONS does not contain all the information. For example,
dtmfmode is not part of it. TFTP server for firmware upgrades isn't
either. Which number to call for support, for voicemail, for reception
?.

> The UA only needs to learn the SIP server address from the
> network (DNS)

How does the UA learn the DNS name? And even if the user had a packet
sniffer to find out a SIP server address, then how does he know what
the service is for? Where is the description of the service, ie
"Flinstones Hotel Walk-in Telephone Service" ?

> and then can query the server directly. Since this can be
> an authenticated call

How can a phone that hasn't been provisioned yet possibly make an
authenticated call?

Please read the scenarios I provided to get a clear understanding of
what the aim is. The use of Rendezvous is *not* meant in place of a
phone directory or ENUM or a distributed/shared dialplan. Instead it
is aimed to be a provisioning aid.

It is meant to help

in respect of scenario #1

setting up new telephones to the point where the only thing remaining
to do is supplying credentials.

Yes, you could do that with DHCP, but the DHCP standard doesn not at
present cater for advertising many of the things we need to commission
a phone. Also, there is no granularity with DHCP, it is always
all-or-nothing, you can't choose between different services.

So, instead of trying to fight with the IETF to get new features into
DHCP, we may as well use a standard that already fits our needs, has
already been approved, has already established itself as the darling
of the industry for all other networked devices, such as printers,
cameras, music gadgets etc etc etc.


in respect of scenario #2

aiding the public to find publicly available services, such as a guest
walking in to a hotel lobby.

Yes, he could walk to the concierge desk and ask for a leaflet with
the details of the service and then spend the next 15 minutes trying
to punch them into his WiFi phone. Who knows, if he is a real hard
core gadget junkie geek, he may actually enjoy that. The rest of us,
however, will prefer to get a list of services, pick the one that says
"Welcome to the Royal Palace Hotel" (or whatever place you're in) and
be online in an instant.

thanks for your interest

rgds
benjk
-- 
Sunrise Telephone Systems, 9F Shibuya Daikyo Bldg., 1-13-5 Shibuya,
Tokyo, Japan.

NB: Spam filters in place. Messages unrelated to the * mailing lists
may get trashed.