You have mentioned some very good points, testing and design will still need to be done, at this point im trying to gather qualified interested parties in getting this started so the ball can begin to roll.
Going to a centralized system does have many advantages and will require a significant amount of design consideration. Im happy to start hacking away at this and would love to start testing after a bit more feedback or perhaps a breif technical meeting to cover of points of interest, security considerations and questions for interoperabiltiy query tools for other platforms such as metaswitch. Tentatively should we set a meeting date at this point to get all interested parties together to hash this out best? Regards, Philip Mullis -----Original Message----- From: Matthew Gamble [mailto:[email protected] Sent: Mon 2/9/2009 7:03 PM To: [email protected] Subject: Re: [biz] dundi/did peering Philip / Tim, First off I need to state that my opinions on this are my own, and not those of my employer. I've been thinking about this issue (voip peering) and while the Dundi peering system looks great on paper but it has several flaws that I couldn't find answers for: 1) The entire model is based solely on trust of the peers to ensure they only advertise routes that belong to them. 2) There are no provisions in the model for handing privacy. In the TDM world when two carriers interconnect, ANI is passed between them for billing and call logging purposes. In the Dundi model I can't peer with another provider and ensure that they won't pass the calls P-Asserted-Identify on to the subscriber, even if privacy is turned on. 3) It seems very difficult for both a subscriber (say someone with 100 DID's) and a Provider to both peer at the same exchange. Both have a valid reason to announce a number, but who takes priority? 4) If a subscriber of mine ports a number away without telling me, NPAC ensures that routing updates in the SS7 world. How is this done in a Dundi system? If I don't remember to remove a number from my switch a subscriber could be unable to receive calls until I remove the number. What I think we *really* need to is to get a system similar to what is done in the TDM world via the NPAC system, but for SIP. SIP peering needs a central authority to ensure number ownership, deal with portability issues, and resolve issues such as the privacy of ANI. These are all things that a distributed system such as Dundi does not provide. I'd love to be involved with anything that brings VoIP peering to Toronto, but I'm not 100% sold that Dundi is the solution. I've talked to several TorIX peers and they are also interested, but they share the same concerns that I do about security, privacy, and number routing. M. Gamble On Mon, Feb 9, 2009 at 6:47 PM, Philip Mullis <[email protected]> wrote: > Thanks for the input Tim, ill start to put together a site for registration > and some tools for testing and to aid people in getting setup. > > Once this is up and running locally we should extend this out to the other > asterisk user groups such as New York, we could create quite a nice large > peering ring in time. > > Phil. > > > > Tim St. Pierre wrote: >> >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> I really like the idea. >> >> I have put hooks in my system for SIP peerings from the beginning, but >> never had the opportunity to use them. >> >> It always seemed a little backwards to me when two IP clients are >> connecting over the PSTN. >> >> 100 DIDs isn't a bad number, but it could be a little bit high. We are >> primarily a business provider, and have just under 100 DIDs, but many >> more endpoints than that, since most of our customers have 6-10 phones >> but only 1 or 2 DIDs. >> >> I agree with connectivity requirements. >> >> We should probably agree that g.711u/A be mandatory, with other codecs >> optional (negotiated upon INVITE). >> >> - -Tim >> >> Philip Mullis wrote: >> >>> >>> I'm popping this off to both list so please forgive me for the cross >>> post. >>> >>> Id like to propose the creation of a /DUNDi/^(TM) network for providers >>> / trunk users if one doesn't already exist (starting with the members >>> within our group). >>> >>> There is quite a few of us now I imagine have become providers over the >>> years along with a number of heavy sip trunk users. >>> >>> Although for some this proposal wouldn't offer drastic reductions in >>> upstream provider channel usage; it would however save all of us >>> tariffed channels if we end up calling DID's in our respective DUNDI >>> cloud. >>> >>> The /DUNDi/^(TM) network member requirements I'm suggesting at this time >>> >>> -minimum of 100 DIDs and (maybe this should be lower?) >>> -connectivity in a data center or a well manage off-site fiber. >>> (concerns over voice quality mandate this choice) >>> >>> There is currently a similar exchange for Data called TORIX, I hope to >>> start something for VOICE (primarily for people at 151, but not limited >>> to that location) >>> >>> Please let me know your thoughts or if anyone is interested. >>> >>> Regards >>> >>> Philip Mullis >>> >>> >>> >> >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v2.0.4 (FreeBSD) >> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org >> >> iD8DBQFJkLzmI1xz6nMGzusRAgLRAJ9qXebGEgKx5m+ZXaQ/judb7Tc5ZACff7LH >> PbnKdLzA1KVj93idY7yvR0w= >> =Vfzm >> -----END PGP SIGNATURE----- >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
