Re: [asterisk-users] Spurious hangups on Sangoma A102d, Trixbox 2.6.1
On Sat, 10 Jan 2009, Tzafrir Cohen wrote: No idea, but the driver is much more aware of the specifics. So maybe their driver has extra debugging information for that case. For starters, have you enabled full debugging in Asterisk? Make sure you log 'debug' and set debug to at least 5 . chan_zap / chan_dahdi will at least tell you what was the immediate case for the hangup: * signal from Zaptel (kernel) * Some sort of decision of chan_zap * Something from the SIP channel * Something completely different I turned debugging on to level 10 and have been accumulating logs at the speed of light all morning ;) I haven't trapped the dropped call yet, but I have been peaking at individual calls to see what extra information is available. For example an outbound call from a SIP extension to a long distance number ended like this: [Jan 12 10:26:22] DEBUG[18302] chan_zap.c: Exception on 9, channel 1 [Jan 12 10:26:22] DEBUG[18302] chan_zap.c: Got event On hook(1) on channel 1 (index 0) [Jan 12 10:26:22] VERBOSE[18302] logger.c: -- Stopped music on hold on Zap/1-1 [Jan 12 10:26:22] DEBUG[18302] channel.c: Set channel Zap/1-1 to write format ulaw [Jan 12 10:26:22] DEBUG[18302] channel.c: Scheduling timer at 0 sample intervals [Jan 12 10:26:22] DEBUG[18302] channel.c: Didn't get a frame from channel: Zap/1-1 [Jan 12 10:26:22] DEBUG[18302] channel.c: Bridge stops bridging channels SIP/2530-b71f9bc8 and Zap/1-1 [Jan 12 10:26:22] DEBUG[18302] channel.c: Hanging up channel 'Zap/1-1' Would you interpret this as the remote end hanging up first, and the Sangoma card detecting the hangup and destroying the bridge? (looks like someone left this poor guy on hold for six minutes, actually, and he finally gave up!) 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
[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 [...@macro-dial:7] Dial(Zap/9-1, SIP/2607SIP/2605SIP/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 [...@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 [...@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 [...@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 [...@macro-dial:1] Macro(Zap/9-1, hangupcall) in new stack [Jan 9 12:35:01] VERBOSE[2778] logger.c: -- Executing [...@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 [...@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 [...@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 [...@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 [...@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 [...@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 [...@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 [...@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
Re: [asterisk-users] Spurious hangups on Sangoma A102d, Trixbox 2.6.1
On Fri, Jan 9, 2009 at 4:33 PM, Jeff LaCoursiere j...@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! j It 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) ___ -- 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
Re: [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 [...@macro-dial:7] Dial(Zap/9-1, SIP/2607SIP/2605SIP/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 [...@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 [...@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 [...@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 [...@macro-dial:1] Macro(Zap/9-1, hangupcall) in new stack [Jan 9 12:35:01] VERBOSE[2778] logger.c: -- Executing [...@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 [...@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 [...@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 [...@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 [...@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 [...@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 [...@macro-hangupcall:9] GotoIf(Zap/9-1, 1?theend) in
Re: [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 EM 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 ___ -- 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
Re: [asterisk-users] Spurious hangups on Sangoma A102d, Trixbox 2.6.1
On Fri, 9 Jan 2009, Steve Totaro wrote: It looks normal to me. I think two dropped calls a day is reasonable and I would start looking for commonalities. I tried that logic - they don't buy it :) The sad part is I replace a Nortel system that did NOT have the issue (according to their reservation folks anyway). [snip] 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. Hmm, good idea with wireshark. Since it happens at least once a day I should have some data to occupy me soon. Do you know if there is a similar intense debug for RBS T1 (since it is not a PRI)? Cheers, 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
Re: [asterisk-users] Spurious hangups on Sangoma A102d, Trixbox 2.6.1
On Fri, Jan 9, 2009 at 2:33 PM, Jeff LaCoursiere j...@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 [...@macro-dial:7] Dial(Zap/9-1, SIP/2607SIP/2605SIP/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 [...@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 [...@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 [...@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 [...@macro-dial:1] Macro(Zap/9-1, hangupcall) in new stack [Jan 9 12:35:01] VERBOSE[2778] logger.c: -- Executing [...@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 [...@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 [...@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 [...@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 [...@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 [...@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 [...@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 [...@macro-hangupcall:11] Hangup(Zap/9-1, ) in new stack [Jan 9 12:35:01]
Re: [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 ___ -- 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
Re: [asterisk-users] Spurious hangups on Sangoma A102d, Trixbox 2.6.1
On Fri, Jan 09, 2009 at 10:33:44PM +, Jeff LaCoursiere wrote: 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 EM Wink. I will try enabling the SIP debug, though, that is a good idea. Is there any kind of extra debugging for RBS T1? No idea, but the driver is much more aware of the specifics. So maybe their driver has extra debugging information for that case. For starters, have you enabled full debugging in Asterisk? Make sure you log 'debug' and set debug to at least 5 . chan_zap / chan_dahdi will at least tell you what was the immediate case for the hangup: * signal from Zaptel (kernel) * Some sort of decision of chan_zap * Something from the SIP channel * Something completely different -- Tzafrir Cohen icq#16849755 jabber:tzafrir.co...@xorcom.com +972-50-7952406 mailto:tzafrir.co...@xorcom.com http://www.xorcom.com iax:gu...@local.xorcom.com/tzafrir ___ -- 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
Re: [asterisk-users] Spurious hangups on Sangoma A102d, Trixbox 2.6.1
On Fri, Jan 9, 2009 at 6:46 PM, Jeff LaCoursiere j...@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) ___ -- 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
Re: [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 ___ -- 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
Re: [asterisk-users] Spurious hangups on Sangoma A102d, Trixbox 2.6.1
On Sat, 10 Jan 2009, Tzafrir Cohen wrote: Its not a PRI. Its an RBS T1 with EM Wink. I will try enabling the SIP debug, though, that is a good idea. Is there any kind of extra debugging for RBS T1? No idea, but the driver is much more aware of the specifics. So maybe their driver has extra debugging information for that case. I was hoping so, and I am working with Sangoma also, but the back and forth seems to span several days. List is more responsive ;) For starters, have you enabled full debugging in Asterisk? Make sure you log 'debug' and set debug to at least 5 . chan_zap / chan_dahdi will at least tell you what was the immediate case for the hangup: * signal from Zaptel (kernel) * Some sort of decision of chan_zap * Something from the SIP channel * Something completely different An excellent plan. I am logging debug, but I think I only set verbose. Thanks for the advice! 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
Re: [asterisk-users] Spurious hangups on Sangoma A102d, Trixbox 2.6.1
On Fri, Jan 9, 2009 at 7:34 PM, Jeff LaCoursiere j...@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) ___ -- 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
Re: [asterisk-users] Spurious hangups on Sangoma A102d, Trixbox 2.6.1
On Fri, Jan 9, 2009 at 4:46 PM, Jeff LaCoursiere j...@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 ___ -- 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 Yeah it wasn't cheap but we dropped enough calls that it was worth it. We had both PRI and RBS. I am not sure if the problem presented itself on the PRI but it definitely was a problem on the RBS T1 James ___ -- 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
