When I make call using softphone to a PSTN through asterisk, sometimes it happens that I hit on hangup from the softphone but call goes on hold and the call does not hangup. “sip show channels” shows call on hold same as if I intentionally put on hold.
So is there any setting to solve this problem or a way to checkout whether the call is really on hold or it is mistakenly went on hold?
My asterisk version is 10.0.1.
Problem is with the phone. On a SIP device, hangup and hold are very different operations.
I know that very well. But when my user calls through a softphone and the call goes on hold, We keep on deducting user’s balance. But if there is a case like above then user’s balance would be deducted however user had hangup from his side and the called party does not hangup. So is there any solution to check whether call is really on hold or Hungup?
One would need to know the deep cause of the bug in the phone before one could speculate on work rounds.
May be there is bug in the phone but even on disconnecting the internet connection from that softphone, call did not drop. why? Cause in general case call disconnects if the device is disconnected from internet.
Because you have neither qualify nor RTP timeouts enabled (I’m not sure that qualify works for established calls, so you would probably need to use an RTP timeout.
I have enabled rtptimeout and rtpholdtimeout. But the problem lies if a user put call on hold then it will too be hangedup.
Yet another sign that the softphone is broken. It should be sending RTCP even if it is on hold.
Generally softphones are not particularly suited to production use, and free ones even less so.
Thanks for the info. Should I consider then that there is no solution to check. I guess that asterisk 12 sends some critical packets and if it doesn’t get response it hangs up call. So will this feature be able to track whether actually call is on hold or not?
If the call is on hold, the phone should respond to all critical packets for that call, so there should be no critical packet errors.
Note that critical packets are only sent as part of specific operations. Unless you have session timers running, there will be none sent by Asterisk whilst the call is on hold. There isn’t a “critical packet”, but rather some requests and responses must produce a response for the call to safely continue. Also a phone that is that badly broken is likely to fail to respond to some critical packets when on a call.
Please fix the phone rather than working round its bugs.