[asterisk-users] Dropping Conference calls

[Jonathan Thomas]

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/20110701/91f41a62/attachment.htm>