[asterisk-users] Dropping Conference calls

Wed Jul 6 16:37:00 CDT 2011

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:mrosedale at oreilly.com] 
> Sent: Friday, July 01, 2011 2:17 PM
> To: jonathan.thomas at 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:mrosedale at oreilly.com] 
> Sent: Friday, July 01, 2011 10:45 AM
> To: jonathan.thomas at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20110706/ffdc1f8d/attachment.htm>