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

Karl Brose khb at brose.com
Thu Nov 11 12:07:30 MST 2004


Doesn't this open all kinds of privacy and security issues?

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. The UA only needs to learn the SIP server address from the 
network (DNS) and then can query the server directly. Since this can be 
an authenticated call it can be more secure and customized wrt the 
calling user.




Benjamin on Asterisk Mailing Lists wrote:

>I spent some time with Stuart Cheshire, the driving force behind
>Apple's Zeroconf implementation, which they call Rendezvous. We agreed
>to work together to bring Rendezvous support to Asterisk. What this
>means is, I will be doing the work and Apple will provide assistance
>in respect of Rendezvous.
>
>For those who are unfamiliar with Rendezvous/Zeroconf, it is a
>technology to use DNS SRV records to dynamically advertise service
>availability and service parameters to clients on the network.
>
>http://www.zeroconf.org
>
>Anyway, the idea is to let Asterisk advertise services so that IP
>phones can discover those services and configure themselves
>automatically. The libraries are built in to Darwin and Apple has
>released the code as open source with Linux compatibility. A Windoze
>version is available as a technology preview.
>
>The API is very straigtforward. The only functions required from the
>viewpoint of a server are DNSServiceRegister, DNSServiceUpdateRecord
>and DNSServiceDeallocate (though the mDNSresponder will automatically
>deregister services when the process that registered them exits).
>
>So building a module for Asterisk to advertise services by calling
>those functions shouldn't be all to difficult. The part that will need
>a little more effort in form of careful thought is how to tell
>Asterisk which services it should advertise and what service
>parameters should be advertised. It is this part that I would like to
>ask interested parties for input/suggestions.
>
>Let me first give you a better view of the DNSServiceRegister function ...
>
>DNSServiceErrorType DNSServiceRegister(
>DNSServiceRef *sdRef,
>DNSServiceFlags flags,
>uint32_t interfaceIndex,
>const char *name,
>const char *regtype,
>const char *domain,
>const char *host,
>uint16_t port,
>uint16_t txtLen,
>const void *txtRecord,
>DNSServiceRegisterReply callBack,
>void *context);
>
>An example of a SIP service being advertised would be:
>
>name = "Flintstones Inc. Internal Telephone Service"
>regtype = "SIP"
>domain = "local"
>host = "pbx"
>port = 5060
>
>and txtRecord which would show up as a DNS TXT record, could contain
>various service parameters like authentication method, registrar
>server, outbound proxy, dtmfmode, contact, voicemail access number etc
>etc. For IAX, switchboard extension and incoming context could also be
>advertised here.
>
>For starters I envisage the following two scenarios:
>
>1) New IP telephone set deployment
>
>The phone would be put on a user's desk, connected to the LAN and
>power, switched on and the menu would display a list of advertised
>services. The "telephone guy" would select the appropriate service and
>all service parameters would be set accordingly, leaving only the user
>ID and password to be supplied. This could be further automated by an
>IVR that an employee calls to be provisioned.
>
>2) Walk-in guest user, ie Hotel
>
>The WiFi phone would be switched on at the Hotel's premises and the
>Hotel's welcome service would show up on the display. The user would
>select the service and thereby be enabled to call an IVR that walks
>him through the necessary steps to receive service, ie establishing
>prepaid credit or key in a code received at check-in which triggers
>automatic provisioning. A similar situation could be imagined for a
>travelling employee visiting a remote office.
>
>I am sure there are more scenarios. As with so many things the
>potential will probably only become visible once using it.
>
>Anyway, with those starter scenarios in mind, I was trying to come up
>with an idea how to tell Asterisk what to advertise and what
>parameters to advertise. I am split between a decidated zeroconf.conf
>configuration file for the details or adding a few things to sip.conf,
>iax.conf etc. The answer probably lies somewhere in between.
>
>For example, if we look at how voicemail is configured, this could
>serve as a model:
>
>voicemail.conf ...
>
>1000 => ...
>
>sip.conf ...
>
>[user]
>...
>mailbox=1000
>
>If we were to use this as a blueprint, then we might do something like this:
>
>For scenario #1
>
>zeroconf.conf ...
>
>[internal]
>enable=yes
>bindaddr=192.168.77.99 ; only advertise on this interface
>servicename="Flintstones Inc. Internal Telephone Service
>(authentication required)"
>username=no ; do not advertise usernames -- this would be the default
>auth=yes ; advertise authentication method
>vmaccess=8500 ; advertise voicemail access number
>
>sip.conf ...
>
>[2001]
>...
>zeroconf=internal ; referring to the entry [internal] in zeroconf.conf
>
>[2002]
>...
>zeroconf=internal ; referring to the entry [internal] in zeroconf.conf
>
>A potential problem I see here would be different users having
>different parameters amongst those to be advertised. Not sure yet how
>to resolve this.
>
>For scenario #2
>
>zeroconf.conf ...
>
>[walk-in]
>enable=yes
>servicename="Flintstones Hotel Walk-in Telephone Service"
>username=yes ; advertise username
>auth=yes ; advertise authentication method
>dtmfmode=yes ; advertise dtmfmode
>contact=7000 ; advertise switchboard/IVR contact number
>
>sip.conf ...
>
>[guest]
>...
>zeroconf=walk-in ; referring to the entry [walk-in] in zeroconf.conf
>
>
>Any comments as to the how and what are appreciated.
>
>Anybody who has issues with zeroconf as such please start a new thread
>and discuss there, don't hijack this one as this one is solely aimed
>at discussing the how and what.
>
>thanks
>rgds
>benjk
>  
>




More information about the asterisk-dev mailing list