Summary:	ASTERISK-03776: [patch] Sending Polarity/DTMF Caller ID in chan_zap
Reporter:	staffanu (staffanu)	Labels:
Date Opened:	2005-03-26 08:42:23.000-0600	Date Closed:	2011-06-07 14:04:49
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) diff-dtmf-cid-transmit-chan_zap.c ( 1) zaptel-1.0.7-polrev.patch ( 2) zaptel-1.0.7-polrev-2.patch
Description:	In Sweden and some other countries Caller ID is sent using DTMF signalling after a polarity switch, but before the first ring.  Asterisk can currently interpret a caller id sent in this way, but is unable to transmit caller id in this way on an fxs interface. ****** ADDITIONAL INFORMATION ****** I did play around with the chan_zap.c source code a bit, but I feel I really do not know what I'm doing here.  The included patch is what I came up with, but it doesn't really work.  On one of my analog phones (a Siemens DECT phone), I get the correct caller id about half of the time. I tried just going off-hook before starting to send DTMF digits to the handset, and was hoping that would be interpreted as a polarity switch.  I don't even know if my hardware (TDM400) is even capable of reversing polarity? Also, to get this working at all, I needed to use loopstart signalling (the hook is put back on before actually ringing, and I guess the hang-up procedure in kewlstart makes the phone forget it just received a caller id?)
Comments:	By: Mark Spencer (markster) 2005-03-26 09:29:38.000-0600 It is capable of reversing polarity.  I can modify the driver to support that! By: staffanu (staffanu) 2005-03-26 10:26:59.000-0600 That would be great! By: riddles (riddles) 2005-04-21 01:45:19 I would really love to see this working.  As soon as the driver supports the polarity reversal, I will work with you on getting this to work (testing, coding, etc.) By: petersv (petersv) 2005-04-22 01:51:34 Please note the correct polarity reversal sequence for Sweden and other European countries (idle is one polarity, comm is the reverse):  idle  reverse to comm  wait 180-1000ms  send cid  reverse to idle  wait 80-900ms  send ring signals after the call is answered, the polarity is reversed to comm and remain in comm until the call is cleared. See http://www.skanova.se/apps/file.asp?Path=2&ID=560&File=1%2D1551%2DLZBA+505+457+revB%5B1%5D.pdf for a precise description. Sweden uses loopstart with polarity reversal signalling of display services (cid), remote answer and remote disconnect. edited on: 04-22-05 01:53 By: riddles (riddles) 2005-05-17 04:35:37 I noticed that Mark just checked the changes for the driver into CVS a couple of days ago.  The attached file works against the 1.0.7 release (though I haven't tested it yet, the patch seems simple enough). I will see if I can get the above to work now with polarity reversal. By: riddles (riddles) 2005-05-17 06:00:46 I just noticed that the driver now has a ZT_SETPOLARITY that I can set to either forward or reverse.  The problem with that is that there's no way to determine the current polarity state (it is undetermined).  You need to reverse polarity, regardless of what the current polarity is.  I can't figure out from the driver source how to do that. By: staffanu (staffanu) 2005-05-17 06:07:56 Since this is an fxs interface, isn't it all up to the application what the current state is?  My guess would be that, if we haven't set reverse polarity before, the interface will have normal polarity...  Do I miss something obvious? By: petersv (petersv) 2005-05-17 06:23:02 Are you sure you actually want to reverse polarity ant not just set it to either "idle" och "comm"? Have you double-checked with your pstn specification? At least for Sweden the two states have distinct meaning in themselves, not the reversals. By: riddles (riddles) 2005-05-17 06:55:52 I have checked the KPN (Dutch) specification here: http://bugs.digium.com/file_download.php?file_id=2289&type=bug. Quote: "The seizure of the line is signalled to the TE by reversing the polarity of the feeding voltage (SEIZ-IS). The idle (I) polarity of the feeding voltage of an SLT is not uniquely defined; the I- polarity may be 'a-wire positive or negative with respect to b-wire'." In the zaptel.h, I can see that ZT_SETPOLARITY can set the polarity to either forward ro reverse.  But I guess it is up to us; I will test this tonight with doing polarity reversal first, sending CLIP and setting polarity forward. By: petersv (petersv) 2005-05-17 07:12:57 Yes, the polarities are not fixed over time - the net end is allowed to reverse it. During a call the polarities are fixed, one polarity means "idle" and the other "comm". If the net end (asterisk in this case) decides to change which physical polarity is "idle" the cpe end will see a spurious polarity change with no cid spill, time out and reset itself to the new polarity as idle. All the complexity is in the cpe end. When asterisk is the net end of a line it can choose one specific polarity to be "idle" and the other to be "comm" and use them consistently. By: riddles (riddles) 2005-05-24 05:54:32 Well, I have done quite a bit of testing, but I cannot get this to work.  I wrote a small cliptest.c (copy of the patched fxstest.c + the code from the first patch above), but I cannot get a callerid on my phone.   I hope someone else can fix this.  I am very willing to test a fix. By: staffanu (staffanu) 2005-05-24 19:45:04 I've done some testing also, without results. The polarity reversal seems to be working, since my old analog phone makes a tick noise, just like it does when connected to the POTS line, before the caller id is transmitted. However, again comparing to the old telephone: if I get a call, and answer it when I hear the tick (the initial polarity reversal), I can hear DTMF tones as they are transmitted.  When trying the same when Asterisk is trying to send the caller id, I hear absolutely nothing.  OTOH, maybe that only shows that Asterisk detects that I lift the handset, since it connects the call at that point. By: Michael Jerris (mikej) 2005-06-19 12:38:18 Is there any update on this?  Also, if you want this in the tree, please try to keep your primary development against head (bug fixes against stable are of course always welcome) By: Michael Jerris (mikej) 2005-06-27 22:34:38 Closed due to no response.  If somone would like to take this on, please re-open with status updates.