Yes, I think that an in-person meeting would be the best way to get this kind of thing started. Trying to work out interop, security, and other issues is a lot easier in a free-flowing conversation.
On Mon, Feb 9, 2009 at 11:08 PM, Philip Mullis <[email protected]> wrote: > 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] > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
