Folks -- First, apologies for not lurking for weeks or months to get the culture of the list. I read the recent post about improvement to the quality of posts with some amusement and full agreement. The problem is a big and very real one. I hope I'm not deepening it. But my question isn't explicitly asked with this subject line or definitively answered in the archives -- that I have found. What I did find left me with the impression that USA 'BRI', uh, '2B1Q' protocol(?) is not supported by *any* hardware vendor, at all, period, nor is it tested and proved in the software... stack(?), in one related branch or another on the OS side. A couple of direct inquiries to card vendors have dead-ended with a flat "no", or requests for development funds(!) -- apparently there is code for one card, one vendor, that runs against 'bristuff', or did at one time, but wasn't maintained through several Asterisk releases (if the code was even released to the community... IDK). Is this common, that someone codes to their chip on their card and sells it to one or two consumers, then lets it drop and never gives the code up for continued development? (It seems contrary to GNU/Linux licensing conventions, but, again, I'm not paid as a software developer. I just think they might have sold more cards with a less proprietary approach.) Anyway, can I, with confidence, state (to the $employer) that Asterisk on linux via USA 'BRI' digital lines simply isn't possible? (In that, obviously, I can't pay for development nor do beta testing, each with vague hope that it might work okay someday...) If this is the case, then I must use multiple analog lines to access PSTN, or pay premium for 'PRI' pipes (80% of which we will never need)... is that about correct? Thanks in advance for any pointers, specific RTFM suggestions, any help appreciated. If there is a different list to post this query to, I'm not (yet) aware of it. Cheers, -- |\ /| | | ~ ~ | \/ | |---| `|` ? | |ichael | |iggins \^ / michael.higgins[at]evolone[dot]org
Michael Higgins wrote: At least here in Canada - DSL just seems to have killed BRI - you practically have to know the secret handshake to even be allowed to provision one any more. It killed it as an internet transport which was its most widespread use, however its many benefits as a digital phone line are being largely ignored. I barked up the same tree you are barking for a while and just gave up - lots of "you could buy this and try it", but no proven solution. Kind of expensive to get a line put in and buy hardware for a maybe. Years ago we had tons of BRI circuits around I could have tried this on, but thats long gone.> Folks -- > > First, apologies for not lurking for weeks or months to get the culture of the list. I read the recent post about improvement to the quality of posts with some amusement and full agreement. The problem is a big and very real one. I hope I'm not deepening it. > > But my question isn't explicitly asked with this subject line or definitively answered in the archives -- that I have found. > > What I did find left me with the impression that USA 'BRI', uh, '2B1Q' protocol(?) is not supported by *any* hardware vendor, at all, period, nor is it tested and proved in the software... stack(?), in one related branch or another on the OS side. > > A couple of direct inquiries to card vendors have dead-ended with a flat "no", or requests for development funds(!) -- apparently there is code for one card, one vendor, that runs against 'bristuff', or did at one time, but wasn't maintained through several Asterisk releases (if the code was even released to the community... IDK). > > Is this common, that someone codes to their chip on their card and sells it to one or two consumers, then lets it drop and never gives the code up for continued development? (It seems contrary to GNU/Linux licensing conventions, but, again, I'm not paid as a software developer. I just think they might have sold more cards with a less proprietary approach.) > > Anyway, can I, with confidence, state (to the $employer) that Asterisk on linux via USA 'BRI' digital lines simply isn't possible? (In that, obviously, I can't pay for development nor do beta testing, each with vague hope that it might work okay someday...) > > If this is the case, then I must use multiple analog lines to access PSTN, or pay premium for 'PRI' pipes (80% of which we will never need)... is that about correct? > > Thanks in advance for any pointers, specific RTFM suggestions, any help appreciated. > > If there is a different list to post this query to, I'm not (yet) aware of it. > > Cheers, > >
On Tue, Jan 27, 2009 at 09:49:41AM -0800, Michael Higgins wrote:> What I did find left me with the impression that USA 'BRI', uh, '2B1Q' > protocol(?) is not supported by *any* hardware vendor, at all, period, > nor is it tested and proved in the software... stack(?), in one > related branch or another on the OS side.To the best of my understanding, latest Asterisk should support it through chan_dahdi . No need for extra bristuff or whatever. But this needs some testing.> > A couple of direct inquiries to card vendors have dead-ended with a > flat "no", or requests for development funds(!) -- apparently there > is code for one card, one vendor, that runs against 'bristuff', or > did at one time, but wasn't maintained through several Asterisk > releases (if the code was even released to the community... IDK).Actually from the little I can tell, BRI there behaves very much like PRI. No extra ptmp complications as in the rest of the world. And then you have to recall that chan_dahdi's libpri was developed by US people originally, and hence actually supports the crazy mess of ISDN signalling there ;-) It seems, though you may need to do some custom wiring.> > Is this common, that someone codes to their chip on their card and > sells it to one or two consumers, then lets it drop and never gives > the code up for continued development? (It seems contrary to GNU/Linux licensing conventions, but, again, I'm not paid as a software developer. I just think they might have sold more cards with a less proprietary approach.) > > Anyway, can I, with confidence, state (to the $employer) that Asterisk > on linux via USA 'BRI' digital lines simply isn't possible? (In that, > obviously, I can't pay for development nor do beta testing, each with > vague hope that it might work okay someday...)A cheap HFC-S -based BRI card (the type supported by virtually all candidate ISDN/BRI channels for Asterisk. Except chan_capi, I guess) shouldn't cost you much (naturally I personally would prefer you used our hardware, but then again, you may have other considerations) I figure that 20$-30$ or so. I have no idea about other setup costs (getting a line, etc.). -- Tzafrir Cohen icq#16849755 jabber:tzafrir.cohen at xorcom.com +972-50-7952406 mailto:tzafrir.cohen at xorcom.com http://www.xorcom.com iax:guest at local.xorcom.com/tzafrir
I'm in the same boat and have been looking at this for several months, but haven't actually jumped in, hands-on, yet. No, I don't think the situation is as dismal as you paint it, although the lack of appropriate marketing for BRI in the US has all but killed it here, making it relatively unattractive to vendors. I have been advised of several cards that support it, but they were two or four port cards that were serious overkill for my application, and expectedly pricy as a result. I am trying to use an HFC card, and have been advised that it is possible, but will take some digging and experimenting. As near as I have been able to figure out, mISDN is the appropriate place to begin, but I haven't tried to sort it out, yet. There are a couple of other paths that might lead to a solution, but they seem to be less supported than mISDN at present (if that is even possible). It sounds like Dahdi is moving towards that, but I don't think its quite there, yet. Qwest is one of the few providers I know of that prices BRI reasonably. I have one up and running on a TA and use it for my voice service. As soon as I can figure out mISDN, I plan to move it to Asterisk. (I'll keep a TA around for backup). Wilton -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20090127/670397f1/attachment.htm
On Tue, Jan 27, 2009 at 12:49 PM, Michael Higgins <linux at evolone.org> wrote:> Folks -- > > First, apologies for not lurking for weeks or months to get the culture of the list. I read the recent post about improvement to the quality of posts with some amusement and full agreement. The problem is a big and very real one. I hope I'm not deepening it. > > But my question isn't explicitly asked with this subject line or definitively answered in the archives -- that I have found. > > What I did find left me with the impression that USA 'BRI', uh, '2B1Q' protocol(?) is not supported by *any* hardware vendor, at all, period, nor is it tested and proved in the software... stack(?), in one related branch or another on the OS side. > > A couple of direct inquiries to card vendors have dead-ended with a flat "no", or requests for development funds(!) -- apparently there is code for one card, one vendor, that runs against 'bristuff', or did at one time, but wasn't maintained through several Asterisk releases (if the code was even released to the community... IDK). > > Is this common, that someone codes to their chip on their card and sells it to one or two consumers, then lets it drop and never gives the code up for continued development? (It seems contrary to GNU/Linux licensing conventions, but, again, I'm not paid as a software developer. I just think they might have sold more cards with a less proprietary approach.) > > Anyway, can I, with confidence, state (to the $employer) that Asterisk on linux via USA 'BRI' digital lines simply isn't possible? (In that, obviously, I can't pay for development nor do beta testing, each with vague hope that it might work okay someday...) > > If this is the case, then I must use multiple analog lines to access PSTN, or pay premium for 'PRI' pipes (80% of which we will never need)... is that about correct? > > Thanks in advance for any pointers, specific RTFM suggestions, any help appreciated. > > If there is a different list to post this query to, I'm not (yet) aware of it. > > Cheers, > > -- > |\ /| | | ~ ~ > | \/ | |---| `|` ? > | |ichael | |iggins \^ / > michael.higgins[at]evolone[dot]org >Get a hold of Marcin Pyco (Former Digium Employee and extrememly smart guy. He has code/patches for zaptel to US BRIs work that include SPID as a variable in zap confs. Just have to be careful if you decide to upgrade at some point Thanks, Steve Totaro -- Thanks, Steve Totaro +18887771888 (Toll Free) +12409381212 (Cell) +12024369784 (Skype)
On Tue, Jan 27, 2009 at 03:45:34PM -0500, Steve Totaro wrote:> Get a hold of Marcin Pyco (Former Digium Employee and extrememly smart guy. > > He has code/patches for zaptel to US BRIs work that include SPID as a > variable in zap confs.Could you please expand on that point? Why should such patches remain secret? And are those patches really necessary now that chan_dahdi knows that there is such a thing called BRI? -- Tzafrir Cohen icq#16849755 jabber:tzafrir.cohen at xorcom.com +972-50-7952406 mailto:tzafrir.cohen at xorcom.com http://www.xorcom.com iax:guest at local.xorcom.com/tzafrir
On Tue, 27 Jan 2009 09:49:41 -0800, Michael Higgins wrote: <snip> It seems to me that there a lot of "it ought to work or could be made to to work" associated with implementing US BRI into Asterisk. That being the case what's called for is someone to try it, just to prove the point. Over the past year or two at least a couple of hardware vendors have indicated a willingness to help with loan of interface hardware (Xorcom & Pika) Perhaps a small group could take on the task of giving it a try? It's a pain to have a BRI provisioned from an ILEC just for sake of an experiment. I may know someone who has functional BRI already. They're a TV station using it to convey production audio. If they agreed would it be possible/practical to use their BRI for a short while just to have a quick test? Michael -- Michael Graves mgraves<at>mstvp.com http://blog.mgraves.org o713-861-4005 c713-201-1262 sip:mgraves at mstvp.onsip.com skype mjgraves fwd 54245
On Wed, Jan 28, 2009 at 2:39 AM, Tzafrir Cohen <tzafrir.cohen at xorcom.com> wrote:> On Tue, Jan 27, 2009 at 08:35:56PM -0500, Steve Totaro wrote: > >> Who said he wants HIS software to be Open Source? It is his and if he >> want to, God forbid, make a profit from his work, then who the hell >> are you to say it is not right? > > His software seems to be patches to GPLed software. That means that > whoever gets those patches has the full right to pass them on. > This is regardless of getting paid for a job.So stop complaining about it and pony up the cash.> >> There are a great deal of missing IEs or Unknown IEs, caller ID does >> not work at all, when first starting the box, oubtbound calls work >> right away, then it takes about 30-40 minutes for inbound to start >> working. At random intervals, the card would stop taking calls for no >> reason and then start again after 30-40 minutes. >> >> If you can deal with that, then go for it. > > Missing IEs? this reads like a patch to libpri. Or incorrect > definitions?Yes, I believe libpri is part of his patches.> > Or try to pull resources. Provide pri debug trace and such.Do the people who "pull resources" get any compensation? Obviously Xorcom gets to benefit financially. I am tired of vendors waiving an opensource flag when in reality, it is their loss leader and turns their NOT FREE products into more than a paper weight.> > No reason to pay this separate development cost on each separate case.No reason from your viewpoint because this is a market that you (Xorcom) would love to tap, and not pay for the ability. Write your own patches if you think it is so trivial and not worth paying for.> > -- > Tzafrir Cohen > icq#16849755 jabber:tzafrir.cohen at xorcom.com > +972-50-7952406 mailto:tzafrir.cohen at xorcom.com > http://www.xorcom.com iax:guest at local.xorcom.com/tzafrir-- Thanks, Steve Totaro +18887771888 (Toll Free) +12409381212 (Cell) +12024369784 (Skype)
BRI is not even supported on Nortel's rural market softswitch, the CS-1500. BRI is a dead horse.. Frank -----Original Message----- From: asterisk-users-bounces at lists.digium.com [mailto:asterisk-users-bounces at lists.digium.com] On Behalf Of Michael Higgins Sent: Tuesday, January 27, 2009 11:50 AM To: Asterisk Users Mailing List - Non-Commercial Discussion Subject: [asterisk-users] USA BRI -- any hope at all? Folks -- First, apologies for not lurking for weeks or months to get the culture of the list. I read the recent post about improvement to the quality of posts with some amusement and full agreement. The problem is a big and very real one. I hope I'm not deepening it. But my question isn't explicitly asked with this subject line or definitively answered in the archives -- that I have found. What I did find left me with the impression that USA 'BRI', uh, '2B1Q' protocol(?) is not supported by *any* hardware vendor, at all, period, nor is it tested and proved in the software... stack(?), in one related branch or another on the OS side. A couple of direct inquiries to card vendors have dead-ended with a flat "no", or requests for development funds(!) -- apparently there is code for one card, one vendor, that runs against 'bristuff', or did at one time, but wasn't maintained through several Asterisk releases (if the code was even released to the community... IDK). Is this common, that someone codes to their chip on their card and sells it to one or two consumers, then lets it drop and never gives the code up for continued development? (It seems contrary to GNU/Linux licensing conventions, but, again, I'm not paid as a software developer. I just think they might have sold more cards with a less proprietary approach.) Anyway, can I, with confidence, state (to the $employer) that Asterisk on linux via USA 'BRI' digital lines simply isn't possible? (In that, obviously, I can't pay for development nor do beta testing, each with vague hope that it might work okay someday...) If this is the case, then I must use multiple analog lines to access PSTN, or pay premium for 'PRI' pipes (80% of which we will never need)... is that about correct? Thanks in advance for any pointers, specific RTFM suggestions, any help appreciated. If there is a different list to post this query to, I'm not (yet) aware of it. Cheers, -- |\ /| | | ~ ~ | \/ | |---| `|` ? | |ichael | |iggins \^ / michael.higgins[at]evolone[dot]org _______________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
On Tuesday 27 January 2009 11:49:41 Michael Higgins wrote:> What I did find left me with the impression that USA 'BRI', uh, '2B1Q' > protocol(?) is not supported by *any* hardware vendor, at all, period, nor > is it tested and proved in the software... stack(?), in one related branch > or another on the OS side.There is a strong possibility that this could be supported in Asterisk in the future. What is preventing it right now is that the people at Digium who are capable of writing this functionality are working on projects with "real customers"; that is, they're working on projects that are already funded. If US BRI support is something that you really would like to see, I would suggest making a call to Digium sales and asking for it, specifically. Only when the sales department starts hearing about it on a regular basis is when the people who are capable of writing it (and releasing it to the community) will be assigned to working on it. If I were the least bit capable of doing this, it would already be in Asterisk. I, for one, would love to replace my analog channels with digital (and it would actually be affordable in Tennessee, where I live ~$40/mo). -- Tilghman
On Wed, 28 Jan 2009, Tilghman Lesher wrote:> If I were the least bit capable of doing this, it would already be in > Asterisk. I, for one, would love to replace my analog channels with digital > (and it would actually be affordable in Tennessee, where I live ~$40/mo).I replaced my analogue channels with digital some time back. Using a technology called VoIP... ;-) However this has been an interesting thread - ISDN2e (BRI) is widely used in the UK and Europe and I have several installations use it in. Just how different is the US system to the European/UK one? (and why?) Gordon
One problem with BRI adoption has no doubt been the need for external power to the NT1 or TA. Obviously analog loops are powered by the CO, so much of the benefit of ISDN-BRI as the first voice circuit is eroded away for a large percentage of the installed base.
On Jan 27, 2009, at 9:49 AM, Michael Higgins wrote:> Folks -- > > First, apologies for not lurking for weeks or months to get the > culture of the list. I read the recent post about improvement to the > quality of posts with some amusement and full agreement. The problem > is a big and very real one. I hope I'm not deepening it. > > But my question isn't explicitly asked with this subject line or > definitively answered in the archives -- that I have found. > > What I did find left me with the impression that USA 'BRI', uh, > '2B1Q' protocol(?) is not supported by *any* hardware vendor, at > all, period, nor is it tested and proved in the software... > stack(?), in one related branch or another on the OS side.You might want to look into Cisco hardware, their WIC-1B-U cards work fine in the US, or they did 10 years ago when I last used them for VoIP. Used the WIC-1B-U is going for under $50 on eBay. An old 1600 or 1700 series router with an IOS that supports SIP wouldn't cost much either.> >-- Eric Chamberlain, Founder RF.com - http://RF.com/