In any case I'm trying to figure out if maybe someone else has seen this problem. Or if they know what it might be.
On 12/28/05, C F <[EMAIL PROTECTED]> wrote: > For somereason I think it's the polycom, which means I need logging > for the Polycom and not the spa. > > On 12/28/05, Rich Adamson <[EMAIL PROTECTED]> wrote: > > > I have the follwoing setup: > > > Asterisk SVN-tag-1.2.1-r7367 > > > 6 Polycom 500 Sip version 1.5.x > > > 4 Sipura SPA3000 (not sure what build) (FXO port) > > > All on flat single network, no NAT, and no gateways to reach each other. > > > Sometimes (happens around 3 times a day, but sometimes far more > > > often), while on the phone to an outside caller (on the PSTN using the > > > FXO on the spa3k), the call dissconects from the polycom and goes thru > > > the incoming extension for the sipura. In other words, astrisk at > > > least as far as I can see from what gets executed in the DP (and maybe > > > spa3k) sees this as if the follwoing has happened: 1. The polycom user > > > hungup, 2. A new call came in on the spa3k. > > > The follwoing is part of the log that I think might help: > > > Dec 28 01:28:24 DEBUG[3368] channel.c: Didn't get a frame from > > > channel: SIP/201-8ba1 > > > Dec 28 01:28:24 DEBUG[3368] channel.c: Bridge stops bridging channels > > > SIP/201-8ba1 and SIP/804-fd83 > > > > > > SIP/201 is the Polycom, while SIP/804 is the spa3k. > > > > > > If I'm losing a frame, is there a way to configure asterisk not to > > > drop the channel? Or is this something the Polycom/Sipura are doing? > > > > > > FYI, asterisk is running on a VIA/MPIA platform. > > > > Pure guess is that something happened (unknown what) and the error messages > > posted above are the result of that, and not the root cause. Finding the > > root cause may require you to implement the "syslog server" and "debug > > server" options in the spa3k, and compare those log entries to what * > > records for log messages during a failure. > > > > Implementing the log functions on the spa3k "does" require a reboot. Their > > log messages are rather cryptic, but looking at keywords and timestamps > > might identify which box(es) are involved with the dropped calls. > > > > > > _______________________________________________ > > --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 > > > _______________________________________________ --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
