Jeff LaCoursiere
2009-Jan-09 21:33 UTC
[asterisk-users] Spurious hangups on Sangoma A102d, Trixbox 2.6.1
[also posted on Trixbox trunk forum] I am also working with Sangoma directly to debug this, but so far no real luck. TrixBox 2.6.1, A102d card with V33 firmware (latest) and WANPIPE 3.2.6 (3.2.7 is out, but nothing has changed that would affect this problem). The system gets about 200 calls inbound on the trunk, which is not very heavily used, and of those calls one or two a day is randomly terminated in the middle of a call. Other than this problem everything is working fine. All phones are Polycom IP501 with latest firmware as of a year ago... There is only one ethernet switch (Linksys 100/1000 managed) between the phones and the Trixbox, and the runs are less than 50 feet. Calls extension to extension seem to have no issue at all. The network *is* shared data/voice with no QOS and no virtual segments, but if the network was the issue I would expect to see extension to extension calls report this issue, which they have not. This is actually a hotel, and the data portion of the traffic isn't heavily used either. They don't even have a file server. I have the "full" logging enabled, and here is an excerpt of a call that was terminated. You can see the conversation lasted about forty seconds before it was hungup. [snipped the beginning of this process...] [Jan 9 12:34:12] VERBOSE[2778] logger.c: -- Executing [s at macro-dial:7] Dial("Zap/9-1", "SIP/2607&SIP/2605&SIP/2510|20|trM(auto-blkvm)") in new stack [Jan 9 12:34:12] VERBOSE[2778] logger.c: -- Called 2607 [Jan 9 12:34:12] VERBOSE[2778] logger.c: -- Called 2605 [Jan 9 12:34:12] VERBOSE[2778] logger.c: -- Called 2510 [Jan 9 12:34:12] VERBOSE[2778] logger.c: -- SIP/2510-0a29a140 is ringing [Jan 9 12:34:12] VERBOSE[2778] logger.c: -- SIP/2607-0a30c8d0 is ringing [Jan 9 12:34:12] VERBOSE[2778] logger.c: -- SIP/2605-0a372cb0 is ringing [Jan 9 12:34:21] VERBOSE[2778] logger.c: -- SIP/2605-0a372cb0 answered Zap/9-1 [Jan 9 12:34:21] VERBOSE[2778] logger.c: -- Executing [s at macro-auto-blkvm:1] Set("SIP/2605-0a372cb0", "__MACRO_RESULT=") in new stack [Jan 9 12:34:21] DEBUG[2778] app_macro.c: Executed application: Set [Jan 9 12:34:21] VERBOSE[2778] logger.c: -- Executing [s at macro-auto-blkvm:2] Set("SIP/2605-0a372cb0", "__CWIGNORE=") in new stack [Jan 9 12:34:21] DEBUG[2778] app_macro.c: Executed application: Set [Jan 9 12:34:21] VERBOSE[2778] logger.c: -- Executing [s at macro-auto-blkvm:3] DBdel("SIP/2605-0a372cb0", "BLKVM/602/Zap/9-1") in new stack [Jan 9 12:34:21] VERBOSE[2778] logger.c: -- DBdel: family=BLKVM, key=602/Zap/9-1 [Jan 9 12:34:21] DEBUG[2778] app_macro.c: Executed application: DBDel [Jan 9 12:34:21] DEBUG[2778] app_dial.c: Macro exited with status 0 [Jan 9 12:34:21] DEBUG[2778] chan_zap.c: Took Zap/9-1 off hook [Jan 9 12:35:01] VERBOSE[2778] logger.c: == Spawn extension (macro-dial, s, 7) exited non-zero on 'Zap/9-1' in macro 'dial' [Jan 9 12:35:01] VERBOSE[2778] logger.c: == Spawn extension (macro-dial, s, 7) exited non-zero on 'Zap/9-1' [Jan 9 12:35:01] VERBOSE[2778] logger.c: -- Executing [h at macro-dial:1] Macro("Zap/9-1", "hangupcall") in new stack [Jan 9 12:35:01] VERBOSE[2778] logger.c: -- Executing [s at macro-hangupcall:1] ResetCDR("Zap/9-1", "w") in new stack [Jan 9 12:35:01] DEBUG[2778] app_macro.c: Executed application: ResetCDR [Jan 9 12:35:01] VERBOSE[2778] logger.c: -- Executing [s at macro-hangupcall:2] NoCDR("Zap/9-1", "") in new stack [Jan 9 12:35:01] DEBUG[2778] app_macro.c: Executed application: NoCDR [Jan 9 12:35:01] VERBOSE[2778] logger.c: -- Executing [s at macro-hangupcall:3] GotoIf("Zap/9-1", "1?skiprg") in new stack [Jan 9 12:35:01] VERBOSE[2778] logger.c: -- Goto (macro-hangupcall,s,6) [Jan 9 12:35:01] DEBUG[2778] app_macro.c: Executed application: GotoIf [Jan 9 12:35:01] VERBOSE[2778] logger.c: -- Executing [s at macro-hangupcall:6] GotoIf("Zap/9-1", "0?skipblkvm") in new stack [Jan 9 12:35:01] DEBUG[2778] app_macro.c: Executed application: GotoIf [Jan 9 12:35:01] VERBOSE[2778] logger.c: -- Executing [s at macro-hangupcall:7] NoOp("Zap/9-1", "Cleaning Up Block VM Flag: BLKVM/602/Zap/9-1") in new stack [Jan 9 12:35:01] DEBUG[2778] app_macro.c: Executed application: Noop [Jan 9 12:35:01] VERBOSE[2778] logger.c: -- Executing [s at macro-hangupcall:8] DBdel("Zap/9-1", "BLKVM/602/Zap/9-1") in new stack [Jan 9 12:35:01] VERBOSE[2778] logger.c: -- DBdel: family=BLKVM, key=602/Zap/9-1 [Jan 9 12:35:01] VERBOSE[2778] logger.c: -- DBdel: Error deleting key from database. [Jan 9 12:35:01] DEBUG[2778] app_macro.c: Executed application: DBDel [Jan 9 12:35:01] VERBOSE[2778] logger.c: -- Executing [s at macro-hangupcall:9] GotoIf("Zap/9-1", "1?theend") in new stack [Jan 9 12:35:01] VERBOSE[2778] logger.c: -- Goto (macro-hangupcall,s,11) [Jan 9 12:35:01] DEBUG[2778] app_macro.c: Executed application: GotoIf [Jan 9 12:35:01] VERBOSE[2778] logger.c: -- Executing [s at macro-hangupcall:11] Hangup("Zap/9-1", "") in new stack [Jan 9 12:35:01] VERBOSE[2778] logger.c: == Spawn extension (macro-hangupcall, s, 11) exited non-zero on 'Zap/9-1' in macro 'hangupcall' [Jan 9 12:35:01] VERBOSE[2778] logger.c: == Spawn extension (macro-hangupcall, s, 11) exited non-zero on 'Zap/9-1' [Jan 9 12:35:01] VERBOSE[2778] logger.c: -- Hungup 'Zap/9-1' Does this trace look normal? Several macros seem to be exiting with non-zero status, but that seems after the fact... the call had already been determined to be hungup. I'm kind of at my wits end with this problem. I don't know if I should blame the Sangoma card or the phone company (which is extremely hard to work with - this being the Virgin Islands!), and it is kind of expensive to go buy an alternate card just to test this. Any advice? Thanks! j
Steve Totaro
2009-Jan-09 21:57 UTC
[asterisk-users] Spurious hangups on Sangoma A102d, Trixbox 2.6.1
On Fri, Jan 9, 2009 at 4:33 PM, Jeff LaCoursiere <jeff at jeff.net> wrote:> > [also posted on Trixbox trunk forum] > > I am also working with Sangoma directly to debug this, but so far no real > luck. TrixBox 2.6.1, A102d card with V33 firmware (latest) and WANPIPE > 3.2.6 (3.2.7 is out, but nothing has changed that would affect this > problem). The system gets about 200 calls inbound on the trunk, which is > not very heavily used, and of those calls one or two a day is randomly > terminated in the middle of a call. Other than this problem everything is > working fine. All phones are Polycom IP501 with latest firmware as of a > year ago... > > There is only one ethernet switch (Linksys 100/1000 managed) between the > phones and the Trixbox, and the runs are less than 50 feet. Calls > extension to extension seem to have no issue at all. The network *is* > shared data/voice with no QOS and no virtual segments, but if the network > was the issue I would expect to see extension to extension calls report > this issue, which they have not. This is actually a hotel, and the data > portion of the traffic isn't heavily used either. They don't even have a > file server. > > I have the "full" logging enabled, and here is an excerpt of a call that > was terminated. You can see the conversation lasted about forty seconds > before it was hungup.<snipped>> > Does this trace look normal? Several macros seem to be exiting with > non-zero status, but that seems after the fact... the call had already > been determined to be hungup. I'm kind of at my wits end with this > problem. I don't know if I should blame the Sangoma card or the phone > company (which is extremely hard to work with - this being the Virgin > Islands!), and it is kind of expensive to go buy an alternate card just to > test this. > > Any advice? > > Thanks! > > jIt looks normal to me. I think two dropped calls a day is reasonable and I would start looking for commonalities. On a busy cell phone day, my Motorola RIZR drops more than two calls a day. Maybe that is the what is going on with your system. Other than that, I have fought with this same issue on a MUCH larger scale, and never found a solution, even looking at intense pri span debugs, having the telco "watch" the circuit, and plenty of SIP debugs and nothing out of the ordinary, just hang ups. Percentage wise, my issue was along the same lines as yours but we were taking over 15 thousand calls a day and agents on commission are very verbal about dropped calls. I did start recording and reviewing the complaints, and some were obviously just not interested and hung up, some were obviously cell phones, and some were truly calls dropped in mid word. I am afraid that FreePBX verbose is going to be no help at all. Try turning off verbose, turn on intense pri debugging and SIP debugging. Wireshark too. -- Thanks, Steve Totaro +18887771888 (Toll Free) +12409381212 (Cell) +12024369784 (Skype)
Andres
2009-Jan-09 22:19 UTC
[asterisk-users] Spurious hangups on Sangoma A102d, Trixbox 2.6.1
Jeff LaCoursiere wrote:>[also posted on Trixbox trunk forum] > >I am also working with Sangoma directly to debug this, but so far no real >luck. TrixBox 2.6.1, A102d card with V33 firmware (latest) and WANPIPE >3.2.6 (3.2.7 is out, but nothing has changed that would affect this >problem). The system gets about 200 calls inbound on the trunk, which is >not very heavily used, and of those calls one or two a day is randomly >terminated in the middle of a call. Other than this problem everything is >working fine. All phones are Polycom IP501 with latest firmware as of a >year ago... > >There is only one ethernet switch (Linksys 100/1000 managed) between the >phones and the Trixbox, and the runs are less than 50 feet. Calls >extension to extension seem to have no issue at all. The network *is* >shared data/voice with no QOS and no virtual segments, but if the network >was the issue I would expect to see extension to extension calls report >this issue, which they have not. This is actually a hotel, and the data >portion of the traffic isn't heavily used either. They don't even have a >file server. > >I have the "full" logging enabled, and here is an excerpt of a call that >was terminated. You can see the conversation lasted about forty seconds >before it was hungup. > >What you need to do is figure out who is ordering the call to be hangup. For that you should enable PRI debuging plus capture all SIP traffic. When a call drops, you should now be able to see if the remote end sent a DISCONNECT, your SIP phone sent a BYE, or your Asterisk randomily hangup the call. Otherwise you are just guessing. Andres http://www.telesip.net>[snipped the beginning of this process...] >[Jan 9 12:34:12] VERBOSE[2778] logger.c: -- Executing [s at macro-dial:7] >Dial("Zap/9-1", "SIP/2607&SIP/2605&SIP/2510|20|trM(auto-blkvm)") in new >stack >[Jan 9 12:34:12] VERBOSE[2778] logger.c: -- Called 2607 >[Jan 9 12:34:12] VERBOSE[2778] logger.c: -- Called 2605 >[Jan 9 12:34:12] VERBOSE[2778] logger.c: -- Called 2510 >[Jan 9 12:34:12] VERBOSE[2778] logger.c: -- SIP/2510-0a29a140 is ringing >[Jan 9 12:34:12] VERBOSE[2778] logger.c: -- SIP/2607-0a30c8d0 is ringing >[Jan 9 12:34:12] VERBOSE[2778] logger.c: -- SIP/2605-0a372cb0 is ringing >[Jan 9 12:34:21] VERBOSE[2778] logger.c: -- SIP/2605-0a372cb0 answered >Zap/9-1 >[Jan 9 12:34:21] VERBOSE[2778] logger.c: -- Executing >[s at macro-auto-blkvm:1] Set("SIP/2605-0a372cb0", "__MACRO_RESULT=") in new >stack >[Jan 9 12:34:21] DEBUG[2778] app_macro.c: Executed application: Set >[Jan 9 12:34:21] VERBOSE[2778] logger.c: -- Executing >[s at macro-auto-blkvm:2] Set("SIP/2605-0a372cb0", "__CWIGNORE=") in new >stack >[Jan 9 12:34:21] DEBUG[2778] app_macro.c: Executed application: Set >[Jan 9 12:34:21] VERBOSE[2778] logger.c: -- Executing >[s at macro-auto-blkvm:3] DBdel("SIP/2605-0a372cb0", "BLKVM/602/Zap/9-1") in >new stack >[Jan 9 12:34:21] VERBOSE[2778] logger.c: -- DBdel: family=BLKVM, >key=602/Zap/9-1 >[Jan 9 12:34:21] DEBUG[2778] app_macro.c: Executed application: DBDel >[Jan 9 12:34:21] DEBUG[2778] app_dial.c: Macro exited with status 0 >[Jan 9 12:34:21] DEBUG[2778] chan_zap.c: Took Zap/9-1 off hook >[Jan 9 12:35:01] VERBOSE[2778] logger.c: == Spawn extension (macro-dial, >s, 7) exited non-zero on 'Zap/9-1' in macro 'dial' >[Jan 9 12:35:01] VERBOSE[2778] logger.c: == Spawn extension (macro-dial, >s, 7) exited non-zero on 'Zap/9-1' >[Jan 9 12:35:01] VERBOSE[2778] logger.c: -- Executing [h at macro-dial:1] >Macro("Zap/9-1", "hangupcall") in new stack >[Jan 9 12:35:01] VERBOSE[2778] logger.c: -- Executing >[s at macro-hangupcall:1] ResetCDR("Zap/9-1", "w") in new stack >[Jan 9 12:35:01] DEBUG[2778] app_macro.c: Executed application: ResetCDR >[Jan 9 12:35:01] VERBOSE[2778] logger.c: -- Executing >[s at macro-hangupcall:2] NoCDR("Zap/9-1", "") in new stack >[Jan 9 12:35:01] DEBUG[2778] app_macro.c: Executed application: NoCDR >[Jan 9 12:35:01] VERBOSE[2778] logger.c: -- Executing >[s at macro-hangupcall:3] GotoIf("Zap/9-1", "1?skiprg") in new stack >[Jan 9 12:35:01] VERBOSE[2778] logger.c: -- Goto (macro-hangupcall,s,6) >[Jan 9 12:35:01] DEBUG[2778] app_macro.c: Executed application: GotoIf >[Jan 9 12:35:01] VERBOSE[2778] logger.c: -- Executing >[s at macro-hangupcall:6] GotoIf("Zap/9-1", "0?skipblkvm") in new stack >[Jan 9 12:35:01] DEBUG[2778] app_macro.c: Executed application: GotoIf >[Jan 9 12:35:01] VERBOSE[2778] logger.c: -- Executing >[s at macro-hangupcall:7] NoOp("Zap/9-1", "Cleaning Up Block VM Flag: >BLKVM/602/Zap/9-1") in new stack >[Jan 9 12:35:01] DEBUG[2778] app_macro.c: Executed application: Noop >[Jan 9 12:35:01] VERBOSE[2778] logger.c: -- Executing >[s at macro-hangupcall:8] DBdel("Zap/9-1", "BLKVM/602/Zap/9-1") in new stack >[Jan 9 12:35:01] VERBOSE[2778] logger.c: -- DBdel: family=BLKVM, >key=602/Zap/9-1 >[Jan 9 12:35:01] VERBOSE[2778] logger.c: -- DBdel: Error deleting key from >database. >[Jan 9 12:35:01] DEBUG[2778] app_macro.c: Executed application: DBDel >[Jan 9 12:35:01] VERBOSE[2778] logger.c: -- Executing >[s at macro-hangupcall:9] GotoIf("Zap/9-1", "1?theend") in new stack >[Jan 9 12:35:01] VERBOSE[2778] logger.c: -- Goto (macro-hangupcall,s,11) >[Jan 9 12:35:01] DEBUG[2778] app_macro.c: Executed application: GotoIf >[Jan 9 12:35:01] VERBOSE[2778] logger.c: -- Executing >[s at macro-hangupcall:11] Hangup("Zap/9-1", "") in new stack >[Jan 9 12:35:01] VERBOSE[2778] logger.c: == Spawn extension >(macro-hangupcall, s, 11) exited non-zero on 'Zap/9-1' in macro >'hangupcall' >[Jan 9 12:35:01] VERBOSE[2778] logger.c: == Spawn extension >(macro-hangupcall, s, 11) exited non-zero on 'Zap/9-1' >[Jan 9 12:35:01] VERBOSE[2778] logger.c: -- Hungup 'Zap/9-1' > >Does this trace look normal? Several macros seem to be exiting with >non-zero status, but that seems after the fact... the call had already >been determined to be hungup. I'm kind of at my wits end with this >problem. I don't know if I should blame the Sangoma card or the phone >company (which is extremely hard to work with - this being the Virgin >Islands!), and it is kind of expensive to go buy an alternate card just to >test this. > >Any advice? > >Thanks! > >j > >_______________________________________________ >-- 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 > > >
Jeff LaCoursiere
2009-Jan-09 22:33 UTC
[asterisk-users] Spurious hangups on Sangoma A102d, Trixbox 2.6.1
On Fri, 9 Jan 2009, Andres wrote: [snip]>> I have the "full" logging enabled, and here is an excerpt of a call that >> was terminated. You can see the conversation lasted about forty seconds >> before it was hungup. >> >> > What you need to do is figure out who is ordering the call to be > hangup. For that you should enable PRI debuging plus capture all SIP > traffic. When a call drops, you should now be able to see if the remote > end sent a DISCONNECT, your SIP phone sent a BYE, or your Asterisk > randomily hangup the call. Otherwise you are just guessing. >Its not a PRI. Its an RBS T1 with E&M Wink. I will try enabling the SIP debug, though, that is a good idea. Is there any kind of extra debugging for RBS T1? Cheers, j
James Noble
2009-Jan-09 23:40 UTC
[asterisk-users] Spurious hangups on Sangoma A102d, Trixbox 2.6.1
On Fri, Jan 9, 2009 at 2:33 PM, Jeff LaCoursiere <jeff at jeff.net> wrote:> > [also posted on Trixbox trunk forum] > > I am also working with Sangoma directly to debug this, but so far no real > luck. TrixBox 2.6.1, A102d card with V33 firmware (latest) and WANPIPE > 3.2.6 (3.2.7 is out, but nothing has changed that would affect this > problem). The system gets about 200 calls inbound on the trunk, which is > not very heavily used, and of those calls one or two a day is randomly > terminated in the middle of a call. Other than this problem everything is > working fine. All phones are Polycom IP501 with latest firmware as of a > year ago... > > There is only one ethernet switch (Linksys 100/1000 managed) between the > phones and the Trixbox, and the runs are less than 50 feet. Calls > extension to extension seem to have no issue at all. The network *is* > shared data/voice with no QOS and no virtual segments, but if the network > was the issue I would expect to see extension to extension calls report > this issue, which they have not. This is actually a hotel, and the data > portion of the traffic isn't heavily used either. They don't even have a > file server. > > I have the "full" logging enabled, and here is an excerpt of a call that > was terminated. You can see the conversation lasted about forty seconds > before it was hungup. > > [snipped the beginning of this process...] > [Jan 9 12:34:12] VERBOSE[2778] logger.c: -- Executing [s at macro-dial:7] > Dial("Zap/9-1", "SIP/2607&SIP/2605&SIP/2510|20|trM(auto-blkvm)") in new > stack > [Jan 9 12:34:12] VERBOSE[2778] logger.c: -- Called 2607 > [Jan 9 12:34:12] VERBOSE[2778] logger.c: -- Called 2605 > [Jan 9 12:34:12] VERBOSE[2778] logger.c: -- Called 2510 > [Jan 9 12:34:12] VERBOSE[2778] logger.c: -- SIP/2510-0a29a140 is ringing > [Jan 9 12:34:12] VERBOSE[2778] logger.c: -- SIP/2607-0a30c8d0 is ringing > [Jan 9 12:34:12] VERBOSE[2778] logger.c: -- SIP/2605-0a372cb0 is ringing > [Jan 9 12:34:21] VERBOSE[2778] logger.c: -- SIP/2605-0a372cb0 answered > Zap/9-1 > [Jan 9 12:34:21] VERBOSE[2778] logger.c: -- Executing > [s at macro-auto-blkvm:1] Set("SIP/2605-0a372cb0", "__MACRO_RESULT=") in new > stack > [Jan 9 12:34:21] DEBUG[2778] app_macro.c: Executed application: Set > [Jan 9 12:34:21] VERBOSE[2778] logger.c: -- Executing > [s at macro-auto-blkvm:2] Set("SIP/2605-0a372cb0", "__CWIGNORE=") in new > stack > [Jan 9 12:34:21] DEBUG[2778] app_macro.c: Executed application: Set > [Jan 9 12:34:21] VERBOSE[2778] logger.c: -- Executing > [s at macro-auto-blkvm:3] DBdel("SIP/2605-0a372cb0", "BLKVM/602/Zap/9-1") in > new stack > [Jan 9 12:34:21] VERBOSE[2778] logger.c: -- DBdel: family=BLKVM, > key=602/Zap/9-1 > [Jan 9 12:34:21] DEBUG[2778] app_macro.c: Executed application: DBDel > [Jan 9 12:34:21] DEBUG[2778] app_dial.c: Macro exited with status 0 > [Jan 9 12:34:21] DEBUG[2778] chan_zap.c: Took Zap/9-1 off hook > [Jan 9 12:35:01] VERBOSE[2778] logger.c: == Spawn extension (macro-dial, > s, 7) exited non-zero on 'Zap/9-1' in macro 'dial' > [Jan 9 12:35:01] VERBOSE[2778] logger.c: == Spawn extension (macro-dial, > s, 7) exited non-zero on 'Zap/9-1' > [Jan 9 12:35:01] VERBOSE[2778] logger.c: -- Executing [h at macro-dial:1] > Macro("Zap/9-1", "hangupcall") in new stack > [Jan 9 12:35:01] VERBOSE[2778] logger.c: -- Executing > [s at macro-hangupcall:1] ResetCDR("Zap/9-1", "w") in new stack > [Jan 9 12:35:01] DEBUG[2778] app_macro.c: Executed application: ResetCDR > [Jan 9 12:35:01] VERBOSE[2778] logger.c: -- Executing > [s at macro-hangupcall:2] NoCDR("Zap/9-1", "") in new stack > [Jan 9 12:35:01] DEBUG[2778] app_macro.c: Executed application: NoCDR > [Jan 9 12:35:01] VERBOSE[2778] logger.c: -- Executing > [s at macro-hangupcall:3] GotoIf("Zap/9-1", "1?skiprg") in new stack > [Jan 9 12:35:01] VERBOSE[2778] logger.c: -- Goto (macro-hangupcall,s,6) > [Jan 9 12:35:01] DEBUG[2778] app_macro.c: Executed application: GotoIf > [Jan 9 12:35:01] VERBOSE[2778] logger.c: -- Executing > [s at macro-hangupcall:6] GotoIf("Zap/9-1", "0?skipblkvm") in new stack > [Jan 9 12:35:01] DEBUG[2778] app_macro.c: Executed application: GotoIf > [Jan 9 12:35:01] VERBOSE[2778] logger.c: -- Executing > [s at macro-hangupcall:7] NoOp("Zap/9-1", "Cleaning Up Block VM Flag: > BLKVM/602/Zap/9-1") in new stack > [Jan 9 12:35:01] DEBUG[2778] app_macro.c: Executed application: Noop > [Jan 9 12:35:01] VERBOSE[2778] logger.c: -- Executing > [s at macro-hangupcall:8] DBdel("Zap/9-1", "BLKVM/602/Zap/9-1") in new stack > [Jan 9 12:35:01] VERBOSE[2778] logger.c: -- DBdel: family=BLKVM, > key=602/Zap/9-1 > [Jan 9 12:35:01] VERBOSE[2778] logger.c: -- DBdel: Error deleting key from > database. > [Jan 9 12:35:01] DEBUG[2778] app_macro.c: Executed application: DBDel > [Jan 9 12:35:01] VERBOSE[2778] logger.c: -- Executing > [s at macro-hangupcall:9] GotoIf("Zap/9-1", "1?theend") in new stack > [Jan 9 12:35:01] VERBOSE[2778] logger.c: -- Goto (macro-hangupcall,s,11) > [Jan 9 12:35:01] DEBUG[2778] app_macro.c: Executed application: GotoIf > [Jan 9 12:35:01] VERBOSE[2778] logger.c: -- Executing > [s at macro-hangupcall:11] Hangup("Zap/9-1", "") in new stack > [Jan 9 12:35:01] VERBOSE[2778] logger.c: == Spawn extension > (macro-hangupcall, s, 11) exited non-zero on 'Zap/9-1' in macro > 'hangupcall' > [Jan 9 12:35:01] VERBOSE[2778] logger.c: == Spawn extension > (macro-hangupcall, s, 11) exited non-zero on 'Zap/9-1' > [Jan 9 12:35:01] VERBOSE[2778] logger.c: -- Hungup 'Zap/9-1' > > Does this trace look normal? Several macros seem to be exiting with > non-zero status, but that seems after the fact... the call had already > been determined to be hungup. I'm kind of at my wits end with this > problem. I don't know if I should blame the Sangoma card or the phone > company (which is extremely hard to work with - this being the Virgin > Islands!), and it is kind of expensive to go buy an alternate card just to > test this. > > Any advice? > > Thanks! > > j > > _______________________________________________ > -- 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-usersI had the same problem with a sangoma card and a clean install of asterisk as well as a trixbox set up. I finally started using a vegastream to handle the T1 connections and was able to get rid of the problem. James -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20090109/52abe9a3/attachment.htm
Jeff LaCoursiere
2009-Jan-09 23:46 UTC
[asterisk-users] Spurious hangups on Sangoma A102d, Trixbox 2.6.1
On Fri, 9 Jan 2009, James Noble wrote:> > I had the same problem with a sangoma card and a clean install of asterisk > as well as a trixbox set up. I finally started using a vegastream to handle > the T1 connections and was able to get rid of the problem. > > James >$5K for a sinlge T1? Thats an expensive solution! PRI or RBS T1? Cheers, j
Steve Totaro
2009-Jan-10 00:15 UTC
[asterisk-users] Spurious hangups on Sangoma A102d, Trixbox 2.6.1
On Fri, Jan 9, 2009 at 6:46 PM, Jeff LaCoursiere <jeff at jeff.net> wrote:> > > On Fri, 9 Jan 2009, James Noble wrote: > >> >> I had the same problem with a sangoma card and a clean install of asterisk >> as well as a trixbox set up. I finally started using a vegastream to handle >> the T1 connections and was able to get rid of the problem. >> >> James >> > > $5K for a sinlge T1? Thats an expensive solution! PRI or RBS T1? > > Cheers, > > j >$5k for a single T1 is/was pretty much the norm. Go price non-used T1 cards for big proprietary phone systems. -- Thanks, Steve Totaro +18887771888 (Toll Free) +12409381212 (Cell) +12024369784 (Skype)
Jeff LaCoursiere
2009-Jan-10 00:34 UTC
[asterisk-users] Spurious hangups on Sangoma A102d, Trixbox 2.6.1
On Fri, 9 Jan 2009, Steve Totaro wrote:> > $5k for a single T1 is/was pretty much the norm. Go price non-used T1 > cards for big proprietary phone systems. >Thats a copout. Big proprietary phone systems are expensive by default - certainly not to be considered "the norm". I say it is an expensive solution to my problem when the dual T1 card I am using was $850 brand new, and a single T1 from Digium is more like $650, 1 port from Rhino is $450, etc. There seem to be lots of choices under $1K that should work as well as an external gateway for $5K. What extra features could possibly be worth so much? j
Steve Totaro
2009-Jan-10 00:40 UTC
[asterisk-users] Spurious hangups on Sangoma A102d, Trixbox 2.6.1
On Fri, Jan 9, 2009 at 7:34 PM, Jeff LaCoursiere <jeff at jeff.net> wrote:> > > On Fri, 9 Jan 2009, Steve Totaro wrote: > >> >> $5k for a single T1 is/was pretty much the norm. Go price non-used T1 >> cards for big proprietary phone systems. >> > > Thats a copout. Big proprietary phone systems are expensive by default - > certainly not to be considered "the norm". > > I say it is an expensive solution to my problem when the dual T1 card I am > using was $850 brand new, and a single T1 from Digium is more like $650, 1 > port from Rhino is $450, etc. There seem to be lots of choices under $1K > that should work as well as an external gateway for $5K. What extra > features could possibly be worth so much? > > j >I guess dropped calls and echo, onboard DSPs. One dropped call or crappy echo on a call could certainly cost you $5k depending what business you are in..... Not sure why you are so defensive, I just stated a fact. As much as you would like, they are still very much "The Norm", but that is changing...... -- Thanks, Steve Totaro +18887771888 (Toll Free) +12409381212 (Cell) +12024369784 (Skype)