<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">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. <div><br></div><div>I would be interested in the debut/logs if you have them.</div><div><br></div><div>I do have <span class="Apple-style-span" style="font-family: Verdana, Arial, Helvetica, sans-serif; font-size: 12px; ">Spawn extension...</span><span class="Apple-style-span" style="font-family: Verdana, Arial, Helvetica, sans-serif; font-size: 12px; ">exited non-zero on 'SIP/'</span></div><div><font class="Apple-style-span" face="Verdana, Arial, Helvetica, sans-serif"><br></font></div><div><font class="Apple-style-span" face="Verdana, Arial, Helvetica, sans-serif">Here is the specifics </font></div><div><font class="Apple-style-span" face="Verdana, Arial, Helvetica, sans-serif">VERBOSE[10928] pbx.c: == Spawn extension (from-sip, 1***, 1) exited non-zero on 'SIP/7XXX-000009d7'</font></div><div><font class="Apple-style-span" face="Verdana, Arial, Helvetica, sans-serif"><br></font></div><div><font class="Apple-style-span" face="Verdana, Arial, Helvetica, sans-serif">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. <br></font><div><div>On Jul 1, 2011, at 11:21 AM, Jonathan Thomas wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>The key item in my logs, which would preface the call dropping, was: <br>[2011-06-28 09:43:49] DEBUG[25563] chan_sip.c: ** SIP TIMER: Cancelling<br>retransmit of packet (reply received) Retransid #858<br><br>For instance - a call would be connected. SIP debug/core debug on. At the<br>14:30 mark I would begin tailing the full log. Once I saw the SIP TIMER<br>notice, it would be followed by a new INVITE (re-invite) SIP transmission<br>that would be sent to the phone currently on call. This re-invite was odd<br>in that it would be on a different port to the phone than was already<br>established (for example the NAT outgoing SIP OPTIONS would be sent to the<br>phone on port 27608 - and this re-invite might go out on port 35780). The<br>behavior following would be: Asterisk would hang up as though the parties<br>disconnected - however the phone would show the call was still going and<br>would continue sending SIP responses to asterisk indicating as such. When<br>the phone was manually hung up it would send a SIP BYE (as normal) to<br>asterisk - indicating it had no notice that Asterisk dropped the call.<br><br>Adding to sip.conf<br><span class="Apple-tab-span" style="white-space:pre"> </span>session-timers=refuse<br>Resolved the issue by stopping Asterisk from sending these re-invites during<br>a live call.<br><br>Hope that helps! I have more SIP debugs/logs if they're useful to ya.<br><br>JT<br><br><br>-----Original Message-----<br>From: Mark Rosedale [mailto:mrosedale@oreilly.com] <br>Sent: Friday, July 01, 2011 10:45 AM<br>To: <a href="mailto:jonathan.thomas@us.patersons.net">jonathan.thomas@us.patersons.net</a>; Asterisk Users Mailing List -<br>Non-Commercial Discussion<br>Subject: Re: [asterisk-users] Dropping Conference calls<br><br>What would I be looking for in the logs to indicate that time? <br><br>I'm looking into the sip session timers. I believe the issue lies there, but<br>haven't confirmed that just yet. <br>On Jul 1, 2011, at 10:31 AM, Jonathan Thomas wrote:<br><br><blockquote type="cite">900ms?<br></blockquote><br><br><br><br>Email has been scanned for viruses<br></div></blockquote></div><br></div></body></html>