[asterisk-users] Dropping Conference calls

Thu Jul 7 12:22:58 CDT 2011

Talk about getting lucky with a <snip>!   The first line you provided in
your log was enough to look-up related errors and find a similar one.
Although I have not encountered a Frame_Control(8), it's indicated as
'Congestion' by frame.h

                AST_CONTROL_CONGESTION = 8,     /*!< Congestion (circuits
busy) */

The one issue I found that appears similar (at least for the error/behavior)
was in relation to the admin's chan_dahdi.conf - the callprogress=yes option
to be specific.  Perhaps posting your chan_dahdi.conf would be helpful in at
least verifying your settings are correct.

JT

From: asterisk-users-bounces at lists.digium.com
[mailto:asterisk-users-bounces at lists.digium.com] On Behalf Of Mark Rosedale
Sent: Wednesday, July 06, 2011 5:37 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 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`,`lastdat
a`,`duration`,`billsec`,`disposition`,`amaflags`,`accountcode`,`uniqueid`)
VALUES ('2011-07-06
15:58:57','7531','8883203585','from-sip','SIP/7531-00000077','DAHDI/i1/18883
203585-7e','Dial','DAHDI/g1/18883203585','1240','1238','ANSWERED','3','\"Ada
m 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/20110707/dd688ea9/attachment.htm>