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/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 >[...@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 >'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 > > > _______________________________________________ -- 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
