CallDuration Adding up



We have a asterisk VOIP system. We are maintaing 4000minuits per day.

Some times we are facing an issue with Duration. I am usind Dial command to make an outgoing call.

If we tested one after the another all calls gets disconnected properly. When we hava Huge traffic sometimes the call may not hangup properly or asterisk not receving Hangup request or asterisk not disconnecting properly.

Because of this reason we are getting craze calldurations i mean ANSWEREDTIME.

Please suggest us where could be the problem.



Hung channels can be the result of any one of a number of contributing factors. My suggestion to you would be to try an Asterisk version change/upgrade as the simplest means to of addressing this issue. Without log samples and detailed information about the environment, this issue cannot be addressed otherwise.

Thank you.


We are using Asterisk version…

But it is happening not for all the calls only for some calls…

The asterisk log been deleted because of huge file content…

Asterisk disconnects unexpectedly sometimes…Because of that the request from agi to Webserver also stops…

What can we do to put those requests in to request queue…


4000 minutes a day is not huge, and the logs should be reasonnably sized…

look at the session timers, or if the media flows through you asterisk, try adding rtptimeout



4000 minuits is not huge i know…
But we will get lot of unwanted requests some times at that time asterisk behaves abnomally…

“if the media flows through you asterisk, try adding rtptimeout” need more details on it…

session timers means start time of the session or will be having cumilative timings…

Because of adding up of secoonds on Hung up channels effects billing issues…

Please help…



Can you clarify ? from known users ? what sort of requests ?

re rtptimeout, if you are not using canreinvite, and that indeed the media (sound) goes to your box, then rtptimeout should help you.

for this & session timers, check the sample config files or google. If issues, please revert.



We set canreinvite to “no” in our configiration…

if i use rtptimeout then will it terminate the channels or session if detects silence on the channel

We are usin our application for Making calls on credit basis.

we are facing an issue when the channel is not hung up or hung up channels are not detcted by asterisk then the call duration between A and B parties keep on adding. even they are not on call…


from sip.conf:

;rtptimeout=60 ; Terminate call if 60 seconds of no RTP or RTCP activity
; on the audio channel
; when we’re not on hold. This is to be able to hangup
; a call in the case of a phone disappearing from the net,
; like a powerloss or grandma tripping over a cable.


Thank you for the suggestion…

What is the Best configuration to avoid these type of issues…

what could be the reason for " The asteisk restarts unexpectedly…" If needed i can provide you the log of last asterisk restarted…We are facing the issues more when asterisk disconnect unexpectedly…



I didn’t notice any reference to “restarts unexpectedly” before, which is actually the important symptom.

Please google “asterisk wiki backtrace”.



What is the Best configuration to avoid these type of issues…

How can we block the unwanted incoming sip requests (SPAM)

What would you suggest using sip-session timers…



you seem to have two issues…
1/ your calls ending while you dont detect. Add rtptimeout and see if it improves…

2/ security… you’ve now anwsered my question:

[quote]But we will get lot of unwanted requests some times at that time asterisk behaves abnomally…

if it is spam / scanning requests (ie from ips that have nothing to do your box), then you need to secure your box, iptables + fail2ban is a good start.


allowguest should be no, unless you really need it.



We have asterisk running in the below mode

root 1717 0.0 0.0 4644 560 ? S Jul31 0:00 /bin/sh /usr/sbin/safe_asterisk
root 1728 0.0 1.2 220408 67076 ? Sl Jul31 0:45 /usr/sbin/asterisk -f -vvvg -c

How do we see the backtrace which file will contain core dump…




when i add this line in sip.conf

allowguest should be no, unless you really need it.

Only sip calls would be allowed not DID calls…

Please suggest…



DID calls (as generally understood by Asterisk SIP users**) are SIP calls; your last posting does not make sense.

allowguest controls the handling of calls for which there is no matching entry in sip.conf. The way that people normally use SIP means that there should be no such calls on a properly configured system.

(**In most cases, so called DID callers are only DID to the service provider, with only one number being passed to the PABX. Traditional DID is direct in dialling to the customer, with a range of numbers being routed to the same line, with routing digits to allow the PABX to distinguish between them.)



We have lots of DID’s which are called by users to provider, Provider inturn route to asterisk to reach our PBX system then IVR then they select contact from IVR. PBX will dial out to destination…

Here when i add allowguest =no in sip.conf file asterisk not allowing the DID calls routed from provider which is an incoming call to provider from customer…



Who pays for these calls? With allowguest, anyone can call in and make a call through your IVR.

allowguest = yes is only really suitable for use behind a firewall that completely blocks direct external access, or when the default context is totally secure and cannot incur any outgoing call costs. The latter case is only really applicable if you are operating in a full SIP peer to peer world, rather than one that uses PSTN numbers as the user part.


I suspect we are facing unwanted calls like SPAM/SCANNER becuase i have given allowguest=yes…

How to prevent these calls…



When we found asterisk disconnected unexpectedly…I did backtrace… I found below…
segmentation fault…

warning: .dynamic section for “/lib/i686/nosegneg/” is not at the expected address

warning: difference appears to be caused by prelink, adjusting expectations

Could you explain what should we do to avoid these unexpected disconnections…