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:[email protected]]
> Sent: Friday, July 01, 2011 2:17 PM
> To: [email protected]
> 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:[email protected]]
> Sent: Friday, July 01, 2011 10:45 AM
> To: [email protected]; 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
