Hangup detection problem on Asterisk

I talked about hanguponpolarityswitch parameter only because I’m looking for everything which can help me resolve my problem. My chan_dadhi.conf file have never been modified …

What AGI script should exit and hang up ? There is no script which are not terminating. The exemple I show you with my h exten is what should happen when a user hang up, and this is not launched until 14400 seconds, and when it is launched it works fine.

And my callers did hang up but sometimes it is not detected by asterisk.

I think you don’t get well what my problem is …

Let say you call my trunk with your cellphone, sometimes when you hang up, Asterisk will not detect that you have hung up your phone and it results on a chanel which is still open until 14400 seconds (which is my trunk limit for every calls). At that time, the BYE is sent as I mention in the 9th message of this conversation.

So yes my ITSP must be at fault, but why ? And why is it doing that randomly ?

You’re are assuming well, these are real incoming calls, as I explain : [quote=“guiguizmo, post:19, topic:67943”]
There is no AGI script that makes a call since this is only physical persons like you and me who make calls
[/quote] And here is a the real Call ID : 2df6-478-822016722-fsc2.gwin

If the AGI script is terminating, one of the events that you should be providing evidence for is that that is what is happening. Although it does look like a fault upstream of you, the fact that you are not hanging up when you would be expected to so so is giving the ITSP a hook onto which to try and turn the problem round and blame it on you.

In fact, if you did hangup, it would b irrelevant as to whether or not they propagated the hangup on the incoming side, as they are presumably not connected over analogue lines and can treat BYE as a full RELEASE of the call. As such, it is arguably not worth pursuing the issue with the ITSP in this case.

Although such things tend not to get enforced these days, there may well be a condition of service that IVRs should not leave lines open.

If you do want to pursue it, you need to prove that the caller really is hanging up, which probably means reproducing it when you are making a call. It may well be that the caller just isn’t hanging up properly.

To add information, and convice you that the caller is really hanging up, I should tell you that :

Let say A is a user.

A calls a toll number (this toll number is connected to a number of my trunk, and have a dialplan)
The channel is created
A navigates into the IVR
A hangs up
The channel is still opened and close itself at 14400 seconds

So I have a call which is marked as if it had last 14400 seconds.

Then I can access statistics of the toll number, and I can see (and so prove) that the call did not last 14400 seconds but 120 seconds for exemple.

And again, my IVR isn’t programmed to hang up, the user who is calling have to hang up when he has fnished his navigation into the IVR. And when he hangs up, I have a h exten which saves data to a database (and this script works well).

I would say both you and the ITSP are wrong. The ITSP should be forwarding the release from your phone, but also your IVR should not be leaving the call open indefinitely. People can fail to hang up properly and run up large bills if the IVR does not release the call.

Ask your provider why they are not forwarding BYE to you. Do some live call testing with them and ask them to send you SIP trace for such call.

Satish: I think the problem is that the provider is in denial and using the fact that there is no backwards clear to avoid investigating properly.

@david551 you think I should put a timeout on my IVR so the call will automaticaly hang up after X seconds ? This is not the way I think I should solve this issue …

Is there a way to detect that there is silence from the caller, so I could cut the channel at this moment ?

@satish4asterisk I have asked my provider why they are not forwarding BYE to me, I’m waiting for their answer. It will be difficult to do live call testing with them because the problem is random.

Try and see using rtptimeout and rtpholdtimeout in sip.conf

I already have a rtptimeout=60 in my sip.conf
I havn’t rtpholdtimeout, you think it could change something to add it ?

I have seen this happen with some telcos. Not SIP trunk providers but actual CLEC telcos. So the person on the CLEC telco end hangs up but the Asterisk extension stays connected because it is not receiving the hangup signal from the telco which would then be passed to you by the SIP trunk provider. I was able to determine this by calling my cell phone which did not exhibit this problem even though the SIP extension, trunk configuration, and SIP trunk provider did not change.

So I would eliminate this possiblility by seeing if you can consistently reproduce this by calling certain numbers but not when you call other numbers such as cell phones or visa versa. If it is the telco then there is nothing you can do about it because it originates with the telco. That is just the way it is. Yes, even if it does not happen if you call other telcos such as a cell phone.

The other possibility is your SIP trunk configuration although it sounds like you have looked into that already.

The trunk never call. It is always users who call the trunk. And they call from mobile line or non-mobile line.

It could be my trunk configuration, but how can it be so random, and what should I change in the configuration to avoid this problem …

We are facing the same problem if you have solved it than can you please help us solve this issue

When people say it is the same problem on an old thread, it rarely is. However, if it is:

  • the answer will already be there on the thread;
  • a question will not have answered that may be critical to the answer; or
  • nobody can answer.

Generally hangup detection problems occur at the boundary of the PSTN, and in particular, where that boundary is analogue. If you are using VoIP, as was the person with the original thread, that boundary is in the ITSP, not in your Asterisk.