[Home]

Summary:ASTERISK-06507: [patch] Fix for CallerID on Indian PSTN
Reporter:Abhishek Tiwari (abhi)Labels:
Date Opened:2006-03-08 16:50:11.000-0600Date Closed:2008-02-25 14:49:47.000-0600
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Channels/chan_zap
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) chan_zap.c.diff
( 1) diff.chan_zap.c.polarity
( 2) diff.chan_zap.c.ring
Description:The default asterisk does not detect the caller id in India. Its a DTMF based system here, where the caller id is sent after the first ring (this as per tests on the second biggest provider Bharti, still go to test with VSNL, will update about the same).

Using certain minor changes, could get it working in both the modes. (polarity and ring), though the polarity mode is more of a hack (since we initialize the state of the channel with AST_STATE_PRERING rather than AST_STATE_RING and get the digits). Basically we needed to do dtmf detection which is done only in PRERING state, so either we could initialize the state with PRERING (wrong way), or do the detection in RING state (aftert the first ring) as well.

  For the polarity mode, chan_zap.c diff is  diff.chan_zap.c.polarity.

  For the start of caller id on ring, the present chan_zap.c code detects the caller id only in bell202 mode. After adding the part to do dtmf detection, this work, though had to make a hack there to make it stop CID detection when we receive ZT_EVENT_RINGBEGIN (also this event is not handled in zt_handle_event). attached diff.chan_zap.c.ring is for the same.
Comments:By: Serge Vecher (serge-v) 2006-05-01 15:34:08

Can anybody else in India confirm that this patch works?
By: Mitul Limbani (enterux) 2006-05-27 07:50:35

Shall check out this patch in couple of days and post the findings.
By: Jason Parker (jparker) 2006-05-28 01:11:42

The formatting is a little broken near the end.
By: Mitul Limbani (enterux) 2006-05-28 07:34:05

Third hunk for ring patch is on line 6178 instead of 6138
Patch for polarity starts from line 6359 instead of 6315


By: Serge Vecher (serge-v) 2006-05-30 08:33:51

enterux:

1) Did the patch work as expected? If yes:
2) can you please upload the new patch with both changes combined?
3) Get a disclaimer on file, please.

Thank you.
By: Mitul Limbani (enterux) 2006-05-30 13:29:46

May 31 08:06:45 NOTICE[1609]: chan_zap.c:6103 ss_thread: Got event 18 (Ring Begin)...
May 31 08:06:45 NOTICE[1609]: chan_zap.c:6103 ss_thread: Got event 2 (Ring/Answered)...
May 31 08:06:45 NOTICE[1609]: chan_zap.c:6103 ss_thread: Got event 18 (Ring Begin)...
May 31 08:06:45 NOTICE[1609]: chan_zap.c:6103 ss_thread: Got event 2 (Ring/Answered)...
May 31 08:06:47 NOTICE[1609]: callerid.c:322 callerid_feed: Caller*ID failed checksum

Can any one suggest what could be th issue ?

Thanks.
By: Mitul Limbani (enterux) 2006-06-21 04:13:25

Hello,

It seems to have some issues.
here is my output.
----------------------------------------------------------------------------------
Jun 21 14:40:09 NOTICE[7908]: chan_zap.c:6102 ss_thread: Got event 18 (Ring Begin)...
Jun 21 14:40:09 NOTICE[7908]: chan_zap.c:6102 ss_thread: Got event 2 (Ring/Answered)...
Jun 21 14:40:16 WARNING[7908]: chan_zap.c:6176 ss_thread: CallerID returned with error on channel 'Zap/1-1'
----------------------------------------------------------------------------------

Regards,
Mitul
By: Serge Vecher (serge-v) 2006-06-21 09:14:23

anybody capable of fixing the patch up?
By: Serge Vecher (serge-v) 2006-07-07 15:35:10

ok, I guess abhi has lost interest in this patch and nobody else want to fix it. If anybody is willing to work on this further, please get a hold of one of the bug marshalls on #asterisk-bugs channel on IRC and request this bug to be open.

thanks.
By: Joshua C. Colp (jcolp) 2006-10-16 15:29:41

Reopened per request of 'abhtiw' on #asterisk-bugs.
By: Abhishek Tiwari (abhi) 2006-10-16 15:34:05

Finally we got the BSNL line up, and I could test the callerid on this too. Using asterisk 1.4 beta2, had to make the same patch to get the callerid working here too.
   As per the existing chan_zap.c code, the DTMF callerid detection is
done only in Polarity mode in the state PRERING. To get the DTMF
detecion in RING state, had to add the same code which does the
detection in POLARITY (plus/minus a couple of lines which stop the
detection). The patch for chan_zap.c (asterisk 1.4 beta2) is attached. Relevant part of zapata.conf is included below. The output on asterisk console is also below.


========= from zapata.conf ============
signalling=fxs_ks
usecallerid=yes
cidsignalling=dtmf
cidstart=ring
hidecallerid=no
callerid=asreceived
group=1
channel => 4

========= Asterisk Console ============
[Oct 13 19:48:15] DEBUG[23678]: chan_zap.c:6919 do_monitor: Monitor
doohicky got event Ring Begin on channel 4
[Oct 13 19:48:16] DEBUG[23678]: chan_zap.c:6919 do_monitor: Monitor
doohicky got event Ring/Answered on channel 4
[Oct 13 19:48:16] DEBUG[23688]: chan_zap.c:6308 ss_thread: Receiving
DTMF cid on channel Zap/4-1
[Oct 13 19:48:16] DEBUG[23689]: app_queue.c:536 changethread: Device
'Zap/4' changed to state '2' (In use) but we don't care because they're
not a member of any queue.
[Oct 13 19:48:16] DEBUG[23688]: chan_zap.c:4805 zt_read: DTMF digit: 1
on Zap/4-1
[Oct 13 19:48:16] DEBUG[23688]: chan_zap.c:6324 ss_thread: CID got digit '1'
[Oct 13 19:48:16] DEBUG[23688]: chan_zap.c:4805 zt_read: DTMF digit: 2
on Zap/4-1
[Oct 13 19:48:16] DEBUG[23688]: chan_zap.c:4805 zt_read: DTMF digit: 4
on Zap/4-1
[Oct 13 19:48:16] DEBUG[23688]: chan_zap.c:6324 ss_thread: CID got digit '2'
[Oct 13 19:48:16] DEBUG[23688]: chan_zap.c:4805 zt_read: DTMF digit: 4
on Zap/4-1
[Oct 13 19:48:16] DEBUG[23688]: chan_zap.c:6324 ss_thread: CID got digit '4'
[Oct 13 19:48:16] DEBUG[23688]: chan_zap.c:4805 zt_read: DTMF digit: 0
on Zap/4-1
[Oct 13 19:48:16] DEBUG[23688]: chan_zap.c:6324 ss_thread: CID got digit '4'
[Oct 13 19:48:16] DEBUG[23688]: chan_zap.c:4805 zt_read: DTMF digit: 3
on Zap/4-1
[Oct 13 19:48:17] DEBUG[23688]: chan_zap.c:4805 zt_read: DTMF digit: 9
on Zap/4-1
[Oct 13 19:48:17] DEBUG[23688]: chan_zap.c:6324 ss_thread: CID got digit '0'
[Oct 13 19:48:17] DEBUG[23688]: chan_zap.c:4805 zt_read: DTMF digit: 9
on Zap/4-1
[Oct 13 19:48:17] DEBUG[23688]: chan_zap.c:6324 ss_thread: CID got digit '3'
[Oct 13 19:48:17] DEBUG[23688]: chan_zap.c:4805 zt_read: DTMF digit: 1
on Zap/4-1
[Oct 13 19:48:17] DEBUG[23688]: chan_zap.c:6324 ss_thread: CID got digit '9'
[Oct 13 19:48:17] DEBUG[23688]: chan_zap.c:4805 zt_read: DTMF digit: 3
on Zap/4-1
[Oct 13 19:48:17] DEBUG[23688]: chan_zap.c:6324 ss_thread: CID got digit '9'
[Oct 13 19:48:17] DEBUG[23688]: chan_zap.c:6324 ss_thread: CID got digit '1'
[Oct 13 19:48:17] DEBUG[23688]: chan_zap.c:6324 ss_thread: CID got digit '3'
[Oct 13 19:48:17] DEBUG[23688]: chan_zap.c:4508 __zt_exception:
Exception on 11, channel 4
[Oct 13 19:48:17] DEBUG[23688]: chan_zap.c:3632 zt_handle_event: Got
event Ring Begin(18) on channel 4 (index 0)
[Oct 13 19:48:17] DEBUG[23688]: chan_zap.c:6336 ss_thread: CID got
string '1244039913'
[Oct 13 19:48:17] WARNING[23688]: callerid.c:219 callerid_get_dtmf:
Couldn't detect start-character. CID parsing might be unreliable
[Oct 13 19:48:17] DEBUG[23688]: chan_zap.c:6338 ss_thread: CID is
'1244039913', flags 0
[Oct 13 19:48:17] DEBUG[23688]: pbx.c:1767 pbx_extension_helper:
Launching 'Answer'
[Oct 13 19:48:17] DEBUG[23688]: chan_zap.c:2789 zt_answer: Took Zap/4-1
off hook
[Oct 13 19:48:17] DEBUG[23688]: chan_zap.c:1461 zt_enable_ec: No echo
cancellation requested
[Oct 13 19:48:17] DEBUG[23688]: chan_zap.c:1477 zt_train_ec: No echo
training requested
[Oct 13 19:48:17] DEBUG[23688]: pbx.c:1767 pbx_extension_helper:
Launching 'Playback'
[Oct 13 19:48:17] DEBUG[23688]: channel.c:2652 set_format: Set channel
Zap/4-1 to write format gsm
[Oct 13 19:48:17] DEBUG[23688]: channel.c:1859 ast_settimeout:
Scheduling timer at 160 sample intervals
[Oct 13 19:48:17] DEBUG[23690]: app_queue.c:536 changethread: Device
'Zap/4' changed to state '2' (In use) but we don't care because they're
not a member of any queue.
[Oct 13 19:48:45] DEBUG[23688]: channel.c:1859 ast_settimeout:
Scheduling timer at 0 sample intervals
[Oct 13 19:48:45] DEBUG[23688]: channel.c:1859 ast_settimeout:
Scheduling timer at 0 sample intervals
[Oct 13 19:48:45] DEBUG[23688]: channel.c:2652 set_format: Set channel
Zap/4-1 to write format ulaw
[Oct 13 19:48:45] DEBUG[23688]: pbx.c:1767 pbx_extension_helper:
Launching 'Hangup'
[Oct 13 19:48:45] DEBUG[23688]: pbx.c:2363 __ast_pbx_run: Spawn
extension (blahblah,s,3) exited non-zero on 'Zap/4-1'
 == Spawn extension (blahblah, s, 3) exited non-zero on 'Zap/4-1'
[Oct 13 19:48:45] DEBUG[23688]: pbx.c:1767 pbx_extension_helper:
Launching 'Answer'
[Oct 13 19:48:45] DEBUG[23688]: pbx.c:1767 pbx_extension_helper:
Launching 'Playback'
[Oct 13 19:48:45] DEBUG[23688]: channel.c:2652 set_format: Set channel
Zap/4-1 to write format gsm
[Oct 13 19:48:45] DEBUG[23688]: channel.c:1859 ast_settimeout:
Scheduling timer at 160 sample intervals
[Oct 13 19:49:08] DEBUG[23658]: channel.c:1345 ast_softhangup_nolock:
Soft-Hanging up channel 'Zap/4-1'
[Oct 13 19:49:08] DEBUG[23688]: channel.c:1859 ast_settimeout:
Scheduling timer at 0 sample intervals
[Oct 13 19:49:08] DEBUG[23688]: channel.c:2652 set_format: Set channel
Zap/4-1 to write format ulaw
[Oct 13 19:49:08] DEBUG[23688]: pbx.c:2483 __ast_pbx_run: Spawn
extension (blahblah,h,2) exited non-zero on 'Zap/4-1'
 == Spawn extension (blahblah, h, 2) exited non-zero on 'Zap/4-1'
[Oct 13 19:49:08] DEBUG[23688]: pbx.c:1621
pbx_substitute_variables_helper_full: Function result is '1244039913'
[Oct 13 19:49:08] DEBUG[23688]: pbx.c:1621
pbx_substitute_variables_helper_full: Function result is '1244039913'
[Oct 13 19:49:08] DEBUG[23688]: pbx.c:1621
pbx_substitute_variables_helper_full: Function result is 's'
[Oct 13 19:49:08] DEBUG[23688]: pbx.c:1621
pbx_substitute_variables_helper_full: Function result is 'blahblah'
[Oct 13 19:49:08] DEBUG[23688]: pbx.c:1621
pbx_substitute_variables_helper_full: Function result is 'Zap/4-1'
[Oct 13 19:49:08] DEBUG[23688]: pbx.c:1621
pbx_substitute_variables_helper_full: Function result is ''
[Oct 13 19:49:08] DEBUG[23688]: pbx.c:1621
pbx_substitute_variables_helper_full: Function result is 'Playback'
[Oct 13 19:49:08] DEBUG[23688]: pbx.c:1621
pbx_substitute_variables_helper_full: Function result is 'demo-congrats'
[Oct 13 19:49:08] DEBUG[23688]: pbx.c:1621
pbx_substitute_variables_helper_full: Function result is '2006-10-13
19:48:17'
[Oct 13 19:49:08] DEBUG[23688]: pbx.c:1621
pbx_substitute_variables_helper_full: Function result is '2006-10-13
19:48:17'
[Oct 13 19:49:08] DEBUG[23688]: pbx.c:1621
pbx_substitute_variables_helper_full: Function result is '2006-10-13
19:49:08'
[Oct 13 19:49:08] DEBUG[23688]: pbx.c:1621
pbx_substitute_variables_helper_full: Function result is '51'
[Oct 13 19:49:08] DEBUG[23688]: pbx.c:1621
pbx_substitute_variables_helper_full: Function result is '51'
[Oct 13 19:49:08] DEBUG[23688]: pbx.c:1621
pbx_substitute_variables_helper_full: Function result is 'ANSWERED'
[Oct 13 19:49:08] DEBUG[23688]: pbx.c:1621
pbx_substitute_variables_helper_full: Function result is 'DOCUMENTATION'
[Oct 13 19:49:08] DEBUG[23688]: pbx.c:1621
pbx_substitute_variables_helper_full: Function result is ''
[Oct 13 19:49:08] DEBUG[23688]: pbx.c:1621
pbx_substitute_variables_helper_full: Function result is '1160783296.0'
[Oct 13 19:49:08] DEBUG[23688]: pbx.c:1621
pbx_substitute_variables_helper_full: Function result is ''

=======================
By: Mitul Limbani (enterux) 2006-10-16 15:41:08

Hello Abhi,

Can you paste up more of you contact details ?
I am sure that I applied the patch exactly the same way you asked for and also tried the options as mentioned in zapata.conf, but things didnt work out.

Now that I can see you around, can you provide me with your contact details ?
Or can you register on http://asterisk.pbx.in/ thats the Forum where we discuss Indian Asterisk related problems.

Looking forward to hear from you,
Mitul Limbani,
Enterux Solutions,
www.enterux.com
By: Ajay Mittal (akmits) 2006-10-30 22:23:59.000-0600

I tried the patch in Pune India with BSNL connection.
I have Motorola 62802 based 1 port FXO.
lspci-> 01:06.0 Communication controller: Motorola: Unknown device 5608

I still didnt get the caller ID. I added some debug messages in the chan_zap.c
(this is when we are expecting caller_id DTMF frames)
f = ast_read(chan);
ast_log(LOG_WARNING, "Frame type %d\n", f->frametype);

But, the frame types received are not DTMF but voice(2).

I also played with opermode while loading WCFXO module. Did not help much.

Can the original poster post the hardware details. I suspect it is hardware dependent now.
By: Ajay Mittal (akmits) 2006-10-31 07:27:25.000-0600

I was reading the datasheet for a Si3034 DAA and found this
note for caller-ID sent after first ring (like India)

"The Si3034 provides the designer with the ability to
pass caller ID data from the phone line to a caller ID
decoder connected to the serial port.
In systems where the caller ID data is passed on the
phone line between the first and second rings, the
following method should be utilized to capture the caller
ID data. The RDTP and RDTN register bits should be
monitored to determine the completion of the first ring.
After completion of the first ring, the DSP should set th
SQLH bit (Register 18, bit 0) for a period of at least
1 ms. This resets the ac coupling network on the ring
input in preparation for the caller ID data. The SQLH bit
is then cleared, and the ONHM (Register 5, bit 3)
should be asserted to enable the caller ID data to be
passed to the DSP and presented on SDO. This bit
enables a low-power ADC (approximately 450 A is
drawn from the line) that digitizes the signal passed
across the RNG1/2 pins. This signal is passed across
the isolation capacitor link to the DSP. The ONHM bit
should be cleared after the caller ID data is received
and prior to the second ring."


I checked the wcfxo.c and it never sets the SQLH bit.
I am not a kernel driver person; but I tried to create a
state machine to detect first ring and then set/unset the SQLH
and ONHM bit in wcfxo.c. No luck :(
Any help from people who understand wcfxo.c will be greatly
appreciated.
By: Abhishek Tiwari (abhi) 2006-10-31 11:09:02.000-0600

my experiments were based on tdm400p. I was trying with Mitul from mumbai on x100p , but couldnt get this working (also using patches from http://bugs.digium.com/view.php?id=9 and http://bugs.digium.com/view.php?id=1719). Can anyone test this out with tdm400p ?
By: mnaffar (mnaffar) 2006-11-01 06:30:41.000-0600

I have worked with the TDM400p and with TDM2400p and i have used this patch and it seems to work fine.
I have worked with an mtnl as well as bsnl line and seems to work fine.
Applied the patch the way the same way. .
By: Tzafrir Cohen (tzafrir) 2007-02-08 03:25:09.000-0600

Should be moved to "channel drivers", right?

Patch seems to apply to current trunk. (Sorry, I'm having some problems building chan_zap on trunk with all of those tests for latest zaptel).
By: Steve Murphy (murf) 2007-03-09 11:58:46.000-0600

I have been assigned to deal with this request. It's been a long time in the list, and needs to be either thrown away, or put into the trunk. Let's do one or the either. It sounds like this would be a great addition for India, and maybe other countries! So, I will create a branch, and see what might be done to fold this code in a way that will not hurt current users.

If this code is to be included, we will need some quick feedback and testing in India. Digium will not pay to fly me out there, even though I offered! Anybody out there up to the task?

By: Steve Murphy (murf) 2007-03-23 17:44:22

OK, I've been looking over the patches; I'm assuming that only the last of the 3 patches needs to be applied. Am I correct?
By: Mitul Limbani (enterux) 2007-03-24 06:40:19

Hi Murf,

I have tested this code and it seems to be working.
The situation in India is that there are two modes in which callerId is prevailing with different operators.
Some of the old operators are still using cidsignalling = v23 (like MTNL, and some old BSNL Switches) although they have been advertising that they are moving over to DTMF mode of callerID system.

So we have had big trouble figuring that out in our office, where we have both Tata Indicom Landlines and MTNL landlines.

It seems that all the new age Telco Providers are using DTMF mode for callerID hence this code work with cidsignalling = dtmf and cidstart=polarity on TATA and i believe that it should be the same for other new age telco providers.

For MTNL cidsignalling = v23, cidstart=ring works well.

I hope this shall help other people.

Thanks & Regards,
Mitul Limbani,
Founder & CEO,
Enterux Solutions,
The Enterprise Linux Company (R),
http://www.enterux.com/
By: Steve Murphy (murf) 2007-03-24 11:52:25

I have a concern, especially for the polarity patch, where there is no conditional wrapped around the new fix, that if I put this into trunk, then it will break everyone that is not in India.

It would be simple to add a cidstart=polarity_in option, and then   case SIG_SF:
      /* Check for callerid, digits, etc */
-      chan = zt_new(i, AST_STATE_RING, 0, SUB_REAL, 0, 0);
+      if (i->cid_start==CID_START_POLARITY_IN)
+          chan = zt_new(i, AST_STATE_PRERING, 0, SUB_REAL, 0, 0);
+      else
+          chan = zt_new(i, AST_STATE_RING, 0, SUB_REAL, 0, 0);
      if (chan && ast_pthread_create(&threadid, &attr, ss_thread, chan)) {
      ast_log(LOG_WARNING, "Unable to start simple switch thread on channel %d\n", i->channel);
      res = tone_zone_play_tone(i->subs[SUB_REAL].zfd, ZT_TONE_CONGESTION);

(and, of course, everywhere else in the code where CID_START_POLARITY is mentioned, we'd have to add || ... CID_START_POLARITY_IN, also! (which is, luckily, only in 3 places, one of which is setting the variable from the config))

Am I wrong? Is this not the right thing to do?
By: Steve Murphy (murf) 2007-03-27 10:44:19

I just made the changes I suggested to the http://svn.digium.com/svn/asterisk/team/murf/bug6683 branch!

Please test it and see if it will work. It requires you set

cidstart=polarity_IN

in your zapata.conf file. (instead of just cidstart=polarity)

This will hopefully keep from making things difficult for those already using cidstart=polarity, who might see problems if the behavior changes.
By: Steve Murphy (murf) 2007-03-27 10:45:31

If someone will test my changes, and say that they work, I will commit these changes to trunk!


By: Gerald Xaviour (brealer) 2007-04-11 05:07:08

I can test it but I need to know if it is supposed work with the X100P


By: Gerald Xaviour (brealer) 2007-05-03 01:16:47

i have tested it on an X100p and a 4 port fxo card.
with the x100p there is no change (i dont receive the clid infomation)
with the 4 port fxo card, the asterisk console reports:

WARNING[3395]: chan_zap.c:6433 ss_thread: DTMFCID timed out waiting for ring. Exiting simple switch

and the call does not get answered by my IVR

---------------
zapata.conf
---------------

language=en
progzone=in
usecallerid=yes
hidecallerid=no
cidstart=polarity_IN
cidsignalling=dtmf
callerid=asreceived
context=default
signalling=fxs_ks
group => 1
channel => 1-4

---------------
zaptel.conf
---------------

fxsks=1-4
loadzone=in
defaultzone=in


By: Gerald Xaviour (brealer) 2007-05-07 07:02:05

I am willing to keep testing any changes made (if needed on a daily basis). I have a TDM400p with 4 FXO modules and an X100p. I have an 8 MTLN lines at my disposal and have access to any other provider if required.
By: Steve Murphy (murf) 2007-05-07 14:08:43

for MTNL, try cidsignalling = v23, cidstart=ring in zapata.conf, and see if the branch works.
By: Gerald Xaviour (brealer) 2007-05-08 01:49:01

I have tried V23 previously the output was:

chan_zap.c:6744 ss_thread: Got event 18 (Ring Begin)...
chan_zap.c:6744 ss_thread: Got event 2 (Ring/Answered)...
chan_zap.c:6744 ss_thread: Got event 18 (Ring Begin)...
   -- Executing [s@default:1] NoOp("Zap/3-1", "caller ID Number is ") in new stack

----------------------

Extentions.conf

exten => s,1,NoOp(caller ID Number is ${CALLERID(num)})

----------------------
By: Steve Murphy (murf) 2007-05-08 08:49:39

Reviewing the comments (again), it seems that patch didn't hit all the situations that exist in India.

I've updated my bug6683 branch to include some log calls so I can verify that the code I inserted for POLARITY_IN indeed is being called.

Please work thru all the permutations of CIDSTART/POLARITY, and see if ANY combination will catch your situation. Then turn on DEBUG with cli command "core set debug atleast 5" or so just before testing (to avoid tons of unnecc. output), and make sure the console is logging DEBUG (logger.conf or whatever its name is).

Thanks for testing!
By: Gerald Xaviour (brealer) 2007-06-18 06:55:13

i have tested with my new TATA line and it works perfectly well.

i am willing to keep testing if anyone is still interested as i think asterisk should work, and be fully functional in all situations.

   -- Starting simple switch on 'Zap/1-1'
[Jun 18 17:25:03] DEBUG[17591]: chan_zap.c:3854 zt_handle_dtmfup: DTMF digit: X on Zap/1-1
[Jun 18 17:25:03] DEBUG[17591]: chan_zap.c:3854 zt_handle_dtmfup: DTMF digit: X on Zap/1-1
[Jun 18 17:25:03] DEBUG[17591]: chan_zap.c:3854 zt_handle_dtmfup: DTMF digit: X on Zap/1-1
[Jun 18 17:25:03] DEBUG[17591]: chan_zap.c:3854 zt_handle_dtmfup: DTMF digit: X on Zap/1-1
[Jun 18 17:25:03] DEBUG[17591]: chan_zap.c:3854 zt_handle_dtmfup: DTMF digit: X on Zap/1-1
[Jun 18 17:25:03] DEBUG[17591]: chan_zap.c:3854 zt_handle_dtmfup: DTMF digit: X on Zap/1-1
[Jun 18 17:25:03] DEBUG[17591]: chan_zap.c:3854 zt_handle_dtmfup: DTMF digit: X on Zap/1-1
[Jun 18 17:25:03] DEBUG[17591]: chan_zap.c:3854 zt_handle_dtmfup: DTMF digit: X on Zap/1-1
[Jun 18 17:25:03] DEBUG[17591]: chan_zap.c:3854 zt_handle_dtmfup: DTMF digit: X on Zap/1-1
[Jun 18 17:25:04] DEBUG[17591]: chan_zap.c:3854 zt_handle_dtmfup: DTMF digit: X on Zap/1-1
[Jun 18 17:25:04] DEBUG[17591]: chan_zap.c:3854 zt_handle_dtmfup: DTMF digit: X on Zap/1-1
[Jun 18 17:25:05] WARNING[17591]: callerid.c:219 callerid_get_dtmf: Couldn't detect start-character. CID parsing might be unreliable
   -- Executing [s@default:1] NoOp("Zap/1-1", "caller ID Number is XXXXXXXXXXX") in new stack
By: Steve Murphy (murf) 2007-06-18 09:46:26

Reading back thru this bug report, I see situations, where testing was done, but it's not clear to me what was tested!

I'm getting lost in the details here. Let's get organized, make a table, keep it up to date. If the "India Patch" doesn't cover all the carriers in its present state, we need to do a little investigation for the carriers it doesn't work for, and perhaps, if we understand what they are doing that's different, we can write some code to handle the situation, or advise existing options to use, so users aren't wasting a lot of time trying to find the magic combination.

Here goes:

Almost all these need to be re-tested with the http://svn.digium.com/svn/asterisk/team/murf/bug6683 branch I've put together.

---------------------------------------------------------
Provider: Bharti (is this BSNL?)
Config: cidstart=polarity_in
       cidsignalling=dtmf
Results: ? (this should work), but needs to be tested?
tested by:
--------------------------------------------------------

Provider: VSNL
Config:

Results: ?
tested by:
--------------------------------------------------------

Provider: BSNL
Config:  cid_start=ring
        cid_signalling=dtmf

Results: ?
tested by: (abhi)
--------------------------------------------------------

Provider: MTNL, old BSNL
Config: cidsignalling = v23
       cidstart=ring

Results: works
tested by: (enterux)
--------------------------------------------------------

Provider: TATA
Config: cidsignalling = dtmf ?
       cidstart=polarity_IN ?

Results: ?
tested by: (brealer)
---------------------------------------------------------
By: Gerald Xaviour (brealer) 2007-06-19 01:38:38

Provider: TATA
Config: cidsignalling = dtmf
       cidstart=polarity_IN

Results: works
tested by: brealer
By: Gerald Xaviour (brealer) 2007-06-19 08:04:50

Provider: MTNL (Delhi)
Config: cidsignalling = v23
       cidstart = ring

cidsignalling = dtmf
cidstart = polarity_IN

cidsignalling = dtmf
cidstart = polarity

Results: fails
tested by: brealer
By: Steve Murphy (murf) 2007-06-19 12:15:52

Ok, I have committed the submitted patches to trunk via r. 70001.
I have added doc/India-CID.txt, which contains the table I introduced.
I'll leave this bug open a while, and use it to collect updates to the table.

brealer-- Unfortunately, the debug logs are not enough for me to determine
what is happening in MTNL(delhi)'s case. Please, contact MTNL and ask them
for details on how CID works for them. You need to know the signalling,
when it starts, how it starts, etc. The more detail, the better. You may have
to take an engineer out to lunch. Flattery. Bribery. Whatever. With enough
detail, we may either be able to write up code that will handle the situation,
or choose the right existing config options.

Everybody else, please, try the latest trunk release and affirm that the
changes still work. Report results via this bug, and I'll update the table
in doc/India-CID.txt.

Best of luck, everyone!
By: onglipo (onglipo) 2007-09-21 12:15:37

---------------------------------------------------------
Provider: Bharti (is this BSNL?)
Config: cidstart=polarity_in
       cidsignalling=dtmf
Results: ? (this should work), but needs to be tested?
tested by:
--------------------------------------------------------
Ok this works for me on TDM400 P in Bangalore, India

Bharti [http://www.bharti.com/] is NOT BSNL [http://www.bsnl.co.in/index.html]

By the way, My TDM22B does not hangup when caller hangs up, anyone else facing this? signalling=fxs_ks, all country parameters are set to in dia & busydetect=yes

great job folks!
-ongs


By: sivaperumalrajamani (sivaperumal) 2007-12-03 06:15:56.000-0600

this patch working but i am getting wrong caller id some times.but some time working correctly. for example  
my actual id is 9845865391 but i am getting some time 984586539 and  some time getting 98458653911. what is the error please help me ?

my zapata.conf

; Zapata telephony interface
;
; Configuration file

[trunkgroups]

[channels]
context=from-pstn


;context=from-zaptel

busydetect=yes
busycount=10
language=en

; Working 1
cidsignalling=dtmf
cidstart=ring

; working 2
;cidstart=polarity_in
;cidsignalling=dtmf

;not working
;cidsignalling = v23
;cidstart=ring
;cidsignalling=bell
;cidsignalling=dtmf_dk
;cidsignalling=bell,dtmf
;cidsignalling=dtmf_astart,bell
;cidstart=ring
usecallingpres=yes
callwaitingcallerid=yes
threewaycalling=yes
usecallerid=yes
callerid=asreceived
hidecallerid=no
relaxdtmf=yes
signalling=fxs_ks
pulsedial=yes
rxwink=300
answeronpolarityswitch=yes
hanguponpolarityswitch=yes
rxgain=0
txgain=0
group=0
channel=1-4

#include  zapata-channels.conf
#include zapata_additional.conf


thanks in advance


By: rkolli (ramaseshireddy) 2007-12-22 07:14:06.000-0600

Hi everybody i am from india (AP).I have applied above pathes could't get it working. I am using TDM 400P cards 2FXO ports.

When calling from mobile first two digits are missing. Please can anybody help me.
By: rkolli (ramaseshireddy) 2007-12-22 07:19:40.000-0600

CLI> [Dec 22 07:45:57] DEBUG[18074]: chan_zap.c:7369 do_monitor: Monitor doohicky got event Ring Begin on channel 3

[Dec 22 07:45:58] DEBUG[18074]: chan_zap.c:7369 do_monitor: Monitor doohicky got event Ring/Answered on channel 3

[Dec 22 07:45:58] DEBUG[18074]: dsp.c:1663 ast_dsp_set_busy_pattern: dsp busy pattern set to 0,0

[Dec 22 07:45:58] DEBUG[18074]: chan_zap.c:5620 zt_new: ASTERISK-369 If (core) Needs a rethink i = 81c6580, i->rdnis = 81c72b8

   -- Starting simple switch on 'Zap/3-1'
[Dec 22 07:45:58] DEBUG[18074]: chan_zap.c:6366 ss_thread: Early Receiving DTMF  onchannel Zap/3-1

[Dec 22 07:45:58] DEBUG[18074]: chan_zap.c:5078 zt_read: DTMF digit: 4 on Zap/3-1
[Dec 22 07:45:58] DEBUG[18074]: chan_zap.c:6383 ss_thread: Seshi got digit '4'
[Dec 22 07:45:58] DEBUG[18074]: chan_zap.c:5078 zt_read: DTMF digit: 9 on Zap/3-1
[Dec 22 07:45:59] DEBUG[18074]: chan_zap.c:5078 zt_read: DTMF digit: 8 on Zap/3-1
[Dec 22 07:45:59] DEBUG[18074]: chan_zap.c:6383 ss_thread: Seshi got digit '9'
[Dec 22 07:45:59] DEBUG[18074]: chan_zap.c:5078 zt_read: DTMF digit: 7 on Zap/3-1
[Dec 22 07:45:59] DEBUG[18074]: chan_zap.c:6383 ss_thread: Seshi got digit '8'
[Dec 22 07:45:59] DEBUG[18074]: chan_zap.c:5078 zt_read: DTMF digit: 5 on Zap/3-1
[Dec 22 07:45:59] DEBUG[18074]: chan_zap.c:6383 ss_thread: Seshi got digit '7'
[Dec 22 07:45:59] DEBUG[18074]: chan_zap.c:5078 zt_read: DTMF digit: 0 on Zap/3-1
[Dec 22 07:45:59] DEBUG[18074]: chan_zap.c:6383 ss_thread: Seshi got digit '5'
[Dec 22 07:45:59] DEBUG[18074]: chan_zap.c:5078 zt_read: DTMF digit: 6 on Zap/3-1
[Dec 22 07:45:59] DEBUG[18074]: chan_zap.c:5078 zt_read: DTMF digit: 4 on Zap/3-1
[Dec 22 07:45:59] DEBUG[18074]: chan_zap.c:6383 ss_thread: Seshi got digit '0'
[Dec 22 07:45:59] DEBUG[18074]: chan_zap.c:6383 ss_thread: Seshi got digit '6'
[Dec 22 07:45:59] DEBUG[18074]: chan_zap.c:6383 ss_thread: Seshi got digit '4'
[Dec 22 07:46:00] DEBUG[18074]: chan_zap.c:4774 __zt_exception: Exception on 9, channel 3
[Dec 22 07:46:00] DEBUG[18074]: chan_zap.c:3864 zt_handle_event: Got event Ring Begin(18) on channel 3 (index 0)
[Dec 22 07:46:00] DEBUG[18074]: chan_zap.c:4774 __zt_exception: Exception on 9, channel 3
[Dec 22 07:46:00] DEBUG[18074]: chan_zap.c:3864 zt_handle_event: Got event Ring/Answered(2) on channel 3 (index 0)
[Dec 22 07:46:00] DEBUG[18074]: chan_zap.c:4247 zt_handle_event: Setting IDLE polarity due to ring. Old polarity was 0
[Dec 22 07:46:00] DEBUG[18074]: chan_zap.c:4272 zt_handle_event: Ring detected
[Dec 22 07:46:00] DEBUG[18074]: chan_zap.c:6395 ss_thread: seshi got string '49875064'

[Dec 22 07:46:00] DEBUG[18074]: chan_zap.c:6398 ss_thread: seshi is '49875064', flags 0

[Dec 22 07:46:00] DEBUG[18074]: pbx.c:1699 pbx_extension_helper: Launching 'Set'
   -- Executing [s@from-pstn:1] Set("Zap/3-1", "user=9000") in new stack
[Dec 22 07:46:00] DEBUG[18074]: pbx.c:1543 pbx_substitute_variables_helper_full: Function result is '49875064'
[Dec 22 07:46:00] DEBUG[18074]: pbx.c:1699 pbx_extension_helper: Launching 'NoOp'
   -- Executing [s@from-pstn:2] NoOp("Zap/3-1", "caller ID Number is 49875064") in new stack
[Dec 22 07:46:00] DEBUG[18074]: pbx.c:1699 pbx_extension_helper: Launching 'Macro'
   -- Executing [s@from-pstn:3] Macro("Zap/3-1", "PSTN|9000|1") in new stack






Actually my mobile number is 9949875064 but it is displaying 49875064.
I am using Bharati (AIRTEL) service provide line.

And another thing is that it is not displaying STD CODE for incoming calls.
i have used following configurations.



;;; line="3 WCTDM/0/2 FXSKS (In use)"
signalling=fxs_ks
usecallerid=yes
cidsignalling=dtmf
cidstart=polarity_in
;relaxdtmf=yes
;rxwink=300
;pulsedial=yes
;answeronpolarityswitch=yes
;hanguponpolarityswitch=yes
callerid=asreceived
group=0
context=from-pstn
channel => 3
context=default

;;; line="4 WCTDM/0/3 FXSKS (In use)"
signalling=fxs_ks
usecallerid=yes
cidsignalling=dtmf
cidstart=polarity
callerid=asreceived
group=0
context=from-pstn
channel => 4
context=default
By: rkolli (ramaseshireddy) 2007-12-22 07:26:27.000-0600

Can anybody please help how to get first digits including STD code.

I think in the zaptel drivers we have to change some code.

I guess for AIRTEL callerid is sent after first ring.So what is happening in my case is that by that time control comes to ss_thread function  in chan_zap.c it is missing some bunch of first numbers.

Mr Murf can you please help in this aspect.

Thanks.
By: mnaffar (mnaffar) 2007-12-25 23:03:50.000-0600

Hi ramaseshireddy

I have modified the chan_zap.c in asterisk 1.2.17 to receive caller id on airtel.

Its a dirty bit of code(hack) but it works fine. I can send that to you. Give me ur id.
By: rkolli (ramaseshireddy) 2007-12-26 06:23:24.000-0600

Hi

My Gtalk id is ramaseshireddy@gmail.com or ramaseshi@gmail.com

Thank Mr.mnaffar

I Look forward to get mail from you.
By: Steve Murphy (murf) 2007-12-27 12:24:10.000-0600

mnaffar --

Please, attach your code to this bug... you may have to do the license-agreement thing in this site first... but it sounds like it might be of general use for folks in India. I'll see if I can work it into the code base somehow...
By: Tilghman Lesher (tilghman) 2008-02-04 11:47:21.000-0600

Any progress on this?
By: jmls (jmls) 2008-02-17 12:57:33.000-0600

urm, ping ....
By: Steve Murphy (murf) 2008-02-25 14:49:45.000-0600

OK, this bug is so old, it appears in the top ten "old, unsolved bugs" list. The original issue has been solved, and the patch applied to trunk last June. It's in the 1.6 alpha. Any new similar issues that come up can be presented in a new bug.
Getting Asterisk to be configurable for all the environments in India will probably take a long time!