Summary:ASTERISK-00594: callerID generated by asterisk don't work on telephons released for France.
Reporter:vmeyer (vmeyer)Labels:
Date Opened:2003-11-29 12:13:49.000-0600Date Closed:2011-06-07 14:05:13
Versions:Frequency of
Environment:Attachments:( 0) 242v2p3.pdf
( 1) patchAstFskV23.diff
( 2) patchZapFskV23.diff
Description:I recently bought siemens gigaset telphons in France.
CallerID works well when connected on PSTN but definitivly not behind an asterisk PABX.
Several tests with other devices too convinced me that asterisk uses US callerID protocol. Not surpising of course.
It appears that the differences between french (V23) and US (Bell) calleID is small, only matter of fequency :

Receiver FSK         Min.   Typ.   Max.    Unit.
Transmission Rate    1188   1200   1212    Baud
V23 Mark (1)         1280   1300   1320    Hz
V23 Space (0)        2068   2100   2132    Hz
Bell202 Mark (1)     1188   1200   1212    Hz
Bell202 Space (0)    2178   2200   2222    Hz.


Asterisk perfectly recognises callerID from french PSTN and correctly report it on a SIP phone.

I tryed modifying conbinations of
callerid.c :
#define CALLERID_SPACE  2100.0          /* 2200 hz for "0" */
#define CALLERID_MARK   1300.0          /* 1200 hz for "1" */

and fskmodem.c :
#define NF      4
#define FLIST {1400,1800,1300,2100}

with no success.
Comments:By: Brian West (bkw918) 2003-11-30 11:28:40.000-0600

Can you give us some more details on your setup?  What cards do you have.... and such.

By: vmeyer (vmeyer) 2003-11-30 14:06:29.000-0600

> Can you give us some more details on your setup? What cards do you have.... and such.

Cards: two Wildcard TDM400P (rev. E) cards from digium fitted with 4 fxs modules each.
(and 2 Wildcard X100P too).

By: Julien Lesaint (jlesaint) 2003-11-30 16:31:27.000-0600

Useful information here (official French CID service specifications):

By: ericbart (ericbart) 2004-03-09 16:38:11.000-0600

Got it. There are several things.

A- According to a european document called "TBR 21", the frequency
of the ringing current has to be 50Hz (or 25 Hz). A 50 Volt
DC voltage offset should be applied. See the zaptel patch.
Whithout this patch my modem would not detect the incoming call.
However, with it it would still not see the caller id.

B- In France (and probably in all Europe), an alerting signal is
sent just before the CID. A short ring signal may be used for AS.
This short ring is called Ring Pulse Alert Signal (RP-AS). From a
document called ETSI EN 300 659-1 V1.3.1 (2001), timings are :
(1) 200ms < RP-AS duration < 300ms
(2) 500ms < RP-AS to FSK pulse < 800ms
(3) 200ms < FSK pulse to second ring < 500ms

The Asterisk problem is to guarantee these timings.

(1) The bug comes from the first timing. I tested it with a
custom ring cadence for the TDM400P. To test it yourself,
use the Ast patch and use the dial command with resource

(2) I first tried to solve the bug by adjusting the second
timing. Now I don't know wether it's neccessary or not.
It's implemented in the Ast patch with a simple counter.

(3) I did not try to deal with the third one.

C- The V23 and the Bell202 frequency differences. I changed
them. It works fine. But the modem and the phone I have will
accept either V23 or Bell202.
applied. See the zaptel patch.
Whithout this patch my modem would not detect the inc

There's an Hayes command for changing the country : AT*NCxx
where xx is the country code, 05 for France, 22 for USA, ...
Here's a list of codes :

With my Olitec modem and patches applied, every settable
countries were able to detect the CID, including USA, UK
and Russia. Without, only USA was OK.

By: ericbart (ericbart) 2004-03-10 13:09:24.000-0600

With a loop test, I saw that the TDM400P was not able to trigger an
answer from the X101P.

TBR 21 allows either 25Hz or 50Hz. With 25 Hz everything work :
Modem, Phone and X101P. I still have some problems with a cheap phone,
it don't detect every time the CID, I don't know why, maybe Asterisk
should not compress the CID spill why sending it to the Si3210 chip.
There's jitter in the amplitude of the output decompressed spill.
Compression is good for audio but not for electronic signals.
I also removed the DC offset, no use, and maybe it's not really
set on the line, can't verify it.

So the new wcfxs.c ind regs would be :
{20,"RING_OSC",0x7E6C},  // 25 Hz as of TBR 21
{21,"RING_X",0x023A},  // 85 Vpk = 30 Vrms (calculation @ 25Hz)

Oh yes, as said above I also changed fskmodem.c :
#define FLIST {1400,1800,1300,2100}

I found this required by the X100P for decoding the CID.

By: timrobinson (timrobinson) 2004-03-11 08:48:24.000-0600

I have also attached the UK caller ID specification which can be located at the BT http://www.sinet.bt.com web site.  This uses V23 signalling but sends the caller ID info BEFORE the first ring.  It also specifies the implementation for caller ID with call waiting.  Hope this is of help - would like to get my X100P working here in the UK with caller ID!

By: ericbart (ericbart) 2004-03-11 15:17:56.000-0600

It seems that the UK use a different alerting signal : line reversal +
special DTMF tone. It should be possible to create this AS with the
Si3210 chip.

By: vmeyer (vmeyer) 2004-04-10 06:13:58

Considering Eric'work (thanks) I tried to implement AS.

I didn't apply zaptel patch.
After applying asterisk patch none of my phones recognized CID any more ! (With Zap/X or Zap/Xr4).
I first removed the counter and CID worked well on all phones (At least with AS simulation with Zap/Xr4).
Just the siemens phone that seems to be very sensible to ring duration thought that each ring was a separate call.
According to ring duration in indications.conf I corrected channels/chan_zap.conf by remplacing { 250, 3000, 1000, 4000, ... } by { 250, 3000, 1500, 3500, ...}. Now evrything works well for me.

I tried to implement that directly in indication.conf but with no success.

By: twisted (twisted) 2004-05-02 23:37:10

So is there a patch for zaptel which will make this work correctly?  Or even an update on this?

By: twisted (twisted) 2004-06-16 23:18:30

Closed due to inactivity/failure to simply respond to request for further information.