On Fri, Jan 9, 2009 at 2:33 PM, Jeff LaCoursiere <span dir="ltr"><<a href="mailto:jeff@jeff.net">jeff@jeff.net</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
[also posted on Trixbox trunk forum]<br>
<br>
I am also working with Sangoma directly to debug this, but so far no real<br>
luck. TrixBox 2.6.1, A102d card with V33 firmware (latest) and WANPIPE<br>
3.2.6 (3.2.7 is out, but nothing has changed that would affect this<br>
problem). The system gets about 200 calls inbound on the trunk, which is<br>
not very heavily used, and of those calls one or two a day is randomly<br>
terminated in the middle of a call. Other than this problem everything is<br>
working fine. All phones are Polycom IP501 with latest firmware as of a<br>
year ago...<br>
<br>
There is only one ethernet switch (Linksys 100/1000 managed) between the<br>
phones and the Trixbox, and the runs are less than 50 feet. Calls<br>
extension to extension seem to have no issue at all. The network *is*<br>
shared data/voice with no QOS and no virtual segments, but if the network<br>
was the issue I would expect to see extension to extension calls report<br>
this issue, which they have not. This is actually a hotel, and the data<br>
portion of the traffic isn't heavily used either. They don't even have a<br>
file server.<br>
<br>
I have the "full" logging enabled, and here is an excerpt of a call that<br>
was terminated. You can see the conversation lasted about forty seconds<br>
before it was hungup.<br>
<br>
[snipped the beginning of this process...]<br>
[Jan 9 12:34:12] VERBOSE[2778] logger.c: -- Executing [s@macro-dial:7]<br>
Dial("Zap/9-1", "SIP/2607&SIP/2605&SIP/2510|20|trM(auto-blkvm)") in new<br>
stack<br>
[Jan 9 12:34:12] VERBOSE[2778] logger.c: -- Called 2607<br>
[Jan 9 12:34:12] VERBOSE[2778] logger.c: -- Called 2605<br>
[Jan 9 12:34:12] VERBOSE[2778] logger.c: -- Called 2510<br>
[Jan 9 12:34:12] VERBOSE[2778] logger.c: -- SIP/2510-0a29a140 is ringing<br>
[Jan 9 12:34:12] VERBOSE[2778] logger.c: -- SIP/2607-0a30c8d0 is ringing<br>
[Jan 9 12:34:12] VERBOSE[2778] logger.c: -- SIP/2605-0a372cb0 is ringing<br>
[Jan 9 12:34:21] VERBOSE[2778] logger.c: -- SIP/2605-0a372cb0 answered<br>
Zap/9-1<br>
[Jan 9 12:34:21] VERBOSE[2778] logger.c: -- Executing<br>
[s@macro-auto-blkvm:1] Set("SIP/2605-0a372cb0", "__MACRO_RESULT=") in new<br>
stack<br>
[Jan 9 12:34:21] DEBUG[2778] app_macro.c: Executed application: Set<br>
[Jan 9 12:34:21] VERBOSE[2778] logger.c: -- Executing<br>
[s@macro-auto-blkvm:2] Set("SIP/2605-0a372cb0", "__CWIGNORE=") in new<br>
stack<br>
[Jan 9 12:34:21] DEBUG[2778] app_macro.c: Executed application: Set<br>
[Jan 9 12:34:21] VERBOSE[2778] logger.c: -- Executing<br>
[s@macro-auto-blkvm:3] DBdel("SIP/2605-0a372cb0", "BLKVM/602/Zap/9-1") in<br>
new stack<br>
[Jan 9 12:34:21] VERBOSE[2778] logger.c: -- DBdel: family=BLKVM,<br>
key=602/Zap/9-1<br>
[Jan 9 12:34:21] DEBUG[2778] app_macro.c: Executed application: DBDel<br>
[Jan 9 12:34:21] DEBUG[2778] app_dial.c: Macro exited with status 0<br>
[Jan 9 12:34:21] DEBUG[2778] chan_zap.c: Took Zap/9-1 off hook<br>
[Jan 9 12:35:01] VERBOSE[2778] logger.c: == Spawn extension (macro-dial,<br>
s, 7) exited non-zero on 'Zap/9-1' in macro 'dial'<br>
[Jan 9 12:35:01] VERBOSE[2778] logger.c: == Spawn extension (macro-dial,<br>
s, 7) exited non-zero on 'Zap/9-1'<br>
[Jan 9 12:35:01] VERBOSE[2778] logger.c: -- Executing [h@macro-dial:1]<br>
Macro("Zap/9-1", "hangupcall") in new stack<br>
[Jan 9 12:35:01] VERBOSE[2778] logger.c: -- Executing<br>
[s@macro-hangupcall:1] ResetCDR("Zap/9-1", "w") in new stack<br>
[Jan 9 12:35:01] DEBUG[2778] app_macro.c: Executed application: ResetCDR<br>
[Jan 9 12:35:01] VERBOSE[2778] logger.c: -- Executing<br>
[s@macro-hangupcall:2] NoCDR("Zap/9-1", "") in new stack<br>
[Jan 9 12:35:01] DEBUG[2778] app_macro.c: Executed application: NoCDR<br>
[Jan 9 12:35:01] VERBOSE[2778] logger.c: -- Executing<br>
[s@macro-hangupcall:3] GotoIf("Zap/9-1", "1?skiprg") in new stack<br>
[Jan 9 12:35:01] VERBOSE[2778] logger.c: -- Goto (macro-hangupcall,s,6)<br>
[Jan 9 12:35:01] DEBUG[2778] app_macro.c: Executed application: GotoIf<br>
[Jan 9 12:35:01] VERBOSE[2778] logger.c: -- Executing<br>
[s@macro-hangupcall:6] GotoIf("Zap/9-1", "0?skipblkvm") in new stack<br>
[Jan 9 12:35:01] DEBUG[2778] app_macro.c: Executed application: GotoIf<br>
[Jan 9 12:35:01] VERBOSE[2778] logger.c: -- Executing<br>
[s@macro-hangupcall:7] NoOp("Zap/9-1", "Cleaning Up Block VM Flag:<br>
BLKVM/602/Zap/9-1") in new stack<br>
[Jan 9 12:35:01] DEBUG[2778] app_macro.c: Executed application: Noop<br>
[Jan 9 12:35:01] VERBOSE[2778] logger.c: -- Executing<br>
[s@macro-hangupcall:8] DBdel("Zap/9-1", "BLKVM/602/Zap/9-1") in new stack<br>
[Jan 9 12:35:01] VERBOSE[2778] logger.c: -- DBdel: family=BLKVM,<br>
key=602/Zap/9-1<br>
[Jan 9 12:35:01] VERBOSE[2778] logger.c: -- DBdel: Error deleting key from<br>
database.<br>
[Jan 9 12:35:01] DEBUG[2778] app_macro.c: Executed application: DBDel<br>
[Jan 9 12:35:01] VERBOSE[2778] logger.c: -- Executing<br>
[s@macro-hangupcall:9] GotoIf("Zap/9-1", "1?theend") in new stack<br>
[Jan 9 12:35:01] VERBOSE[2778] logger.c: -- Goto (macro-hangupcall,s,11)<br>
[Jan 9 12:35:01] DEBUG[2778] app_macro.c: Executed application: GotoIf<br>
[Jan 9 12:35:01] VERBOSE[2778] logger.c: -- Executing<br>
[s@macro-hangupcall:11] Hangup("Zap/9-1", "") in new stack<br>
[Jan 9 12:35:01] VERBOSE[2778] logger.c: == Spawn extension<br>
(macro-hangupcall, s, 11) exited non-zero on 'Zap/9-1' in macro<br>
'hangupcall'<br>
[Jan 9 12:35:01] VERBOSE[2778] logger.c: == Spawn extension<br>
(macro-hangupcall, s, 11) exited non-zero on 'Zap/9-1'<br>
[Jan 9 12:35:01] VERBOSE[2778] logger.c: -- Hungup 'Zap/9-1'<br>
<br>
Does this trace look normal? Several macros seem to be exiting with<br>
non-zero status, but that seems after the fact... the call had already<br>
been determined to be hungup. I'm kind of at my wits end with this<br>
problem. I don't know if I should blame the Sangoma card or the phone<br>
company (which is extremely hard to work with - this being the Virgin<br>
Islands!), and it is kind of expensive to go buy an alternate card just to<br>
test this.<br>
<br>
Any advice?<br>
<br>
Thanks!<br>
<br>
j<br>
<br>
_______________________________________________<br>
-- Bandwidth and Colocation Provided by <a href="http://www.api-digital.com" target="_blank">http://www.api-digital.com</a> --<br>
<br>
asterisk-users mailing list<br>
To UNSUBSCRIBE or update options visit:<br>
<a href="http://lists.digium.com/mailman/listinfo/asterisk-users" target="_blank">http://lists.digium.com/mailman/listinfo/asterisk-users</a></blockquote><div><br><br><br>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.<br>
<br>James<br></div></div><br>