So I made the change you suggested. That still hasn't worked, but I did manage to grab some logging from a dropped call.
[Jul 6 16:19:37] DEBUG[25950] channel.c: Got a FRAME_CONTROL (8) frame on channel DAHDI/i1/18883203585-7e [Jul 6 16:19:37] DEBUG[25950] res_rtp_asterisk.c: Setting the marker bit due to a source update [Jul 6 16:19:37] DEBUG[25950] chan_dahdi.c: Requested indication 20 on channel DAHDI/i1/18883203585-7e [Jul 6 16:19:37] DEBUG[25950] channel.c: Bridge stops bridging channels SIP/7531-00000077 and DAHDI/i1/18883203585-7e [Jul 6 16:19:37] DEBUG[25950] cdr_mysql.c: Inserting a CDR record. [Jul 6 16:19:37] DEBUG[25950] cdr_mysql.c: SQL command as follows: INSERT INTO cdr (`calldate`,`src`,`dst`,`dcontext`,`channel`,`dstchannel`,`lastapp`,`lastdata`,`duration`,`billsec`,`disposition`,`amaflags`,`accountcode`,`uniqueid`) VALUES ('2011-07-06 15:58:57','7531','8883203585','from-sip','SIP/7531-00000077','DAHDI/i1/18883203585-7e','Dial','DAHDI/g1/18883203585','1240','1238','ANSWERED','3','\"Adam Witwer\"','1309982337.338') [Jul 6 16:19:37] DEBUG[25950] channel.c: Hanging up channel 'DAHDI/i1/18883203585-7e' [Jul 6 16:19:37] DEBUG[25950] chan_dahdi.c: dahdi_hangup(DAHDI/i1/18883203585-7e) [Jul 6 16:19:37] DEBUG[25950] chan_dahdi.c: Set option AUDIO MODE, value: ON(1) on DAHDI/i1/18883203585-7e [Jul 6 16:19:37] DEBUG[25950] sig_pri.c: sig_pri_hangup 1 [Jul 6 16:19:37] DEBUG[25950] sig_pri.c: Not yet hungup... Calling hangup once with icause, and clearing call [Jul 6 16:19:37] DEBUG[25950] chan_dahdi.c: Disabled echo cancellation on channel 1 [Jul 6 16:19:37] DEBUG[25950] chan_dahdi.c: Set option TDD MODE, value: OFF(0) on DAHDI/i1/18883203585-7e [Jul 6 16:19:37] DEBUG[25950] chan_dahdi.c: Updated conferencing on 1, with 0 conference users [Jul 6 16:19:37] DEBUG[25950] chan_dahdi.c: Set option AUDIO MODE, value: OFF(0) on DAHDI/i1/18883203585-7e [Jul 6 16:19:37] VERBOSE[25950] chan_dahdi.c: -- Hungup 'DAHDI/i1/18883203585-7e' On Jul 1, 2011, at 2:38 PM, Jonathan Thomas wrote: > The exited non-zero is typical when a call has ended. What I would recommend > (easiest method) is for you to enter the CLI using: asterisk > –rvvvvvvvvvvvvvvvvvvvdddd > The v’s will provide more verbose logging, the 4 d’s will place the core in > debug mode(4). Once in the CLI, pick a phone you will use as a test unit and > issue a > > sip set debug peer XXXXXX (X=peer device id, such as 10001) > > This will seriously increase the size of your logging – but should provide > you with a very thorough trace of the call as its in flight, including the > SIP dialog between the phone/server. > Perhaps you can enable the above, place a call that drops, then snip that > section of the full log and send it to the list for parsing. It’s the best > way to nail down an issue like this. > > > JT > > > From: Mark Rosedale [mailto:mrosed...@oreilly.com] > Sent: Friday, July 01, 2011 2:17 PM > To: jonathan.tho...@us.patersons.net > Cc: 'Asterisk Users Mailing List - Non-Commercial Discussion' > Subject: Re: [asterisk-users] Dropping Conference calls > > So I didn't have sip debug set. So I don't have any SIP TIMER's in my log. I > have that set now. > > I would be interested in the debut/logs if you have them. > > I do have Spawn extension...exited non-zero on 'SIP/' > > Here is the specifics > VERBOSE[10928] pbx.c: == Spawn extension (from-sip, 1***, 1) exited > non-zero on 'SIP/7XXX-000009d7' > > Not sure if that relates or not, but it is the only hit for the connection > between my sip client and the PRI going outbound right before the hangup. > On Jul 1, 2011, at 11:21 AM, Jonathan Thomas wrote: > > > The key item in my logs, which would preface the call dropping, was: > [2011-06-28 09:43:49] DEBUG[25563] chan_sip.c: ** SIP TIMER: Cancelling > retransmit of packet (reply received) Retransid #858 > > For instance - a call would be connected. SIP debug/core debug on. At the > 14:30 mark I would begin tailing the full log. Once I saw the SIP TIMER > notice, it would be followed by a new INVITE (re-invite) SIP transmission > that would be sent to the phone currently on call. This re-invite was odd > in that it would be on a different port to the phone than was already > established (for example the NAT outgoing SIP OPTIONS would be sent to the > phone on port 27608 - and this re-invite might go out on port 35780). The > behavior following would be: Asterisk would hang up as though the parties > disconnected - however the phone would show the call was still going and > would continue sending SIP responses to asterisk indicating as such. When > the phone was manually hung up it would send a SIP BYE (as normal) to > asterisk - indicating it had no notice that Asterisk dropped the call. > > Adding to sip.conf > session-timers=refuse > Resolved the issue by stopping Asterisk from sending these re-invites during > a live call. > > Hope that helps! I have more SIP debugs/logs if they're useful to ya. > > JT > > > -----Original Message----- > From: Mark Rosedale [mailto:mrosed...@oreilly.com] > Sent: Friday, July 01, 2011 10:45 AM > To: jonathan.tho...@us.patersons.net; Asterisk Users Mailing List - > Non-Commercial Discussion > Subject: Re: [asterisk-users] Dropping Conference calls > > What would I be looking for in the logs to indicate that time? > > I'm looking into the sip session timers. I believe the issue lies there, but > haven't confirmed that just yet. > On Jul 1, 2011, at 10:31 AM, Jonathan Thomas wrote: > > > 900ms? > > > > > Email has been scanned for viruses > > > Email has been scanned for viruses > > Email has been scanned for viruses
-- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users