SIP and hangup problems with POTS phones

Hi,

I have now asterisk 1.6 (some problem with 1.4) and i’m using AGI scripts to implement a more sofisticated callback system.

This system only use SIP, to make and receive the calls

And the problem is:

If I receive a call from asterisk in a POTS phone, and answer it, I can hear the welcome message, and the other messages saying that the system will connect to the other party, costs, etc.
if during this time, I hangup the POTS phone, the agi script continues till the end, and try to establish the connection to the other partie !!!

If I receive the call im a mobile phone, and press the hangup key, the agi script ends right away!

So my question is, what is wrong, for the hook button in the POTS phone, to not hangup the call

Thks

PS: I have no dadhi (zaptel) configuration, because I believe, using only SIP, to receive and make calls from and to the outside, it is no necessary

Seems to me that the pstn-sip gateway which sends you the call isn’t understanding the disconnection signalling (tones) sended by the telco when the far end hangs up, try talk with your sip service provider about.

Cheers.

Marco Bruni

The UK PSTN, and probably most others, only implements calling party clearing for normal calls. One of the reasons behind this is supposedly so that the called party can hangup on the original phone and pick up on a more suitable extension.

Mobile networks generally implement an either party clearing policy.

The UK SS7 network did actually signal called party hangup and re-answer events, but these won’t be provided to an analogue line caller and I don’t know if they are presented over subscriber level common channel signalling.

[quote=“david55”]The UK PSTN, and probably most others, only implements calling party clearing for normal calls. One of the reasons behind this is supposedly so that the called party can hangup on the original phone and pick up on a more suitable extension.

Mobile networks generally implement an either party clearing policy.

The UK SS7 network did actually signal called party hangup and re-answer events, but these won’t be provided to an analogue line caller and I don’t know if they are presented over subscriber level common channel signalling.[/quote]

I think, the same applies here in Portugal, and the reason you wrote make sense, because I remember it happened to me, a long time ago, when POTS were the most common telephones, and during a conversation, i could hangup one phone and answer it in another phone in my place.

But my problem continues, how can I stop the agi script from running? as Marco Bruni wrote, how can I detect that signal in asterisk and in the presence of that, end the agi script?

I guess if this POTS behaviour applies in many countries, someone should already implemented a way to fix this issue, :confused:

Thks for your help, and for any workaround or solution that could fix “my” problem

Cheers

You haven’t said the nature of your POTS interface, but the first thing you need to do is to determine whether the supervision signals are even being supplied to you, which probably means enabling low level debugging, possibly at the kernel driver level.

Trying to remember back a couple of decades, I think that SS7 has CLEAR and ANSWER for the on hook and off hook events, and RELEASE for when the network finally drops the call. If you have an analogue line, and line reversal on clearing, you may find that it responds to RELEASE, rather than CLEAR.

If you have common channel signalling, I don’t know how the SS7 CLEAR and Re-ANSWER events are mapped into QSIG, or ISDN type signalling. It is possible that they are not.

The pots interface is the pt pstn with a gateway to the sip network provider

I tried sip set debug on, and didn’t see any event when pressing the hook button. When you say kernel driver level, how can i do it?
I think too, that the first step is to know if the hangup signal from a pots phone reaches the asterisk system. But I really don’t know how to do it…

Thks David for you help

If the PSTN interface is outside your system, the point about device drivers isn’t relevant.

I think the nearest in SIP to CLEAR and Re-ANSWER is holding and unholding. If you are not hearing music on hold, those events are probably not being presented. If they are presented, you should be able to see re-invite’s in the SIP history for the call, or by using “sip set debug on”.

If you are getting hold, it may be possible to monitor the channel state for this, but that would require some research.

I suspect the solution to your problem may require changes in the gateway configuration, that may or may not be possible.