This is an outbound issue that affects SIP and Zap (T1 from another PBX) channels going out our PRI to Telco. I have two AT&T conference number that will take the conference access codes. (in theory) (214) 622 4991 (866) 340 2763 If we dial the toll free one, the menus time out because they are not recieving any DTMF. If I wait and connect to the conference receptionist/tech(?) they can do a three way call back in and my DTMF works. (they then tell me there is no problem) If I call the 214 number it works without issue. The odd thing here is that I receive DTMF back from them when it first answers the line. ref: Dec 6 10:28:21 VERBOSE[1448]: -- Called g0/12146224991 Dec 6 10:28:21 DEBUG[1448]: Ooh, format changed from unknown to ulaw Dec 6 10:28:24 DEBUG[1448]: DTMF digit: * on Zap/2-1 Dec 6 10:28:24 DEBUG[1448]: DTMF digit: 8 on Zap/2-1 Dec 6 10:28:24 DEBUG[1448]: Enabled echo cancellation on channel 2 Is this something that they are sending to test/set some DTMF setting on my side, or might I just be hearing them call forward to some other number? The thing that really confuses me is the 866 number. If there is something wrong with my setup, then why does my DTMF work if they 3 way back in. I am still on the same call and do not think any settings on my side would change because of what they do on the other side. But I still think the Issue IS on my side, because if the main toll free AT&T Conference number has this problem, I think they would know and would have addressed it. zaptel.conf: span=1,1,0,esf,b8zs bchan=1-23 dchan=24 span=2,0,0,esf,b8zs e&m=25-48 loadzone = us defaultzone = us zapata.conf: context=from-pstn switchtype=national priindication = outofband signalling=pri_cpe rxwink=300 ; Atlas seems to use long (250ms) winks usecallerid=yes hidecallerid=no callwaiting=no usecallingpres=yes callwaitingcallerid=no threewaycalling=no transfer=no cancallforward=yes callreturn=yes echocancel=yes echocancelwhenbridged=no echotraining=no rxgain=0.0 txgain=0.0 faxdetect=no group=0 callgroup=1 pickupgroup=1 immediate=no accountcode=I musiconhold=default channel => 1-23 -- -- Steven May you have the peace and freedom that come from abandoning all hope of having a better past. --- - --- - - - - - - - -- - - - --- - ------ - - --- - - -- - - - -- - - -
Note: I upgraded Zaptel to the 1.2 stable and changed digits.h line to #define DEFAULT_DTMF_LENGTH 250 * 8. I was told that there is still a problem. -- -- Steven May you have the peace and freedom that come from abandoning all hope of having a better past. --- - --- - - - - - - - -- - - - --- - ------ - - --- - - -- - - - -- - - - "Steven" <asterisk@tescogroup.com> wrote in message news:dn4bsi$djm$1@sea.gmane.org...> This is an outbound issue that affects SIP and Zap (T1 from another PBX) > channels going out our PRI to Telco. > > I have two AT&T conference number that will take the conference access > codes. (in theory) > (214) 622 4991 > (866) 340 2763 > > If we dial the toll free one, the menus time out because they are not > recieving any DTMF. > If I wait and connect to the conference receptionist/tech(?) they can do a > three way call back in and my DTMF works. (they then tell me there is no > problem) > > If I call the 214 number it works without issue. The odd thing here is > that I receive DTMF back from them when it first answers the line. > ref: > Dec 6 10:28:21 VERBOSE[1448]: -- Called g0/12146224991 > Dec 6 10:28:21 DEBUG[1448]: Ooh, format changed from unknown to ulaw > Dec 6 10:28:24 DEBUG[1448]: DTMF digit: * on Zap/2-1 > Dec 6 10:28:24 DEBUG[1448]: DTMF digit: 8 on Zap/2-1 > Dec 6 10:28:24 DEBUG[1448]: Enabled echo cancellation on channel 2 > > Is this something that they are sending to test/set some DTMF setting on > my side, or might I just be hearing them call forward to some other > number? > > The thing that really confuses me is the 866 number. If there is > something wrong with my setup, then why does my DTMF work if they 3 way > back in. I am still on the same call and do not think any settings on my > side would change because of what they do on the other side. > > But I still think the Issue IS on my side, because if the main toll free > AT&T Conference number has this problem, I think they would know and would > have addressed it. > > zaptel.conf: > span=1,1,0,esf,b8zs > bchan=1-23 > dchan=24 > > span=2,0,0,esf,b8zs > e&m=25-48 > > loadzone = us > defaultzone = us > > > zapata.conf: > > context=from-pstn > switchtype=national > priindication = outofband > signalling=pri_cpe > rxwink=300 ; Atlas seems to use long (250ms) winks > usecallerid=yes > hidecallerid=no > callwaiting=no > usecallingpres=yes > callwaitingcallerid=no > threewaycalling=no > transfer=no > cancallforward=yes > callreturn=yes > echocancel=yes > echocancelwhenbridged=no > echotraining=no > rxgain=0.0 > txgain=0.0 > faxdetect=no > group=0 > callgroup=1 > pickupgroup=1 > immediate=no > accountcode=I > musiconhold=default > channel => 1-23 > > > -- > -- > Steven > > May you have the peace and freedom that come from abandoning all hope of > having a better past. > --- - --- - - - - - - - -- - - - --- - ------ > - - --- - - -- - - - -- - - - > > > _______________________________________________ > --Bandwidth and Colocation provided by Easynews.com -- > > Asterisk-Users mailing list > To UNSUBSCRIBE or update options visit: > http://lists.digium.com/mailman/listinfo/asterisk-users >
It looks like http://bugs.digium.com/view.php?id=5266 is the problem here. My CDR shows as not answered for the tool free number. The local number answers and call forwards. Questions: It says it was committed on 10-04-05. How do I know which versions that was? I am currently running: asterisk stable 1.0.9 zaptel stable 1.2.1 libpri stable 1.0.9 I was told that zaptel and asterisk versions do not have to match. What about libpri? Can I go to libpri 1.2.1 and stay with asterisk 1.0.9? Should I just patch 1.0.9? (I would have to figure out which version the patch was for) -- -- Steven May you have the peace and freedom that come from abandoning all hope of having a better past. --- - --- - - - - - - - -- - - - --- - ------ - - --- - - -- - - - -- - - - "Steven" <asterisk@tescogroup.com> wrote in message news:dn4bsi$djm$1@sea.gmane.org...> This is an outbound issue that affects SIP and Zap (T1 from another PBX) channels going out our PRI to Telco. > > I have two AT&T conference number that will take the conference access codes. (in theory) > (214) 622 4991 > (866) 340 2763 > > If we dial the toll free one, the menus time out because they are not recieving any DTMF. > If I wait and connect to the conference receptionist/tech(?) they can do a three way call back in and my DTMF works. (they then > tell me there is no problem) > > If I call the 214 number it works without issue. The odd thing here is that I receive DTMF back from them when it first answers > the line. > ref: > Dec 6 10:28:21 VERBOSE[1448]: -- Called g0/12146224991 > Dec 6 10:28:21 DEBUG[1448]: Ooh, format changed from unknown to ulaw > Dec 6 10:28:24 DEBUG[1448]: DTMF digit: * on Zap/2-1 > Dec 6 10:28:24 DEBUG[1448]: DTMF digit: 8 on Zap/2-1 > Dec 6 10:28:24 DEBUG[1448]: Enabled echo cancellation on channel 2 > > Is this something that they are sending to test/set some DTMF setting on my side, or might I just be hearing them call forward to > some other number? > > The thing that really confuses me is the 866 number. If there is something wrong with my setup, then why does my DTMF work if > they 3 way back in. I am still on the same call and do not think any settings on my side would change because of what they do on > the other side. > > But I still think the Issue IS on my side, because if the main toll free AT&T Conference number has this problem, I think they > would know and would have addressed it. > > zaptel.conf: > span=1,1,0,esf,b8zs > bchan=1-23 > dchan=24 > > span=2,0,0,esf,b8zs > e&m=25-48 > > loadzone = us > defaultzone = us > > > zapata.conf: > > context=from-pstn > switchtype=national > priindication = outofband > signalling=pri_cpe > rxwink=300 ; Atlas seems to use long (250ms) winks > usecallerid=yes > hidecallerid=no > callwaiting=no > usecallingpres=yes > callwaitingcallerid=no > threewaycalling=no > transfer=no > cancallforward=yes > callreturn=yes > echocancel=yes > echocancelwhenbridged=no > echotraining=no > rxgain=0.0 > txgain=0.0 > faxdetect=no > group=0 > callgroup=1 > pickupgroup=1 > immediate=no > accountcode=I > musiconhold=default > channel => 1-23 > > > -- > -- > Steven > > May you have the peace and freedom that come from abandoning all hope of having a better past. > --- - --- - - - - - - - -- - - - --- - ------ - - --- - - -- - - - -- - - - > > > _______________________________________________ > --Bandwidth and Colocation provided by Easynews.com -- > > Asterisk-Users mailing list > To UNSUBSCRIBE or update options visit: > http://lists.digium.com/mailman/listinfo/asterisk-users >
I was wrong. This patch is for channels/chan_zap.c I have been hesitant to go to 1.2.1 without config testing. Should I have any negative issues going from 1.0.9 to 1.0.10? ( I have to see if the changes are in the 1.0.10 version of channels/chan_zap.c) -- -- Steven It looks like http://bugs.digium.com/view.php?id=5266 is the problem here. My CDR shows as not answered for the tool free number. The local number answers and call forwards. Questions: It says it was committed on 10-04-05. How do I know which versions that was? I am currently running: asterisk stable 1.0.9 zaptel stable 1.2.1 libpri stable 1.0.9 I was told that zaptel and asterisk versions do not have to match. What about libpri? Can I go to libpri 1.2.1 and stay with asterisk 1.0.9? Should I just patch 1.0.9? (I would have to figure out which version the patch was for)