SIP in higher education

[William Caban <>]

I perfectly understand your points. I did notice the scaling issue from 
the very beginning but actually I'm thinking at them as complementary 
protocols. I understand is not widely supported by commercial vendors 
and probably won't be for a while, but that is relatively easy to 
change. Not too long ago (still some nowadays) vendors were not willing 
to support sip because it was not of interest to the traditional telcos. 
Now we know it has been changed, not because of the telcos but because 
of the users. What I actually liked about DUNDi was the ability to 
aggregate numbers in a central location just like a "routing table" for 
telephony, now, I'm thinking more in a close system (lets say a 
University or a Corporation or an organization) where "trust" can be 
achieve with more control,  and from there do Enum.164.

I'm from the networking world so I actually see this as the IGP vs EGP 
of VoIP, but again, I'm not up-to-date with the VoIP+prefix_routing RFCs.

--William

Duane wrote:

> William Caban wrote:
>
> > I just came across this draft and I don't remember a mention about it 
> > before. Probably it will be a good protocol/specification/draft to 
> > explore for SIPedu peering and identify the protocol extensions that 
> > might be in common with SIPedu or that might help the adoption of 
> > SIPedu outside a research network.
> >
> > Distributed Universal Number Discovery (DUNDi)
> > http://www.dundi.com/dundi.txt
>
>
> Dundi is often confusingly promoted as to it's real benefits (and it's 
> downfalls), mainly it's key benefit is a corp lan running a couple of 
> asterisk boxes that they don't care about vendor lock-in... Enum.164 
> won't lock you to any vendor and is already widely supported, IAX is 
> another open protocol that very few things support, and it's unlikely 
> to be picked up by the cisco's of the world any time soon...
>
> Dundi is no better then internal enum, except it locks you in to only 
> using asterisk boxes, so anyone with cisco etc kit won't be able to 
> make use of it out of the box, you'd have to proxy via an asterisk box 
> (which would be self defeating)... Cisco etc can usually talk enum out 
> of the box...
>
> Dundi could have potential issues with scaling, as the more boxes used 
> to add routing to the network increases and each box in turn is 
> searched it could cause increasingly long wait times to find routes... 
> Enum.164 because of the efficiencies of DNS won't suffer scalability 
> issues, just add more servers basically...
>
> Dundi is an explicit trust system, you either trust it or you don't, 
> and any boxes you trust, have the ability to inject routes they don't 
> own... While Enum.164 can also be this way if NS records are delegated 
> willy nilly, more often then not it's a more highly controlled system 
> of who has access to what...