Hello everyone,
To revive an old payphone for hobbistic purposes, I have the need to make Asterisk perform something I not ever heard about.
I have the need, during an established call (so during the application dial is running) to make Asterisk reverse the line polarity.
The line polarity was indeed an issue, there’s no application performing this service, besides Asterisk supports battery-reversal signalinig.
Starting from that I managed to build a simple Asterisk application called polaity that can be issued from dialplan to reverse polarity of a given dahdi fxs.
After achieved this objective, I’m facing another which can lead to even more difficulties, reverse the polarity during the application dial run.
I though it could be done easily using chan local.
Many examples show how chan local can be used to do things in a multithread fashion.
But I learnt at myself expenses that this multithread ends as soon as a dial connects.
Does anyone have any workaround to make run chan local threads after a dial connects, or the only solution to my issue is to add a flag to applicatio dial to make IT reverse polarity during its execution?
The G option in dial can be used to run dialplan on the incoming leg at the point the outgoing leg answer. You use Bridge to complete the call.
However, if you want to do this at the point of answer, that is normal answer supervision, and is still in use. Does Asterisk not support this on FXS interfaces, or is there some reason why you have to, prematurely, answer the incoming call?
Thanks for your precious advice.
The polarity reversal has its reason to send the billing events to the payphone.
One of the bill events is indeed at the connection. But after the connection during the call, others need to be issued. This part is the one that make me struggling.
The G option which I don’t considered, basically because my lack of knowledge, seems to be useful to my goal. From Asterisk wiki: "If the call is answered, transfer the calling party to the specified priority and the called party to the specified priority plus one. ".
But then I have a question: does it let dialplan keep run while dial is running? If yes, that’s my solution. I can arrange a wait - polarity dialplan sequence to simulate billing events to the payphone.
I ask that instead try it myself because I can’t do it before tomorrow.
Thanks again for your help.
So it seems that if I want to do something during the dial, there’s no way but make dial do it.
I also considered the use an AGI script, but unless some other evidences, I found that when Asterisk starts, it lock the DAHDI devices, so I cannot use fxstest shell command to send polarity reversal commands to the FXS.
I’d like not to modify dial, it is very complicated function, modifications might lead some other disfunctions, so I’d rather not do it.
Any other suggestion would be very appreciated.
AC
Hi acarminati, had you got this implemented already? I am in the exact situation requiring to generate a polarity reversal in the execution of a dialplan or somewhere in the progress of answering incoming call on a FXS port. Can you share your solution with me? Thank you.
Actions on answer are relatively easy, and one method has already been described. His problem was doing them at timed intervals mid-call. Are you sure that Asterisk doesn’t have this facility already. It certainly has the converse, i.e. detect reversal as an indication of answer.
You will need his custom application if you have to do it from the dialplan.
I have been searching sometime and there is none existing commands/facilities that can trigger polarity events. Any idea or concrete examples? I can feel my boss is starting impatient and I am so desperate now.
; Use a polarity reversal to mark when a outgoing call is answered by the
; remote party.
;
;answeronpolarityswitch=yes
doesn’t work for FXS lines, and the original poster doesn’t volunteer his code, you will need to hire a programmer, for which you want the Biz and Jobs forum, although most people there don’t do C code, which will be needed.
In any case, I would suggest a new thread, as this thread is not about you problem, which had already been solved by the original poster, albeit by writing his own C code.