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

[Benjamin on Asterisk Mailing Lists]

On Thu, 11 Nov 2004 23:59:48 -0500, Jon Radon <jonr800 at gmail.com> wrote:
> It's definitely a good idea.  Especially if the authentication was
> made fairly seamless.

As far as Zeroconf is concerned it is only about advertising services
(and service parameters) so that they are easily discoverable without
any prior knowledge about where to ask.

This is done using a mechanism called multicast DNS. Apple are about
to enhance this for WAN use which will be unicast based but for now, I
would like to focus on mDNS based service discovery on the LAN.

In any event, once the client has discovered the service (and
optionally advertised service parameters), it will be up to the
protocol that service is based on to do authentication.

> What specific user services were you referring to?

Look at the two scenarios I gave as examples. One would be a
provisioning service for devices to be connected (over IP) to a
PBX/VoIP server, in this case Asterisk. The other would be a public
phone service for guests.

In both scenarios, the actual service that's being advertised would be
a SIP or IAX (or other VoIP protocol based) service.

As an example for a possible flow of events let's look at scenario 1 again ...

1) IP phone with factory settings and no configuration whatsoever is
being connected to the LAN and powered up
2) The phone gets an IP address via DHCP, or if there is no DHCP
server, the phone self assigns a zeroconf link-local address
(169.254.x.x)
3) The phone listens for services advertised by Asterisk through mDNS
4) The phone advertises its own presence with a URI pointing to a
setup web page it provides
5) The phone guy sees the phone's URI showing up in his web browser
automatically
NB: Mozilla and Safari do this already. IE requires a plug-in
available from Apple.
6) The phone guy clicks on the URI and is taken to the phone's setup page
7) The setup page shows a list of services, advertised through
Zeroconf by local PBXes
8) The phone guy picks a service/PBX for this phone on this web browser
9) The phone obtains all the service parameters accordingly to configure itself

The phone is now ready to be assigned an extension number. At this
stage, the phone is already able to call an IVR menu for
self-provisioning or employee login, depending on what scheme the
company wants to use.

There are now a number of possibilities to continue ...

1) phone's credentials supplied manually by admin

The phone guy could proceed to a web page to supply user ID and
password which the phone would then store and use henceforth to sign
in.

2) phone's credentials supplied manually by user

The user at the desk where the phone is could dial into an IVR (any
number dialled would take him there) to identify himself with a PIN
number and get the phone provisioned accordingly.

3) phone does not use device based credentials but user login instead

Whoever wants to use the phone has to log in from that phone, using
the same mechanism already employed by Asterisk for agent login.


> I think most of them should be defined in the usual confs...

The services themselves will of course remain to be defined in their
respective configuration files. However, the control over what
services should be advertised and what parameters should be advertised
alongside those to be advertised services, that will probably have to
go into a zeroconf specific configuration file.

> We could setup zerconf.conf much like a dialplan.  Search for matches
> first then falll back to the default.

That's an interesting idea. However, I am a bit worried about
complexity. I think this should be kept fairly simple, like

a) which services do we want to advertise (enable/disable)
b) what do we want to call them (service short description)
c) which additional information do we want to advertise alongside

We need to be careful not to make this too complex.

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.