I've tested this change already, and it's actually more broke than fixed. I have a T100P card connected to a TA750, with 20/4 FXS/FXO. When dialing TO one of these ports, it always looks busy to asterisk... I've backed off to version 1.330 of chan_zap.c and it works fine...
I'll try to post something on the bugtracker... On Thu, 2 Sep 2004 15:34:13 -0600, Rich Adamson <[EMAIL PROTECTED]> wrote: > > > > > > > > A customer of mine has 3 TDM400P cards in a box running > > > > > > asterisk. On each card he has four FXO modules. > > > > > > > > > > > > I have set up the dialplan to dial via group 1 for an outgoing > > > > > > call. > > > > > > > > > > > > Channels 1-12 are in group 1. > > > > > > > > > > > > If he plugs a telephone cable into socket 2 or 3 etc, but not 1, > > > > > > when he dials out, it still tries to make the call via socket 1. > > > > > > > > > > > > Straight away the console says that it has dialed the number via > > > > > > g1 and that it is connecting sip/bla with zap/1-1 (or some > > > > > > such)... > > > > > > > > > > > > On my X100P I get a red alarm if the phone cable is not plugged > > > > > > in. Is there any way to do this with the TDM400P? > > > > > > > > > > > > They would like to be able to unplug lines and use them for > > > > > > other purposes at times. > > > > > > > > > > > > Make sense? > > > > > > > > > > > > I kinda thought that asterisk would realise that nothing was > > > > > > connected to the TDM card and try the second socket, the third > > > > > > etc... > > > > > > > > > > It makes sense, but the code to detect unused rj11's is not in * > > > > > now. > > > > > > > > > > In fact, you'll find that unplugging and replugging the rj11's > > > > > will cause * to fail after a while. (At least that was the case > > > > > about a month ago and there really haven't been any changes to the > > > > > fxo software for some time.) > > > > > > > > > > There are no alarms or other indicators available that would > > > > > suggest a port has failed or is unavailable. > > > > > > > > > So basically if there is a problem with line 1 out of 12, no calls > > > > are going to get through...surely this isn't expected behaviour. > > > > > > > > Is there any way to fix this (I'm the New Zealand distributor of > > > > Digium products and if this is the case, they will be returning to > > > > their propreity pabx)? > > > > > > > > Should I open a bugnote? > > > > > > > > I spoke to a few people on IRC last night who confirmed that this is > > > > the case. It seems crazy. If I send a fax using a fax machine it > > > > works, if I dial a number with a modem it works (even a $5 modem) so > > > > why can't it work in asterisk? It used to work on the X100P's... > > > > > > > > I just want the card not to dial if there is no dialtone... > > > > > > The only response that seems to have any real logic in it is this... > > > > > > - The TDM card seems to have the hardware facilities (eg, chipsets) on > > > it to do substantially more then what it is today > > > - There are very few * developers that truly understand the low level > > > pstn interface requirements necessary to code additional > > > functionality into the TDM drivers > > > - Mark is one of the few that can translate pstn interface > > > requirements > > > into real code, and his time seems to be distributed across a lot of > > > different areas (not sure when he gets to sleep) > > > - the overall design of the TDM card relies on the host system > > > processor > > > to interpret dtmf tones (from digital pcm data flows), etc. > > > Therefore adding functionality to the drivers is a delicate balance > > > between the function and burning host cycles that might be > > > disruptive to other * components > > > - detecting dial tone before dialing would seem to be trevial (I can > > > easily say that as a non programmer), but someone needs to add the > > > code to do it reliably > > > - the chip set in use already has provisions to detect CO battery, > > > line > > > off hook (presumably from a bridged analog phone), battery reversal > > > (supervision), etc, but someone needs to add the code to use it. > > > > > > Best guess is time constraints are having "the" biggest impact. The > > > unwritten default condition for * development is that if a feature or > > > bug fix is expected/required, there is a high probability it won't be > > > addressed unless a bug report is generated, or, one of the developers > > > has the same problem; sort of the squeaky wheel gets the grease. > > > > > > It's my belief (right, wrong or indifferent) that digium is missing > > > out on a major revenue stream due to a lack of understanding > > > "marketing" and the prioritization of certain development functions > > > (like the above) required to sustain/grow sales. If digium is going to > > > rely on the sales of these cards to grow/support *, then something is > > > going to have to change since user experience/opinion for those > > > products is heading in a downward direction (not upward). > > > > > > I'm certainly not ragging on anyone, just stating an opinion FWIW. > > > > > > Rich > > > > How's this for service!!!! > > > > > > =============================================== > > 09-02-04 14:00 ZX81 New Bug > > 09-02-04 15:04 markster Bugnote Added: 0013839 > > 09-02-04 15:04 markster Assigned To => markster > > 09-02-04 15:04 markster Resolution open => fixed > > 09-02-04 15:04 markster Status new => resolved > > =============================================== > > > > And: > > > > =============================================== > > Update of /usr/cvsroot/asterisk/channels > > In directory mongoose.digium.com:/tmp/cvs-serv14053/channels > > > > Modified Files: > > chan_zap.c > > Log Message: > > Don't use FXO's with no battery (bug #2359) > > =============================================== > > > > Amazing! That's great! My customer will be really happy! > > > > Mark thanks for this. > > That sounds excellent! But, the comments within the code imply the change > is for T1 interfaces only (maybe not the TDM card?). > > Just sent a note off to Mark asking for clearification as to which > interfaces it actually applies to. > > Rich > > > > > _______________________________________________ > Asterisk-Users mailing list > [EMAIL PROTECTED] > http://lists.digium.com/mailman/listinfo/asterisk-users > To UNSUBSCRIBE or update options visit: > http://lists.digium.com/mailman/listinfo/asterisk-users > _______________________________________________ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
