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

[Karl Brose]

Benjamin on Asterisk Mailing Lists wrote:

>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.
>
>  
>
And why is that?

>First, security by obscurity is one of the most silly ideas of our time.
>  
>
You seem to be responding to some other post or idea.


>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.
>
>  
>
Good question, what's the point of it?
May be you start looking at Asterisk's configuration files.

>>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?
>  
>
SIP UA's send _sip._udp  SRV DNS queries to their name server to learn 
their SIP server DNS name
and port. And then they find the IP address of that DNS name.
They can learn their name server (and other network info)  from DHCP.  
Someone needs to enter
a username/password into the device for authenticated services.
How does your idea( or better Apple's) know where to ask when it comes 
out of the box?
So any device needs some basic provisioning.

>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
>?.
>  
>
An OPTIONS response can contain any information desired. The client just 
needs to ask the proper question.
Server and client of course need to agree what is being transmitted via 
a definition, such as SDP. But,
this will be a requirement for any information service.

>>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" ?
>  
>
Well, any device that has a defined purpose has a defined protocol to 
start operating.
What's your point?
E.g. A wireless IP phone today already will automatically detect a 
hotspot to get network provisioning info
and connect to a SIP server of choice or by default for guest services.

>>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?
>  
>
See above.

>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 still needs to know where and how to query, nothing magical here.
It seems to me, if this is meant to be a provisioning tool, it would 
better be built on DHCP
a standard protocol already for provisioning, rather than DNS.  Many 
people have had ideas
to load additional services on DNS.  The fact that Apple had some idea 
for doing so, doesn't
make a better one, a priori.  Unfortunately, it does motivate some 
people to blow their horns
in concert.
But anyone is free to implement what you want and show the merits. I 
hope Apple is paying well.